OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
How then, you might ask, are filenames represented in DCE? Here are two examples of
remote filenames:
/.../tinseltown.org/fs/doc/jones/app.gd/chap2.ps
/.../tinseltown.org/fs/doc/tolstoy/novels/war_and_peace/chap2.ps
As you may have guessed, these too are namespace entries, but the entries in this case
refer to remote files, and the entry name as a whole is the remote filename. What makes
these names different from the other two names given earlier is their third element, fs/,
which identifies a junction from the DCE Directory Service’s namespace into the DCE
Distributed File Service’s own, separately maintained, namespace.
What happens is that /.../tinseltown.org/fs is the DFS file server’s DCE namespace entry,
and any attempt by a file service client to access a file object whose name begins with
/.../tinseltown.org/fs will implicitly bind to this server, which will then be responsible for
finding, in its own namespace, the file object referred to by doc/jones/app.gd/chap2.ps
or doc/tolstoy/novels/war_and_peace/chap2.ps and performing the requested
operations on it.
5.1.1 The UUID
Thus, it is a mistake to suppose that a name is identical to an object. The name merely
points in the direction of the object it names. Objects do, however, have identifiers.
These are the 128-bit universal unique identifier (UUID) data structures, which are the
identities that the DCE components recognize. They are not usually seen by users,
although they play a part in the object-finding process.
UUIDs are used within DCE to identify all sorts of things. From the standpoint of the
application programmer, they have two main uses: to identify objects and to identify
interfaces.
5.1.2 Object UUIDs
Although object is necessarily a rather vague term, a reasonable definition would be the
following: an object is any DCE entity that can be accessed by a client, and which can be
represented by a namespace entry and identified therein by a UUID. This category can
include servers, devices, and other resources. UUIDs that are used in this way are called
object UUIDs in order to distinguish them from the other main use of UUIDs, namely to
identify interfaces (interface UUIDs). The difference between these two uses consists
only in the way the UUIDs are interpreted by the name service and RPC runtime. Note
that it follows from this discussion that an interface is usually not an object. Clients do
not normally access an interface as such; the interface is rather a description of the rules
of access.
5− 2 Tandem Computers Incorporated 124246