The type UUIDs and the type manager vectoring mechanism have nothing to do with the use of the object UUIDs themselves as lookups for the host endpoint mapper. The type manager vectoring occurs after object UUID binding happens, at the server. Note also that object UUID binding happens only once in an uninterrupted client/server session; after the partial binding is completed, communications proceed directly between the client and server. Type manager vectoring, on the other hand, occurs every time an incoming RPC contains an object UUID.
The very different nature of the two mechanisms just discussed is somewhat obscured by the order in which they are initialized in the steps in this topic. The following list shows the relevant server steps, with an indication in each instance to which mechanism they are related:
1. When setting up the server's objects, groups of object UUIDs are associated under type UUIDs in the RPC runtime related to the type vectoring mechanism.
2. When defining the manager EPVs, each type UUID is associated with a manager EPV (in the RPC runtime) related to the type vectoring mechanism.
3. When registering the server, object UUIDs and server endpoints are registered with the server's endpoint mapper and the server bindings (containing the object UUIDs) are exported into the namespace. These are related to the endpoint mapping mechanism.