After server registration obtains the endpoints, the endpoints, protocol sequences, and object UUIDs are registered with the endpoint mapper service of the local host's dced.
Typically the server has received a certain number of endpoints dynamically allocated on its host machine. However, when prospective clients import binding information from the namespace, they get partial bindings. When they first try to contact their server, the partial binding will get them only as far as the server's endpoint mapper service. The purpose of registering endpoints is to let the endpoint mapper know what endpoints belong to the server so that it can fill in the partial bindings as they arrive and route the incoming remote calls on their proper ways. Subsequent remote calls executed with the same bindings will go straight to the server, since the bindings are now complete.
The purpose of registering endpoints together with object UUIDs is to account for all possible incoming object UUIDs (that is, object UUIDs that could appear in incoming partial bindings arriving at the endpoint mapper), and to associate with each of them one of the server's allocated endpoints. Then the endpoint mapper can simply look up the object UUID, find an endpoint, insert it into the binding, and send the RPC on to its destination.
An incoming RPC always has an interface UUID associated with it; therefore, if a server registers all of its endpoints with the interface it is offering, this will usually be sufficient for the endpoint mapper to send the incoming requests to one of the servers that offer the desired interface, even if there is more than one such server active on the machine. However, if the application is designed in such a way that the binding operation should not be generalized to the interface but must be made more specific (in other words, this server's clients should always bind to this server and no other, even if some other server happens to offer the same interface), then object UUIDs must be used to accomplish this. Generic interfaces offered by an application (such as the remote ACL or the DCE serviceability interface) require an object UUID in order to distinguish the application's instance of them; unique interfaces, however, do not require an object UUID.
Of course, the server's interface UUID must also be included in each object UUID/endpoint mapping, since no RPC will pass the endpoint mapper if it does not have a matching interface UUID for its destination server. Therefore, the endpoint mapper takes either two or three types of item to be registered, namely
· Endpoints
· Interface UUID
· Object UUIDs (optionally)
It then generates a cross-product table of all possible combinations of all values of the items. This allows it to find a valid endpoint for every possible valid object UUID/interface UUID combination.
The endpoint mapper is the first point of decision for an incoming RPC with a partial binding. The mapper makes its decision solely on the basis of the contents of its endpoint map. The object/type and manager EPV registrations that were done earlier have no effect on the endpoint mapper. Only after a client request arrives at the server does the server's runtime routines dispatch the request among multiple managers, if type managers have been registered by the server. The endpoint mapper knows nothing about registered object types.