|Previous Contents Index Next|
|iPlanet Meta-Directory Configuration and Administration Guide|
Chapter 1 Meta-Directory Overview
This chapter provides an overview of iPlanet Meta-Directory including how data is integrated and how components interact. It contains the following sections:
What is Meta-Directory?
iPlanet Meta-Directory is a set of software components that synchronize data from one or more external data sources into a single repository. This repository then becomes the authoritative source for the combined data, acting as a starting point for searches and for modifications that flow back to the original data sources. These data sources can include LDAP directories, SQL (Oracle) databases, and other proprietary formats.
The join engine and direct and indirect connectors are the components which flow data into and out of Meta-Directory and integrate it into one definitive source. The connectors transfer information to and from a number of data sources to the join engine. The join engine links these entries together to form one repository.
A connector transfers information between an external data source and its corresponding connector view. When configuring a connector to transfer the information, an LDAP sub-tree is created on a Directory Server. This sub-tree is called a connector view. The connector view is populated with LDAP-structured copies of the entries that reside in the external data source. From this connector view, Meta-Directory is able to integrate the new LDAP-structured data into an LDAP meta view.
There are two types of connectors: direct and indirect. The connector view for an LDAP Directory Server or a SQL (Oracle) database uses a direct connector; it communicates directly with the join engine. The connector view for other sources of data uses an indirect connector which translates the data into LDAP for inclusion into a connector view before passing it to the join engine.
iPlanet Directory Server 4.1x and 5.x and an Oracle database accessible using Oracle Call Interface have direct connections to the join engine. Because the join engine understands LDAP, it can directly read or write any entry stored on an LDAP-based Directory Server. On the other hand, in order to read and write to an entry stored within Oracle's SQL database, the join engine uses the Database connector plug-in to provide direct, two-way access. (Because the Database Connector is a join engine plug-in as opposed to a connector outside the join engine, it is considered a direct connector.)
Indirect connectors are used to transport entries stored in external data sources that use protocol not directly accessible by the join engine. The indirect connectors manage the process, transforming the data using rules and filters. (The indirect connector rules include Attribute Flow Rules, Default Attribute Value Rules and Filter Rules.) Meta-Directory supports the following indirect connectors:
Universal Connector and Universal Text Parser
The Universal connector (also known as the Universal Text Connector or UTC) is an indirect connector that enables the transfer of data between data sources and a connector view. The Universal Text Parser (UTP) is a set of text file parsers and generators that are used with the UTC to make certain text files [currently Comma-Separated Values (CSV) files, LDAP Data Interchange Format (LDIF) files and Name-Value Pair (NVP) files] compatible with the connector view.
NT Domain Connector
The NT Domain connector is a Universal connector with Windows NT-specific Perl scripts and binaries that provides two-way synchronization of user and group data between a Windows NT SAM database and its connector view.
Active Directory Connector
The Active Directory connector is a Universal connector with Active Directory-specific Perl scripts and binaries that provides two-way synchronization of user and group data between an Active Directory database and its connector view.
The core service of Meta-Directory is the join engine, responsible for linking entries and controlling the flow of information from a connector view into or out of the meta view. The meta view is an LDAP sub-tree where entries from one or more connector views are linked, stored and accessed. The join engine synchronizes the data by flowing it through a sequence of rules and filters which map attributes from the connector view with corresponding attributes in the meta view. (Mapping is the assignment of an attribute or entry in one source to link with a particular attribute or entry in another source.) The movement of this data through the sequence of rules is referred to as the join process. The join engine also monitors the connector views for changes and incorporates them into the meta view; conversely, it monitors the meta view for changes and incorporates them into the connector view and back to the related external data source.
The join process is the movement of data through a sequence of rules and filters that are used by the join engine to determine how connector view entries will be represented in the meta view. To successfully join entries, the join engine must match data in the connector view with a congruous entry in the meta view. To do this, rules containing values and attributes are issued against the connector view. These rules find a matching entry, and create a link to it, in the meta view. The search strings include Join Rules, Attribute Construction Definitions, Attribute Flow Rules, Filters, and DN Mapping Rules.
In connecting data from several data sources, Meta-Directory allows the information to be accessed in two ways:
The meta view, a representation of the culmination of the join process a view of the combined data from all connector views.The following sections describe these views in more detail.
The meta view is a unified view of LDAP entries from one or more connector views, representing the result of the join engine's join process. After the join engine receives information from a connector view, it synchronizes the information in the meta view.
From the meta view, you can view the linked entries as well as modify them and send the modifications back to the original connector views. Meta-Directory supports only one meta view per join engine.
A connector view is an LDAP representation of an entry (or entries) that resides in an external data source. This representation is merged with other connector views to form the meta view. In order for this merger to take effect, you must specify that a connector view is a participating view. Adding a participating view allows the connector view to `participate' in the join process; enabling it allows the data to flow from the connector view into the meta view. (It is through the participating view that the rules of the join process are applied.)
How Meta-Directory Works
Information from data sources is channeled to one or more connector views via a direct or indirect connector. The join engine combines the data from the connector views into one meta view. All the information in the meta view is then accessible via a directory server and other web-based applications. This is how the process plays itself out:
The join engine works with direct and indirect connectors that channel data from external sources into a Directory Server connector view.Figure 1-1 is a graphical representation of Meta-Directory's process.
The direct connectors read entries from either an LDAP directory or an Oracle database and map the data into LDAP-configured connector views.
For other sources of data, an indirect connector transforms information from a proprietary format into LDAP and flows this data into an LDAP-configured connector view.
The meta view becomes the replicated source for the combined data, allowing searches and changes to be made and flowed back to the original source.
- The data in these LDAP-configured connector views can then be flowed into, and stored on, a meta view (another directory subtree in a Directory Information Tree) via the direct LDAP connector.
Figure 1-1    Data Integration Into Meta-Directory
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated April 08, 2002