Once you have distinguished the objects your application uses, you must decide on an appropriate set of names for the entries themselves. The entries can be created either by the application (server), if it has the necessary privileges, or by a system administrator using the rpccp command interface.
After the entries have been created, each server must do the following:
1. Create an object UUID for each object managed by the server under an interface, insert it into the binding handle(s) for that object, and export the handle(s) for each object to a separate entry
in the namespace.
Note that the object UUID should be generated and exported in general only once per created namespace entry, and not each time the server starts up (see the
example that follows of how to do this). When a newly restarted server exports its partial bindings, nothing actually happens in the namespace because the partial binding information remains the
same (unless the server has moved to a different machine). However, if the object UUIDs are regenerated, then the change in exported information will force needless update activity in CDS, which is
where the entries exist.
2. Register with the endpoint mapper the full bindings (including endpoints) obtained for the interface; rpc_ep_register( ) performs this operation.
One way of avoiding unnecessary regeneration of object UUIDs would be to have a restarted server check the namespace for the presence of its previously exported object UUIDs, as demonstrated in the following code fragment. Refer to the OSF DCE Application Development Reference for further information on the function calls.
have_object = false;
/* Create an inquiry context for inspecting the object */
/* UUIDs exported to "my_entry_name"... */
rpc_ns_entry_object_inq_begin(my_entry_name_syntax,
my_entry_name,
&context, &st);
/* If we successfully created context, look at */
/* object UUIDs... */
if (st == rpc_s_ok)
{
/* Try to get one object UUID from the entry... */
rpc_ns_entry_object_inq_next(context, &obj, &st);
/* If an object UUID is
there already, we don't */
/* need to generate another one... */
have_object = (st == rpc_s_ok)
/* Delete the
inquiry context... */
rpc_ns_entry_object_inq_done(&context, &st);
/* If there were no object UUIDs in the entry, */
/* generate one now... */
if (! have_object)
{
uuid_create(&obj, &st);
/*
Put it in an object UUID vector... */
objvec.count = 1; objvec.id[0] = &uuid; }
/* Export bindings. If an object UUID was generated,
*/
/* export it too... */
rpc_ns_binding_export( my_entry_name_syntax,
my_entry_name,
my_interface_spec,
my_bindings,
have_object ? NULL : &objvec, &st);
Whenever you want to offer more than one instance of the same interface on the same host, you must distinguish by object UUID the binding information in the name entries exported by the servers, if it is important to distinguish among the servers when binding to them. Otherwise, the endpoint mapper's selection of an endpoint with which to complete the binding from among all the servers on that host that offer the appropriate interface will be random.
The next figure illustrates what such an object-oriented namespace should look like.
Object-Oriented Namespace Organization
Each entry has a name denoting the object represented, although the names are not shown in this figure.
Under this model, clients bind to servers via named objects in the namespace, each of which contains enough specific information in its partial binding to allow the endpoint mapper at the destination host to choose an appropriate endpoint for the incoming RPC.
By setting a namespace up this way, however, you do not necessarily restrict yourself to this one model for accessing binding information. Through the use of two other types of entry, groups and profiles, which can be superimposed on the simple object model, you can set up models where clients bind to abstractions such as services, or directly to the servers themselves. These techniques are described in the next topic.
Nevertheless, at this point you have enough information to set up a namespace that consists of an entirely flat expanse of separate resource entries. Bindings can be imported by clients by looking up specific names. If the client has no specific name to look up, or if the lookup on the name(s) it has fails, it has no alternative way of binding to a server.