Presentation: The CORBA Portable Object Adapter (POA)

Ingeniørhøjskolen i Århus Slide 2 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

Ingeniørhøjskolen i Århus Slide 3 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

Ingeniørhøjskolen i Århus Slide 4 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

Ingeniørhøjskolen i Århus Slide 5 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 POA’s in one”

Ingeniørhøjskolen i Århus Slide 6 High-level Architecture of POA & POA Manager ORB Core POA Manager POA Server Application Servants Dispatch with help 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 POAs A default POA Manager exists for all server processes The 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 POAs A default POA Manager exists for all server processes The developer can create custom POA Managers Servants have no identity – in a CORBA sense they are anonymous. They are merely code implementations Servants have no identity – in a CORBA sense they are anonymous. They are merely code implementations There may be one or more POA’s in a server process – but always at least one – the RootPOA Each POA form a namespace for servants All servants sharing the same POA share common implementation characteristics determined by the POA’s policies Each servant has exactly one POA but many servants may share the same POA The POA manage the relationships between object references, object IDs and servants If 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 RootPOA Each POA form a namespace for servants All servants sharing the same POA share common implementation characteristics determined by the POA’s policies Each servant has exactly one POA but many servants may share the same POA The POA manage the relationships between object references, object IDs and servants If the RootPOA’s policies are sufficient – then one need not care about implementing other POA’s

Ingeniørhøjskolen i Århus Slide 7 Abstract vs. Real.... Servants AOM POA1 TRSFactory:1 Reader:2 Reader:1 Server Servants Server Client TRSFactory:1 Reader:1 Reader:2 Object references (IOR’s) In an abstract view – references point directly at the servants In an abstract view – references point directly at the servants Client In practice the POA uses it Active Object Map to associate anonyms servants with objectId’s In practice the POA uses it Active Object Map to associate anonyms servants with objectId’s Implementation code – e.g. TRSFactoryImpl Abstract: Real: May be activated or not. Servant & AOM entry has shared lifecycle, but a persistent reference allows the POA to activate new servant and AOM entry May be activated or not. Servant & AOM entry has shared lifecycle, but a persistent reference allows the POA to activate new servant and AOM entry Object ID’s IOR Object Reference POA1,Reader:1 …… ….. ORBD Direct binding with persistent objects is not supported by J2SE SUN ORB – ORBD acts as the Implementation Repositiory Direct binding with persistent objects is not supported by J2SE SUN ORB – ORBD acts as the Implementation Repositiory Direct binding is used for transient objects in Suns ORB

Ingeniørhøjskolen i Århus Slide 8 POA Manager Active Holding Discarding Inactive Creation Hold_requests Active Hold_ requests Discard_ requests Discard_requests Deactivate POA Manager state transitions

Ingeniørhøjskolen i Århus Slide 9 RootPOA example code import org.omg.CORBA.*; import org.omg.PortableServer.*; // Initialize ORB and POA ORB orb = ORB.init (args, props); POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA")); // Get a reference to the POA manager POAManager manager = rootPOA.the_POAManager(); // Create a servant and activate it HelloWorldImpl hwImpl = new HelloWorldImpl(); HelloWorld hw = hwImpl._this (orb); // Wait for incoming requests ("run the implementation") manager.activate(); orb.run(); Server code when using rootPOA with default policies _this(orb) will use the default POA to activate The object. You may override _default_POA() at the servant implementation code. _this(orb) will use the default POA to activate The 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);

Ingeniørhøjskolen i Århus Slide 10 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 TypeAllowed Values ThreadPolicyORB_CTRL_MODEL SINGLE_THREAD_MODEL LifespanPolicyTRANSIENT PERSISTENT IdAssignmentPolicySYSTEM_ID USER_ID IdUniquenessPolicyUNIQE_ID MULTIPLE_ID RequestProcessingPolicyUSE_ACTIVE_OBJECT_MAP_ONLY USE_DEFAULT_SERVANT USE_SEVANT_MANAGER ServerRetentionPolicyRETAIN NON_RETAIN ImplicitActiavationPolicyNO_IMPLICIT_ACTIVATION IMPLICIT_ACTIVATION

