portable object adaptor

of 31 /31
Portable Object Adaptor Martin Senger [email protected]

Upload: paul-jackson

Post on 06-Jan-2018




1 download

Embed Size (px)


Significant news in CORBA Objects By Value CORBA Components CORBA scripting Metadata and modeling Quality of Service Portable Object Adaptor BOA deprecated now


Page 1: Portable Object Adaptor

Portable Object Adaptor

Martin [email protected]

Page 2: Portable Object Adaptor

Significant news in CORBA

• Objects By Value• CORBA Components• CORBA scripting• Metadata and modeling• Quality of Service• Portable Object Adaptor

– BOA deprecated now

Page 3: Portable Object Adaptor

CORBA Object Adaptors

• a piece of CORBA architecture dispatching client requests to the servants (implementations)

• object adaptors are only on the server side• key functions are

– they create CORBA object references– they ensure that target objects are incarnated by

servants– they direct requests to the servants (they connect orb

with the servants - locating and marshaling)

remember this term,use this term

remember: object references andservants are two different things

Page 4: Portable Object Adaptor


• BOA was the original CORBA object adaptor• BOA was under-specified and therefore less

portable between ORBs• BOA had no servant management• BOA has been removed from CORBA!• POA is everything else

– portable– providing many more features

Page 5: Portable Object Adaptor

POA abstract model

Client Server




Object Id

logical connection to the target CORBA object




Page 6: Portable Object Adaptor

Three key Entities[CORBA Object is a programming entity with an identity, an

interface and an implementation]• Servant

– a programming language object implementing requests on one or more CORBA objects (modifier “native” in IDL)

• Object Id– a value identifying a particular CORBA object within the

scope of its POA– Ids are hidden from clients, encapsulated by object

references• Object Reference

– a usual reference to a CORBA object– encapsulates an Object Id and a POA identity

Page 7: Portable Object Adaptor

A simplified picture









Server Application


Page 8: Portable Object Adaptor

How to code Serverimport org.omg.CORBA.*;

// Initialize ORB and BOAORB orb = ORB.init (args, props);BOA boa = orb.BOA_init(args, props);

// Create a servant and activate itHelloWorldImpl hw = new HelloWorldImpl();

// Wait for requestsboa.impl_is_ready(null);

with BOA

import org.omg.CORBA.*;import org.omg.PortableServer.*;

// Initialize ORB and POAORB orb = ORB.init (args, props);POA rootPOA = POAHelper.narrow (

orb.resolve_initial_references ("RootPOA"));

// Get a reference to the POA managerPOAManager manager = rootPOA.the_POAManager();

// Create a servant and activate itHelloWorldImpl hwImpl = new HelloWorldImpl();HelloWorld hw = hwImpl._this (orb);

// Wait for incoming requests ("run the implementation")manager.activate();orb.run(); with POA

Page 9: Portable Object Adaptor











The old way - with BOA












The new way - with POA

this is a servant

this is an interfaceof the same type asthe object reference

How to connectyour implementation

classes withthe generated code

_this() oractivate_object()

Page 10: Portable Object Adaptor


Yet another picture

extract POA namefrom Object Key


Object Reference(with Object Key)

requestfrom a client


Adaptor Activator

call AdaptorActivator ifPOA not found

create POA

extract Object Idfrom Object Key Active Object Map

Object ID

Object ID

Object IDServant



Default Servant


Servant Manager






Page 11: Portable Object Adaptor

POA Policies

• there can be more POAs and each of them can have different features = policies

• the policies are given to the POA in its creation time, they are not changeable later

• the policies are not inherited from parent POA to its children POA

• the policies are locally-constrained objects– they cannot be passed as arguments to normal

CORBA operations, or be converted to strings

Page 12: Portable Object Adaptor

policy: CORBA Object Life Span

• TRANSIENT– the objects created in the POA cannot outlive

this POA– they are more modest regarding resources

• PERSISTENT– the objects can outlive the process in which

they were first created– their POA name is stored in the object


enum LifespanPolicyValue { TRANSIENT, PERSISTENT };

