4.4. Virtual Directory Information Tree Views

Directory Server supports a concept for hierarchical navigation and organization of directory information called virtual directory information tree views or virtual DIT views.

Note

Virtual views are not entirely compatible with multiple back ends in that the entries to be returned by the views must reside in the same back end; the search is limited to one back end.

4.4.1. About Virtual DIT Views

There are two ways to configure the directory namespace:
  • A hierarchical directory information tree.
  • A flat directory information tree.
The hierarchical DIT is useful for navigating the directory but is cumbersome and time-consuming to change. A major organizational change to a hierarchical DIT can be an expensive and time-consuming operation, because it usually involves considerable service disruption. This can usually only be minimized by performing changes after hours and during periods of low traffic.
The flat DIT, while requiring little to no change, does not provide a convenient way to navigate or manage the entries in the directory service. A flat DIT also presents many management challenges as administration becomes more complex without any natural hierarchical groupings.
Examples of a Flat and an Organizationally-Based DIT

Figure 4.14. Examples of a Flat and an Organizationally-Based DIT

Using a hierarchical DIT, a deployment must then determine the subject domain of the hierarchy. Only one choice can be made; the natural tendency is to choose the organizational hierarchy.
This view of the organization serves well in many cases, but having only a single view can be very limiting for directory navigation and management. For example, an organizational hierarchy is fine for looking for entries that belong to people in the Accounts department. However, this view is much less useful for finding entries that belong to people in a geographical location, such as Mountain View, California. The second query is as valid as the first, yet it requires knowledge of the attributes contained in the entries and additional search tools. For such a case, navigation using the DIT is not an option.
Similarly, management of the directory is much easier when the DIT matches the requirements of the management function. The organization of the DIT may also be affected by other factors, such as replication and migration considerations, that cause the DIT to have functional utility for those applications but very little practical utility in other cases.
Clearly, hierarchies are a useful mechanism for navigation and management. To avoid the burden of making changes to an existing DIT, however, a deployment may elect to forgo a hierarchy altogether in favor of a flat DIT.
It would be advantageous for deployments if the directory provided a way to create an arbitrary number of hierarchies that get mapped to entries without having to move the target entries in question. The virtual DIT views feature of Directory Server resolves the quandary of deciding the type of DIT to use for the directory deployment.
Virtual DIT views provide a way to hierarchically navigate entries without the requirement that those entries physically exist in any particular place. The virtual DIT view uses information about the entries to place them in the view hierarchy. To client applications, virtual DIT views appear as ordinary container hierarchies. In a sense, virtual DIT views superimpose a DIT hierarchy over a set of entries, irrespective of whether those entries are in a flat namespace or in another hierarchy of their own.
Create a virtual DIT view hierarchy in the same way as a normal DIT hierarchy. Create the same entries (for example, organizational unit entries) but with an additional object class (nsview) and a filter attribute (nsviewfilter) that describes the view. After adding the additional attribute, the entries that match the view filter instantly populate the view. The target entries only appear to exist in the view; their true location never changes. Virtual DIT views behave like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned.
For information about adding and modifying entries, see "Creating Directory Entries" in the Red Hat Directory Server Administration Guide
A Combined DIT Using Views

Figure 4.15. A Combined DIT Using Views

The DIT Figure 4.15, “A Combined DIT Using Views” in illustrates what happens when the two DITs shown in Figure 4.14, “Examples of a Flat and an Organizationally-Based DIT” are combined using views. Because views inherently allow entries to appear in more than one place in a view hierarchy, this feature has been used to expand the ou=Sales entry to enable viewing the Sales entries either by location or by product.
Given a set of virtual DIT view hierarchies, a directory user can use the view that makes the most sense to navigate to the required entries. For example, if the target entries were those who live in Mountain View, a view which begins by navigating using location-based information is most appropriate. If it were an organizational question, the organization view would be a better choice. Both of these views exist in the Directory Server at the same time and operate on the same entries; the different views just have different objectives when displaying their version of the directory structure.
The entries in the views-enabled directory in Figure 4.15, “A Combined DIT Using Views” are contained in a flat namespace just below the parent of the top-most view in the hierarchy. This is not required. The entries can exist in a hierarchy of their own. The only concern that a view has about the placement of an entry is that it must be a descendant of the parent of the view hierarchy.
A DIT with a Virtual DIT View Hierarchy

