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 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:
- 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.