When developing an RPC application, you need to decide whether to use object UUIDs to identify RPC resources and, if so, what sorts of resources receive UUIDs that servers export to the namespace. When making these decisions, consider the following questions:
· Will users need to select a server entry from the namespace based on what object UUIDs the entry contains (and what the client needs)?
If yes, then a client must specify an object UUID to the import operation.
· Does the type of resource you are using last for a long time (months or years), so you can advertise object UUIDs efficiently in the namespace?
The information kept in a namespace should be static or rarely change. For example, print queues are appropriate RPC resources. In contrast, quickly changing information, such as the jobs queued for the printer, owners of the jobs, or the time the job was added to the queue, should not be viewed as RPC resources. Such short-lived data may be viewed as local objects, which are stored and managed at a specific server. Programming with local objects is in the area of regular object-oriented programming and is independent of an application's use of RPC resources.
· Is the number of objects belonging to the type of resource bounded in order to avoid placing high demands on the directory service?
· Will the server implement an interface for different types of a resource, such as different forms of calendar databases or different types of queues?
If yes, then the server must classify objects into types. For each type, the server generates a nonnil UUID for the type UUID, sets the type UUID for every object of the type, and specifies that type as the manager type when registering the interface. When making a remote procedure call to the interface, a client must supply an object UUID to specify an RPC resource.
· Is control over specific resources an important factor for distinguishing among server instances on a host?
If yes, then each server must generate an object UUID for each of its resources.
For some applications, such as those accessing a database that many people use, shared access to one or more objects may be essential. However, not all objects accommodate such shared access.