The Directory Life Cycle

Understanding and Deploying LDAP Directory Services > 8. Namespace Design > The Purposes of a Namespace

<  BACK

CONTINUE  >

153021169001182127177100019128036004029190136140232051053055078214174201125191094171140

The Purposes of a Namespace

A namespace provides the means by which directory data is named and referenced. In this respect, directory entries need names for the same reason that you or I need a name ” so that we can be referred to by a more meaningful and precise term than "Hey, you!"

In some environments few, if any, additional requirements are placed on the namespace. In others, requirements for access control, replication, data partitioning, application access, and perhaps other aspects of the service impose additional requirements. This section summarizes the more common purposes of a namespace, some of which may not have occurred to you:

• Data reference.   A namespace provides the means by which directory data is referenced, which is important for two reasons. First, of course, is that there must be a way for directory clients to refer unambiguously to a directory entry when retrieving or modifying the information associated with it. Second, the directory name provides a compact and efficient way to support groups of directory entries and directory entries that refer to one another (for example, through the use of a seeAlso , owner , or manager attribute). An example of this application is shown in Figure 8.5.

  Figure 8.5 A data reference example.

  

• Data organization.   A namespace provides a way to organize data. For example, you might place all entries corresponding to people in one portion of the namespace, entries corresponding to devices (such as printers) in another, and groups in yet another part of the namespace. Further subdivisions of organization are also possible, perhaps based on geographical or organizational information. Such organization can help facilitate browsing of the directory. For example, a printing application that enables a user to choose a nearby printer based on characteristics such as speed, color , and duplex ability can more easily present only printers in a user 's vicinity if that portion of the directory is organized by locality. A namespace designed for this purpose is shown in Figure 8.6.

  Figure 8.6 A namespace example for data organization.

  

• Data partitioning.   A namespace enables directory data to be partitioned, or divided among multiple servers. Typically, partitioning can be performed only at certain well-defined namespace points (for example, on a subtree basis). If your namespace does not contain such partitioning points, you cannot partition your data. An example partitioning scheme in which the namespace enables a company's three main offices each to own and manage its own part of the data is shown in Figure 8.7. Partitioning is discussed in more detail in Chapter 9, "Topology Design."

  Figure 8.7 A namespace example for partitioning, replication, and delegation through access control.

  

• Data replication.   Although not directly related to replication, your choice of namespace can constrain the replication scenarios your directory can support. This is a logical consequence of the partitioning restrictions described previously. Most replication solutions require partitioning on well-defined namespace boundaries. For example, if you choose a completely flat namespace, it is more difficult to replicate only a portion of your data. Some directory implementations may allow directory partitioning based on criteria other than the namespace. For example, imagine a directory server with a filtered replication feature that allows data to be partitioned based on an arbitrary LDAP filter. An example of a replication scheme, in which the more traditional namespace partitioning example just described is replicated to multiple servers, is shown in Figure 8.7. More on this topic can be found in Chapter 10, "Replication Design."

• Access control.   Like replication, access control can be affected by your choice of namespace. Some products allow the setting of access control only at namespace branch points. This is especially true when delegating authority to some of your data. This may be possible only if the data is divided on a subtree basis. Some better products have a more flexible access control scheme, allowing control to be delegated on a basis other than namespace. For example, the Netscape Directory Server allows you to specify access control rules that apply to any entry in your directory that satisfies a given directory search filter. This ability to delegate authority over portions of data is one of the most important features of a directory service. Access control is discussed extensively in Chapter 11, "Privacy and Security Design."

• Application support.   The foregoing purposes of a namespace have all been related to the operation of the directory itself. The final purpose we will mention is that your namespace should support the applications that you are designing your directory for in the first place. This may seem almost too obvious to mention, but in our experience it is easy to get caught up in the excitement of directory design and lose track of the big picture. Make sure the namespace you design satisfies the requirements of your applications, both present and future.

You may be tempted to ascribe another purpose to your namespace, perhaps requiring that it should hold some aesthetic value of its own. After all, if people are going to have to look at the names, you might as well make them meaningful, even pleasing to look at. Perhaps your users might even be able to guess the names of entries given a standard, intuitively constructed namespace. Perhaps this is a nice idea in theory, but such dreams seldom work out in practice. Do not be fooled into considering such ideas.

A namespace should have functional value primarily, and the structure of your namespace should be hidden from users as much as possible. The primary purpose of a name is to provide a unique way of referencing the entry, and the driver behind its design is ease of administration. The other purposes described, including the effect your namespace may have on replication and access control, may also affect your choice of namespace. But these goals are administrative, and they should not be inflicted upon your users.

A directory client should hide the directory namespace from users of the client (or at the very least it should provide this option), which most modern clients do successfully. Failure to hide directory names often results in users being confused or upset by the name given to their entry, and users are unlikely to be sympathetic to the administrative concerns that caused you to name entries as you did. Furthermore, if you ever need to redesign your namespace, you will be glad you hid the original namespace from your users.

Tip

Choose names for administrative convenience, not aesthetic value. Try to hide names from users of the directory as much as possible. When developing applications, avoid making any assumptions about namespace design. Be sure to make your application flexible enough to adapt to different namespaces.

In summary, a namespace is required to reference entries and provide features such as groups, and it should support the applications using the directory. Your choice of namespace interacts with other important design decisions, often constraining the choices available when distributing, replicating, or controlling access to your data. These considerations are primary; other considerations, such as the aesthetics of your namespace, should be given less weight.

Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing

<  BACK

CONTINUE  >

Index terms contained in this section

access control
          namespaces 2nd
applications
         support
                    namespaces
choosing
          directory names
data
         organizing
                    namespaces 2nd
         partitioning
                    namespaces 2nd
         referencing
                    namespaces
         replication
                    namespaces
design
         namespace
                    choosing names
                    hiding from users
                    purposes of 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
directories
         namespaces
                    choosing names
                    hiding from users
                    purposes of 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
hiding
         namespaces
                    from users
namespaces
          choosing names
          hiding from users
          purposes of 2nd
                    access control 2nd
                    application support
                    data organization 2nd
                    data partitioning 2nd
                    data reference
                    data replication
organizing
         data
                    namespaces 2nd
partitioning
         data
                    namespaces 2nd
referencing
         data
                    namespaces
replication
         data
                    namespaces
support
         application
                    namespaces
users
          hiding namespaces from

2002, O'Reilly & Associates, Inc.