|< Day Day Up >|| |
In the previous step (schema design), you decided how to build object classes from attributes to project your data into the directory. In this step, you must structure your object classes to build up the directory information tree (DIT). The DIT defines the namespace where all the objects of your directory reside. The definition of the namespace helps the directory server to decide whether a client can get information from his directory or whether he should contact another directory server.
In designing the tree, you have to make the following decisions:
Choose a suffix as a root for the DIT
Choose a branching policy
Choose a naming policy
We will look at each of these steps in detail, but first let us consider the importance of the namespace. The design of the DIT strongly influences the following points:
Data organization: A good tree layout facilitates organization of the data, helps your users to browse the tree, and returns queries faster.
Replication, partitioning, and access control: We will have to decide about replication and partitioning a bit later. However, we lay a foundation for these future decisions when we design the directory tree. In both data replication and data partitioning, the boundaries between the single parts of the directory can only be at certain points within the namespace. The same is true for access control. It is easier to control access to a completely separated subtree than to have a tree where confidential data is mixed with public data. Furthermore, you may wish that a user or an application does not even see that there is additional private data available.
Maintenance: Changes in the tree are not infrequent. A well-organized tree will facilitate later changes.
Application support: The DIT must also support the directory applications using the directory.
The first step in designing the tree is to choose a root for the DIT. This root is also called a "directory suffix" or a "root distinguished name" (root DN). In most directory server implementations, it is possible to define more than one root DN in one directory server. During the installation, some implementations of directory servers configure more than one root DN. For example, the i-Planet directory server uses one root DN for the directory and one root DN for the administration of the directory server itself.
There are three different naming conventions you can use:
The domainComponent attribute, where you split your domain name into its individual components:
dc = bmw, dc = de
The domain name assigned to the enterprise:
o = bmw.de
The traditional X.500 naming conventions:
o = bmw, c = de
The choice of a naming convention depends on your actual situation. You may be constrained in your choice if there are already directory-enabled applications using one of these possibilities. Choosing the last one is normally a good idea because it guarantees compatibility with the X.500 standard. LDAP works with any of the three naming conventions. However, regardless of the naming convention you choose, there are things that you should bear in mind when choosing a root DN:
The root DN has to be unique within the range of its visibility. If you are working inside the intranet of an enterprise, the name must be unique within the companywide intranet. If the directory services are meant for use over the Internet, the name must be unique throughout the worldwide Internet.
Once chosen, the root DN should not be changed. If the root DN changes, you have to change your whole directory tree and all applications using the directory services. In a large organization, this could take months.
The root DN should be not too long and it should be easy to remember. Your users and your application engineers will be happy, and the applications will be less error prone.
When the directory server receives a query from a client, the server decides whether it is competent to answer the query. A well-designed DIT facilitates this decision. Now all the server has to do is take the DN from the request and see whether it exists within one of the namespaces defined by the root DNs. If it is beneath one of the root DNs, then the directory server knows that it holds information useful for the query. If it does not, the directory server's response depends on its configuration. It could direct the client to another server, or it could simply answer with an error code.
The question is, should you use a flat namespace or a hierarchical schema? It is a good idea to keep your tree as flat as possible, such as the completely flat schema depicted in Exhibit 17 in Chapter 3. This namespace design has several advantages. First of all, it keeps things simple. A complicated hierarchy is more difficult to understand and is consequently more difficult to use and to maintain than a flat configuration. The flatter the directory tree, the easier it is for application designers to use it. Another reason to keep the hierarchy flat is that a flat namespace reduces the probability that the tree will undergo changes later on. A flat namespace also tends to have shorter relative distinguished names (RDN). The shorter the RDNs, the easier they are to remember.
So why would anyone ever use a hierarchical schema? There are several reasons, and we will encounter some of these arguments again in the later sections of this chapter.
Administrative purposes: If your enterprise is spread among several countries, then data maintenance, data backup, and statistics can be done locally. The local competence can impose branching decisions, as shown in Exhibit 18 in Chapter 3.
Partitioning decisions: When the amount of data is so high that you wish to distribute your data over more machines to improve performance, you need an opportune branch point to do so.
Replication decisions: You maintain your data centrally, but you want the option of replicating some of the data to local applications where the data is needed. The reason may be slow communication lines or dial-up connections.
Access control and security questions: Security issues are different for different types of data. Some data is appropriate for public consumption, and some data is proprietary and should be visible only to a defined group of people. You can differentiate security among data classes by branching up your tree.
The most important consideration is to design the tree so that there will be as few changes as possible. So avoid designing a tree based upon your actual organigram, if possible. Organigrams are subject to frequent changes, and after each reorganization you will have to redesign you namespace and change all applications accessing your directory server.
|< Day Day Up >|| |