Virtual member manager hierarchy

Virtual member manager hierarchy is designed to ease the integration with LDAP directories, particularly directories with existing data.

Every LDAP directory has a Directory Information Tree (DIT), which is a hierarchical structuring of entries on the LDAP server. Every entry in an LDAP server occupies a location in the DIT and the distinguished name (DN) of an LDAP entry identifies the location of the entry in the DIT.

Because virtual member manager needs to use existing LDAP directories (both read from and write to them), the virtual member manager hierarchy is a hierarchical structuring of entities. This hierarchical structure, as much as possible, reflects the LDAP DIT structure. This enables virtual member manager to use various operations, such as create, to place an entry into an LDAP directory and respect the existing DIT structure that is already in place.

Virtual member manager hierarchical structure also provides virtual member manager with a hierarchical namespace. Adopting ideas from LDAP directories, each name in the virtual member manager hierarchical namespace follows the same format as an LDAP DN. In virtual member manager, the DNs are referred to as uniqueNames. Each uniqueName uniquely identifies an entity in virtual member manager, but a uniqueName is not static (it can change) and it may be reused. As a result, a uniqueName only uniquely identifies an entry at a point in time, not over time.

When virtual member manager is used with multiple repositories simultaneously, the virtual member manager hierarchy is divided among the multiple repositories so that uniqueNames for the different repositories do not collide.

As an example, virtual member manager is configured with three repositories, two of which are LDAP and one is a database. The LDAP directories have the DIT structures shown in the diagram. The corresponding virtual member manager hierarchy is also displayed in the diagram:

The illustration shows the difference between the LDAP hierarchy and the virtual member manager hierarchy.
The top of the virtual member manager hierarchy is an imaginary root, that is not illustrated. Entries under the root are mapped to one or more main repositories.
Note: A property extension repository is not considered a main repository.
Entries from a main repository reside under the corresponding entries assigned to the repository. If a repository does not have an explicit structure (like the LDAP DIT), it is the responsibility of the repository adapter to do any transformation necessary. For example, the database repository in the diagram might have a flat namespace (for example, its entries have primary keys from 1-100). The database repository adapter is responsible for translating a virtual member manager uniqueName into a primary key that the database can understand.

Virtual member manager provides a construct called a realm which consists of all or a subset of the entries from a main repository under a partition of the virtual member manager hierarchy. Using above as example, dc=comA,dc=com is considered a realm.

When an entry is to be created by virtual member manager, the caller can optionally specify a parent entry in the virtual member manager hierarchy under which the new entry are created. If a parent entry is not specified, a default parent (which is configurable for each realm ) is used. In virtual member manager a default parent entry can be configured for each entity type within each realm.

Entries in the virtual member manager hierarchy under the imaginary root can be defined during configuration time and can also be created programmatically at runtime.
Note: The entries might not correspond to real entries in the profile repositories. For example, the entry o=comC in the hierarchy might not correspond to a real entry in the profile repository for company C.
The illustrated scheme implies that if multiple repositories have entries with the same name (for example, two different LDAP directories each with an entry named o=USdiv ) and the customer wants to configure those entries directly under the root in the virtual member manager hierarchy, those entries must be changed to have unique names. For example, one of the LDAP directories with the o=USdiv entry can map that entry to the o=USdiv entry in the virtual member manager hierarchy. But the other directory with the o=USdiv entry must map to an entry with a name like o=USdivision in the virtual member manager hierarchy.
Note: o=USdivision is a uniqueName configured in virtual member manager, it is not stored in the LDAP directory as a real entry.

If virtual member manager is configured with only one repository, that repository occupies the entire the virtual member manager hierarchy.

To take advantage of the potentially globally-unique nature of LDAP DNs (for those that follow RFC 2247, by making use of Internet Domain Names), virtual member manager supports dc=com as part of a virtual member manager uniqueName (even if dc=com does not identify an entry in virtual member manager).

The virtual member manager hierarchy is to virtual member manager as the DIT is to LDAP. However, some important points to remember are:
Terms of use | Feedback
(C) Copyright IBM Corporation 2005. All Rights Reserved.
IBM virtual member manager 6.1