1. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Part I A RMI case study Karsten Schulz Terp-Nielsen

2. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Agenda  Object Managment Group (OMG)  Corba Overview – Architecture – OMG IDL – ORB – Object Model – The Interoperability Architecture – Language mappings  J2SE 1.4 support for CORBA

3. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Object Management Group (OMG) CORBA/OMG  CORBA is the acronym for Common Object Request Broker Architecture  CORBA is OMG's open, vendorindependent specification for an architecture and infrastructure that computer applications use to work together over networks  OMG is the world ’ s largest computer industry consortium with over 800 members ( year 2000 figure)  OMG began its work in 1989  The goals of OMG are – promotion of the object-oriented approach to software engineering – development of a common architectual framework for writing distributed object-oriented applications based on interface specifications for the objects in the application

4. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Object Management Group (OMG) OMA  Besides CORBA OMG also controls the Object Management Architecture (OMA) specification and other specifications in the area Analysis and Design (XMI, UML etc.)  OMA is the framework which all OMGs adapted technology fits  OMA consists of two main parts – Core Object Model – The Reference Model

5. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Object Management Group (OMG) OMA Core Object Model  Defines concepts that allow distributed application development to be facilitated by an ORB – Contains abstract definitions  The goals of the Core Object Model are – portability (design portability - to be able to create components that don ’ t rely on existence and location of a particular object implementation) – interoperability (to be able to invoke operations on objects regardless of where they are located, on which platform they execute, or in which programming language they are implemented

6. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Object Management Group (OMG) OMA Core Object Model  The Core Object Model is a classic object model (actions performed by invoking operations on objects) – Objects (entities or concepts, identity represented by an object reference) – Operations: signatures, parameters, return values, exceptions – Nonobject types (data types), Not specified by the core model, CORBA does – Interfaces, grouping of operations – Substitutability  When two interfaces can act as substitutes to each other (only substitution through inheritance are acceptable in the CoreObject Model) Two interfaces having the same operations are not substi- tutable as they problably don ’ t have the same semantic

7. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Object Management Group (OMG) OMA Reference Model OMA defines the interfaces for the objects and leave the implementation to software vendors OMA is OMGs vision for a software component environment where all their work fits The OMA Reference Model categories objects into four application areas Your CORBA objects! Naming, Notification, Security, Trading etc. Mobile Agents, MOF, Data Interchange Tele, Health Care, Manu- facturing etc. Domain objects Common facilities Object ervices

8. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview CORBA  Introduction  Architecture  OMG IDL  ORB  Object Model  The Interoperability Architecture  Language mappings

9. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Introduction  CORBA builds on the OMA Core Object Model and provides – syntax and semantics for IDL – A framework for interoperability: two specific protocols – a set of language mappings from IDL to prog.lang.  CORBA is operating with transparency – Location transparency – Programming Language transpareny – Platform/vendor transparency – Network HW/SW transparency

10. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Introduction  The key to Location transparency is the Object Request Broker (ORB)  The key to Programming Language Transparency is an implementation neutral Interface Definition Language called OMG IDL that provides separation of interface and implementation  The key to Platform transparency and Network HW/SW transparency is GIOP/CDR (Common Data Representation)

11. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Introduction In other words …………….. CORBA allow programs from any vendor, on almost any computer, operating system, programming language, and network, to interoperate with a CORBA- based program from the same or another vendor, on almost any other computer, operating system, programming language, and network

12. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Architecture client server proxy or dynamic invocation implementation repository object adapter ORB skeleton or dynamic skeleton client program interface repository Request Reply core for A Servant A The Orb core equals the Communication Module in the generic RMI architecture The ORB can be implemented in many ways; stand-alone, distributed To the programmer the ORB is a pseudo-object; interface to library functions ORB IIOP

13. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Architecture  Compared to the Generic RMI architecture there is only 3 new modules – Object Adapter – Implementation Repository – Interface Repository  The communication protocol used by CORBA is based on the GIOP (General Inter-ORB Protocol) specification  IIOP (Internet Inter-ORB Protocol) denotes the implementation of GIOP over TCP/IP

14. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview OMG IDL  OMG IDL is a declarative language for defining the interfaces of CORBA objects  OMG IDL is language independent  OMG IDL is used by ORB-specific IDL compilers to generate stubs, skeletons and interface code in a given programming language in compliance with the IDL mapping specification for that programming language

15. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview OMG IDL  The syntax of OMG IDL is drawn from C++ but it contains different keywords for stuff  OMG IDL doesn ’ t contain programming statements as its only purpose is to define interface signatures  The following constructs are available – Constants – Data type declarations (IDL types) – Attributes

16. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview OMG IDL – Operations  Parameters are marked as either in, out or inout – Interfaces  Group data type, attribute and operation declarations  Exceptions can be defined  Support for multiple inheritance – name collision not allowed – Valuetypes  Group data type, state and operation declaration  When client invokes methods -> local method invocation – Modules  Name space separation

17. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview OMG IDL - Example struct Rectangle{1 long width; long height; long x; long y; } ; struct GraphicalObject {2 string type; Rectangle enclosing; boolean isFilled; }; interface Shape {3 long getVersion() ; GraphicalObject getAllState() ; // returns state of the GraphicalObject }; typedef sequence All; 4 interface ShapeList {5 exception FullException{ }; 6 Shape newShape(in GraphicalObject g) raises (FullException);7 All allShapes();// returns sequence of remote object references8 long getVersion() ; };

18. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview OMG IDL - Example public interface ShapeList extends org.omg.CORBA.Object { Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException; Shape[] allShapes(); int getVersion(); } The following are generated by the idl2java (ORBACUS: jidl) compiler + ShapeListHolder.java, ShapeListHelper.java, ShapeListOperations.java, ShapeListPOA.java, _ShapeListStub.java, ShapeHolder.java, ShapeHelper.java, ShapePOA.java, _ShapeStub.java, Shape.java, ShapeOperations.java, FullException.java, FullExceptionHolder.java, FullExceptionHelper.java, GraphicalObject.java, GraphicalObjectHolder.java, GraphicalObjectHelper.java Rectangle.java, RectangleHolder.java, RectangleHelper.java AllHelper.java, AllHolder.java

19. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB  The ORB is particular responsible for – making the location transparency ie. routing the request from a client to object and routing the reply to destination – management of the Interface Repository; a distributed database of IDL definitions – Client side services for converting remote object references to and from strings – Client side dynamic invocation of remote objects – Server side resource management that is activation and deactivation of objects

20. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Components  Implementation Repository (optional)  Interface Repository  Client Stubs  Server Skeletons  Portable Object Adapter (POA)  Dynamic Invocation Interface (DII)  Dynamic Skeleton Interfaces (DSI)

21. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Components diagram The Implementation Repository and the Interface Repository are not shown here

22. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Implementation Repository  ORBs also often communicate with a ORB deamon process which is a Implementation Repository  Implementation Repository is a database of object implementation information which the ORB can use for locating the server housing the object implementation  Implementation Repository is a server activator  Example: Java IDL in Java 1.4 – ORBD  Example: Orbacus fra IONA – Imr

23. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Implementation Repository  An Implementation Repository is responsible for locating and activating on demand registered CORBA servers  An Implementation Repository stores a mapping from names of Object Adapters to servers address (host:port) along with scripts/batch files for starting the server if not running Implementation Repository: Jupiter:8080 POA1 \bin\server\startPOA1 TestHost:8888 The ORBcus IMR console is an ex. of GUI adm. of the IMR

24. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Interface Repository  The Interface Repository stores information about registered IDL Interfaces to clients and servers – names of methods – for each method the names and types of arguments and exceptions – the key is a IDL compiler generated unique identifier which is generated for each IDL type it compiles  The Interface Repository is the fundament for reflection in CORBA  The Interface Repository and the Dynamic Invocation Interface adds the power of reflection to CORBA

25. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Interface Repository  The Interface Repository can be access by both clients and servers  The Interface Repository is often a autonom server/process which contain command line commandos for feeding interface definitions into and deleting interface definitions from the Repository  Example: ORBacus – irserv, irfeed, irdel

26. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Client stubs/proxy  Generated from an OMG IDL compiler to the client language of choise  Acts as a local proxy for the remote object  Aggregates the IOR  Marshals data to be send;Unmarshal result – Data send is typically Object key, name of operation and in and inout parameters  There exists one client stub instance per instance of remote object  Can ’ t be downloaded at run-time as in JavaRMI

27. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Client stubs/proxy example interface Hello { string say_hello(); void shutdown(); }; public interface HelloOperations { // // IDL:Hello/say_hello:1.0 // /***/ String say_hello(); // // IDL:Hello/shutdown:1.0 // /***/ void shutdown(); } hello.idl Generated HelloOperations.java interface to use for the Skeleton public interface Hello extends HelloOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } Generated Hello.java interface to use for the Stub

28. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Client stubs/proxy example public class _HelloStub extends org.omg.CORBA.portable.ObjectImpl implements Hello { private static final String[] _ob_ids_ = { "IDL:Hello:1.0", }; …. // IDL:Hello/say_hello:1.0 public String say_hello() { while(true) { if(!this._is_local()) { org.omg.CORBA.portable.OutputStream out = null; org.omg.CORBA.portable.InputStream in = null; try { out = _request("say_hello", true); in = _invoke(out); String _ob_r = in.read_string(); return _ob_r; } catch(org.omg.CORBA.portable.RemarshalException _ob_ex) Create output stream Create input stream as a Result of the invocation Marshall arguments Un-Marshall result, out, inout

29. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Skeleton  Generated from an OMG IDL compiler to the server language of choice  Unmarshals request data; Dispatch request to servant; Marshals reply data  Servant is the actual CORBA object implementation in a chosen programming language  Skeletons are used by the POA

30. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Skeleton example public abstract class HelloPOA extends org.omg.PortableServer.Servant implements org.omg.CORBA.portable.InvokeHandler, HelloOperations { static final String[] _ob_ids_ = { "IDL:Hello:1.0",}; public org.omg.CORBA.portable.OutputStream _invoke(String opName, org.omg.CORBA.portable.InputStream in, org.omg.CORBA.portable.ResponseHandler handler) { final String[] _ob_names = { "say_hello","shutdown" }; …. //Find index for operation ….. switch(_ob_index) { case 0: // say_hello return _OB_op_say_hello(in, handler); case 1: // shutdown return _OB_op_shutdown(in, handler); } throw new org.omg.CORBA.BAD_OPERATION();} Skeleton code for hello.idl produced by IDL2Java compiler from ORBACus -jidl

31. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Skeleton example continued private org.omg.CORBA.portable.OutputStream _OB_op_say_hello(org.omg.CORBA.portable.InputStream in, org.omg.CORBA.portable.ResponseHandler handler) { org.omg.CORBA.portable.OutputStream out = null; String _ob_r = say_hello(); out = handler.createReply(); out.write_string(_ob_r); return out; } private org.omg.CORBA.portable.OutputStream _OB_op_shutdown(org.omg.CORBA.portable.InputStream in, org.omg.CORBA.portable.ResponseHandler handler) { …. } Skeleton code continued

32. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter  An Object Adapter is responsible for – Generation and interpretation of IORs – Carrying out method invocations – Security on interactions – CORBA Object/implementation activation and deactivation – Mapping of IORs to corresponding object implementations – Registration of object implementations The component in the ORB architecture that maps the abstract concept of a CORBA Object onto concrete concepts provided by a specific prog. lang. Life cycle managment

33. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter  Terminology – Servant: Implementation object providing the run- time semantic of one or more CORBA objects – ObjectID: An identifier, unique within a POA, that a POA uses to identify a CORBA Object – AOM: A table of Associations between ObjectIDs and servants – Incarnate: The action of providing a running servant to serve requests associated with a particular ObjectID  The POA will keep the association in AOM if configurated to do that

34. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Etherealize: The action of destroying the association between an ObjectID and a servant – Activated: When a CORBA Object has been associated with a servant incarnating the object – Deactivated: When a CORBA Object has no incarnating servant – Default Servant: An object for which all incomming requests for ObjectIDs not in AOM are dispatched to  Only if configurated to do that

35. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter  An Object Adapter provides a public interface to object implementations  An Object Adapter provides a private interface to the Skeleton  An Object Adapter is build upon a private ORB-dependent interface to the ORB Core  There are a variety of possible Object Adapters but it preferrable to use a few as possible as the object implementation is dependent upon them

36. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - high-level architecture ORB Core POA Manager POA Server Application Servants Dispatch with help from skeletons Request

37. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA Manager  Represents an 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

38. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA Manager Active Holding Discarding Inactive Creation Hold_requests Active Hold_ requests Discard_ requests Discard_requests Deactivate POA Manager state transitions

39. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA overview  A server process contains one or more POAs  All server processes contains one special POA called the ” rootPOA ” which is managed by the ORB – Developers can use this if default policies are suitable  Additional POAs can be created as children of other POA resulting in a hierarcy with the ” rootPOA ” as the root  Advantages: Different policies can be assigned to each POA

40. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA overview 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

41. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA overview  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

42. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – POA overview 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 create servant update map

43. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Adapter Activator  An Adapter Activator is an application object the developer can associate with a POA  The ORB will invoke an operation on an adapter if its processing a request for a child POA that does not currently exist  The Adapter Activator can then create the child POA on demand and the ORB will deliver the request to the newly created POA

44. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment  To better understand the activation/passivation mechanism offered by the POA, let ’ s talk a little bit about Life Cycle management in distributed OO systems  When we make OO development we make a conceptual model of the problem domain consisting of system entities denoted objects categorized in classes  The conceptual model is then mapped to the machine when we make a design model for the application – a model for the system running on a machine

45. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment Phenomenons Problem spec. concepts Abstraction Machine lang. Realized Concepts Abstraction Problem domainSystem model Modeling A conceptual model is made for the Problem domain OOA Problem spec. Concepts are defined from the realized concepts OOD We find elements that model phenomenos and concepts from the problem domain/conceptual model OOP

46. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment  The Implementation Model model the behaviour of the objects in the problem domain – The application will consist of the implementation model plus objects modeling the functionality and interfaces (UI+integration)  The model register and remember relevant states in the problem domain – The objects in the implementation model register the behaviour of the objects in the problem domain – With some delay the state of the implementation model objects are changed according to events happening in the problem domain

47. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment  When done modeling we have one or more implementation objects register relevant state changes for each system entity (problem domain object)  The life cycle of a system entity in the problem domain and the related implementation objects need not be the same – The difference between system entities and object implementations is the heart of Life Cycle and Persistence

48. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment  Persistence is chiefly concerned with what it means for an system entity to exist when its implementation object(s) does not  Life cycle is chiefly concerned with the life cycle of system entities versus the life cycle of the runtime implementation objects – System entities: created, activated, deactivated, destroyed – Runtime instance: instantiated, persistent information loaded, remote reference exported etc.  In CORBA most of the basic life cycle support lies within the POA

49. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment  In CORBA persistence is provided through a CORBA service named Persistent State Service – Likewise is enhanced Life cycle support provided through Life cycle service  In CORBA system entities are implemented/modeled by CORBA Objects  CORBA Objects are identified by remote object references, specified through IDL interfaces and implemented by servants  So CORBA Objects and servants have different life cycle and remember: System entities and CORBA objects have different life cycle

50. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle management  There is no actual relationship between the life time of a servant and the life time of a CORBA Object – Only that a servant must exist at the time the CORBA Object is activated – The servant may have been created before the CORBA Object activation or even before the remote object reference creation – The servant may exists beyond the time the CORBA Object is active or even exists

51. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment CORBA Object non-existent CORBA Object existent CORBA Object activated CORBA Object deactivated activate create reference CORBA Object State diagram deactivate activate All transitions are triggered by operations on a POA When activating an CORBA object immediately - the corresponding remote ref doesn ’ t have to be created right away; it can done anytime later When creating an remote object ref - an ObjectID and a remote object reference is associated; activation can be done later! destroy Remember when the CORBA Object does not exist, the system entity can exist in terms of fx. a row in a db table

52. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle managment Object create_reference (in CORBA::RepositoryId intf) raises (WrongPolicy); Object create_reference_with_id (in ObjectId oid, in CORBA::RepositoryId intf) raises (WrongPOlicy); ServantManager get_servant_manager () raises (WrongPolicy); void set_servant_manager (in ServantManager imgr) raises (WrongPOlicy); Servant get_servant () raises (NoServant, WrongPolicy); void set_servant (in Servant serv) raises (WrongPOlicy); ObjectId activate_object (in Servant serv) raises (ServantAlreadyActive, WrongPolicy); void activate_object_with_id (in ObjectId oid, in Servant serv) raises (ServantAlreadyActive, ObjectAlreadyActive, WrongPolicy); Object activation with servantRemote reference creation without servant CORBA object activatedCORBA object exist Servant manager registrationDefault servant registration

53. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter – Life cycle management Object Reference Object Id Servant ObjectId reference_to_id (in Object ref) raises (WrongAdapter, WrongPolicy); Object id_to_reference (in ObjectId oid) raises (ObjectNotActive, WrongPolicy); ObjectId reference_to_id (in Object ref) raises (WrongAdapter, WrongPolicy); Object id_to_reference (in ObjectId oid) raises (ObjectNotActive, WrongPolicy); ObjectId servant_to_id (in Servant serv) raises (ServantNotActive, WrongPolicy); Servant id_to_servant (in ObjectId oid) raises (ObjectNotActive, WrongPolicy); ObjectId servant_to_id (in Servant serv) raises (ServantNotActive, WrongPolicy); Servant id_to_servant (in ObjectId oid) raises (ObjectNotActive, WrongPolicy); Servant reference_to_servant (in Object ref) raises (ObjectNotActive, WrongAdapter, WrongPolicy); Object servant_to_reference (in Servant serv) raises (ServantNotActive, WrongPolicy); Servant reference_to_servant (in Object ref) raises (ObjectNotActive, WrongAdapter, WrongPolicy); Object servant_to_reference (in Servant serv) raises (ServantNotActive, WrongPolicy); Methods on the POA Only if RETAIN policy Plus UNIQUE_ID Or IMPLICIT_ACTIVATION And not active Plus UNIQUE_ID Or MULTIPLE_ID And not active activated

54. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies Each POA maintain a Active Object Map (AOM) that map object IDs to servants.... Servants AOM POA OBJID:1 OBJID:N+1 OBJID:N IOR Object Reference POA1,OBJID:N Client …… ….. It can however be disabled

55. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  Each POA is associated with 7 policies when its created – they are not changeable later  The policies are not inherited from parent POA to its children POA upon creation – Given a set of standard policies  Policies control implementation characteristics of the servants and object references  Examples are – threading model for request dispatch – life time of references

56. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  LifespanPolicy – Transient object references – Persistent object references  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 Detailed further in discussing the object model

57. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  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

58. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies – Using MULTIPLE_ID offers you  scalability  possible slow access to servant state  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 Lets you develop the server as ‘ Type ’ based while clients see it as instance based!!!!!

59. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  RequestProcessingPolicy – Whether the POA uses static servant mapping (AOM) or servants are instantiated dynamically – Possible values  USE_ACTIVE_OBJECT_MAP_ONLY  USE_DEFAULT_SERVANT  USE_SERVANT_MANAGER ­ Servant Activator (RETAIN - servant for continues use) ­ Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())

60. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  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

61. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  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

62. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  ORBaCus provides more threading models – SingleThreaded Blocking (Client) – SingleThreaded Reactive (Client/Server) – Threaded (Client/Server) – Thread-per-Client (Server) – Thread-per-Request (Server) – ThreadPool (Server)  Java ORB 1.4 doesn ’ t support SingleThreaded model

63. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  Default values for the 7 policies for the RootPOA – transient – system_id – unique_id – retain – use_active_object_map_only – implicit_activation – orb_ctl_model

64. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  Standard policies for POA creation – transient – system_id – unique_id – retain – use_active_object_map_only – no_implicit_activation – orb_ctl_model

65. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - 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

66. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter - Policies  When deciding on how to configurate the POA, the following main design factors has to be taken into account – How many objects will the POA host? – What is the expected request load? – Do objects have persistent state?

67. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter example  To create a POA based CORBA server application you have to 1) IDL-2-Java compile the interfaces you are going to use -> this produces the following files for IDL interface hello:HelloOperations.java, HelloPOA.java HelloPOATie.java (--tie), HelloHelper.java, HelloHolder.java, _HelloStub.java, Hello.java 2) make a servant class 3) make a CORBA server that instantiates the servant and activate it

68. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Portable Object Adapter example  To make the servant class – Inherit from the POA skeleton generated by the OMG Idl-2-Java compiler – What if I want to servant to inherit from another class?  Solution - generate the skeleton as a tie implementation – Example Hello (eksempler/hello)  Servant class:Hello_impl.java  Server class:Server.java – This program uses the default values for the 7 policies for the RootPOA

69. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Dynamic Invocation Interface (DII)  DII is how you from a client can invoke remote object without having stubs/proxies for them – As noted earlier; in Java RMI this is done by downloading the stubs/proxies at run-time  The steps involved are – Client obtain interface from the Interface Repository – Client constructs an invocation by usage of DII and sends it to the server

70. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Dynamic Invocation Interface (DII)  DII requests send to server can be of the following types – Synchronous; blocking call invoke() – Asynchronous; non-blocking call send_deferred returns without waiting for the invocation to complete  to get the result the client can either invoke the blocking get_response() or poll for completion by poll_response() – One-way call send_oneway() without reply from server  Multiple requests can also be issued for one-way and asynchronous requests by providing a list of request

71. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Dynamic Skeleton Interface (DSI)  The Dynamic Skeleton Interface allows an ORB to invoke an object implementation without compile-time knowledge about the interface ie. without a Skeleton class  This allows for writing programs that deal with requests in a generic manner – look at request and arguments – interpreted the semantic dynamically and return result  The server is coded normally!

72. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Dynamic Skeleton Interface (DSI) class HelloServant extends DynamicImplementation { // store the repository ID for the implemented interface static String[] myIDs = {"IDL:JavaIDL/DSIExample:1.0"}; ORB orb; // create a reference to the ORB HelloServant(ORB orb) { this.orb = orb; } // must implement invoke() for handling requests public void invoke(ServerRequest request) { try { System.out.println("DSI: invoke called, op = "+request.op_name()); // create an NVList to hold the parameters NVList nvlist = orb.create_list(0); // need an if statement like this for each method name if (request.op_name().equals("printHelloArgs") == true) { Example of servant code using DSI Essentially - you code the Skeleton code your self!!!

73. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping  Before a program can use CORBA objects, it must initialize itself – Create a ORB object – Obtain one or more initial object references, typically at least a Naming Context in a Naming Service  To create a ORB object the following is done import org.omg.CORBA.ORB; public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); // code continues

74. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping  Remeber that the ORB object is just a pseudo-object that can ’ t be passed around like a normal object  For Applets its special import org.omg.CORBA.ORB; public void init() { try { ORB orb = ORB.init(this, null); // code continues Must be upplied so the ORB can retrieve the Applet properties

75. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping  If there are more ORBs present in the runtime invi- ronment it has to be pointed out which ORB to use – Some browers contain an ORB – The Java 1.2 SE and up contains an ORB import java.util.Properties; import org.omg.CORBA.*; public class MyApplet extends java.applet.Applet { public void init() { // Instantiate the Java IDL ORB, passing in this applet // so that the ORB can retrieve the applet properties. Properties props = new Properties(); props.put("org.omg.CORBA.ORBClass", "com.sun.CORBA.iiop.ORB"); ORB orb = ORB.init(this, props);... }}

76. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping  To invoke a CORBA object the client must have a reference for it  Four ways to get a reference for a CORBA object – From a string created from a remote reference – From a Naming Service/Trader Service – From the ORB operation resolve_initial_references – From the result of calling a remote method on a CORBA object

77. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping Stringified object references  ORB implementation independent - the ORB can always convert a CORBA object reference to and from a string  Ensure that the object referred to is in fact accessible from where the client is running  Obtain the stringified reference, perhaps from a file or a parameter Object obj = orb.string_to_object("relfile:/Hello.ref"); if(obj == null) { System.err.println("hello.Client:cannot read Hello.ref"); return 1;} Hello hello = HelloHelper.narrow(obj);

78. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping Stringified object references The following fragment shows how a server converts a CORBA object reference to a string: org.omg.CORBA.ORB orb = // get an ORB object org.omg.CORBA.Object obj = // create the object reference String str = orb.object_to_string(obj); // make the string available to the client This code fragment shows how a client converts the stringified object reference back to an object: org.omg.CORBA.ORB orb = // get an ORB object String stringifiedref = // read string org.omg.CORBA.Object obj = orb.string_to_object(stringifiedref);

79. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping ORB references to services  The ORB resolve_initial_references is intended for bootstrapping object references into a newly started client  ORB dependent implementation for many services but now specified for the Naming Service  The operation takes a string argument that names one of a few recognized objects; it returns a CORBA Object, which must be narrowed to the type the client knows it to be

80. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Bootstrapping ORB references to services  Examples of recognized objects are – NamingService, TradingService – RootPOA, InterfaceRepository public calls NameClient { public static void main(String args[]) { try { Properties props = new Properties(); props.put("org.omg.CORBA.ORBInitialPort", "1050"); ORB orb = ORB.init(args, props); NamingContext ctx = NamingContextHelper.narrow( orb.resolve_initial_references("NameService"));...

81. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview ORB - Java CORBA Client example  To create a CORBA based Java client application you do the following – Implement the client application  Bootstrap ORB  Get initial reference (NamingService, file etc.)  Get remote object reference – Example: Hello  Client: Client.java ­ uses file to get initial reference which in this case equals the remote object reference

82. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model  The OMA Core Object Model defines some fundamental definitions of concepts which are extended, made more specific and concrete by CORBA  The class concept does not exist in CORBA as non-Object Oriented programming languages can be used as implementation language  Clients for remote objects are not necessary objects as Client implementation languages also can be non-Object Oriented

83. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references  Remote Object References can be in two forms Session form and Interoperable Object Reference (IOR) form  The session form is a vendor specific format – In session form there is no information that is meaningful for the client as the ref is only interpreted at the server side  The IOR form is intended for interoperability between different ORBs – The IOR form can be stringified to enable IORs to be stored, emailed, printed, and retrieved

84. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references 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

85. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references  Object references are opaque - application code isn ’ t allowed to look inside or make any assumptions about the internals  Remote Object references have a semantics very similar to class pointers in C++ - they can dangle ie pointing at a non-existing or unreachable object – If the server where the remote object lived is shutdown and started again on another host

86. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references  CORBA distinguishes between transient and persistent object references (LifeSpan policy)  A transient IOR continues to work a long as the corresponding server process where the remote object remains available – Once the server process is shutdown the IOR is non-functional forever (even if the server process is started again)  IOR Host:port contains the server process information for the POA

87. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references 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

88. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references  A persistent object reference survives shutdown of the server process - it still denotes the same CORBA object  This works even if the server process is started on another host:port  The persistent object reference has a life cycle independent of the life cycle of the servant  Many ORBs can transparently start server processes and shut them down again after some idle time in order to save resources

89. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references  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

90. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - remote object references IOR Object Reference IDL:MyObject Jupiter:8080 Server: TestHost:8888 OBJID:11 OBJID:12 POA1,OBJID:12 OBJID:13 Client POA1 Pseudo-random number Implementation Repository: Jupiter:8080 POA1 \bin\server\startPOA1 TestHost:8888

91. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Object Model - Persistent Reference example  To make the Hello object references persistent you do the following – Create a new Policy  the LifeSpanPolicy equals persistent  the IDAssignmentPolicy equals user_id  for all others default values are used – Create new POA associated with RooTManager with Policy ‘ the new policy ’ – Create servant and explicit activate servant – Example hello_imr

92. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Interoperability Architecture  The Interoperability Architecture for CORBA contain elements like – ORB interoperability – Inter-ORB bridge support – GIOPs and IIOPs  An ORB is considered being interoperability compliant when supporting – GIOP/IIOP – IOR

93. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Language Mappings  The following language specific OMG IDL compilers are contained in specifications ADA C C++ Java Smalltalk CORBA Script COBOL LISP Phyton Client Server ADA C C++ Java Smalltalk CORBA Script COBOL LISP Phyton

94. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen CORBA Overview Language Mappings - cross language example  To show CORBA is language independent use the IDL2CPP (idl) compiler on hello.idl to generate a interface and a stub  idl --no-skeletons hello.idl  Make a client.cpp implementation and link it to a client.exe  Start the Java ORB based hello server and start the C++ ORB based hello client

95. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen J2SE 1.4 support for CORBA

96. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen J2SE 1.4 support for CORBA CORBA compliance  JDK 1.4 contains a Java ORB implementation supporting a part of CORBA specification 2.3.1 – http://java.sun.com/j2se/1.4/docs/api/org/omg/CORBA/do c-files/compliance.html  JDK 1.4 contains the following CORBA tools – IDL-to-Java compiler (idlj) – Implementation Repository (orbd) – transient Naming Service (orbd) – persistent Naming Service (orbd) – servertool (cmd line interface tool) – tnamesrv (backward compability)

97. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen J2SE 1.4 support for CORBA CORBA features  GIOP 1.2 (IIOP)  POA  Portable interceptors – provides hooks, or interception points, through which ORB services can intercept the normal flow of execution of the ORB – three types  IORInterceptor  ClientRequestInterceptor  ServerRequestInterceptor

98. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen J2SE 1.4 support for CORBA CORBA features – The class ORBInitializer facilitates interceptor registration and ORB initialization  done through properties org.omg.PortableInterceptor.ORBInitializerClass.  where is the string name of a class which implements org.omg.PortableInterceptor.ORBInitializer  Interoperable Naming Service – can use corba urls

99. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen J2SE 1.4 support for CORBA CORBA example  Example of using persistent object references and the implementation repository in J2SE 1.4 (javacorba\exservertool) – start the orbd (startorbd) – start the server tool (startservertool) – register HelloServer and start it up – start the client (startclient)  every 6 seconds the client class the sayHello() on the remote object and shutdown the server  watch in Taskmanager how the server is automatically started up when its shutdown by the client

100. ® Distributed Systems Copyright Karsten Schulz Terp-Nielsen Next Time CORBA Part II  Summary  IDL to Java mapping  Corba Communication Models  CORBA Services  CORBA Naming Service  CORBA Transaction Service  CORBA Concurrency Service  RMI/IIOP  CORBA 3.0 - Whats new?