The virtual directory is an advanced feature of Directory Proxy Server that aggregates information, in real time, from multiple data repositories. This chapter describes how you can use a virtual directory in a Directory Server Enterprise Edition deployment.
The architectural concepts of a virtual directory are described in Chapter 18, Directory Proxy Server Virtualization, in Sun Java System Directory Server Enterprise Edition 6.2 Reference. Procedural information about setting up a virtual directory is provided in Chapter 23, Directory Proxy Server Virtualization, in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
This chapter covers the following topics:
Virtual directory features can be deployed if your directory service has any of the following requirements:
Client applications require an aggregated view of entries across multiple data repositories.
For example, you might have several directory servers that contain the same users, but different data. The virtual directory can be used to create a single view of a user's entry across all directories. The virtual directory can also provide a single point of administration for each individual directory.
Types of data repositories that are supported include LDAP directories, Java Database Connectivity (JDBCTM) compliant sources such as MySQL, and LDIF flat files.
Separate data stores are required for user credentials and application specific data.
For example, an application might have specific data that you do not want to be stored in a corporate directory. The virtual directory enables you to separate the data but make it appear as one source for applications. This simplifies application development and data management because applications do not need to know the details of the data infrastructure. In addition, changes to backend data sources can be abstracted from applications.
Your enterprise has acquired another company, or merged with another company.
The virtual directory enables the two company directories to be merged so that they appear as a single directory. For example, imagine you have two directories, dc=example,dc=com and dc=acquisition,dc=com. You also have client applications that need both directories to look like dc=example,dc=com.
Client applications require database tables to be displayed in the format of a DIT hierarchy.
Read and write operations are required to multiple data repositories.
Multiple field join criteria with dissimilar attribute names are required.
Client applications require support for multi-valued attributes across directories and databases from multiple LDAP or JDBC backends.
Attribute renaming, DN rewriting, and attribute value rewriting for DN syntax attributes are required.
Multiple client applications require different views of a single data repository.
This section provides simple scenarios that show how a virtual directory answers specific business requirements. For more complex sample scenarios, and for details of virtual directory configuration, see Sample Virtual Configurations in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Example.com stores uses three different data repositories to store user data. Example.com's Directory Server contains the bulk of the user data. User email addresses are stored in an Active Directory, and HR data is stored in a MySQL database.
Example.com has several client applications that require a complete view of all user data. The following diagram illustrates how the virtual directory provides a complete view of a user's identity to the client application.
In this scenario, Example.com acquires a new company, Acquisition.com. The new company stores its user data in its own Directory Server. For management purposes, Example.com wants to retain this directory structure. However, certain client applications need to see the use data from Acquisition.com as if it were user data from Example.com.
The following diagram illustrates how the virtual directory provides a virtualized merge of the acquired company's data into the existing directory structure.
Acquisition.com's directory is seen as a separate branch under the ou=people branch. The DNs of the entry's in Acquisition.com's directory are transformed when they are viewed through the virtual directory.