Figure 4.16. A DIT with a Virtual DIT View Hierarchy

  • The sub-tree ou=People contains the real Entry A and Entry B entries.
  • The sub-tree ou=Location Views is a view hierarchy.
  • The leaf nodes ou=Sunnyvale and ou=Mountain View each contain an attribute, nsviewfilter, which describes the view.
    These are leaf nodes because they do not contain the real entries. However, when a client application searches these views, it finds Entry A under ou=Sunnyvale and Entry B under ou=Mountain View. This virtual search space is described by the nsviewfilter attributes of all ancestor views. A search made from a view returns both entries from the virtual search space and those from the actual search space. This enables the view hierarchies to function as a conventional DIT or change a conventional DIT into a view hierarchy.

4.4.2. Advantages of Using Virtual DIT Views

The deployment decisions become easier with virtual DIT views because:
  • Views facilitate the use of a flat namespace for entries, because virtual DIT views provide navigational and managerial support similar to those provided by traditional hierarchies.
    In addition, whenever there is a change to the DIT, the entries never need to be moved; only the virtual DIT view hierarchies change. Because these hierarchies contain no real entries, they are simple and quick to modify.
  • Oversights during deployment planning are less catastrophic with virtual DIT views. If the hierarchy is not developed correctly in the first instance, it can be changed easily and quickly without disrupting the service.
  • View hierarchies can be completely revised in minutes and the results instantly realized, significantly reducing the cost of directory maintenance.
    Changes to a virtual DIT hierarchy are instantly realized. When an organizational change occurs, a new virtual DIT view can be created quickly. The new virtual DIT view can exist at the same time as the old view, thereby facilitating a more gradual changeover for the entries themselves and for the applications that use them. Because an organizational change in the directory is not an all-or-nothing operation, it can be performed over a period of time and without service disruption.
  • Using multiple virtual DIT views for navigation and management allows for more flexible use of the directory service.
    With the functionality provided by virtual DIT views, an organization can use both the old and new methods to organize directory data without any requirement to place entries at certain points in the DIT.
  • Virtual DIT view hierarchies can be created as a kind of ready-made query to facilitate the retrieval of commonly-required information.
  • Views promote flexibility in working practices and reduce the requirement that directory users create complex search filters, using attribute names and values that they would otherwise have no need to know.
    The flexibility of having more than one way to view and query directory information allows end users and applications to find what they need intuitively through hierarchical navigation.

4.4.3. Example of Virtual DIT Views

The LDIF entries below show a virtual DIT view hierarchy that is based on location. Any entry that resides below dc=example,dc=com and fits the view description appears in this view, organized by location. 
dn: ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Location Views
description: views categorized by location


dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Sunnyvale
nsViewFilter: (l=Sunnyvale)
description: views categorized by location


dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Santa Clara
nsViewFilter: (l=Santa Clara)
description: views categorized by location


