presentation: the corba portable object adapter (poa)
DESCRIPTION
Presentation: The CORBA Portable Object Adapter (POA). Object Oriented Middleware (OOMI). Goals of this lesson. After these 2x35 min. lesson you will be : Introduced to the Portable Object Adapter (POA) Introduced to the many possibilities provided by the POA - PowerPoint PPT PresentationTRANSCRIPT
Presentation:The CORBA Portable Object Adapter (POA)
Object Oriented Middleware (OOMI)
Goals of this lesson
• After these 2x35 min. lesson you will be:• Introduced to the Portable Object Adapter (POA)
• Introduced to the many possibilities provided by the POA
• Prepared for POA self-study & experiments
• Warning – see below
• The CORBA spec. holds countless coding and configuration possibilities• Thus CORBA complexity is often considered high• Basic CORBA usage should be understood by now
• New levels of complexities is revealed all the time, but not necessarily used• Same with POA• Simple POA usage is relatively simple (RootPOA)
• But high complexities is available for maximum configurability and adaptability• Watch out for “Gold plating” – choose a sound design approach – don’t over-do-it
Outline
• Theory: (2x35 min.)• Object Adapters• POA introduced• High-level architecture• Internal mechanics of the POA• POA Policies• Advanced Policy Usage• Activation Policies
• Lazy Actication• Evictor
• Discussion
Object Adapters
• Main responsibilities of an Object Adapter is• Provide mechanism for associating servant
implementations (the C++ / Java / etc. classed) with a particular IDL interface
• Making CORBA objects accessible to the network
• Identifies and dispatches request to proper implementation code
• Manage lifecycle of CORBA objects
• Many Object Adapters (BOA, POA, COA)
• Huge differences between different vendor ORBs
POA introduced
• Original specification: BOA - Basic Object Adapter• Under specified (pre CORBA 2.2)• Each vendor has own implementation• No compatibility between ORB vendors• Idea of CORBA severely hampered• Enter the POA
• The POA – Portable Object Adapter• Is “Portable” across ORB vendors (post CORBA 2.2)• Server code written for one vendor -> works with others• May be configured in a myriad of ways• “Many OA’s in one”
High-level Architecture of POA & POA Manager
ORBCore
POAManager POA
Server Application
Servants
Dispatch withhelp from skeletons
Request
POA Managers represents a transport endpoint (host-port for TCP/IP)Associated with a POA when the POA is created - cannot be changed Acts as a gate and controls the flow of requests into one or more POAsA default POA Manager exists for all server processesThe developer can create custom POA Managers
POA Managers represents a transport endpoint (host-port for TCP/IP)Associated with a POA when the POA is created - cannot be changed Acts as a gate and controls the flow of requests into one or more POAsA default POA Manager exists for all server processesThe developer can create custom POA Managers
Servants have no identity – in a CORBA sense they are anonymous. They aremerely code implementations
Servants have no identity – in a CORBA sense they are anonymous. They aremerely code implementations
There may be one or more POA’s in a server process – but always at least one – the RootPOAEach POA form a namespace for servantsAll servants sharing the same POA share common implementation characteristics determined by the POA’s policiesEach servant has exactly one POA but many servants may share the same POAThe POA manages the relationships between object references, object IDs and servantsIf the RootPOA’s policies are sufficient – then one need not care about implementing other POA’s
There may be one or more POA’s in a server process – but always at least one – the RootPOAEach POA form a namespace for servantsAll servants sharing the same POA share common implementation characteristics determined by the POA’s policiesEach servant has exactly one POA but many servants may share the same POAThe POA manages the relationships between object references, object IDs and servantsIf the RootPOA’s policies are sufficient – then one need not care about implementing other POA’s
Object References
• The organization of an IOR with specific information for IIOP.
Many different profiles exists – IIOP is standard!An Object Reference may point to several server objects!
Abstract vs. Real
.
.
ServantsAOM
POA1
TRSFactory:1
Reader:2
Reader:1
Server
Servants
ServerClient
TRSFactory:1
Reader:1
Reader:2Object references (IOR’s)Object references (IOR’s)
In an abstract view – referencespoint directly at the servantsIn an abstract view – referencespoint directly at the servants
Client
Implementation code – e.g. TRSFactoryImplImplementation code – e.g. TRSFactoryImpl
Abstract:
Real:
May be activated or not. Servant & AOM entryhas shared lifecycle, but a persistent reference allows the POA to activate new servant and AOM entry
May be activated or not. Servant & AOM entryhas shared lifecycle, but a persistent reference allows the POA to activate new servant and AOM entry
Object ID’sObject ID’s
IOR Object Reference
POA1,Reader:1…… …..
ORBDORBD
Direct binding with persistent objects is notsupported by J2SE SUN ORB – ORBD actsas the Implementation Repositiory
Direct binding with persistent objects is notsupported by J2SE SUN ORB – ORBD actsas the Implementation Repositiory
Direct binding is used for transient objects in Suns ORBDirect binding is used for transient objects in Suns ORB
In practice the POA uses it Active Object Mapto associate anonyms servants with objectId’sIn practice the POA uses it Active Object Mapto associate anonyms servants with objectId’s
POA Manager
Active
Holding
Discarding
Inactive
Creation
Hold_requests
Active
Active
Hold_requests
Discard_requests
Discard_requests
Deactivate
Deactivate
Deactivate
POA Manager state transitions
RootPOA example code
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();
Server code when usingrootPOA with default policies
_this(orb) will use the default POA to activateThe object. You may override _default_POA()
at the servant implementation code.
_this(orb) will use the default POA to activateThe object. You may override _default_POA()
at the servant implementation code.
Instead: byte[] oid = rootPOA.activate_object(hwImpl); hw = rootPOA.id_to_reference(oid);
Instead: byte[] oid = rootPOA.activate_object(hwImpl); hw = rootPOA.id_to_reference(oid);
POA Policies
Policies are used to configure a POA for special usage
One POA for transient objects short-lived session objects
One POA for persistent session objects
One POA for persistent entity objects with user_id (from DB)
Not all combinations are valid – dependencies exist
POA Policy Type Allowed Values
ThreadPolicy ORB_CTRL_MODEL
SINGLE_THREAD_MODEL
LifespanPolicy TRANSIENT
PERSISTENT
IdAssignmentPolicy SYSTEM_ID
USER_ID
IdUniquenessPolicy UNIQE_ID
MULTIPLE_ID
RequestProcessingPolicy USE_ACTIVE_OBJECT_MAP_ONLY
USE_DEFAULT_SERVANT
USE_SEVANT_MANAGER
ServerRetentionPolicy RETAIN
NON_RETAIN
ImplicitActiavationPolicy NO_IMPLICIT_ACTIVATION
IMPLICIT_ACTIVATION
RootPOA Policies
RootPOA policies cannot be changed
May be sufficient for many types of applications
One might choose to depend on transient stateless session facade – using non-CORBA data transfer objects
POA Policy Type RootPOA values
ThreadPolicy ORB_CTRL_MODEL
LifespanPolicy TRANSIENT
IdAssignmentPolicy SYSTEM_ID
IdUniquenessPolicy UNIQE_ID
RequestProcessingPolicy USE_ACTIVE_OBJECT_MAP_ONLY
ServerRetentionPolicy RETAIN
ImplicitActiavationPolicy IMPLICIT_ACTIVATION
Default POA Policies
If child POA is created without explicitly stating policies – it will be equipped with these values
Notice – NOT the same as the RootPOA
POA Policy Type RootPOA values
ThreadPolicy ORB_CTRL_MODEL
LifespanPolicy TRANSIENT
IdAssignmentPolicy SYSTEM_ID
IdUniquenessPolicy UNIQE_ID
RequestProcessingPolicy USE_ACTIVE_OBJECT_MAP_ONLY
ServerRetentionPolicy RETAIN
ImplicitActiavationPolicy NO_IMPLICIT_ACTIVATION
Configuring Policies
Code for applying policies
......Policy[] tpolicy = new Policy[3];tpolicy[0] = rootPOA.create_lifespan_policy( LifespanPolicyValue.TRANSIENT );tpolicy[1] = rootPOA.create_request_processing_policy( RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY );tpolicy[2] = rootPOA.create_servant_retention_policy( ServantRetentionPolicyValue.RETAIN);POA myPOA = rootPOA.create_POA(”myPOA”,rootPOA.the_POAmanager(), tpolicy);.....
Each policy has its own factory
LifespanPolicy• LifespanPolicy
• Transient object references• Persistent object references
• Transient• Usually seen in conjunction with the Session or Service pattern• Short-lived, dies with the servant process• Remote IOR reference may dangle (like in C++) pointing at nothing
• Persistent• Usually seen in conjunction with the Entity pattern• Long-lived, references survive the implementation servants• Only reference and object key (POA+object ID) survives – POA guaranties to find
the servant implementation again (load it into memory)• But servant state is not retained – so state is NOT persisted• Must manually store / load state of servant• E.g. using a DB or file – e.g. using the Persistent State Service• Used with the IdAssignmentPolicy: USER_ID (e.g. DB key)• Some ORBs can transparently start server processes and shut them
down again after some idle time in order to save resources (check ORB documentation)
IOR POA & Object ID connection
IOR Object Reference
Repository IDTransport Address IIOP:host:port
Object Key
POA Name
Object ID
Identifies Interface Type
Identifies a transport endpoint
Identifies the object within POA
Is in proprietary format for a given ORB
Interoperability is not affectedas the server is the only onelooking in it
Transient Object IOR mapping
If the server is up and running -> OkIf the server is down - > OBJECT_NOT_EXISTIf the server is running but not the right adapter ID (check for pseudo-random number) -> OBJECT_NOT_EXISTIf the server is running but not the right ORB (check for vendor specific tag in IOR identifying ORB) ->OBJECT-NOT_EXIST
IOR Object Reference
IDL:MyObject TestHost:8888
Server: TestHost:8888
OBJID:11
OBJID:12
POA1,OBJID:12
OBJID:13
Client
POA1
Pseudo-random number for mapping
Persistent Object IOR Mapping
IOR Object Reference
IDL:MyObject Jupiter:8080
Server: TestHost:8888
OBJID:11
OBJID:12
POA1,OBJID:12
OBJID:13
Client
POA1
Pseudo-random number for mapping
Implementation Repository: Jupiter:8080
POA1 \bin\server\startPOA1 TestHost:8888
Persistent object references are implemented by usage of the Implementation RepositoryIOR Host:port contains the Implementation Repository server process information
More host:port occurences allow for replicated Implementation ServicesImplementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client
Persistent object references are implemented by usage of the Implementation RepositoryIOR Host:port contains the Implementation Repository server process information
More host:port occurences allow for replicated Implementation ServicesImplementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client
IdAssignmentPolicy
• IdAssignmentPolicy• Object id provided by either the application or the
system (USER_ID, SYSTEM_ID)
• Persistent object references usually use IDs generated by the application (fx. Db primary key)
• uses activate_object_with_id on POAs• Transient object references usually use IDs generated
by the system
IdUniquenessPolicy
• IdUniquenessPolicy• How object references are mapped to servants
• one servant for each Corba object (UNIQUE_ID)
• one servant for more Corba objects (MULTIPLE_ID)
.
.
ServantsAOM
POA
OBJID:1
OBJID:N+1
OBJID:N
.
.
ServantsAOM
POA
OBJID:1
OBJID:N+1
OBJID:N
OBJID:N+2
current
ImplicitActivationPolicy
• ImplicitActivationPolicy• Whether newly instantiated servants need be registered
with the ORB (activation) manually or it happens automatically (NO_IMPLICIT_ACTIVATION, IMPLICIT_ACTIVATION)
• Transient object references usually use implicit activation of servants
• Persistent object references usually use explicit activation of servants
RequestProcessingPolicy
• RequestProcessingPolicy• Whether the POA uses static servant mapping (AOM) or
servants are instantiated dynamically• Possible values
• USE_ACTIVE_OBJECT_MAP_ONLY– All objects must be mapped at startup, or as needed (e.g. you
may search the AOM first, and then search e.g. a database and activate the object, thus bringing it into the AOM
• USE_DEFAULT_SERVANT • USE_SERVANT_MANAGER
– Servant Activator (RETAIN - servant for continuos use in AOM)
– Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())
ServantRetentionPolicy
• ServantRetentionPolicy• Whether the POA keeps the servants in memory all the
time (RETAIN) or not (NON_RETAIN)• NON_RETAIN has to be used with
USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER RequestProcessing
• If AOM the POA automatically calls a default servant or a servant manager if the requested object ID isn’t in the AOM
• This policy can be used to create the illusion of all objects running in the server - the default servant or servant manager just creates servants on request and maybe destroys them again
ThreadPolicy
• ThreadPolicy• Whether the POAs processes request single threaded
or whether the ORB chooses a threading model for request dispatch (ORB_CTL_MODEL, SINGLE_THREAD_MODEL)
• Single-threaded means that all requests for that POA is serialized
• If you choose to let the ORB decide you have to consult your ORBs documentation to see which threading the particular ORB practices
• SUN’s Java ORB does not support SINGLE_THREAD for example
Advanced Policy Usage
ORBextract POA namefrom Object Key
POAfindPOA
Object Reference(with Object Key)
requestfrom a client
or
Adaptor Activator
call AdaptorActivator ifPOA not found
create POA
extract Object Idfrom Object Key Active Object Map
Object ID
Object ID
Object IDServant
Servant
incarnateservant
Default Servant
or
Servant Manager
or
ServantActivator
ServantLocator
updatemap
Application object that the developer can associate with a POACreate POA’s if they do not exist
Application object that the developer can associate with a POACreate POA’s if they do not exist
DBDB
E.g. check in DBE.g. check in DB
Incarnate and etheralize – used with the POAIncarnate and etheralize – used with the POA
USE_SERVANT_MANAGER & RETAIN
USE_SERVANT_MANAGER & NON_RETAIN
USE_ACTIVE_OBJECT_MAP& RETAIN
createservant
Does not update AOMbut creates servantPreinvoke & Postinvoke
Does not update AOMbut creates servantPreinvoke & Postinvoke
Check example Bank App at: http://www.javaworld.com/javaworld/jw-10-2002/jw-1025-corba-p2.html Check example Bank App at: http://www.javaworld.com/javaworld/jw-10-2002/jw-1025-corba-p2.html
USE_DEFAULT_SERVANTboth RETAIN & NON_RETAIN
Does not updateAOM map!
checkmap
Must be thread-safe – can not have stateMust be thread-safe – can not have state
Used with EJB,CCM or similar. Massive Data.
Singleton
3 configurations
// Create the AccountPOA and set its ServantActivator policies[0] = rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT); policies[1] = rootPOA.create_request_processing_policy(RequestProcessingPolicyValue.USE_SERVANT_MANAGER); policies[2] = rootPOA.create_servant_retention_policy(ServantRetentionPolicyValue.RETAIN); POA accountPOA = rootPOA.create_POA("AccountPOA",null,policies); AccountServerActivatorImpl asa = new bank.AccountServerActivatorImpl(); rootPOA.activate_object(asa); accountPOA.set_servant_manager(asa._this(orb));
// Create the AccountPOA and set its ServantLocator (NON_RETAIN Policy) policies[0] = rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT); policies[1] = rootPOA.create_request_processing_policy(RequestProcessingPolicyValue.USE_SERVANT_MANAGER); policies[2] = rootPOA.create_servant_retention_policy(ServantRetentionPolicyValue. NON_RETAIN); POA accountPOA = rootPOA.create_POA("AccountPOA",null,policies); AccountServerLocatorImpl asl = new bank.AccountServerLocatorImpl(); rootPOA.activate_object(asl); accountPOA.set_servant_manager(asl._this(orb));
// Create the AccountPOA and set its default servant (NON_RETAIN Policy) policies[0] = rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT); policies[1] = rootPOA.create_request_processing_policy(RequestProcessingPolicyValue.USE_DEFAULT_SERVANT); policies[2] = rootPOA.create_servant_retention_policy(ServantRetentionPolicyValue.NON_RETAIN); POA accountPOA = rootPOA.create_POA("AccountPOA",null,policies); AccountDefaultServantImpl defaultAcc = new bank.AccountDefaultServantImpl(); rootPOA.activate_object(defaultAcc); accountPOA.set_servant(defaultAcc);
Activation Policies
• Lazy Activation Pattern• Start with only creating references• Account theAccount = AccountHelper.narrow(
accountPOA.create_reference_with_id(accNum.getBytes(), "IDL:bank/Account:1.0"));
• Only invoke servants when client requests
• Evictor Pattern• Use FIFO list or time stamp to evict oldest or least used
servants from memory
Discussion
• POA usage can be simple • Using the RootPOA or• Using only a few child POA’s without exotic policies
• POA usage can be complicated• If special conditions demand special POA behavior
• Keep it simple stupid• Always focus – do we need it?• Start with the RootPOA or a simple child POA• Use DTO’s (replicating objects) and not massive CORBA
Objects
Group Assignment
• Try to find examples on when to employ the different strategies of the POA (see the figure on “Advanced Policy Usage”)
• Try to discover the different code units that needs to be produced – what do they do?
• Discuss what you need for your project, and document this on no more than 1/3 A4. Hand-in is optional.
Læringsmål Alignment
Når kurset er færdigt forventes den studerende at kunne:• Definere, beskrive og sammenligne forskellige typer af
objektorienterede middleware frameworks til apparater og computere, med primær fokus på CORBA og sekundært .NET Remoting teknologierne, herunder fordele og ulemper forbundet med de forskellige teknologier
• Definere og beskrive principper omkring transparens og heterogenitet i relation til middlewareteknologier
• Definere og beskrive gængse teorier, metoder og retningslinier indenfor det objektorienterede middleware paradigme og anvende disse til at designe effektive distribuerede systemer
• Designe og konstruere et distribueret system der gør brug af CORBA og .NET Remoting teknologierne med tilhørende værktøjssupport
OA og særligt POA er centralfor forståelsen af CORBA.
Derfor skal både koncept ogKode kunne genkendes og
forklares
OA og særligt POA er centralfor forståelsen af CORBA.
Derfor skal både koncept ogKode kunne genkendes og
forklares
MANGLER: hvordan I praktisk omsætter denne viden
Det forventes at I kan bruge CORBA POA, rootPOA,
childPOA til jeres opgave. Både design og i praksis.
I skal forstå Policies og hvadde kan bruges til. Ok
at bruge RootPOA, men der skalargumenteres herfor
Det forventes at I kan bruge CORBA POA, rootPOA,
childPOA til jeres opgave. Både design og i praksis.
I skal forstå Policies og hvadde kan bruges til. Ok
at bruge RootPOA, men der skalargumenteres herfor