OSF DCE Application Development Guide--Introduction and Style Guide

Using the DCE Name Service
As far as the DCE RPC and name service mechanisms are concerned, it is enough if a
client is brought into contact with some server, as long as that server offers the service
the client is looking for; in other words, as long as the server offers the interface the
client wants to use. To accomplish this rendezvous, interface UUIDs are sufficient.
They are also mandatory. There cannot be a client/server relationship without an
interface, and the entire RPC runtime mechanism is dependent on the concept of
interfaces.
Object UUIDs are different. The RPC runtime usually does not care if they are present or
not. But if they are present, they activate various runtime mechanisms that allow clients
and servers to be much more specific (always within the bounds of a given interface)
about what servers are bound to, and/or what resources the servers will use to fulfill the
clients’ requests. How this works is explained later in this chapter.
5.1.3 Interface UUIDs
Every IDL-compiled interface specification has its own UUID associated with it, and the
IDL-generated stub routines include this interface UUID with every operation request or
return sent over the network by clients and servers. In this way receiving stubs ensure
that they and the sending stubs are sharing exactly the same interface. If the interface
UUIDs are different, or are not present, then the remote call will not be completed. But
interface UUIDs, although they are required, play only a secondary role in a client’s
finding the interface (that is, finding a server that offers the interface); the main tool for
this is NSI, which makes use of the DCE Directory Service, as explained later in this part
of the chapter.
5.1.4 Summary: Names and UUIDs
Both names and UUIDs identify objects. But names are separable from the objects they
identify, and are only as trustworthy as the binding information their entries contain.
UUIDs, on the other hand, are inalienable identifiers. Once the desired binding
information for an interface or an interface/object combination has been found and used,
the name that was used to retrieve it can be forgotten; it is of no further use. This is not
true of either interface or object UUIDs.
Note that names become completely unnecessary only if clients have some other means
of obtaining valid binding information for the desired service, such as string bindings.
The following figure illustrates how the information a client finds through a name is
turned into network contact with the object named.
Figure 5-1. How a Name Turns into an Object
124246 Tandem Computers Incorporated 5−3