Ingeniørhøjskolen i Århus Slide 11 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 TypeRootPOA values ThreadPolicyORB_CTRL_MODEL LifespanPolicyTRANSIENT IdAssignmentPolicySYSTEM_ID IdUniquenessPolicyUNIQE_ID RequestProcessingPolicyUSE_ACTIVE_OBJECT_MAP_ONLY ServerRetentionPolicyRETAIN ImplicitActiavationPolicyIMPLICIT_ACTIVATION

Ingeniørhøjskolen i Århus Slide 12 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 TypeRootPOA values ThreadPolicyORB_CTRL_MODEL LifespanPolicyTRANSIENT IdAssignmentPolicySYSTEM_ID IdUniquenessPolicyUNIQE_ID RequestProcessingPolicyUSE_ACTIVE_OBJECT_MAP_ONLY ServerRetentionPolicyRETAIN ImplicitActiavationPolicyNO_IMPLICIT_ACTIVATION

Ingeniørhøjskolen i Århus Slide 13 Configuring Policies Code for creation of 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

Ingeniørhøjskolen i Århus Slide 14 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)

Ingeniørhøjskolen i Århus Slide 15 IOR POA & Object ID connection IOR Object Reference Repository ID Transport 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 affected as the server is the only one looking in it

Ingeniørhøjskolen i Århus Slide 16 Transient Object IOR mapping If the server is up and running -> Ok If the server is down - > OBJECT_NOT_EXIST If the server is running but not the right adapter ID (check for pseudo-random number) -> OBJECT_NOT_EXIST If 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

Ingeniørhøjskolen i Århus Slide 17 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 Repository IOR Host:port contains the Implementation Repository server process information More host:port occurences allow for replicated Implementation Services Implementation 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 Repository IOR Host:port contains the Implementation Repository server process information More host:port occurences allow for replicated Implementation Services Implementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client

Ingeniørhøjskolen i Århus Slide 18 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

Ingeniørhøjskolen i Århus Slide 19 IdUniquenessPolicy –How object references are mapped to servants –one servant for each Corba object (UNIQUE_ID) –one servant for more Corba objects (MULTIPLE_ID).... Servants AOM POA OBJID:1 OBJID:N+1 OBJID:N.... Servants AOM POA OBJID:1 OBJID:N+1 OBJID:N OBJID:N+2 current

Ingeniørhøjskolen i Århus Slide 20 ImplicitActivationPolicy –Whether newly instantiated servants need be registered with the ORB (activation) manually or that happen automatically (NO_IMPLICIT_ACTIVATION, IMPLICIT_ACTIVATION) –Transient object references usually use implicit activation of servants –Persistent object references usually use explicit activation of servants

Ingeniørhøjskolen i Århus Slide 21 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 continues use i AOM) –Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())

Ingeniørhøjskolen i Århus Slide 22 ServantRetentionPolicy –Whether the POA keep 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

Ingeniørhøjskolen i Århus Slide 23 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

Ingeniørhøjskolen i Århus Slide 24 Advanced Policy Usage ORB extract POA name from Object Key POA find POA Object Reference (with Object Key) request from a client or Adaptor Activator call Adaptor Activator if POA not found create POA extract Object Id from Object Key Active Object Map Object ID Servant incarnate servant Default Servant or Servant Manager or Servant Activator Servant Locator update map Application object that the developer can associate with a POA Create POA’s if they do not exist Application object that the developer can associate with a POA Create POA’s if they do not exist DB E.g. check in DB Incarnate and etheralize – used with the POA USE_SERVANT_MANAGER & RETAIN USE_SERVANT_MANAGER & NON_RETAIN USE_ACTIVE_OBJECT_MAP & RETAIN create servant Does not update AOM but creates servant Preinvoke & Postinvoke Does not update AOM but creates servant Preinvoke & Postinvoke Check example Bank App at: Check example Bank App at: USE_DEFAULT_SERVANT both RETAIN & NON_RETAIN Does not update AOM map! check map Must be thread-safe – can not have state

Ingeniørhøjskolen i Århus Slide 25 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);

Ingeniørhøjskolen i Århus Slide 26 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

Ingeniørhøjskolen i Århus Slide 27 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