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 Directory Server Enterprise Edition 7.0 Reference. Procedural information about setting up a virtual directory is provided in Chapter 22, Directory Proxy Server Virtualization, in Sun Directory Server Enterprise Edition 7.0 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 multivalued 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 a simple scenario that shows 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 Directory Server Enterprise Edition 7.0 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.