Page 13: Portable Object Adaptor

policy: Object Id Uniqueness

• UNIQUE_ID– each servant support exactly one Object Id

• MULTIPLE_ID– a servant may support one or more Object Ids– good, for example, for many database objects

which may all be served by a single servant (assuming that the state of the objects is kept in the database)

enum IdUniquenessPolicyValue { UNIQUE_ID, MULTIPLE_ID };

Page 14: Portable Object Adaptor

policy: Id Assignment

• USER_ID– Object IDs are assigned by the application, not

by the POA– typical for persistent objects (the same ID is

used for keeping track where the object state is stored)

• SYSTEM_ID– Object IDs are assigned by the POA

enum IdAssignmentPolicyValue { USER_ID, SYSTEM_ID };

Page 15: Portable Object Adaptor

policy: Request Processing

• USE_ACTIVE_OBJECT_MAP_ONLY– an Object Id must be found in the active object map

• USE_DEFAULT_SERVANT– if an Object Id is not found in the active object map

the request is dispatched to the default servant• USE_SERVANT_MANAGER

– if an Object Id is not found in the active object map the servant manager gets control


Page 16: Portable Object Adaptor

policy: ObjectId to Servant Associations

• RETAIN– the POA will keep active servants in its active

object map– various combinations of this policy and Request

Processing policy• NON_RETAIN

– servants are not retained by the POA– it is up to the application to keep track about active

(existing) servants

enum ServantRetentionPolicyValue { RETAIN, NON_RETAIN };

Page 17: Portable Object Adaptor

policy: Implicit Activation

• IMPLICIT_ACTIVATION– the POA will support implicit activation of servants– also requires SYSTEM_ID and RETAIN policies– implicit activation is done (in Java) using a shortcut

method “_this”

• NO_IMPLICIT_ACTIVATION– the POA will not support implicit activation of

servant– typically used to avoid accidental object creation


Page 18: Portable Object Adaptor

policy: Thread• ORB_CTRL_MODEL

– servants can be called in parallel from separate threads (created and controlled by the ORB)

– servants must be written as thread-aware• SINGLE_THREAD_MODEL

– a model which guarantees that all requests for all objects in this POA will be dispatched sequentially

– but the application still can have more single-threaded POAs running in parallel (in separate threads)


Page 19: Portable Object Adaptor

How to create “policies”

• each policy has its own factory:

• an example how to use the policy factory:

• typically, all necessary policy objects are passed in a PolicyList to the POA creation function

• …and then invoke destroy on the policy objects

interface POA {LifespanPolicy create_lifespan_policy (

in LifespanPolicyValue value);};

Policy policy =parentPOA.create_lifespan_policy (LifespanPolicyValue.ORB_CTRL_MODEL);

Page 20: Portable Object Adaptor


Yet another picture(now let’s show where

different policies apply)

extract POA namefrom Object Key


Object Reference(with Object Key)

requestfrom a client


Adaptor Activator

call AdaptorActivator ifPOA not found

create POA

extract Object Idfrom Object Key Active Object Map

Object ID

Object ID

Object IDServant



Default Servant


Servant Manager






Page 21: Portable Object Adaptor

POA Creation

• each POA is created as a child of another POA

• all server applications have a “RootPOA”• POAs are created in a tree, in a hierarchy• each POA has its own namespace for its

Object Ids• remember: if you need a different policy you

need a new POA

Page 22: Portable Object Adaptor

code: POA Creation

interface POA {POA create_POA (

in string adapter_name,in POAManager manager,in CORBA::PolicyList policies)

raises (AdapterAlreadyExists, InvalidPolicy);};

// get a reference to the Root POAPOA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA"));

// get a reference to the POA managerPOAManager manager = rootPOA.the_POAManager();

// create an empty PolicyList for child POAPolicy[] policies = new Policy [0];

// create the child POAPOA child = rootPOA.create_POA (“child”, manager, policies);

Page 23: Portable Object Adaptor

Activation: don’t be confuse...

• “Object activation” is not the same as “Server activation”– Server activation is about “how to start a

