OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
to specific operations.
Implicit binding allows the client to establish a default binding for an interface. When
the [implicit_binding] attribute is applied to a data item in the ACF, then each call that
does not specify an explicit binding parameter (either in the IDL or via the
[explicit_binding] attribute in the ACF) uses the default binding information referenced
by the implicit binding data item.
With automatic binding, the client stub finds a useable binding for each RPC. Automatic
binding is the default for any operation when the following three things are true:
• Implicit or explicit binding has not been specified in the ACF for the interface
• The call does not specify an explicit binding handle parameter
• The ACF does not specify explicit binding for the call
The semantics of automatic binding may differ between the first and subsequent calls on
an interface. When the runtime does not have a cached compatible binding, the stub will
perform a namespace search to find and import one. The imported binding will be
cached for use in subsequent calls. If the client-server connection for the cached binding
fails, the client stub will attempt to find a new binding. Therefore, it is possible that later
calls will not be made on the same binding, and possibly will even be made to a different
server.
A server binding handle that the runtime provides directly to an application is a primitive
binding handle. To declare a primitive binding handle, application code uses the
predefined RPC binding handle data type rpc_binding_handle_t, and an interface
definition uses the IDL data type handle_t. Primitive binding handles offer a simple
means of referring to binding information, which works in most cases. The automatic
method of binding management always uses primitive binding handles.
Applications that use the implicit or explicit methods of binding management can choose
to store primitive binding handles in an application-specific data structure known as a
customized binding handle. Customized binding handles enable application developers
to manage binding information to meet the special needs of a specific application. For
example, a customized binding handle can be the handle of a file whose records contain
the information required to construct a string binding.
Using customized binding handles requires the application developer to perform several
special tasks. The RPC interface definition must include a declaration of the customized
binding handle as a data structure with a handle data type; this is done by using the
handle attribute. The client application code must contain specialized procedures that
the client stub calls to obtain a primitive binding handle from the customized handle and
to release any resources, such as memory, used for the customized handle.
When a customized binding handle is used with the explicit method, responsibility for
setting the binding handle shifts to the client stub. The client code provides procedures
for obtaining the primitive binding handle from the customized handle and for freeing
the primitive binding handle after the call completes. However, it is the stub that calls
these procedures to set and free the primitive binding handle.
Calls made with a context handle and no explicit binding handle also have automatic
binding semantics. That is, such calls will use the cached binding associated with the
context handle. Of course, this binding may have been constructed by the client
application and passed, either as an explicit or implicit binding, to the call that returned
4− 12 Tandem Computers Incorporated 124246