1 / 100

CORBA Part I A RMI case study

CORBA Part I A RMI case study. 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. Object Management Group (OMG) CORBA/OMG.

sydney
Download Presentation

CORBA Part I A RMI case study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CORBA Part IA RMI case study Karsten Schulz Terp-Nielsen

  2. 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. 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. 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. 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. 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. Object Management Group (OMG) OMA Reference Model The OMA Reference Model categories objects into four application areas Common facilities Domain objects Mobile Agents, MOF, Data Interchange Your CORBA objects! Tele, Health Care, Manu- facturing etc. Naming, Notification, Security, Trading etc. Object ervices 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

  8. CORBA OverviewCORBA • Introduction • Architecture • OMG IDL • ORB • Object Model • The Interoperability Architecture • Language mappings

  9. CORBA OverviewIntroduction • 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. CORBA OverviewIntroduction • 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. CORBA OverviewIntroduction 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. CORBA OverviewArchitecture ORB server client implementation interface repository repository skeleton object adapter Request ORB client proxy Servant ORB IIOP program for A core A core Reply or dynamic invocation or dynamic skeleton 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

  13. CORBA OverviewArchitecture • 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. CORBA OverviewOMG 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. CORBA OverviewOMG 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. CORBA OverviewOMG 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. CORBA OverviewOMG 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 <Shape, 100> All; 4 interface ShapeList { 5 exception FullException{ }; 6 Shape newShape(in GraphicalObject g) raises (FullException); 7 All allShapes(); // returns sequence of remote object references 8 long getVersion() ; };

  18. CORBA OverviewOMG IDL - Example The following are generated by the idl2java (ORBACUS: jidl) compiler public interface ShapeList extends org.omg.CORBA.Object { Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException; Shape[] allShapes(); int getVersion(); } + 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. CORBA OverviewORB • 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. CORBA OverviewORB - Components • Implementation Repository (optional) • Interface Repository • Client Stubs • Server Skeletons • Portable Object Adapter (POA) • Dynamic Invocation Interface (DII) • Dynamic Skeleton Interfaces (DSI)

  21. CORBA OverviewORB - Components diagram The Implementation Repository and the Interface Repository are not shown here

  22. CORBA OverviewORB - 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. CORBA OverviewORB - 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 The ORBcus IMR console is an ex. of GUI adm. of the IMR POA1 \bin\server\startPOA1 TestHost:8888

  24. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - Client stubs/proxy example Generated HelloOperations.java interface to use for the Skeleton hello.idl 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(); } Generated Hello.java interface to use for the Stub public interface Hello extends HelloOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { }

  28. CORBA OverviewORB - 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 Marshall arguments Create input stream as a Result of the invocation Un-Marshall result, out, inout

  29. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - Portable Object Adapter The component in the ORB architecture that maps the abstract concept of a CORBA Object onto concrete concepts provided by a specific prog. lang. • 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 Life cycle managment

  33. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - Portable Object Adapter - high-level architecture Server Application Dispatch with help from skeletons Request ORB Core POA Manager Servants POA

  37. CORBA OverviewORB - 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. CORBA OverviewORB - Portable Object Adapter – POA Manager POA Manager state transitions Creation Holding Hold_requests Hold_ requests Deactivate Active Deactivate Active Inactive Active Discard_ requests Deactivate Discarding Discard_requests

  39. CORBA OverviewORB - 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. CORBA OverviewORB - Portable Object Adapter – POA overview Server code when using rootPOA with default policies import org.omg.CORBA.*; import org.omg.PortableServer.*; // Initialize ORB and POA ORB orb = ORB.init (args, props); POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA")); // Get a reference to the POA manager POAManager manager = rootPOA.the_POAManager(); // Create a servant and activate it HelloWorldImpl hwImpl = new HelloWorldImpl(); HelloWorld hw = hwImpl._this (orb); // Wait for incoming requests ("run the implementation") manager.activate(); orb.run();

  41. CORBA OverviewORB - 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. Active Object Map Default Servant Object Reference (with Object Key) CORBA OverviewORB - Portable Object Adapter – POA overview request from a client ORB POA extract POA name from Object Key extract Object Id from Object Key incarnate servant find POA Object ID Servant or or Object ID or Servant Object ID call Adaptor Activator if POA not found create POA update map create servant Servant Activator Servant Locator Adaptor Activator Servant Manager

  43. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - Portable Object Adapter – Life cycle managment Problem spec. Concepts are defined from the realized concepts OOD We find elements that model phenomenos and concepts from the problem domain/conceptual model A conceptual model is made for the Problem domain Modeling Problem spec. concepts Realized Concepts OOA OOP Abstraction Abstraction Phenomenons Machine lang. Problem domain System model

  46. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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. CORBA OverviewORB - 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

More Related