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"
.
.
.
/* These are the backing store database handles: */
dce_db_handle_t db_acl, db_object, db_name;
.
.
.
/* A UUID for a sample object: */
uuid_t sample_object_uuid = {/* 00415371-f29a-1d3d-b8c8-0000c0d4de56
*/
0x00415371, 0xf29a, 0x1d3d, 0xb8, 0xc8, 0x00, 0x00, 0xc0, 0xd4,
0xde, 0x56 };
.
.
.
uuid_create(&server_uuid, &status);
..
..
..
dce_db_store_by_uuid(db_object, object_uuid, (void
*)&sample_data,
status);
if (*status != error_status_ok)
{
print_server_error("dce_db_store_by_uuid()", *status);
return;
}
/* Finally, store the object UUID keyed by the object */
/* ("residual") name... */
dce_db_store_by_name(db_name, (char *)object_name, object_uuid,
status);
.
.
.
Names are established so that applications can refer to objects in a way other than through the cumbersome UUID. Object UUIDs are generated in the following two ways:
· The uuidgen -s command generates the C-structure form of a UUID that can then be hard-coded into applications
· The uuid_create( ) routine generates a UUID "on-the-fly.''
After creating backing store headers (if desired) and opening the backing store databases, UUIDs are stored by calling the dce_db_store_by_uuid( ) routine. To store names associated with the UUIDs, call the dce_db_store_by_name( ) routine.
More:
Making Object-UUID/Type-UUID Associations
Summary of Mechanisms that Rely on Object UUIDs