6.4.1 Object adapters

An object adapter is responsible for the following functions:

• Generation and interpretation of object references
• Registration of servants
• Mapping object references to the corresponding servants
• IDL method invocations, mediated by skeleton methods
• Servant activation and deactivation

The Functional Developer ORB library provides an implementation of the Portable Object Adapter (POA). This object adapter forms part of the CORBA standard and, like the ORB, has an interface that is specified in pseudo IDL (PIDL). The Functional Developer interface to the POA conforms closely to the interface obtained by applying the Dylan mapping rules to the POA's PIDL specification.

A POA object manages the implementation of a collection of objects, associating object references with specific servants. While the ORB is an abstraction visible to both the client and server, POA objects are visible only to the server. User-supplied object implementations are registered with a POA and assigned object references. When a client issues a request to perform an operation on such an object reference, the ORB and POA cooperate to determine which servant the operation should be invoked on, and to perform the invocation as an upcall through a skeleton method.

The POA allows several ways of using servants although it does not deal with the issue of starting the server process. Once started, however, there can be a servant started and ended for a single method call, a separate servant for each object, or a shared servant for all instances of the object type. It allows for groups of objects to be associated by means of being registered with different instances of the POA object and allows implementations to specify their own activation techniques. If the implementation is not active when an invocation is performed, the POA will start one.

Unfortunately, the flexibility afforded by the POA means that its interface is complex and somewhat difficult to use. The example in this tutorial makes only elementary use of the POA.

Here is the PIDL specification of the facilities of the POA that are used in this tutorial:

module PortableServer {

  native Servant;

  interface POAManager {
    exception AdapterInactive{};

    void activate() raises (...);
    ...
  };

(see next page)

  interface POA {
    exception WrongAdapter {};

    readonly attribute POAManager the_POAManager;

    Object servant_to_reference(in Servant p_servant) 
      raises (...);

    Servant reference_to_servant(in Object reference) 
      raises (WrongAdapter, ...);
    ...
  };
};

The POA-related interfaces are defined in a module separate from the CORBA module, called PortableServer. That module declares several interfaces, of which only the POA and POAManager are shown here.

The PortableServer module specifies the type Servant. Values of type Servant represent language-specific implementations of CORBA interfaces. Since this type can only be determined by the programming language in question, it is merely declared as a native type in the PIDL.

In the Dylan mapping, the Servant type maps to the abstract class PortableServer/<Servant>. User-defined Dylan classes that are meant to implement CORBA objects and be registered with a POA must inherit from this abstract class.

Each POA object has an associated POAManager object. A POA manager encapsulates the processing state of the POA it is associated with. Using operations on the POA manager, an application can make requests for a POA to be queued or discarded, and can have the POA deactivated.

A POA manager has two main processing states, holding and active, that determine the capabilities of the associated POA and the handling of ORB requests received by that POA. Both the POA manager and its associated POA are initially in the holding state.

When a POA is in the holding state, it simply queues requests received from the ORB without dispatching them to their implementation objects. In the active state, the POA receives and processes requests.

Invoking the POA Manager's activate operation causes it, and its associated POA, to enter the active state.

A POA object provides two useful operations that map between object references and servants: servant_to_reference and reference_to_servant.

The servant_to_reference operation has two behaviors. If the given servant is not already active in the POA, then the POA generates a new object reference for that servant, records the association in the POA, and returns the reference. If the servant is already active in the POA, then the operation merely returns its associated object reference.

The reference_to_servant operation returns the servant associated with a given object reference in the POA. If the object reference was not created by this POA, the operation raises the WrongAdapter exception.

---

Developing Component Software with CORBA - 26 May 1999