There are many ways in which clients and servers can arrange the details of binding among themselves, including: how bindings are exported and imported, whether object UUIDs are used, and how object-type mappings are established. High-level resource policy issues relating to the name service and endpoint mapper are discussed in Using the DCE Name Service . In this topic, some of the lower-level routing policy questions that arise from the binding model itself will be discussed. These, in fact, have a substantial impact on how the namespace is used by applications.
The most important issues concern the role of UUIDs in the binding model. Interface identifiers, which consist of a UUID and version number, have a well-defined and unambiguous role. But object UUIDs are somewhat overloaded by the binding model. An object UUID may be used to select bindings from the name service, to select endpoints from the endpoint mapper, and to map a call to the correct manager type within the server. Furthermore, a server may use object UUIDs in some application-specific way to identify and manipulate the objects it manages.
There is great potential for conflict between the use of object UUIDs to select bindings and endpoints and their use to identify objects and routes to manager types. This conflict is particularly evident in the case of servers that provide so-called ubiquitous interfaces, such as the rdacl interface. Because many servers on a host are likely to export such an interface, it is essential to have an object UUID to identify the correct endpoint in the endpoint map. Without an object UUID, the endpoint mapper can only return the endpoint of some server that exports the requested interface, very likely the wrong one.
An alternative strategy does exist: a client can call rpc_ep_resolve_binding( ) using a nonubiquitous interface that it knows the server of interest does export. The call to the ubiquitous interface can then be made with the resolved binding. Clients often use this technique to call the remote rpc_mgmt_* routines. Nevertheless, the objection remains that it is still impossible to select among endpoints of servers or server instances that export the same nonubiquitous interface.
The most straightforward solution is for a server to export a UUID to the namespace where it functions as an unambiguous tag for the servers' endpoints. Clients can find this UUID either by importing it from a named entry or it may be made well-known, effectively becoming a stable, well-known tag for the server's volatile endpoints. When endpoint UUIDs are well-known, they become useful for finding servers even when the client is interested in a nonubiquitous interface. Exactly how servers export and clients find these UUIDs depends on the resource model adopted, as discussed in Using the DCE Name Service.
This obvious use of UUIDs as endpoint identifiers, however, potentially conflicts with their use as object identifiers. According to the RPC binding model, when clients import bindings based on object UUIDs, these UUIDs are incorporated into call bindings where they may used for endpoint selection, for manager selection, and possibly for some application-specific purpose. If an application exports its object UUIDs to the namespace, then they are used both to identify objects and to identify endpoints. This means that, at a minimum, a server would need to maintain a potentially large number of mappings to the same endpoints.
Moreover, especially when servers manage many objects or create them dynamically, clients will typically know objects by names rather than by UUIDs. Servers can provide such mappings via the namespace itself by exporting each object UUID to a different namespace entry, but this even further complicates the server's job of maintaining its exports and mappings.
The obvious solution to these problems is to have servers maintain their object UUIDs and name-to-object UUID mappings internally. The basic RPC binding mechanism does not provide much support for this approach: there is no generic way for servers to make objects or names available to clients except through the name service. Also, a UUID used to identify a server endpoint is probably useless for call routing to a manager type within a server. However, the higher-level object management interfaces discussed in Using the DCE Name Service provide this functionality.
This leads to two important recommendations:
· Servers should export to the namespace at least one UUID as a tag for its endpoints, and should register the UUID with the endpoint map.
· Servers which support multiple objects should also support the object management interface(s) discussed in Using the DCE Name Service, instead of exporting multiple object UUIDs to the namespace.