Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Deployment Planning Guide 11g Release 1 (11.1.1.5.0) |
Part I Overview of Deployment Planning for Directory Server Enterprise Edition
1. Introduction to Deployment Planning for Directory Server Enterprise Edition
2. Business Analysis for Directory Server Enterprise Edition
Part II Technical Requirements
3. Usage Analysis for Directory Server Enterprise Edition
4. Defining Data Characteristics
5. Defining Service Level Agreements
6. Tuning System Characteristics and Hardware Sizing
7. Identifying Security Requirements
8. Identifying Administration and Monitoring Requirements
9. Designing a Basic Deployment
10. Designing a Scaled Deployment
11. Designing a Global Deployment
12. Designing a Highly Available Deployment
Part IV Advanced Deployment Topics
13. Using LDAP-Based Naming With Solaris
14. Deploying a Virtual Directory
Typical Virtual Directory Scenario
Connecting User Identities From Different Data Sources
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.