OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming
dce_msg_define_msg_table(smp__table,
sizeof smp__table / sizeof smp__table[0],
&status);
if (status != error_status_ok)
{
print_server_error("dce_msg_define_msg_table()", status);
exit(1);
}
dce_svc_printf(SIGN_ON_MSG);
.
.
.
DCE_SVC_DEBUG((smp_svc_handle,
smp_s_server,
svc_c_debug4,
"Calling dce_server_sec_begin()");
1.5.2 Setting Up the Server’s Objects
The term object is a very general term that has meaning specific to each application.
DCE uses object UUIDs to uniquely identify any object. The creation of object UUIDs,
the determination of what (if anything) constitutes an object for a server application, and
the association of these objects’ UUIDs into collective types are all your application
design decisions.
Object UUIDs have a double use in the routing of RPCs, and you may at first find this a
bit confusing. One use of object UUIDs is in the DCE RPC binding mechanism so that
clients can distinguish between specific resources, and another use of object UUIDs in
routing involves grouping objects into types so that a server can support different
implementations of the same interface. (DCE servers also use type UUIDs to associate
objects for each ACL manager.)
If an application makes use of object UUIDs in bindings, it makes them accessible to
clients by exporting them with its bindings when a server registers with DCE.
The following shows sample code to create UUIDs for server objects and how to store
them using the backing store API:
.
.
.
/* A "well-known" residual name for the management "object": */
#define MGMT_OBJ_NAME "server_mgmt"
/* */
/* A residual name for a sample object: */
#define SAMPLE_OBJECT_NAME "sample_object"
.
.
124246 Tandem Computers Incorporated 1− 15