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 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 manages 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 manages 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

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

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

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

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

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

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

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

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

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

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

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 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 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 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 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 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 central for forståelsen af CORBA. Derfor skal både koncept og Kode kunne genkendes og forklares OA og særligt POA er central for forståelsen af CORBA. Derfor skal både koncept og Kode 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 hvad de kan bruges til. Ok at bruge RootPOA, men der skal argumenteres 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 hvad de kan bruges til. Ok at bruge RootPOA, men der skal argumenteres herfor