In Fig. 10-21 (b), there are two CDS servers in the cell, but the clerk only knows about one of them — the wrong one, as it turns out. When the CDS server sees that it does not have the directory entry needed, it looks in the root directory (remember that all CDS servers have the full root directory), to find the soft link to the correct CDS server. Armed with this information, the clerk tries again (message 4). As before, the clerk caches the results before replying.
10.5.3. The Global Directory Service
In addition to CDS, DCE has a second directory service, GDS, which is used to locate remote cells, but can also be used to store other arbitrary directory information. GDS is important because it is the DCE implementation of X.500, and as such, can interwork with other (non-DCE) X.500 directory services. X.500 is defined in International Standard ISO 9594.
Fig. 10-21. Two examples of a client looking up a name. (a) The CDS server first contacted has the name. (b) The CDS server first contacted does not have the name.
X.500 uses an object-oriented information model. Every item stored in an X.500 directory is an object. An object can be a country, a company, a city, a person, a cell, or a server, for example.
Every object has one or more attributes. An attribute consists of a type and a value (or sometimes multiple values). In written form, the type and value are separated by an equal sign, as in C=US to indicate that the type is country and the value is United States.
Objects are grouped into classes, with all the objects of a given class referring to the same "kind" of object. A class can have mandatory attributes, such as a zipcode for a post office object, and optional attributes, such as a FAX number for a company object. The object class attribute is always mandatory.
The X.500 naming structure is hierarchical. A simple example is given in Fig. 10-22. Here we have shown just two of the entries below the root, a country (US) and an organization (IBM). The decision of which object to put where in the tree is not part of X.500, but is up to the relevant registration authority. For example, if a newly-formed company, say, Invisible Graphics, wishes to register to be just below C=US in the worldwide tree, it must contact ANSI to see if that name is already in use, and if not, claim it and pay a registration fee.
Fig. 10-22. An X.500 directory information tree.
Paths through the naming tree are given by a sequence of attributes separated by slashes, as we saw earlier. In our current example, Joe of Joe's Deli in San Francisco would be
/C=US/STATE=CA/LOC=SF/O=JOE'S-DELI/CN=JOE/
where LOC indicates a location and CN is the (common) name of the object. In X.500 jargon, each component of the path is called the RDN (Relative Distinguished Name) and the full path is called the DN (Distinguished Name). All the RDNs originating at any given object must be distinct, but RDNs originating at different objects may be the same.
In addition to normal objects, the X.500 tree can contain aliases, which name other objects. Aliases are similar to symbolic links in a file system.
The structure and properties of an X.500 directory information tree are defined by its schema, which consists of three tables:
1. Structure Rule Table — Where each object belongs in the tree.
2. Object Class Table — Inheritance relationships among the classes.
3. Attribute Table — Specifies the size and type of each attribute.
The Structure Rule Table is basically a description of the tree in table form and primarily tells which object is a child of which other object. The Object Class Table describes the inheritance hierarchy of the objects. For example, there might conceivably be a class telephone number, with subclasses voice and FAX. Note that the example of Fig. 10-22 contains no information at all about the object inheritance hierarchy since organizations there occur under country, location, and the root. The structure depicted in this figure would be reflected in the Structure Rule Table. The Object Class Table might be set up with organizational unit as a subclass of an organization, and cell as a subclass of organizational unit, but this information cannot be derived from the figure. In addition to telling which class a given class is derived from, the Object Class Table lists its unique object identifier, and its mandatory and optional attributes.
The Attribute Table tells how many values each attribute may have, how much memory they may occupy, and what their types are (e.g., integers, Boole-ans, or reals). Attributes are described in the OSI ASN.1 notation. DCE provides a compiler from ASN.1 to C (MAVROS), which is analogous to its IDL compiler for RPC stubs. This compiler is really for use in building DCE; normally, users do not encounter it.
Each attribute can be marked as PUBLIC, STANDARD, or SENSITIVE. It is possible to associate with each object access control lists specifying which users may read and which users may modify attributes in each of these three categories.
The standard interface to X.500, called XOM (X/Open Object Management), is supported. however, the usual way for programs to access the GDS system is via the XDS (X/Open Directory Server) library. When a call is made to one of the XDS procedures, it checks to see if the entry being manipulated is a CDS entry or a GDS entry. If it is CDS, it just does the work directly. If it is GDS, it makes the necessary XOM calls to get the job done.
The XDS interface is amazingly small, only 13 calls (versus 101 calls and a 409-page manual for DCE RPC). Of these, five set up and initialize the connection between the client and the directory server. The eight calls that actually use directory objects are listed in Fig. 10-23.
| Call | Description |
|---|---|
| Add_entry | Add an object or alias to the directory |
| Remove_entry | Remove an object or alias from the directory |
| List | List all the objects directly below a specified object |
| Read | Read the attributes of a specified object |
| Modify_entry | Atomically change the attributes of a specified object |
| Compare | Compare a certain attribute value with a given one |
| Modify_rdn | Rename an object |
| Search | Search a portion of the tree for an object |
Fig. 10-23. The XDS calls for manipulating directory objects.
The first two calls add and delete objects from the directory tree, respectively. Each call specifies a full path so there is never any ambiguity about which object is being added or deleted. The list call lists all the objects directly under the object specified. Read and modify_entry read and write the attributes of the specified object, copying them from the tree to the caller, or vice versa. Compare examines a particular attribute of a specified object, compares it to a given value, and tells whether the two match or not. Modify_rdn changes one relative distinguished name, for example, changing the path a/b/c to a/x/c. Finally, search starts at a given object and searches the object tree below it (or a portion of it) looking for objects that meet a given criterion.