eDirectory Architecture

The eDirectory architecture has three main aspects:

• Physical database

• Rules governing data

• Organization of data

Each of these is addressed individually in the sections that follow.

Physical Database

At its lowest physical level, eDirectory is a database. A typical database consists of a dataset together with methods of searching and retrieving specific data from the dataset. eDirectory is an object-oriented, hierarchical database. A hierarchical database maintains data (objects) in a logical tree structure. Specific objects are located by traversing (walking) the tree. Each object in the eDirectory database is uniquely identifiable by a combination of the object name, or Common Name (CN), together with information describing the location of that object within the tree, or Context. Figure 7.1 shows a possible tree structure and the relationship between object name and logical position within the directory. The combination of Common Name and Context is known as the Distinguished Name.

Figure 7.1. A sample eDirectory tree structure showing how location determines name.

The underlying eDirectory database is organized as a b-tree, which those of you with a programming background will recognize as a well-known type of data structure. B-trees are ordered, or sorted, trees in which the root node always stores values at the midpoint of the sorted value set. As new elements are added, the tree automatically reorders itself. The eDirectory b-tree nodes contain multiple elements, each of which is a directory object.

The result of these two characteristics is a data structure in which a huge number of elements can be stored, and elements that are stored can be located very quickly.

The eDirectory database also makes extensive use of indexing. Data is sorted in a variety of ways in order to decrease the time required to locate a given piece of data even more. Each index is a smaller b-tree structure that is automatically updated whenever any relevant piece of the database is added, changed, or deleted. When a query is received by eDirectory, internal logic determines what index, if any, should be used to most efficiently respond to the query. Figure 7.2 shows you some of the default indexes created by eDirectory. You can also add custom indexes by completing the following steps:

1.	Launch iManager.
2.	In the Navigation frame, open the eDirectory Maintenance group and click Index Management.
3.	In the Content frame, select the server for which you want to manage indexes.
4.	Click Create. Provide the required information and click OK. Name Specify a name for the new index. Attribute Select the attribute on which the new index should be sorted. Rule Select the type of index you want created from the drop-down list. Select Presence to create an index based on whether the specified attribute has a value. Select Value to create an index based on values of the specified attribute.

Figure 7.2. Default eDirectory indexes.

eDirectory will automatically create the index based on your configuration choices.

Rules Governing Data

Rules defining valid object types, where they can be stored, and what can be done with each of the object types are maintained within the eDirectory schema. The schema provides the structure to the eDirectory tree. The schema is composed of a set of object classes. Object classes describe the types of objects that can be created in eDirectory. Each object class contains a set of attributes that specifies the type(s) of data that can be stored within each object. In this way, the schema creates the logical view of the eDirectory data that network administrators and users make use of every day.

Novell provides a base set of object classes in eDirectory but has recognized that it cannot account for every possible use of the directory. To address this, the eDirectory schema is extensible/extendable, meaning that third parties are free to define new object classes and attributes in order to extend eDirectory capabilities.

Organization of Data

eDirectory organization has two aspects: the physical organization and the logical organization. Physical organization of data in eDirectory revolves around its distributed nature and the need to provide fault tolerance for the eDirectory database. Each piece of the total eDirectory database is known as a partition.

In order to make the data contained in a given partition more secure and accessible, multiple copies of that partition can be stored across the network. This process of creating and maintaining multiple partition copies is known as replication, as shown in Figure 7.3. Replication is an extremely powerful capability, and Novell has designed eDirectory with a complex set of checks and balances in order to maintain the integrity of directory data across the distributed environment.

Figure 7.3. eDirectory partitions and replicas.

The logical organization of data in eDirectory determines how data will be presented to users and administrators. The logical organization is what you see when you look at eDirectory. The schema controls this logical eDirectory organization. The schema essentially defines the types of data that can be stored in eDirectory and the acceptable set of operations that can be performed on that data.

The eDirectory schema defines a class of objects that can store other objects. These are known as Container objects, or simply as Containers. Containers are the building blocks used to create the structure of the eDirectory tree. Objects that cannot hold other objects are known as Leaf objects. Leaf objects define the actual network resources available in the eDirectory tree.

Each class of Leaf objects contains a unique set of attributes that describe the data and functionality associated with that object. Leaf objects can include users, printers, network routers, applications, or even other databases. Because the eDirectory schema is fully extensible, new object classes can be defined and created within eDirectory by anyone who might need them.