OSF DCE Application Development Guide--Core Components

Using the DCE Serviceability Application Interface
3. Runtime steps
• At server startup:
The binding handles that the server receives from the RPC runtime, and which
it then registers both with the Name Server Interface (NSI) and the endpoint
mapper under its ‘‘own’’ interface, must also be registered to the endpoint
mapper with the serviceability interface. Note that servers do not explicitly
register the serviceability interface with the NSI. Instead, they use their
existing namespace entries without change. They do register the serviceability
interface with their endpoint mapper.
• For a client application:
To call one of a server’s remote serviceability routines, the client must import a
binding handle using a NULL UUID; this operation will yield a ‘‘plain’’
handle. The client can then pass this handle to the desired remote
serviceability routine and make the call. The server’s host endpoint mapper
will recognize the incoming serviceability UUID in the RPC, and will send the
RPC on to one of the registered endpoints.
The following code fragments illustrate how to define, export, and access the
serviceability remote interface.
4.3.14.2 Implementing the Remote Routines
The following code fragments show in skeletal form how an application’s remote
serviceability routines should be implemented. The pseudo-code references to ‘‘access
tests’’ are calls to the application’s ACL manager to assess the caller’s authorization. For
information on implementing an ACL manager, see the security chapters of the and the .
#include <dce/dce.h>
#include <dce/dce_msg.h>
#include <dce/dcesvcmsg.h>
#include <dce/svcremote.h>
struct serviceability_v1_0_epv_t dce_svc_epv;
/*****
*
* hel_svc_set_route -- remote call-in to set routing.
*
*****/
static void
hel_svc_set_route(
handle_t h,
idl_byte where[],
error_status_t *st
)
124245 Tandem Computers Incorporated 4− 41