OSF DCE Application Development Guide--Introduction and Style Guide

Using the DCE Name Service
5.13 Models Based on Non-CDS Databases
The three models previously described are not mutually exclusive; if the namespace is
set up correctly, all three can coexist at the same time. All three of the models are
implemented through the functionality of the DCE RPC name service.
Although the emphasis in this discussion has been placed on the storage and retrieval of
binding information, the namespace entries can be used to store additional states for
objects. In order to do this, an application would have to create additional attributes on
the CDS entries it intended to use because the name service recognizes only the four NSI
attributes: binding, object, group, and profile.
Such additional entry attributes would be created and accessed through XDS. However,
whenever you find yourself contemplating extending the name service in this manner,
you should carefully consider whether the name service (and, consequently, CDS) is the
best mechanism for doing what you want to do.
In the preceding example, where an object-oriented namespace containing separate
entries for individual printers was described, only the identifier for the printer (the object
UUID) and the binding for the server that managed it were stored in the CDS entry.
Other information, such as what jobs are currently queued for the printer, who owns the
jobs, and so on, was maintained by the server. This data could be stored in CDS only by
creating new attributes to put it in, but it would be changing too quickly for CDS to
efficiently keep up with it anyway. The performance of both the application and CDS
would suffer from such an arrangement.
It is possible to imagine distributed applications whose resources (the objects they are
managing) are of such a nature that they could be more efficiently managed through a
private application-implemented database. Suppose the number of managed objects is
very large, or that the state of the objects is volatile. It would certainly be a bad idea to
try to use CDS to store this kind of information, which would be changing much more
rapidly than CDS’s ability to propagate the updates.
5.13.1 Example of a Privately Managed Database
As an example of such a privately managed database, consider a print service where jobs
are submitted not to individual printers, but rather to a generic printer service. The
client, lpr, binds (probably through a group entry) to some certain print server, and sends
the job to be printed to that server, which then, after some thought, sends the job to one
of the printers that it manages.
Consider, for example, what happens if a user invokes the client cancel sometime later to
stop a job. If, for example, the original command was
lpr War_and_Peace.ps
and the subsequent request to cancel is
124246 Tandem Computers Incorporated 5− 23