Front cover - IBM Redbooks

CN=David Hinkle
EmpID=1234
Dept=ISSL
CN=David Hinkle
EmpID=1234
Phone=555-1234
Mail=dave@ibm.com
and so forth. The connectors can be used to map data between different
directories somewhat independently (for example, A to B, B to A and C). They
generally use no permanent data store of their own, relying on the data stores of
the directories they connect to create a “virtual” directory. Such a virtual directory
could provide an LDAP service that accesses data from multiple directories in
order to be able to respond to LDAP requests. However, it would store nothing in
a database of its own. Each request requires connection to, and a search against
existing source databases, with the metadirectory performing a merging of the
collected data “on the fly” for the response to the original LDAP request.
database 1 database 3
metadirectory
database 2 database 4
Figure 8-12 Metadirectory conceptual architecture
CN=David Hinkle
EmpID=1234
Dept=LPS ISSL
Mail=dave@ibm.com
As shown in Figure 8-12, the “Dept” attribute has been updated in database 3
using data from database 1, and the “Mail” attribute has been added in database
2 from the information in database 3. This is a simple example of data
synchronization between different directories being performed by the
metadirectory.
A central directory accepts data feeds from the different existing subordinate
directories, and can provide the consolidated data back to the different
subordinate directories. Like a metadirectory, it requires connectors to the
various “spoke” directories to read and write data. Unlike a metadirectory, it
provides its own permanent data store, and the data mapping is always defined
in terms of the attributes maintained in the central directory (example, A to X, B
to X, C to X). The merging of data is performed as part of ongoing
synchronization with the spoke directories, and it is the merged data that is
stored.
Chapter 8. Directory strategies 341