Sun Java System Directory Server Enterprise Edition 6.0 Reference

Data View Features

A simple data view is defined primarily by the base DN of the data view. In a simple data view all of the entries in the subtree are encompassed by the data view. Data views can exist in hierarchy, with a superior data view and a subordinate data view. A subordinate data view is a data view whose base DN is inferior to the base DN of a superior data view. The entries in a subordinate data view are excluded from the superior data view.

Data views can be defined with distribution algorithms to separates entries from data views with the same base DN into different data views.

For information about the features of a data view, see the following sections.

Excluding a Subtree From a Data View

When a subordinate data view is created, Directory Proxy Server automatically excludes the subordinate data view from the superior data view. When a request targets the subordinate data view, the request is sent to the subordinate data view instead of the superior data view.

By default, Directory Proxy Server automatically configures the excluded-subtrees parameter in the superior data view to exclude subordinate data views. For information about how to disable the automatic configuration, see To Manually Configure the excluded-subtrees and alternate-search-base-dn Properties in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

The following subtrees are excluded by default from all data views: cn=config, cn=monitor, and cn=proxy manager.

Performing a Search Directed at a Superior Data View on an Excluded, Subordinate Data View

When an alternate search base is specified in a subordinate data view, search operations targeted at the superior data view are also performed in the subordinate data view.

By default, Directory Proxy Server automatically configures the alternateSearchBase parameter in the subordinate data view. For information about how to disable the automatic configuration, see To Manually Configure the excluded-subtrees and alternate-search-base-dn Properties in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

Distributing Entries In a Subtree to Different Data Views

A distribution algorithm distributes operations across data views that have the same base DN. The type of distribution algorithm is defined by the distribution-algorithm parameter.

To determine how to distribute operations, the distribution algorithm considers the value of the attribute directly below the base DN of the data view. For example, consider a data view with a base DN of ou=people,dc=example,dc=com. If a search operation contains the base DN uid=23,ou=people,dc=example,dc=com, the distribution algorithm considers uid to be the routing attribute, because uid is directly below the base DN of the data view. The algorithm then attempts to match the value 23 to determine how to route the operation.

However, if the search operation contains the base DN uid=23,ou=managers,ou=people,dc=example,dc=com, the distribution algorithm considers ou to be the routing attribute, because ou is directly below the base DN of the data view. Because ou does not match the uid specified in the search query, the distribution algorithm cannot distribute the search correctly. For distribution to work in this case, the base DN of the data view should be ou=managers,ou=people,dc=example,dc=com.

You must therefore ensure that the base DN of the data view is appropriate to the distribution algorithm.

The following distribution algorithms are provided with Directory Proxy Server:

Pattern matching

Requests are distributed to data views based on the match between the parameters of the requests and one or more patterns. Patterns are defined by the following parameters:

pattern-matching-base-object-search-filter
pattern-matching-dn-regular-expression
pattern-matching-one-level-search-filter
pattern-matching-subtree-search-filter

The syntax supported by the pattern matching algorithm is specified by the Java Pattern class (documented at http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html). This syntax is not the same as the usual regex syntax.

Numeric

Requests are distributed to data views according to the numeric value of the RDN in the request. The numeric value is taken from the value of the first RDN beneath the base DN of the data view. Numeric bounds are defined by these parameters:

numeric-attrs
numeric-default-data-view
numeric-lower-bound
numeric-upper-bound

Lexicographic

Requests are distributed to data views according to the lexicographic value of the RDN in the request. Lexico bounds are taken from the value of the first RDN beneath the base DN of the data view. Lexico bounds are defined by these parameters:

lexicographic-attrs
lexicographic-lower-bound
lexicographic-upper-bound

Replication

Requests are distributed to data views according to the role of the data view in replication. The algorithm distributes write operations to all data sources in the data source pool and read operations to a single data source. The replication role is defined by the replication-role parameter. A data view can have a master role or a consumer role.

For information about how to configure a distribution algorithm, see Data Views With Hierarchy and a Distribution Algorithm in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide. For information about the parameters used with the distribution algorithms, see distribution-algorithm(5dpconf).

Limitations of Distribution Algorithms

The distribution algorithms provided with Directory Proxy Server6.0 have certain limitations in specific request scenarios.

The following list outlines the situations in which requests do not respect the distribution algorithm. The examples in this list assume that the routing attribute is uid and the view base of the data view is dc=example,dc=com.

When the search base ends with the view base and the scope is base, requests are always distributed to the first data view. For example:
```
$ ldapsearch -b "ou=people,dc=example,dc=com" -s base "uid=116352"
```
When the search base ends with the view base and the scope is one level or subtree, requests are always distributed to the first data view. For example:
```
$ ldapsearch -b "ou=people,dc=example,dc=com" -s sub "uid=116352"
```
When the search base ends with the view base and starts with the routing attribute, but the search filter does not contain the routing attribute, requests are distributed to all data views. For example:
```
$ ldapsearch -b "uid=116352",ou=people,dc=example,dc=com" -s base "objectclass=*"
```
In this example, requests are distributed correctly if the RDN value matches the data view criteria.
When the search base ends with the view base and contains the routing attribute, but the search filter does not contain the routing attribute, requests are distributed to all data views. For example:
```
$ ldapsearch -b "cn=myAccount,uid=116352,ou=people,dc=example,dc=com" -s base "objectclass=*"
```
In this example, requests are distributed correctly if the RDN value matches the data view criteria.

Attribute Renaming and DN Renaming

Each entry in a directory is identified by a DN and a set of attributes and their values. Often, the DN and the attributes defined on the client side do not map to the DN and the attributes defined on the server side.

Data views can be defined to rename DNs and attributes to values that match the server side. When a client makes a request, the DNs and attributes are renamed to match the server side. When the result is returned to a client, the DN and attributes are changed back to match the client side.

Attribute Renaming

The following figure illustrates how attribute renaming is performed by Directory Proxy Server.

Figure 22–1 Attribute Renaming

Figure shows how attribute renaming is performed.

In Figure 22–1, the email client expects the last names to be specified by the attribute surname However, in the LDAP server, last names are specified by the attribute sn. When attributes are renamed, only the name of the attribute is affected — the value of the attribute is not changed. However, when attributes are renamed all entries with that name are renamed.

For information about how to configure attribute renaming, see To Configure Attribute Renaming in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

DN Renaming

The following figure illustrates how DN renaming is performed by Directory Proxy Server.

Figure 22–2 DN Renaming

Figure shows how DN renaming is performed.

In Figure 22–2, the client contains the dc=example, dc=com database. The LDAP server contains the dc=example, dc=org database. The Directory Proxy Server renames the DNs.

Attributes that contain DNs must also be renamed if those DNs are in the portion of the DIT that is affected by the original DN renaming. In Figure 22–2, the group attribute contains a list of the DNs of group members. When dc=example, dc=com is renamed to dc=example, dc=org, the DNs in the group attribute must also be renamed.

For information about how to configure DN renaming, see To Configure DN Renaming in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.