PreviousNext

Binding Methods

In view of what was said earlier about binding handles, the binding method chosen also will be a purely local matter for the client application and stubs. For example, it is perfectly feasible for a server manager to make explicit use of binding information via a binding handle parameter in a remote call, even though the client does not use an explicit handle for the call.

DCE RPC provides the automatic, implicit, and explicit methods for clients to manage bindings for remote procedure calls:

· Automatic method
This is the simplest method of managing the binding for remote procedure calls of an entire interface. With the automatic method, the server exports its binding information to a namespace, and the client stub automatically manages a binding for the application code.

The automatic method completely hides binding management from client application code. The stub imports the binding information and maintains a binding handle. The stub passes the binding handle to the runtime with the remote procedure call, and the runtime uses the binding handle to retrieve the associated binding information. If the client makes a series of remote procedure calls to the same interface, the stub passes the same binding handle with each call.

With the automatic method, a disrupted call can sometimes be automatically rebound. The automatic rebinding requires either that the remote procedure never begins to execute or that the operation is idempotent. If the call meets either of these requirements, the RPC runtime automatically tries to rebind the client to another server (if one is available).

· Implicit method
This is a relatively simple method of managing a binding for an entire interface. With the implicit method, prior to making any remote procedure calls, the client application code obtains server binding information from a namespace or a string binding. The client assigns a server binding handle to a global variable in the client application (for each interface using this method). When calling a remote procedure using the implicit method, the client stub passes the specific interface's global binding handle to the runtime.

Note: Multithreaded clients must be careful not to allow one thread to change the value of the shared global binding handle while another thread is using it.

· Explicit method
This is a more complex yet more flexible method of managing a binding. As with the implicit method, the explicit method requires that the client application code call runtime routines to initialize a binding handle. In the explicit method, however, this binding handle is supplied by the application code as a parameter to the remote procedure call. By allowing a client to manage bindings for individual calls, the explicit method enables clients to meet specialized binding requirements.

The following figure shows the distribution of responsibility for binding management in applications for each of the three methods. The top portion of each box represents the client application code written by the developer. The bottom portion of each box represents the client stub code generated from an IDL interface definition.


Methods of Binding Management

You can see from this figure that with the automatic method, binding management belongs completely to the client-stub code generated by the DCE IDL compiler. The implicit method provides the application developer with some control over binding management without having to pass a binding handle as a call argument. With the explicit method, the application developer is completely responsible for binding management. The automatic method requires the server to store binding information in server entries in a namespace; the implicit and explicit methods work with any source of binding information.

A client can use a combination of methods, even for an individual interface or if it uses more than one interface. for example, one interface might use the automatic method, another interface could use the implicit method, and a third could use the explicit method. In addition, some procedures for the interfaces that use automatic or implicit methods could use the explicit method instead. The method(s) of binding management for an interface is specified using the interface definition, the attribute configuration file (ACF), or both. In the interface definition, the explicit method can be specified for the whole interface, or for an operation by declaring a binding handle (using the IDL type handle_t) as the first parameter of the operation declaration.

The automatic and implicit methods are interface-wide and therefore mutually exclusive; that is, for a given interface, a client can use only one of these interface-wide methods. A client that uses either the automatic or implicit method for an interface can also use the explicit method for some or all of the remote procedure calls to that interface. If the remote procedure call has a binding handle parameter, the explicit method takes precedence over either the automatic or implicit methods of managing bindings.

Explicit and implicit binding both give the client application means to select and modify the binding information used by calls. Explicit binding allows the client to specify binding information per call. This method may be established either by declaring a binding handle parameter as the first parameter for a call in the IDL, or by applying the [explicit_binding] attribute in the associated ACF, either to the interface as a whole, or 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 the context handle. Also, the stub will not attempt to renew such a cached binding if the client-server connection fails. Even if the server is still running and the connection could be reestablished, the server will have rundown the context it is holding for the client, so that the context handle will no longer be valid. When implicit binding is in effect, a call made with a context handle and without an explicit binding parameter will use the cached binding associated with the context handle rather than the implicit binding.

The following table summarizes the binding semantics applied to a client operation:


Binding Semantics

ACF ACF ACF ACF/IDL IDL Binding
auto_handle
attribute
implicit_handle
attribute
explicit_handle
attribute
on interface
explicit_handle
attribute
on interface
context
handle
Semantics
No
No

No
No
No
No

No
No
No
No

No
No
No
No

Yes
Yes
No
Yes

No
Yes
Auto
Auto
(context handle)
Explicit
Explicit
Yes
Yes

Yes
Yes
No
No
No

No
No
No
No

No
No
Yes
No

Yes
No
No
Yes

Yes
Auto
Explicit
Auto
(context handle)
Explicit
No
No
No

No
Yes
Yes
Yes

Yes
No
No
No

No
No
Yes
No

Yes
No
No
Yes

Yes
Implicit
Explicit
Auto
(context handle)
Explicit
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
No
Yes
No
Yes
No
No
Yes
Yes
Explicit
Explicit
Explicit
Explicit
When a binding handle is selected automatically by the client stub, there is no way for the application to specify authentication data. In principle, it would be possible to have the client authenticate itself to the server in such a case, although a client that does not care about which server it calls obviously cannot authenticate the server. In practice, calls made with automatic bindings are simply unauthenticated. Therefore, if your application cares about authentication, it should avoid using automatic binding.