Binding handles, although they appear as parameters of RPCs, are in fact purely local to the server or client applications that use them. A binding handle is simply a reference to binding information that is cached by the local runtime. The runtime uses this binding information to construct its side of a client-server association. Even when a binding handle appears as an explicit parameter of an RPC, it is not marshalled or unmarshalled as call data in the same way as other call parameters.
On the client side, a binding handle parameter simply permits an application to indicate explicitly to the runtime which cached binding should be used for the call.
On the server side, a binding handle parameter provides a manager operation with a reference to cached binding information for the calling client so that the manager can, for example, extract authorization information about the client.
In calls to ubiquitous interfaces, such as the rpc_mgmt interface, partial bindings without an object UUID are rarely adequate, since the endpoint mapper cannot know which server supporting the ubiquitous interface is of interest to the client. The usual model is that the ubiquitous interface is not exported to the name space. Instead, the client imports bindings based either on another interface supported by the server or an object UUID. If servers follow the recommendation to export at least one UUID with their bindings, no additional preparation will be necessary to allow their clients to successfully call the ubiquitous interfaces the offer. If they do not export the UUID, they will have to adopt the rpc_ep_resolve_binding( ) method described in Routing Policy.