Since DCE is designed to support very large namespaces, it uses a hierarchical service for binding. The global scale is separated into cells whose boundaries are administratively defined. For example, a company using DCE might have a cell containing its employees and local services. The cell namespace administrator could decide to put all the service entries in a single directory if the cell were small.
Both the import and export name service operations support default values derived from environment variables; for example, RPC_DEFAULT_ENTRY_NAME. The environment variables can be set by start-up files to the name of a well-known directory within the cell. The only remaining decision then will be how to name the actual entries within the directory. One easy method is to use mnemonic names, or names of interfaces such as binop, spm_library, and so on. If these entries are only being accessed by clients through profiles, their names will not be directly visible to the client anyway.
But now imagine a larger organization. The administrator will want to define some naming hierarchy based on geography, organization, or other criteria. Somewhere within this hierarchy some writeable directories (or parent directories) would be created, which could contain server entries, profiles, and so on. If clients are using only profiles to access bindings, then this organization will still be transparent to them. If clients want to bind to specific servers or objects, then more attention must be paid to the names given the servers' or objects' entries. The names should in some way reflect the organization, geography, or other relevant aspects of the server or object.
In summary, the important points to keep in mind are the following:
· The model should be appropriate for the organization and permit efficient administration of the namespace.
· There should be simple guidelines for naming objects and services so that users have a good chance of guessing the right answer.