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:

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 the previous 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.
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).
- Virtual member manager hierarchy might look exactly the same as an LDAP DIT, but the virtual member manager hierarchy is not the LDAP DIT. It is mapped onto the LDAP DIT and, as such the uniqueName in virtual member manager, although it looks very much like an LDAP DN, it is not an LDAP DN. Virtual member manager uniqueName is not guaranteed to be the same as the LDAP DN, even if the two happens to have the same value for some deployments of virtual member manager.
- Virtual member manager hierarchy affects the location of an entry when it is stored, that is which repository is used, if multiple main repositories are configured under virtual member manager. It also affects the actual location of the entry in the repository (as determined by the repository adapter).
- Virtual member manager hierarchy is not meant to reflect a meaningful organizational structure even if it happens to look like a meaningful organizational structure for some deployments. There can be quite a number of different organizational structures for a virtual member manager deployment. For example, a company might organize its entities according to a functional reporting structure, and might also organize its entities according to a regional reporting structure. Another might organize the entities for the purpose of performing delegated administration. Because of the need for different organizational structures, the virtual member manager hierarchy can only be a meaningful organizational structure for a single organizational structure. With multiple repositories and structures, virtual member manager cannot represent a meaningful organizational structure.
- Virtual member manager hierarchy might not be uniform. Entries placed into the virtual member manager hierarchy might not follow a uniform approach in terms of their placement. Virtual member manager hierarchy might place entries according to their type in one portion of the hierarchy, and place entries according to the organization to which they belong in another portion of the hierarchy.
- Entries in the virtual member manager hierarchy and the underlying LDAP DIT need not map in a one-to-one manner. It is possible for a repository adapter to do the transformation such that multiple entries in an underlying repository are combined to become a single entry exposed by virtual member manager, or an entry in an underlying repository separated into multiple entries exposed by virtual member manager.
- The parent and children references on Entity refer to the parent entry and children entries in the virtual member manager hierarchy, not the hierarchy of the underlying repository. Virtual member manager delegates most of the work of resolving the parent and children entries to the appropriate repository adapter.
- LDAP supports many different DIT structures, virtual member manager supports representative DIT structures only.