separate process on the server side”• also called: “Implementation repository” issue (see

another talk)– Object activation is about “how to make objects

visible within already running process

Page 24: Portable Object Adaptor

Object creation and activation• POA provides several options for creating

objects and activating them– an application can create objects without

creating any servants– a servant can be explicitly or implicitly

registered to incarnate an object - and POA can remember it in its Active Object Map

– an application can supply servant managers– an application can provide a default servant

Page 25: Portable Object Adaptor

Creation and activation methods

Object create_reference (in CORBA::RepositoryId intf)raises (WrongPolicy);

Object create_reference_with_id (in ObjectId oid,in CORBA::RepositoryId intf)

raises (WrongPOlicy);

Creating CORBA Objectswithout creating servants

ServantManager get_servant_manager ()raises (WrongPolicy);

void set_servant_manager (in ServantManager imgr)raises (WrongPOlicy);

Registration ofServant managers

Servant get_servant ()raises (NoServant, WrongPolicy);

void set_servant (in Servant serv)raises (WrongPOlicy);

Registration ofDefault Servant

ObjectId activate_object (in Servant serv)raises (ServantAlreadyActive, WrongPolicy);

void activate_object_with_id (in ObjectId oid,in Servant serv)

raises (ServantAlreadyActive, ObjectAlreadyActive, WrongPolicy);

Object activation

Page 26: Portable Object Adaptor

Conversions among key entitiesObject Reference

Object Id


ObjectId reference_to_id (in Object ref)raises (WrongAdapter, WrongPolicy);

Object id_to_reference (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

ObjectId servant_to_id (in Servant serv)raises (ServantNotActive, WrongPolicy);

Servant id_to_servant (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

Servant reference_to_servant (in Object ref)raises (ObjectNotActive, WrongAdapter, WrongPolicy);

Object servant_to_reference (in Servant serv)raises (ServantNotActive, WrongPolicy);

Page 27: Portable Object Adaptor

Servant managers• Used when an explicit servant registration is

difficult or impossible– e.g. dealing with too many objects– or finding objects dynamically

• Servant Activator– Servant incarnate (in ObjectId oid, in POA adapter)– void etherealize (in ObjectId oid, in POA adapter, …)

– the resulting servant retains in the Active Object Map

• Servant Locator– Servant preinvoke (in ObjectId oid, in POA adapter, in CORBA::Identifier operation, out Cookie the_cookie)– void postinvoke (in ObjectId oid, in POA adapter, in CORBA::Identifier operation, out Cookie the_cookie,…)

– the resulting servant does not appear in the AOM

Page 28: Portable Object Adaptor

Common for both Servant managers• The incarnate() and preinvoke() may raise any system

exception– e.g. OBJECT_NOT_EXIST if the object corresponding

to the Object Id cannot be incarnated• SeqFactory.get_sequence() normally would raise at once exception

WrongAccession but if the real access to the database is postponed some other exception must be used

• Both operations may also raise a ForwardRequest

– then the ORB is responsible for delivering the current and subsequent requests to the object denoted in forward_reference member

Page 29: Portable Object Adaptor

Default Servant• a single Servant for many CORBA objects

– typically of the same type– ideally suited to objects in large databases

• the invoking POA and ObjectId is accessible using Current interface

org.omg.CORBA obj =orb.resolve_initial_references (”POACurrent"));

Current current = CurrentHelper.narrow (obj);

How to get Current

interface Current {POA get_POA();ObjectID get_object_id();


What to get from Current

Page 30: Portable Object Adaptor

Object deactivation• deactivation is breaking object-to-servant

association• after deactivation the object is not visible

any more– but the corresponding servant can still be available and

may be activated later again

• an administrative tool for controlling the contents of the Active Object Map

void deactivate_object (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

Page 31: Portable Object Adaptor

Notes on hands-on• POA/stage1

– plain differences between BOA and POA• POA/stage2-persistent

– create persistent object reference• POA/stage3-servantActivator

– create a factory for sequence references,– the servants are created later only when a

method on a sequence reference is called