[Up: Design and Implementation of]
[Previous: Evaluation] [Next: Basic Object Adapter]

Object Adapters

Using CORBA-based services is rather simple and straightforward: After receiving and translating the IDL file into the target language, all that is needed is an object reference. Henceforth, methods on the remote object can be called through the stub object as if they were local.

More thought must be spent on the server-side, where servants are to be provided. Even after registering the actual program code with the ORB - for example by passing C++ objects - the programmer will usually want to have a certain control over ORB processing, such as when a method may be executed. Missing control on the server side is also a frequent complaint about RPC (see section 2.4.1), where a server is simply expected to run in perpetuity, not having any control over the execution of incoming requests.

The OMG concluded that an implementation's requirements are highly dependent on the operating system, programming language, and environment. For the sake of an example, the needs of a server representing an object database would be very different from a server providing a printing service.

In order to allow for different possibilities, the handling of actual user code, servants, is decoupled from normal ORB processing by the introduction of object adapters. An object adapter serves as mediator between the ORB and the servant, providing the ORB with a consistent interface for interacting with user code, and being flexible in cooperating with the servant. Different object adapters could then be provided to suit the various server requirements, and an implementation could choose between them and select the most appropriate.

Figure 4.1: Server-side view of the ORB

Gamma, Helm, Johnson and Vlissides [10] define an object adapter as a design pattern to achieve a ``reusable class that cooperates with unrelated or unforeseen classes.'' According to their definition, an object adapter receives a client's request and translates it into a request that is understood by the ``adaptee,'' the servant. This description matches that of a CORBA object adapter [57] quite well. The basic task of an object adapter is a simple one of dispatching an incoming request to user code, the servant.

When an invocation is made, the client-side ORB is responsible for interpreting the object's profiles, for locating the server in which the object is implemented, and for sending a request to that server. On the server side, the request is received by the ORB, where three steps of dispatching are necessary:

1. The ORB must find the object adapter that the object is implemented in and pass the request on to that object adapter.
2. The object adapter must find the servant that implements the object.
3. If the servant uses a static skeleton, the request is unpacked by the IDL-generated code and the desired method is invoked.

But before any of this can happen, the object adapter must first know about the servant. After registering the servant with the object adapter, an implementation must be able to create and export object references that address the servant. So beside merely performing invocations, the object adapter must provide an administrative interface as well. The OMG lists the following white-paper responsibilities [25] of an object adapter:

• registration of implementations
• mapping object references to the corresponding object implementations
• object and implementation activation and deactivation
• generation and interpretation of object references
• method invocation
• security of interactions

The first five items have already been mentioned; the security of interactions is only historical, as it is not a server-side issue only. Security must be an integral part of ORB processing and is now addressed by the Security Service [36] instead.

Figure 4.1 shows the object adapter in relation to the other server-side parts of an ORB. The object adapter is sandwiched between the ORB core and the object implementation and has to provide three interfaces: one to the ORB, which consists of a single method to receive an incoming request, one to the user code to pass this request to, either using the Dynamic or Static Skeleton Interface, and one administrative interface through which an implementation can cause objects to be activated or deactivated, and can influence the processing of requests.

The most simple object adapter would be no more than a table that maps object keys (the server-side part of an object reference) to servants. Upon invocation, only a single table lookup would be necessary, and activation and deactivation of servants would cause insertions and deletions into that table.

In fact, the Basic Object Adapter (BOA), the first and until recently only object adapter specified by the OMG, is little more than that. As the name suggests, it does not provide much but basic functionality, and it was envisioned that a range of further, more specific object adapters would be added later on.

An object adapter has a certain impact on the programming style to be used, as each brings its own concepts and enforces a concrete structure for servants that an implementation has to submit to. Apart from the very generic description above, object adapters do not have a common behavior, but have to be considered individually.

[Previous: Evaluation] [Next: Basic Object Adapter]
[Up: Design and Implementation of]