Architecture

 

The general idea is to have each server contain a hierarchy of POAs. Only the Root POA is created by default; a reference to the Root POA is obtained using the resolve_initial_references() operation on the ORB. New POAs can be created as the child of an existing POA, each with its own set of policies.

Each POA maintains an Active Object Map that maps all objects that have been activated in the POA to a servant. For each incoming request, the POA looks up the object reference in the Active Object Map and tries to find the responsible servant. If none is found, the request is either delegated to a default servant, or a servant manager is invoked to activate or locate an appropriate servant.

Associated with each POA is a POA Manager object. A POA Manager can control one or many POAs. For each incoming request to an object, the POA Manager's state is checked, which can be one of the following:

Active

 
Requests are performed immediately.

Holding

 
Incoming requests are queued. This is the initial state of a POA Manager; to perform requests, the POA Manager must be explicitely set to the Active state.

Discarding

 
Requests are discarded. Clients receive a TRANSIENT exception.

Inactive

 
This is the ``final'' state of a POA Manager, which is entered prior to destruction of the associated POAs. Clients receive an OBJ_ADAPTER exception.

Before continuing, we should more precisely define a few terms that have already been freely used.

Object Reference

 
On the client side, an object reference encapsulates the identity of a distinct abstract object. On the server side, an object reference is composed of the POA identity in which the object is realized, and a Object Id that uniquely identifies the object within the POA.

Object Id

 
An Object Id is an opaque sequence of octets. Object Ids can be either system generated (the POA assigns a unique Id upon object activation), or user generated (the user must provide an Id upon object activation). The object's Object Id cannot be changed through the object's lifetime.

In many cases, object references and Object Id can be used synonymously, since an object reference is just an Object Id with opaque POA-added ``internal'' information.

Servant

 
A servant provides the implementation for one or more object references. In the C++ language mapping, a servant is an instance of a C++ class that inherits from PortableServer::ServantBase. This is true for dynamic skeleton implementations (DSI), or for classes that inherit from IDL-generated skeletons.

The process of associating a servant with an Object Id is called activation and is performed using POA methods. A servant can be activated more than once (to serve many different Object Ids) and can be activated in many POAs. After activation, object references can be obtained using other POA methods.

Servants are not objects and do not inherit from CORBA::Object. It is illegal to perform operations directly upon a servant - all invocations must be routed through the ORB. Also, memory management of servants is entirely left to the user. POAs keep only a pointer to a servant, so they must not be deleted while being activated.

Server

 
``Server'' refers to a complete process in which servants exist. A server can contain one or more POAs, each of which can provide zero, one or more active servants. Each active servant can then serve one or more object references.