Client Import

· rpc_ns_entry_object_inq_begin( )
To set up an object inquiry context; the client application here specifies the name of the desired namespace object entry.

· rpc_ns_entry_object_inq_next( )
To return the object UUID that the server exported to the object's entry.
This UUID (which will be passed to the rpc_ns_binding_import_begin( ) routine, below) will enable the server host's endpoint mapper to accurately map the incoming remote procedure call to the server that exported this entry.
The UUID may also be used by the server itself to determine which object the client wants to access. Note that although this set of library routines is designed to accommodate schemes in which multiple object UUIDs have been exported to the same entry, the model described here requires that only one object UUID (the unique identifier of the object to bind to) be exported.

· rpc_ns_entry_object_inq_done( )
To delete the object inquiry context.

· rpc_ns_binding_import_begin( )
To set up a binding import context.
Note that the object UUID that was returned by the call to rpc_ns_entry_object_inq_next( ) must be passed to rpc_ns_binding_import_begin( ); as a result of this the import operation (rpc_ns_binding_import_next( )) will return only a binding with that object UUID.
An alternative to using the binding import routines would be to use the group member inquiry (rpc_ns_group_mbr_inq_*( )) routines to learn the name of the entry referred to in the group attribute, and then to do a direct import from that entry.
The reason for using the rpc_ns_group_mbr_inq_*( ) routines, rather than the normal import functions (rpc_ns_binding_*( )), would be to make sure that the group (and not some other) attribute in the entry is read. The rpc_ns_binding_import_next( ) routine is defined to successively exhaust the contents of an entry's

- binding attribute

- group attribute

- profile attribute

Since the model described here employs object entries with only group attributes and no binding or profile attributes, using the normal import routine should work fine.

· rpc_ns_binding_import_next( )
To read the entry's group attribute.
The name service's access to (and return of the binding handle from) the entry's group attribute is transparent and unerring because there is only one set of binding information associated with a given entry in this scheme, and that information is found only in the group attribute. Note that if there had been more than one member in the group, which in fact is generally the case when group attributes are used, then the order of return would be random. Or if there had been binding information associated with both attributes, then here also the order in which binding handles would be returned would be random; that is, the caller might get a handle from the simple name attribute first, and then the handles exported to the group members, or it might get one or more of the group's member's handles, then one or more of the simple entry's handles, and so on.

· rpc_ns_binding_import_done( )
To delete the binding import context.

The next figure illustrates this activity.

Importing from a Model That Uses Grouped Bindings

The client shown in the figure imports a binding for object A. This becomes (through the group attribute) a referral back to the server's entry where the bindings are held, and a binding is indirectly imported from the server entry. The object UUID for A is read, in a separate operation, directly from the object's entry. With this information in its binding handle, the client makes its first remote call through the server's interface. The call finds its way to the endpoint mapper via the partial binding information, and the endpoint mapper completes the binding by looking up the object UUID, which was registered there by the server.