dn: ou=Cupertino,ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Cupertino
nsViewFilter: (l=Cupertino)
description: views categorized by location
A subtree search based at ou=Location Views,dc=example,dc=com would return all entries below dc=example,dc=com which match the filters (l=Sunnyvale), (l=Santa Clara), or (l=Cupertino). Conversely, a one-level search would return no entries other than the child view entries because all qualifying entries reside in the three descendant views.
The ou=Location Views,dc=example,dc=com view entry itself does not contain a filter. This feature facilitates hierarchical organization without the requirement to further restrict the entries contained in the view. Any view may omit the filter. Although the example filters are very simple, the filter used can be as complex as necessary.
It may be desirable to limit the type of entry that the view should contain. For example, to limit this hierarchy to contain only people entries, add an nsfilter attribute to ou=Location Views,dc=example,dc=com with the filter value (objectclass=organizationalperson).
Each view with a filter restricts the content of all descendant views, while descendant views with filters also restrict their ancestor's contents. For example, creating the top view ou=Location Views first together with the new filter mentioned above would create a view with all entries with the organization object class. When the descendant views are added that further restrict entries, the entries that now appear in the descendant views are removed from the ancestor views. This demonstrates how virtual DIT views mimic the behavior of traditional DITs.
Although virtual DIT views mimic the behavior of traditional DITs, views can do something that traditional DITs cannot: entries can appear in more than one location. For example, to associate Entry B with both Mountain View and Sunnyvale (see Figure 4.16, “A DIT with a Virtual DIT View Hierarchy”), add the Sunnyvale value to the location attribute, and the entry appears in both views.

4.4.4. Views and Other Directory Features

Both class of service and roles in Directory Server support views; see Section 4.3, “Grouping Directory Entries”. When adding a class of service or a role under a view hierarchy, the entries that are both logically and actually contained in the view are considered within scope. This means that roles and class of service can be applied using a virtual DIT view, but the effects of that application can be seen even when querying the flat namespace.
For information on using these features, see "Advanced Entry Management," in the Red Hat Directory Server Administration Guide.
The use of views requires a slightly different approach to access control. Because there is currently no explicit support for ACLs in views, create role-based ACLs at the view parent and add the roles to the appropriate parts of the view hierarchy. In this way, take advantage of the organizational property of the hierarchy.
If the base of a search is a view and the scope of the search is not a base, then the search is a views-based search. Otherwise, it is a conventional search.
For example, performing a search with a base of dc=example,dc=com does not return any entries from the virtual search space; in fact, no virtual-search-space search is performed. Views processing occurs only if the search base is ou=Location Views. This way, views ensure that the search does not result in entries from both locations. (If it were a conventional DIT, entries from both locations would be returned.)

4.4.5. Effects of Virtual Views on Performance

The performance of views-based hierarchies depends on the construction of the hierarchy itself and the number of entries in the DIT. In general, there may be a marginal change in performance (within a few percentage points of equivalent searches on a conventional DIT) if virtual DIT views are enabled in the directory service. If a search does not invoke a view, then there is no performance impact. Test the virtual DIT views against expected search patterns and loads before deployment.
We also recommend that the attributes used in view filters be indexed if the views are to be used as general-purpose navigation tools in the organization. Further, when a sub-filter used by views matches a configured virtual list view index, that index is used in views evaluation.
There is no need to tune any other part of the directory specifically for views.

4.4.6. Compatibility with Existing Applications

Virtual DIT views are designed to mimic conventional DITs to a high degree. The existence of views should be transparent to most applications; there should be no indication that they are working with views. Except for a few specialized cases, there is no need for directory users to know that views are being used in a Directory Server instance; views appear and behave like conventional DITs.
Certain types of applications may have problems working with a views-enabled directory service. For example:
  • Applications that use the DN of a target entry to navigate up the DIT.
    This type of application would find that it is navigating up the hierarchy in which the entry physically exists instead of the view hierarchy in which the entry was found. The reason for this is that views make no attempt to disguise the true location of an entry by changing the DN of the entry to conform to the view's hierarchy. This is by design - many applications would not function if the true location of an entry were disguised, such as those applications that rely on the DN to identify a unique entry. This upward navigation by deconstructing a DN is an unusual technique for a client application, but, nonetheless, those clients that do this may not function as intended.
  • Applications that use the numSubordinates operational attribute to determine how many entries exist beneath a node.
    For the nodes in a view, this is currently a count of only those entries that exist in the real search space, ignoring the virtual search space. Consequently, applications may not evaluate the view with a search.