| 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: -
Data reference . A namespace provides the means by which directory data is referenced, which is important for two reasons. First, there must be a way for directory clients to refer unambiguously to a directory entry. 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 member , seeAlso , owner , or manager attribute). Figure 9.5 shows an example of this application. Figure 9.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 entries corresponding to groups in yet another part of the namespace. Further organizational subdivisions 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 on the basis of characteristics such as speed, color , and two-sided printing capability can more easily present only printers in a user 's vicinity if that portion of the directory is organized by locality. Figure 9.6 shows a namespace designed for this purpose. Figure 9.6. A Namespace Example for Data Organization  -
Data partitioning . A namespace enables directory data to be partitioned, or divided, among multiple servers. Typically, data can be partitioned only at a branch point in the directory. If your namespace does not contain branch points (for example, if you have designed a one-level , flat namespace), you cannot partition your data. In contrast, Figure 9.7 shows a partitioning scheme in which the namespace enables a company's three main offices each to own and manage its own part of the data. Partitioning is discussed in more detail in Chapter 10, Topology Design. Figure 9.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 already described. Most replication solutions allow replication of only an entire partition. Therefore, if you choose a completely flat namespace, it is impossible to replicate only a portion of your data. The example shown in Figure 9.7 shows the directory divided into four partitions, each of which may be replicated (each of the four partitions is represented by a box in Figure 9.7). Chapter 11, Replication Design, says more on this topic. -
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 you're delegating authority to some of your data. Delegation may be possible only if the data is divided on a subtree basis. Some products have a more flexible access control scheme, allowing control to be delegated on a basis other than the namespace. For example, Netscape Directory Server 6 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 12, Privacy and Security Design. -
Application support . The purposes of a namespace we've discussed so far have all been related to operation of the directory itself. The final purpose we will mention is that your namespace should support the applications for which you're designing your directory 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. Check whether any of the applications you plan to deploy require a particular namespace design, and make sure that the namespace you design satisfies the requirements of your applications. 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 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. This may be 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 primarily functional value, 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 entries, 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 on your users. A well-designed directory client should hide the directory namespace from users of the client (or at least it should provide this option), and most modern clients do this 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, to support features such as groups, and to support the applications using the directory. Your choice of namespace interacts with other important design decisions, often constraining the choices available when you're 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. |
