Slide 1 © Ingeniørhøjskolen i Århus TIMICO Middleware with CORBA

Slide 2 © Ingeniørhøjskolen i Århus Outline Middleware CORBA Background Architecture Session & Presentation layer GIOP / IIOP / CDR CORBA Interface Definition Language – IDL Language mappings CORBA development steps

Slide 3 © Ingeniørhøjskolen i Århus Middleware Between Application and Network layers Makes distribution transparent Resolves heterogeneity of Hardware Operating Systems Networks Programming Languages Provides development and run-time environment for distributed systems “Gets you of the hook” – concerning the nasty stuff in network programming

Slide 4 © Ingeniørhøjskolen i Århus Goal of CORBA CORBA: Common Object Request Broker Architecture Support distributed and heterogeneous object request in a way transparent to users and application programmers Facilitate the integration of new components with legacy components (COBOL, C, ADA, C++, C#, Java, Python) Open standard that can be used free of charge Based on industry consensus

Slide 5 © Ingeniørhøjskolen i Århus Standardizing body OMG: Object Management Group Non-profit Founded April 1989 CORBA, UML SysML, DDS, etc.

Slide 6 © Ingeniørhøjskolen i Århus OMG and CORBA Speifications CORBA is a collection of specifications Common Object Request Broker Architecture (3.2) CORBA Component Model (4.0) CORBA/e ( And others:

Slide 7 © Ingeniørhøjskolen i Århus CORBA History CORBA 1.0 (1991): IDL, C mapping CORBA 1.1 (1992): BOA CORBA 1.2 (1993): minor updates CORBA 2.0 (1996): DSI, GIOP, IIOP, C++, SmallTalk mappings CORBA 2.1 (1997) : Secure IIOP / SSL, COBOL, ADA mappings CORBA 2.2 (1998): POA, Java mapping CORBA 2.3 (1999): Objects by Value CORBA 2.4 (2000) : INS & Interop services CORBA 2.5 (2001) : Real-time CORBA CORBA 2.6 (2001) : Common Security CORBA 3.0 (2002): CCM, Minimum CORBA CORBA 3.1 (2008): CORBAe CORBA 3.11 (2011) CORBA 3.2 (in proces)

Slide 8 © Ingeniørhøjskolen i Århus CORBA CORBA comes down to: Objects Requests Brokers

Slide 9 © Ingeniørhøjskolen i Århus Application Objects CORBA Facilities CORBA Services (mandatory) Domain Interfaces Object Management Architecture (OMA) Object Request Broker

Slide 10 © Ingeniørhøjskolen i Århus One standardised interface One interface per object operation ORB-dependent interface One interface per object adapter Dynamic Invocation Client Stubs ORB Interface Implementation Skeletons Client Object Implementation ORB Core Object Adapter CORBA Architecture 2

Slide 11 © Ingeniørhøjskolen i Århus CORBA Architecture1 Many different vendors and ORB types Many of which do not interoperate Must check specification compliance OrbBacus from IONA produces both C++ and Java Sun J2SE SDK has only Java-based ORB C++ ORB from IONA will work with SUN ORB as specified Many others MicoORB, Middcor (C#), TAO (C++), openORB, VisiBroker OmniORB (C++, Phyton) OrbExpress RT: Java, C++, Ada, Android, DSP, FPGA

Slide 12 © Ingeniørhøjskolen i Århus Exercise 1: 15 minutes Find CORBA implementations to support a system with the following needs: Java Server on LINUX C# Client on Windows C++ Client on Embedded Linux Phyton Client on Linux FPGA Client For each vendor write down: CORBA support level (which version e.g. CORBA 2.2 or 2.6) Which Services are supported? Minimum hardware requirements and foot print How does it achieve interoperability? Protocol?

Slide 13 © Ingeniørhøjskolen i Århus CORBA 2.0 Applications GIOP ESIOP IIOPDOETalk DCE-CIOP Mandatory: provides "out of the box" interoperability Interoperability Protocols Environment Specific.. IIOP: Internet Inter-ORB Protocol is the primary CORBA transport protocol

Slide 14 © Ingeniørhøjskolen i Århus General Inter-ORB Protocol (GIOP) Handles the session & presentation layer Defines seven message primitives: Request, Reply, Locate Request, Locate Reply, Cancel request, Close Connection, Message Error More simple than JRMP for Java RMI Internet Inter-ORB Protocol (IIOP) Maps GIOP to TCP/IP Provides operations to open and close TCP/IP connections Is required from ORBs for CORBA compliance But intra vendor ORB com is not restricted to this More on the IIOP later in the course

Slide 15 © Ingeniørhøjskolen i Århus Common Data Representation (CDR) Defined as part of GIOP Presentation layer implementation to support heterogeneity Mapping of IDL data types to transport byte stream Encodings of primitive types constructed types interoperable object references

Slide 16 © Ingeniørhøjskolen i Århus IDL Motivation IDL: Interface Definition Language Components of distributed systems are written in different programming languages Programming languages may or may not have their own object model Object models largely vary Differences need to be overcome in order to facilitate integration

Slide 17 © Ingeniørhøjskolen i Århus Heterogeneous OO Network CORBA C++ Client App.3 CORBA C# Client App.2 CORBA Java Client App.1 TCP/IP Network CORBA Cobol Database Server DB “Object Wrapping of non OO application” Different ORB’s from different vendors, on different operating systems – and written in different languages = Heterogenity

Slide 18 © Ingeniørhøjskolen i Århus PL IDL CORBA IDL & Mappings Avoid multiple mappings

Slide 19 © Ingeniørhøjskolen i Århus IDL Common Object Model Smalltalk Cobol Java Ada-95 C++ C C CORBA Programming Language Bindings.NET Janeva / Middcor (C#) Win32 Delphi

Slide 20 © Ingeniørhøjskolen i Århus Interface Definition Language (IDL) Language for expressing all concepts of the middleware’s object model Should be programming-language independent not computationally complete Bindings to different programming languages needed language bindings are specified by CORBA The IDL is very comprehensive – please read and experiment with it

Slide 21 © Ingeniørhøjskolen i Århus Example UML to IDL mapping Player -name:string -Number:int +book() Team -name:string +bookGoalies() plays in transfer(p:Player) Club -noOfMembers:int -location:Address has 1 * uses Organization #name:string coaches 1..* Trainer -name:string 11..* +train() works for

Slide 22 © Ingeniørhøjskolen i Århus Constructed types CORBA Object Model: Types typedef struct Address { string street; string postcode; string city; }; typedef sequence AddressList; interface Team {... }; Atomic types Objec t type

Slide 23 © Ingeniørhøjskolen i Århus CORBA Object Model: Modules module Soccer { typedef struct Address { string street; string postcode; string city; }; module People { typedef struct Address { string flat_number; string street; string postcode; string city; string country; }; Modules = namespaces Soccer::Address People::Address

Slide 24 © Ingeniørhøjskolen i Århus CORBA Object Model: Attributes interface Player; typedef sequence PlayerList; interface Trainer; typedef sequence TrainerList; interface Team { readonly attribute string name; attribute TrainerList coached_by; attribute Club belongs_to; attribute PlayerList players;... }; Attribute typeAttribute name changeable Clients cannot change value

Slide 25 © Ingeniørhøjskolen i Århus CORBA Object Model: Operations interface Team {... void bookGoalies(in Date d); string print(); }; Parameter list Parameter kind Parameter type Parameter name Operation name used in requests Return types

Slide 26 © Ingeniørhøjskolen i Århus CORBA Object Model: Exceptions Generic Exceptions (e.g. network down, invalid object reference, out of memory) Type-specific Exceptions (e.g. PlayerBooked) exception PlayerBooked{sequence free;}; interface Team { void bookGoalies(in Date d) raises(PlayerBooked); }; exception PlayerBooked{sequence free;}; interface Team { void bookGoalies(in Date d) raises(PlayerBooked); }; Exception data Operations declare exceptions they raise Exception name

Slide 27 © Ingeniørhøjskolen i Århus CORBA Object Model: Subtypes interface Organization { readonly attribute string name; }; interface Club : Organization { exception NotInClub{}; readonly attribute short noOfMembers; readonly attribute Address location; attribute TeamList teams; attribute TrainerList trainers; void transfer(in Player p) raises NotInClub; }; interface Organization { readonly attribute string name; }; interface Club : Organization { exception NotInClub{}; readonly attribute short noOfMembers; readonly attribute Address location; attribute TeamList teams; attribute TrainerList trainers; void transfer(in Player p) raises NotInClub; }; Inherited by Club Supertype Implicit supertype: Object This has only been a minimal presentation of the IDL

Slide 28 © Ingeniørhøjskolen i Århus Legal Values in CORBA (Types)

Slide 29 © Ingeniørhøjskolen i Århus Interface Definition Design Server Stub Generation Client Stub Generation Server Coding Client Coding Server Registration Development Steps – CORBA vs Java RMI & Web services SOAP: WSDL Java2WSDL WSDL2JAVA AXIS SOAP RMI: rmic RMI: JAVA J2SE JDK Start with Server Interface Coding: JAVA Start with Server Interface Coding: JAVA rmiregistry CORBA CORBA: IDL ORB RMI: JAVA interface C++, Java …

Slide 30 © Ingeniørhøjskolen i Århus C++ Compiler, Linker Server Client.cc Server.cc C++ Compiler, Linker Client Team.idl included in generates reads IDL-Compiler Teamcl.hh Teamcl.cc Teamsv.cc Teamsv.hh CORBA Client and Server Implementation Next we will look into a simple CORBA programming example

Slide 31 © Ingeniørhøjskolen i Århus Exercise 2: IDL (15 minutes) Create an IDL for an ER system: Should be able to report: Systolic blood pressure (int32) Diastolic blood pressure (int32) Heart Rate/Pulse(int32) Saturation (int32) Given a PatientID (string) sensor clients should be able to store healthcare data on a server It should be possible to query all data on a patient given the PatientID It should be possible to subscribe to alerts, e.g. a given PatientID reading dropping below Systolic 100, and Saturation below 90. Make a UML deployment diagram sketch of the system Consider how a C++ client, C# client, and Java server can interoperate Which technologies could be useful here?

Slide 32 © Ingeniørhøjskolen i Århus “Hello World” CORBA Example with file IOR Client app. Server app. Development PC CORBA Java / C++ Hello World Client CORBA Java Hello World Server TCP/IP Network TCP/IP Network User activa- tes client Server returns “Hello World !“

Slide 33 © Ingeniørhøjskolen i Århus Who’s doing what? Some code will get generated by the IDL compiler Some code we will need to implement ourselves Starting with the IDL file

Slide 34 © Ingeniørhøjskolen i Århus IDL Interface of Hello Servant module HelloApp interface Hello { string sayHello(); };

Slide 35 © Ingeniørhøjskolen i Århus IDL Compiler Example Java Hello.idl file Java IDL Compiler - IDLJ Hello.java (Both Client & Server) contains the Java version of the IDL interface. HelloOperations.java contains the methods – here only sayHello(). All the operations in the IDL interface are placed in the operations file. _HelloStub.java is the client stub. HelloPOA.java is the skeleton class you should extend from. It implements dynamic invocation functions. HelloHelper.java (Both Client & Server) provides auxiliary functionality, notably the narrow() method required to cast CORBA object references to their proper types. HelloHolder.java Whenever the IDL type is an out or an inout parameter, the Holder class is used. Generates Input What gets generated by the IDL Compiler

Slide 36 © Ingeniørhøjskolen i Århus Extract from _HelloStub.java What are we looking at?

Slide 37 © Ingeniørhøjskolen i Århus Extract from HelloHelper.java Discuss with your neighbor 2 min. what is this? what is it used for?

Slide 38 © Ingeniørhøjskolen i Århus Extract from HelloPOA Discuss with your neighbor 2 min. what is this? what is used for? More on this later

Slide 39 © Ingeniørhøjskolen i Århus // HelloServer.java, stringified object reference version // Stefan Wagner, 2003 import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import org.omg.PortableServer.*; import org.omg.PortableServer.POA; import HelloApp.*; //This is the servant - implementing the methods from the IDL class HelloServant extends HelloPOA { private ORB orb; public HelloServant(ORB orb) { this.orb = orb; } public String sayHello() { return "\nHello world !!\n"; } Constructor taking ORB as a parameter (from HelloPOA) HelloServant The server object (Part 1) The CORBA operation implemented By extending from HelloPOA we may communicate with ORB Implemented manually

Slide 40 © Ingeniørhøjskolen i Århus //This is the HelloServer - the server running the HelloServant - Servant public class HelloServer { public static void main(String args[]) { try{ // create and initialize the ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null); // create servant and register it with the ORB HelloServant helloRef = new HelloServant(orb); // get reference to rootpoa and activate the POAManager POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); rootpoa.the_POAManager().activate(); // get object reference from the servant org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloRef); Hello href = HelloHelper.narrow(ref); // stringify the helloRef and dump it in a file String oir = orb.object_to_string(href); java.io.PrintWriter out = new java.io.PrintWriter(new java.io.FileOutputStream("object.ref")); out.println(oir); out.close(); // wait for invocations from clients orb.run(); } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } } } HelloServant The server object (Part 2) Init ORB and register servant with ORB Start the orb server process The POA produces the reference Narrow the call (CORBA type cast + IDL type check) Object reference ”stringified” and Sent to file object.ref Object reference ”stringified” and Sent to file object.ref Activate rootPOA Implemented manually

Slide 41 © Ingeniørhøjskolen i Århus // HelloClientSOR.java, stringified object reference version import java.io.*; import org.omg.CORBA.*; import HelloApp.HelloHelper; import HelloApp.*; public class HelloClientSOR { public static void main(String args[]) { try { // create and initialize the ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null); // Get the stringified object reference and destringify it. java.io.BufferedReader in = new java.io.BufferedReader(new java.io.FileReader("object.ref")); String ref = in.readLine(); org.omg.CORBA.Object obj = orb.string_to_object(ref) ; Hello helloRef = HelloHelper.narrow(obj); // call the Hello server object and print results String Hello = helloRef.sayHello(); System.out.println(Hello); } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out);} } HelloClientSOR The Client program Init ORB Narrow the call (CORBA type cast + IDL type check) Object reference Read from file Object reference Read from file Call via Proxy Implemented manually Discuss with your neighbor 2 min. what happens after sayHello()

Slide 42 © Ingeniørhøjskolen i Århus What is this object.ref file? IOR: Interoperable Object Reference Includes info on: Repository ID (standard), Endpoint Info (standard) - including IP and port number, Object Key (proprietary) Can be written into a file Not really nice with a file-based reference – or what? May employ a naming service instead This we shall look at later File-based may be necessary due to firewall problems Possible to use a HTTP or FTP server for distributing the references IOR: c3 a48656c6c6f f48656c6c6 f3a312e c e e e312e b afabcb a80a a

Slide 43 © Ingeniørhøjskolen i Århus Parsed IOR _IIOP_ParseCDR: byte order BigEndian, repository id, 1 profile _IIOP_ParseCDR: profile 1 is 138 bytes, tag 0 (INTERNET), BigEndian byte order (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.2, hostname= , port=1658, object_key= (iiop.c:parse_IIOP_Profile): encoded object key is (iiop.c:parse_IIOP_Profile): non-native cinfo is object key is ; no trustworthy most-specific-type info; unrecognized ORB type; reachable with IIOP 1.2 at host " ", port For the translation of IORs

Slide 44 © Ingeniørhøjskolen i Århus #include int run(CORBA::ORB_ptr); int main(int argc, char* argv[]) {int status = EXIT_SUCCESS; CORBA::ORB_var orb; try { orb = CORBA::ORB_init(argc, argv); status = run(orb); } catch (const CORBA::Exception&) { status = EXIT_FAILURE; } if(!CORBA::is_nil(orb)) { try { orb -> destroy(); } catch(const CORBA::Exception&) {status = EXIT_FAILURE; } } return status; } HelloCorba C++ Client Part 1 Init ORB Destroy ORB Call run method (see next slide) Implemented manually

Slide 45 © Ingeniørhøjskolen i Århus … int run(CORBA::ORB_ptr orb) { const char* refFile = "object.ref"; ifstream in(refFile); char s[2048]; in >> s; CORBA::Object_var obj = orb -> string_to_object(s); HelloApp::Hello_var hello = HelloApp::Hello::_narrow(obj); cout sayHello() << endl; return 0; } HelloCorba C++ Client Part 2 Narrow the call (CORBA type cast) to the Hello_var smartpointer (helper + memory management) Narrow the call (CORBA type cast) to the Hello_var smartpointer (helper + memory management) Object reference Read from file Object reference Read from file Call method via Proxy and print result HelloApp::Hello_var smartpointer type Generated by IDL compiler + Hello Read more on Smartpointer types in OOMI-1 chapter 4

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

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

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

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

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

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

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

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

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

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

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

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

Slide 58 © Ingeniørhøjskolen i Århus CORBA Problems Problem with CORBA Considered too complex by many Open standards -> cluttered solutions Limited platform support Is CORBA dead?

Slide 59 © Ingeniørhøjskolen i Århus Exercise 3: 15 minutes Download one or more IDL compilers (or just use the idlj.exe if you have Java JSE installed - see: l/jidlExample.html) l/jidlExample.html Try compiling the IDL from exercise 3 with a Java Compiler What was the result?