OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
cancel War_and_Peace.ps
then how does the server that cancel binds to find the right job to delete? There is no
guarantee that cancel will bind to the same server that happened to receive the original
print request, so having each print server keep track of its own jobs would not be the
answer.
One way to keep track of jobs queued would be to have a dedicated job location server
as part of the application. Each time a print server queued a job to a printer it would
record the fact (with all the pertinent details) with the location server. Whenever a job
completed, the server would again notify the location server to remove its record of that
job from its database. A client cancel then binds first to the location service, where it
receives the name of the print server associated with the job it wants to cancel. It then
looks up that name, binds to the right print server, and sends the cancel request. In
effect, the location server has become a name service for cancel.
This method of organizing activity results in a split-model database. The print servers’
binding information is managed through CDS, as usual, and the location server manages
other more volatile information associated with those same servers.
Another way a server could maintain its own database of named objects would be by
implementing a junction.
5.13.2 Combining Models
In designing a binding access model for an application, consider also whether it may be
appropriate to combine some of the models previously discussed. In the print service
application, it may be desirable for servers to also offer a management interface to
specific servers rather than to specific objects; for example, lpr, lpq, and lprm are
generic application clients, so it is appropriate for them to bind to printer objects, but if
lpr_mgmt is supposed to manage characteristics of a whole service, then it should bind
to servers.
5.14 An Object-Oriented Model with Grouped Binding
Information
The following variation on the object-oriented binding model shows how the group
attribute can be used in object entries. In this model, each of the object entries contains,
as before, an object UUID that will uniquely identify (either to the endpoint mapper on
the exporting server’s machine, and/or to the server itself) the object referred to by that
entry. However, the object entries do not contain any binding information. Instead, a
group attribute in each object entry refers clients’ import operations back to the server’s
own separate entry, which contains the binding information for that server.
The namespace ingredients of this model are the following:
5− 24 Tandem Computers Incorporated 124246