Presentation: The CORBA Portable Object Adapter (POA)

1. Presentation:The CORBA Portable Object Adapter (POA)

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

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

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

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”

6. High-level Architecture of POA & POA Manager 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 Server Application Request Dispatch with help from skeletons ORB Core POA Manager Servants POA 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

7. Abstract vs. Real Implementation code – e.g. TRSFactoryImpl Server Client Servants In an abstract view – references point directly at the servants TRSFactory:1 Abstract: Direct binding is used for transient objects in Suns ORB Reader:1 Object ID’s Reader:2 Object references (IOR’s) In practice the POA uses it Active Object Map to associate anonyms servants with objectId’s Server Client POA1 Servants ORBD AOM Real: TRSFactory:1 . . Reader:1 Reader:2 IOR Object Reference ……….. POA1,Reader:1 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 Direct binding with persistent objects is not supported by J2SE SUN ORB – ORBD acts as the Implementation Repositiory

8. POA Manager POA Manager state transitions Creation Holding Hold_requests Hold_ requests Deactivate Active Deactivate Active Inactive Active Discard_ requests Deactivate Discarding Discard_requests

9. RootPOA example code Server code when using rootPOA with default policies 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(); _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);

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

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

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

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

14. 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)

15. IOR POA & Object ID connection IOR Object Reference Object Key Transport Address IIOP:host:port Repository ID POA Name Object ID Identifies Interface Type 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 Identifies a transport endpoint

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 Pseudo-random number for mapping Client Server: TestHost:8888 IOR Object Reference POA1 TestHost:8888 POA1,OBJID:12 OBJID:11 IDL:MyObject OBJID:12 OBJID:13

17. Persistent Object IOR Mapping Pseudo-random number for mapping Client Server: TestHost:8888 IOR Object Reference POA1 Jupiter:8080 POA1,OBJID:12 OBJID:11 IDL:MyObject OBJID:12 OBJID:13 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

18. 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

19. 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) POA POA Servants Servants AOM AOM OBJID:1 OBJID:1 current . . . . OBJID:N OBJID:N OBJID:N+1 OBJID:N+1 OBJID:N+2

20. ImplicitActivationPolicy • 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

21. 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 continues use i AOM) • Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())

22. ServantRetentionPolicy • 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

23. 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

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

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);

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

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