Distributed Systems Session 5 Common Object Request Broker

Distributed Systems Session 5: Common Object Request Broker, (CORBA) Christos Kloukinas Dept. of Computing City University London © City University London, Dept. of Computing Distributed Systems / 5 - 1

0. 0 Review: RMI l RMI – Remote Method Invocation » RPC in Java Technology and more » Concrete programming technology » Designed to solve the problems of writing and organizing executable code » Native to Java, an extension of core language » Benefits from specific features of Java – Object serialization – Portable, downloadable object implementations – Java interface definitions © City University London, Dept. of Computing Distributed Systems / 5 - 2

0. 1 RMI: Benefits Invoke object methods, and have them execute on remote Java Virtual Machines (JVMs) l Entire objects can be passed and returned as parameters l » Unlike many other remote procedure call based mechanisms requiring either primitive data types as parameters, or structures composed of primitive data types l New Java objects can be passed as a parameter » Can move behavior (class implementations) from client to server and server to client © City University London, Dept. of Computing Distributed Systems / 5 - 3

0. 2 RMI: Benefits l Enables use of Design Patterns » Use the full power of object oriented technology in distributed computing, such as two- and three-tier systems (pass behavior and use OO design patterns) l Safe and Secure » RMI uses built-in Java security mechanisms l Easy to Write/Easy to Use » A remote interface is an actual Java interface l Distributed Garbage Collection » Collects remote server objects that are no longer referenced by any client in the network © City University London, Dept. of Computing Distributed Systems / 5 - 4

0. 3 RMI: Implementation © City University London, Dept. of Computing Distributed Systems / 5 - 5

0. 4 Developing RMI l Define a remote interface » define a remote interface that specifies the signatures of the methods to be provided by the server and invoked by clients » It must be declared public, in order for clients to be able to load remote objects which implement the remote interface. » It must extend the Remote interface, to fulfill the requirement for making the object a remote one. » Each method in the interface must throw a java. rmi. Remote. Exception. © City University London, Dept. of Computing Distributed Systems / 5 - 6

Developing RMI Implement the remote interface l Develop the server l l Create an instance of the RMISecurity. Manager and install it l Create an instance of the remote object l Register the object created with the RMI registry l Develop the client – First obtain a reference to the remote object from the RMI registry © City University London, Dept. of Computing Distributed Systems / 5 - 7

Developing RMI l Running the application » » Generate stubs and skeletons - rmic Compile the server and the client - javac Start the RMI registry - rmiregistry Start the server and the client © City University London, Dept. of Computing Distributed Systems / 5 - 8

Outline l 1. 0 The Object Management Group and Introduction l 2. 0 Object Management Architecture l 3. 0 CORBA Communication l 4. 0 Implementation, “Hello World” Example l 5. 0 RMI vs CORBA Comparison © City University London, Dept. of Computing Distributed Systems / 5 - 9

Remember: Conceptual Framework l Architecture. l Accessing components from programming languages. l Interfaces to lower layers. l Component identification. l Service invocation styles. l Handling of failures. © City University London, Dept. of Computing Distributed Systems / 5 - 10

CORBA l Object management architecture. l Accessing remote objects. l ORB interface. l Object identification l Activation strategies. l Request vs. notification. l Handling of failures. © City University London, Dept. of Computing Distributed Systems / 5 - 11

1. 0 The Object Management Group l l l The OMG is a non-profit consortium created in 1989 with the purpose of promoting theory and practice of object technology in distributed computing systems to reduce the complexity, lower the costs, and hasten the introduction of new software applications. Originally formed by 13 companies, OMG membership grew to over 500 software vendors, developers and users. OMG realizes its goals through creating standards which allow interoperability and portability of distributed object oriented applications. They do not produce software or implementation guidelines. © City University London, Dept. of Computing Distributed Systems / 5 - 12

