Portable Object Adapter

1
Portable Object Adapter

• Ariel Peltz
• July 2001

2
CORBA Object and Servant Life Cycle
Reference associated with an existing servant
that processes requests.
Reference has no associated servant.
3
Life Cycle Terminology

• Activate a CORBA object associate an object
  reference with a servant. We say the servant
  incarnates the object.
• Deactivate a CORBA object break the
  reference-servantassociation. The servant is
  etherialized and or may not be destroyed.
• CORBA object exists it can respond to requests.
  It may be
• Activeincarnated by a servant in a running
  process.
• Inactive not incarnated by any servant, but will
  be automatically activated if needed.
• CORBA object does not exist
• It is not active and cannot be automatically
  activated.
• Clients get OBJECT_NOT_EXIST exception.

4
Objects in the POA Architecture

• POA architecture is described in IDL in module
  PortableServer.
• Servant a native programming language object
  that incarnates a CORBA object.
• POA Connects CORBA objects to servants.
• Policy defines POA behavior set when creating a
  POA.
• Servant Manager activates objects on demand.
  Two kinds
• Servant Activator activates on first request.
• Servant Locator activate for each request.
• POA Manager controls processing state of one or
  more POAs.

5
What is a POA?

• A POA implements a collection of CORBA objects
• Creates object references.
• Associates object reference with servant via
  Object ID.
• Directs requests to the appropriate servant.
• Asks the application to create servants on
  demand.
• Tells the application when servants are no longer
  needed.

• POA behavior is controlled by policies
• Set when the POA is created, cannot be changed.
• ORB provides the Root POA with a standard set of
  policies.
• Groups objects with similar implementation
  policies.

6
Multiple POAs

• A server usually has multiple POAs with
  customized policies.
• Each POA has a name.
• POA names form a hierarchy.
• A POA is identified by its Fully Qualified POA
  Name(FQPN)

7
What is in a Reference?

• All object references include the following
  pieces of information
• Repository ID (identifies the interface type).
• Protocol-specific information (identifies
  server).
• Object key (identifies object).

• Object key is ORB specific, however it usually
  contains
• FQPN (identifies POA within server).
• Object ID (identifies object within POA).

Repository ID
Protocol Info
Object Key
FQPN
Object ID
8
Object Activation

• An active object has a servant and can process
  requests.
• We say the the servant incarnates the object.

• Activating an object informs the relevant POA
  which servant should handle requests for a
  particular object ID.
• The application can explicitly activate objects.
• The POA can ask the application to activate
  objects on demand.
• The POA can remember activations or they can last
  just fora single operation call.
• POA Policies determine how the POA behaves.

Deactivating an object breaks the association
between an object key and servant.
9
POA Policies

• There are seven different policies to control POA
  behavior
• Lifespan Policy
• ID Assignment Policy
• ID Uniqueness Policy
• Implicit Activation Policy
• Thread Policy
• Request Processing Policy
• Servant Retention Policy

Each policy has at least two possible values.
Not all combinations of policy values are legal
or sensible,We will discuss models for using
these policies.
10
Using the POA
There are a bewildering number of possible
combinations butyou can boil it down to five
main models

• Models are characterized by how objects are
  activated
• Simple Active Object Map explicit activation of
  objects.
• Servant Activator activate a servant on first
  request.
• Servant Locator select servant on each request,
  ideal for cache.
• Default Servant one servant for many objects
  with oneinterface.
• Servant Locator again this time managing
  servant-per-interface for many interfaces.

Lets outline these models.
11
Model 1 Simple Active Object Map
USE_ACTIVE_OBJECT_MAP_ONLY, RETAIN
12
Model 2 Servant Activator
USE_SERVANT_MANAGER, RETAIN
13
Model 3 Servant Locator Cache
USE_SERVANT_MANAGER, NON_RETAIN
14
Model 4 Default Servant
USE_DEFAULT_SERVANT, MULTIPLE_ID(,RETAIN)
15
Model 5 Servant Per-Interface Locator
USE_SERVANT_MANAGER, NON_RETAIN
16
How to Pick Your Policies
17
How to Pick Your Policies (cont.)
Remaining policies are mostly independent.

• Threading Is your application thread-safe?
• Yes ORB_CTRL_MODEL. No SINGLE_THREAD_MODEL

• Lifespan Can an object outlive a single run of
  the server?
• Yes PERSISTENT. No TRANSIENT.

• ID Assignment Are your object associated with
  external data?
• Yes USER_ID. Usually with PERSISTENT.No
  SYSTEM_ID. Only with TRANSIENT.

• Implicit Activation probably not.
• Only with TRANSIENT, SYSTEM_ID, RETAIN
  andUSE_ACTIVE_OBJECT_MAP_ONLY.