Earlier we described how to establish an EPV for each set of operations provided by interfaces. Remember that an EPV is a list of pointers to procedures. The first affect of registering the server is to register the services offered (represented by IDL interfaces) and the associated EPVs with the RPC runtime. Registering interfaces with their associated EPVs allow the RPC runtime to use the EPVs to direct an incoming remote procedure call to the correct procedure implemented in the server's manager code.
We also described earlier the type manager mechanism which uses a type UUID to group together object UUIDs. With this mechanism, a different EPV can be associated with each type UUID so that different manager code can be called, depending on an object's type UUID. After these EPVs are registered with the runtime, incoming RPC binding that contain a typed object can be routed by the runtime to the correct manager code.
The data structure the server uses to establish its services is of type dce_server_register_data_t. This data structure is initialized prior to the dce_server_register( ) routine call as in the following example:
dce_server_register_data_t register_data[2];
.
.
.
register_data.ifhandle[0] = rdaclif_v1_0_s_ifspec;
register_data.epv[0] = NULL; /* use the default epv */
register_data[0].num_types = 0;
register_data[0].types = NULL;
register_data.ifhandle[1] = sample_bind_v1_0_s_ifspec;
register_data.epv[1] = NULL; /* use the default epv */ register_data[1].num_types = 0;
register_data[1].types = NULL;
The dce_server_register( ) routine usually establishes all the services for a server at once. This is a reasonable approach for most applications, but some interfaces for services may have dependencies on the order in which they are enabled. After the server calls dce_server_register( ), it can use a series of calls to dce_server_disable_service( ) and dce_server_enable_service( ) to disable and then later reenable any interface offered by the server.