1. 1 CORBA (Common Object Request Broker Architecture) Specification by OMG of an OO infrastructure for Distributed Computing. l Defines Object Request Broker and IDL l Enables Software interoperability across languages and platforms l Applicable to legacy, commercial-off-the-shelf(COTS) integration and new software development l CORBA is just a specification for creating and using distributed Objects, it is an integration technology NOT a programming language l © City University London, Dept. of Computing Distributed Systems / 5 - 13

1. 2 CORBA: A Specification Takes care of cross-language issues automatically l Uses OMG IDL (Interface Definition Language l Java Client CORBA/IIOP l Runs over IIOP (Internet Inter-Orb Protocol) © City University London, Dept. of Computing C++ Object P IO I / A RB O C Cobol CORBA/IIOP Client Java Object Distributed Systems / 5 - 14

1. 3 CORBA Concepts l CORBA’s theoretical underpinnings are based on three important concepts; » An Object-Oriented Model » Open Distributed Computing Environment » Component Integration and Reuse l CORBA Provides » Uniform access to services » Uniform discovery of resources and object names » Uniform error handling methods » Uniform security policies © City University London, Dept. of Computing Distributed Systems / 5 - 15

1. 4. The OMG Object Model l The OMG Object Model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. l In this model clients request services from objects (which will also be called servers) through a well-defined interface. This interface is specified in OMG IDL (Interface Definition Language). A client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters (if any). l l © City University London, Dept. of Computing Distributed Systems / 5 - 16

© City University London, Dept. of Computing Distributed Systems / 5 - 17

© City University London, Dept. of Computing Distributed Systems / 5 - 18

1. 5 About CORBA Objects l CORBA objects differ from typical objects in 3 ways » CORBA objects can run on any platform. » CORBA objects can be located anywhere » CORBA Objects can be written in any language that has an IDL mapping l A CORBA object is a virtual programming entity that consists of an identity, an interface, and an implementation which is known as a Servant. » It is virtual in the sense that it does not really exist unless it is made concrete by an implementation written in a programming language © City University London, Dept. of Computing Distributed Systems / 5 - 19

1. 6 Objects and Applications l l l CORBA applications are composed of objects. Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually one instance. © City University London, Dept. of Computing Distributed Systems / 5 - 20

2. 0 Object Management Architecture (OMA) Application Objects CORBA facilities Object Request Broker CORBA services © City University London, Dept. of Computing Distributed Systems / 5 - 21

2. 1 OMA Model CORBA is based on the object model, derived from the abstract core object model of OMG’s OMA (Object Management Architecture) l OMA groups objects into four categories l » CORBAservices » CORBAfacilities O » CORBAdomain M » Application object A © City University London, Dept. of Computing C O R B A Distributed Systems / 5 - 22

2. 2 CORBAservices l CORBAservices » Provide basic functionality, that almost every object needs – Naming Service-name binding , associating names and references – Event Service- asynchronous event notification – Concurrency Control Service-mediates simultaneous access l CORBAfacilities (sometimes called Horizontal CORBAfacilities) » Between CORBAservices and Application Objects » Potentially useful across business domains – Printing, Secure Time Facility, Internationalization Facility, Mobile Agent Facility. © City University London, Dept. of Computing Distributed Systems / 5 - 23

2. 3 OMA model l Domain (Vertical) CORBAfacilities » Domain-based and provide functionality for specific domains such as telecommunications, electronic commerce, or health care. l Application Objects » Topmost part of the OMA hierarchy » Customized for an Individual application, so do not need standardization © City University London, Dept. of Computing Distributed Systems / 5 - 24

2. 4 CORBA Architecture Client Dynamic Invocation Client Stubs Object Implementation ORB Interface Server Skeleton Object Adapter ORB Core © City University London, Dept. of Computing Distributed Systems / 5 - 25

CORBA Architecture Object Implementation (Servant) Client Dynamic Skeleton Stub Dynamic Invocation Static Skeleton Object Adapter ORB Interface Object Request Broker (ORB) Interface identical for all ORB implementations There maybe multiple object adapters There are stubs and skeletons for each object type ORB-dependent interface © City University London, Dept. of Computing Up-call interface Normal call interface Distributed Systems / 5 - 26

2. 5 CORBA Architecture l A general CORBA request structure A request consists of • Target object (identified by unique object reference) • Operation. • Parameters (the input, output, and in-out parameters defined for the operation; maybe specified individually or as a list IIOP Request • Optional request context • Results (the results values returned by operation) Request from a client to an object implementation © City University London, Dept. of Computing Distributed Systems / 5 - 27

2. 6 CORBA Architecture l CORBA is composed of five major components; » » » ORB, IDL, Dynamic Invocation Interface (DII), Interface Repositories (IR), Object Adapters (OA), Inter-Orb Protocol (IIOP) l CORBA provides both static and dynamic interfaces to its services l Happened because two strong proposals from Hyper. Desk and Digital based on a Dynamic API & from SUN and HP based on a static API. “Common” stands for a two-API proposal © City University London, Dept. of Computing Distributed Systems / 5 - 28

2. 7 Object Request Broker, ORB l l Core of CORBA, middleware that establishes the client/server relationship between objects This is the object manager in CORBA, the software that implements the CORBA specification, (implements the session, transport and network layers), provides object location transparency, communication and activation, i. e » Find object implementation for requests (provide location transparency) » Prepare the object implementation to receive request » Communicate the data making up request. (Vendors & Products: ORBIX from IONA, Visi. Broker from Inprise, Java. IDL from javasoft) © City University London, Dept. of Computing Distributed Systems / 5 - 29

2. 8 CORBA Architecture: ORB l On the client side the ORB is responsible for » accepting requests for a remote object » finding the implementation of the object » accepting a client-side reference to the remote object (converted to a language specific form, e. g. a java stub object) » Routing client method calls through the object reference to the object implementation l On the Server side » » lets object servers register new objects receives requests from the client ORB uses object’s skeleton interface to invoke the object activation method Creates reference for new object and sends it back to client. © City University London, Dept. of Computing Distributed Systems / 5 - 30

2. 9 CORBA Architecture: Stubs, Skeletons l Client Stub » provides the static interfaces to object services. These precompiled stubs define how clients invoke corresponding services on the server. From a client’s perspective, the stub acts like a local call- it’s a local proxy for a remote server object. Generated by the IDL compiler (there as many stubs as there are interfaces!) l Server Skeleton » provides static interfaces to each service exported by the server. Performance unmarshalling, and the actual method invocation on the server object l ORB Interface » Interface to few ORB operations common to all objects, e. g. operation which returns an object’s interface type. © City University London, Dept. of Computing Distributed Systems / 5 - 31

2. 10 CORBA Architecture: Servant &Clients l Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. l Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada. l Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object. The remaining components help to support this level of transparency. © City University London, Dept. of Computing Distributed Systems / 5 - 32

2. 11 CORBA Architecture: DII l Dynamic Invocation Interface (DII) » Static invocation interfaces are determined at compile time, and they are presented to the client using stubs » The DII allows client applications to use server objects without knowing the type of objects at compile time – Client obtains an instance of a CORBA object and makes invocations on that object by dynamically creating requests. » DII uses the interface repository to validate and retrieve the signature of the operation on which a request is made © City University London, Dept. of Computing Distributed Systems / 5 - 33

2. 12 CORBA Architecture: DSI l Dynamic Skeleton Interface (DSI) » Server-side dynamic skeleton interface » Allows servers to be written without having skeletons, or compile time knowledge for which objects will be called remotely » Provides a runtime binding mechanism for servers that need to handle incoming method calls for components that do not have IDL-based compiled skeletons » Useful for implementing generic bridges between ORBs » Also used for interactive software tools based on interpreters and distributed debuggers © City University London, Dept. of Computing Distributed Systems / 5 - 34

2. 13 CORBA Architecture: IR l Interface Repository » allows YOU to obtain and modify the descriptions of all registered component interfaces(method supported, parameters i. e method signatures) » It is a run-time distributed database that contains machine readable versions of the IDL interfaces » Interfaces can be added to the interface repository » Enable Clients to; – locate an object that is unknown at compile time – find information about its interface – build a request to be forwarded through the ORB © City University London, Dept. of Computing Distributed Systems / 5 - 35

2. 13 CORBA Architecture: OA l Object Adapter (OA) e. g (Basic-BOA or Portable-POA) » Purpose: interface an object’s implementation with its ORB » Primary way that an object implementation accesses services provided by the ORB. » Sits on top of the ORB’s core communication services and accepts requests for service on behalf of server objects, passing requests to them and assigning them IDs (object references) » Registers classes it supports and their run-time instances with the implementation repository » In summary, its duties are: – Object reference generation, and interpretation, method invocation, security of interactions, and implementation of object activation and de-activation © City University London, Dept. of Computing Distributed Systems / 5 - 36

2. 14 Implementation Repository Provides a run-time repository of information about classes a server supports, the objects that are instantiated and their IDs l Also serves as a common place to store additional information associated with implementations of ORBS l » e. g. trace information, audit trails and other administrative data © City University London, Dept. of Computing Distributed Systems / 5 - 37

2. 15 Summary of CORBA Interfaces l Interface and Implementation Repositories • All objects are defined in IDL by specifying their interfaces • Object definitions (interfaces) are manifested as objects in the interface repository, compiled to stubs and skeletons Accesses • Descriptions of object implementations are maintained as objects in the implementation repository © City University London, Dept. of Computing includes Decsribes Distributed Systems / 5 - 38

2. 16 Accessing Remote Objects Client Dynamic Invocation Client Stubs Object Implementation ORB Interface Server Skeleton Object Adapter ORB Core © City University London, Dept. of Computing Distributed Systems / 5 - 39

2. 17 Client Side Clients perform requests using object references Clients May issue requests through object interface stubs (static) or dynamic invocation interface (Dynamic) Clients may access general ORB services: • Interface Repository Dynamic Invocation Client Stubs ORB Interface • Context management • List Management • Request Management © City University London, Dept. of Computing Distributed Systems / 5 - 40

2. 18 Implementation Side (Server side) l Implementations receive requests through skeletons (without knowledge of invocation approach) The object Adapter provides for: Object Implementation • Management of references; • Method invocation; • authentication • implementation registration • activation/deactivation © City University London, Dept. of Computing ORB Interface Server Skeleton Object Adapter Distributed Systems / 5 - 41

3. 0 CORBA Communication l CORBA Spec Neutral w. r. t network protocols » CORBA specifies GIOP, a high level standard protocol for communication between ORBs Generalized Inter-ORB Protocol (GIOP) is a collection of message requests an ORB can make over a network l GIOP maps ORB requests to different transports l » Internet Inter-ORB Protocol (IIOP) uses TCP/IP to carry the messages, hence fits well into Internet world » Environment Specific Inter-ORB Protocol (ESIOP) complements GIOP enabling interoperability with environments not having CORBA support © City University London, Dept. of Computing Distributed Systems / 5 - 42

3. 1 CORBA Communication l GIOP contains specifications for » Common Data Representation (CDR) » Message formats (Reply, Request, Locate. Reply, Locate. Request, Cancel. Request, etc) » Message transport assumptions – Connection-Oriented – Reliable – A Byte Stream Protocol © City University London, Dept. of Computing Distributed Systems / 5 - 43

3. 2 Communication: Inter-Orb Architecture CORBA IDL Object Request Semantics Transfer and Message Syntax Transports General Inter-ORB Protocol (GIOP) Internet Inter-ORB Protocol (IIOP) Others for example OSI and IPX/SPX TCP/IP Internet © City University London, Dept. of Computing Distributed Systems / 5 - 44

© City University London, Dept. of Computing Distributed Systems / 5 - 45

3. 3 Other Features l CORBA Messaging » CORBA 2. 0 provides three different techniques for operation invocations: – Synchronous The client invokes an operation, then pauses, waiting for a response – Deferred synchronous The client invokes an operation then continues processing. It can go back later to either poll or block waiting for a response – One-way The client invokes an operation, and the ORB provides a guarantee that the request will be delivered. In one-way operation invocations, there is no response © City University London, Dept. of Computing Distributed Systems / 5 - 46

3. 4 New Features » Two newer, enhanced mechanisms are introduced – Callback The client supplies an additional object reference with each request invocation. When the response arrives, the ORB uses that object reference to deliver the response back to the client – Polling The client invokes an operation that immediately returns a valuetype that can be used to either poll or wait for the response » The callback and polling techniques are available for clients using statically typed stubs generated from IDL interfaces (not for DII) © City University London, Dept. of Computing Distributed Systems / 5 - 47

4. 0 Implementation © City University London, Dept. of Computing Distributed Systems / 5 - 48

4. 0 How to Write CORBA Applications Create IDL definition load Interface repository idl Example Servant Server Skeleton Client IDL Stub is used by Implement Client Implement Servant Object Adapter instantiates Implementation repository javac Start client Start server © City University London, Dept. of Computing Server Client Distributed Systems / 5 - 49

4. 1 Example: Hello world ID module Hello. App { interface Hello { string say. Hello(); }; }; © City University London, Dept. of Computing Distributed Systems / 5 - 50

4. 2 Example: Hello World Server import Hello. App. *; // get the root naming context import org. omg. Cos. Naming. *; org. omg. CORBA. Object obj. Ref = import org. omg. Cos. Naming. Context. Package. *; orb. resolve_initial_references("Name. Service"); import org. omg. CORBA. *; Naming. Context nc. Ref = Servant Naming. Context. Helper. narrow(obj. Ref); class Hello. Servant extends _Hello. Impl. Base { public String say. Hello() { // bind the Object Reference in Naming return "n. Hello world !!n"; Name. Component nc = new Name. Component("Hello", ""); } Server Skeleton Name. Component path[] = {nc}; } nc. Ref. rebind(path, hello. Ref); public class Hello. Server { Binding public static void main(String args[]) // wait for invocations from clients { java. lang. Object sync = new java. lang. Object(); try{ synchronized (sync) { // create and initialize the ORB sync. wait(); ORB orb = ORB. init(args, null); } // create servant and register it with the ORB } catch (Exception e) {…} Hello. Servant hello. Ref = new Hello. Servant(); } orb. connect(hello. Ref); } © City University London, Dept. of Computing ORB interface Distributed Systems / 5 - 51

4. 3 Example: Hello World Client import Hello. App. *; import org. omg. Cos. Naming. *; import org. omg. CORBA. *; public class Hello. Client { public static void main(String args[]) { try{ ORB orb = ORB. init(args, null); // create and initialize the ORB // get the root naming context org. omg. CORBA. Object obj. Ref = orb. resolve_initial_references("Name. Service"); Naming. Context nc. Ref = Naming. Context. Helper. narrow(obj. Ref); // resolve the Object Reference in Naming Name. Component nc = new Name. Component("Hello", ""); Name. Component path[] = {nc}; Hello hello. Ref = Hello. Helper. narrow(nc. Ref. resolve(path)); // call the Hello server object and print results String hello = hello. Ref. say. Hello(); System. out. println(hello); } catch (Exception e) {…} }}University London, Dept. of Computing © City Service Request Casting Distributed Systems / 5 - 52

4. 4 Static vs. Dynamic Invocation l Static invocation: IDL operations must have been defined before client can be developed. l Does not suit every application (Example? ) l Dynamic invocation interface enables clients to define operation invocations at run-time. l Interface repository can be used to ensure that calls are type safe. © City University London, Dept. of Computing Distributed Systems / 5 - 53

4. 5 ORB Interface l Object type Object. l Initialisation of object request broker. l Initialisation of client / server applications. l Programming interface to interface repository. © City University London, Dept. of Computing Distributed Systems / 5 - 54

4. 6 Object Identification Objects are uniquely identified by object identifiers. l Object identifiers are persistent. l Identifiers can be externalised (converted into string) and internalised. l Identifiers can be obtained l » from a naming or a trading service, » by reading attributes, » from an operation result or » by internalising an externalised reference. © City University London, Dept. of Computing Distributed Systems / 5 - 55

© City University London, Dept. of Computing Distributed Systems / 5 - 56

© City University London, Dept. of Computing Distributed Systems / 5 - 57

4. 7 Activation Strategies A D B C Basic Object Adapter © City University London, Dept. of Computing A Shared Server B Unshared Server C Server per method D Persistent server Process Object Registration Activation Distributed Systems / 5 - 58

3. 5 Request vs. Notification IDL operations are handled synchronously. l For notifications, it may not be necessary to await the server, if operation does not l » have a return value, » have out or inout parameters and » raise specific exceptions. Notification can be implemented as oneway operations in IDL. l Client continues after notification is delivered. l © City University London, Dept. of Computing Distributed Systems / 5 - 59

3. 5 Notification (Example) /* person. idl */ enum sex_type { FEMALE, MALE }; struct Person { string first_name; string last_name; sex_type sex; string city; }; © City University London, Dept. of Computing interface Person. Manager { oneway void print(in Person); long store(in Person pers); Person load(in long pers_id); }; Distributed Systems / 5 - 60

3. 6 Failures l CORBA operation invocations may fail for the same reasons as RMIs. l Exceptions give detailed account why an operation has failed. l System vs. application specific exceptions. © City University London, Dept. of Computing Distributed Systems / 5 - 61

CORBA AND JAVA 1997: RMI Introduced with JDK 1. 1 l 1998: Java. IDL with JDK 1. 2 – Java ORB supporting IIOP. ORB also supports RMI over IIOP remote objects written in the Java programming language accessible from any language via IIOP l CORBA provides the network transparency, Java provides the implementation transparency l © City University London, Dept. of Computing Distributed Systems / 5 - 62

4 Comparison l RMI architecture lacks interface repository (but has reflection). l IDL and RMI allow for: » inheritance, » attributes and » exceptions. (These three are missing in RPC) l IDL has multiple standardised language bindings. RMI is part of JAVA, RPC goes with C and C++ © City University London, Dept. of Computing Distributed Systems / 5 - 63

4 Comparison (cont´d) l RMIs are lightweight. l Component identification is reflexive in IDL and RMI, as opposed to RPC. l Basic object adapter provides more flexible activation strategies. l Oneway operations can be used for asynchronous notifications. © City University London, Dept. of Computing Distributed Systems / 5 - 64

4 Comparison (cont´d) l RMIs may be more efficient than CORBA operation invocations. l RMI comes with JAVA, whilst you would have to obtain a CORBA product (open-source ones exist). © City University London, Dept. of Computing Distributed Systems / 5 - 65

6. 2 RMI vs CORBA (ctd. ) l Relatively speaking, RMI can be easier to master, especially for experienced Java programmers, than CORBA is a rich, extensive family of standards and interfaces, and delving into the details of these interfaces is sometimes overkill for the task at hand. © City University London, Dept. of Computing Distributed Systems / 5 - 67

6. 3 RMI vs CORBA (ctd. ) l CORBA is a more mature standard than RMI, and has had time to gain richer implementations. The CORBA standard is a fairly comprehensive one in terms of distributed objects, and there are CORBA implementations out there that provide many more services and distribution options than RMI or Java. The CORBA Services specifications, for example, include comprehensive high-level interfaces for naming, security, and transaction services. © City University London, Dept. of Computing Distributed Systems / 5 - 68

6. 4 The Bottom Line l l So which is better, CORBA or RMI? Basically, it depends. If you're looking at a system that you're building from scratch, with no hooks to legacy systems and fairly mainstream requirements in terms of performance and other language features, then RMI may be the most effective and efficient tool for you to use. On the other hand, if you're linking your distributed system to legacy services implemented in other languages, or if there is the possibility that subsystems of your application will need to migrate to other languages in the future, or if your system depends strongly on services that are available in CORBA and not in RMI, or if critical subsystems have highly-specialized requirements that Java can't meet, then CORBA may be your best bet. © City University London, Dept. of Computing Distributed Systems / 5 - 69