When to Use a Virtual Directory

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 (JDBC) 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.