OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
TABLE 5-1. Some Examples of Objects
_____________________________________________
Service Object(s)
_____________________________________________
_____________________________________________
Printing A specific printer
Process Server A specific server
The print queue,the kill queue, the
backup queue
Queue Service
_____________________________________________
Thus, for a client that wants to have a file printed, it is natural to allow it to specify a
printer as a destination. Therefore, the client would bind to the print server through a
name entry that specifies a printer. To send something to a different printer, the client
would import a binding from the name entry for that other printer. The server may (or
may not) be identical, but the object UUID in the binding handle returned would
uniquely specify the one printer represented by that entry.
On the other hand, consider an application that returns statistics about the processes
currently active on a group of machines. In this case it would be reasonable to regard the
server as the object. In the namespace entries for such an application, each entry would
uniquely represent one server. A client would import a binding from the name entry for
the server it wanted to work with.
In other words, object is a handy way of saying ‘‘the thing that clients will want to
access’’ in order to accomplish the task set for the application. If the namespace is
organized correctly, clients will be able to import bindings from these objects’ entries.
5.10 Setting Up an Object-Oriented Namespace
Once you have distinguished the objects your application uses, you must decide on an
appropriate set of names for the entries themselves. The entries can be created either by
the application (server), if it has the necessary privileges, or by a system administrator
using the rpccp command interface.
After the entries have been created, each server must do the following:
1. Create an object UUID for each object managed by the server under an interface,
insert it into the binding handle(s) for that object, and export the handle(s) for each
object to a separate entry in the namespace.
Note that the object UUID should be generated and exported in general only once
per created namespace entry, and not each time the server starts up (see the
example that follows of how to do this). When a newly restarted server exports its
partial bindings, nothing actually happens in the namespace because the partial
binding information remains the same (unless the server has moved to a different
machine). However, if the object UUIDs are regenerated, then the change in
exported information will force needless update activity in CDS, which is where
the entries exist.
2. Register with the endpoint mapper the full bindings (including endpoints) obtained
for the interface; rpc_ep_register( ) performs this operation.
5− 16 Tandem Computers Incorporated 124246