The single model provided by virtual member manager assists IBM® customers
to achieve a single view of their own customer data.
Virtual member manager provides a common API for WebSphere and customer
applications to share data for organizational entities. The key to sharing
is not so much that a common API is available, but instead, a common model
for the data be available. A common model means using the same data and interpreting
the data in the same way. Virtual member manager needs to support a variety
of applications. Many applications currently have their own components for
managing organizational entities and consequently their own models of the
organizational entities. The common model from the virtual member manager
converges the models used by these various applications.
Virtual member manager relies mostly on the repository adapter to do the
adaptation or transformation. However, there are limitations to repository
adapter functionality. For example, if an existing repository for business
or technical reasons cannot support an entity type in the virtual member manager
model, but a virtual member manager applications need that entity type, the
repository adapter needs to have an additional repository available to store
entries of that new entity type. The same limitation applies at the property
level. If some properties are not available from the existing repository,
then another repository has to be used to supplement the existing repository.
With an existing repository, two categories of data exist:
- Data (that is, entries and their properties) that can be provided by the
existing repository. Such data can be adapted to the virtual member manager
model by its repository adapter.
- Data (that is, entries and their properties) that cannot be provided by
the existing repository, but is needed by virtual member manager applications.
Such data has to be stored in another repository. Because it is not existing
data, they can be stored in such a way that the amount of adaptation or transformation
is minimized.
When an additional repository is needed, virtual member manager
offers two possible solutions:
- The out-of-the-box limited data integration capability provided by virtual
member manager. Virtual member manager can be configured to do entry level
join and property level join. Entry level join is useful in the case where
an existing repository cannot support certain entities (for example, a customer's
LDAP directory is read-only and does not allow additional groups to be created
in the directory). The database repository can be used to supplement the
existing repository to store the additional groups. Property level join
is useful in the case where an existing repository cannot support certain
properties for entities (for example, a customer's LDAP directory is read-only
and does not allow additional properties for people and group entries). Virtual
member manager repository can be used in this case to store the additional
properties. Virtual member manager is able to gather all the properties for
a single entry (from both the property extension and the main repository)
and present them as one logical entry to a virtual member manager application.
The application does not know that the properties come from two different
places.
- The use of a product that specializes in data integration and synchronization
with virtual member manager. If more advanced data integration is required,
a product such as the IBM Tivoli® Directory Integrator or the WebSphere Information
Integrator can be used. Such products provide advanced functions to enable
data from multiple repositories to be combined, reconciled, and synchronized
in different manners. Both the IBM Tivoli Directory Integrator and the WebSphere
Information Integrator present to virtual member manager the image of a single
repository.