Distributed Systems

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

2. 0.0 Review: RMI • 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

3. 0.1 RMI: Benefits • Invoke object methods, and have them execute on remote Java Virtual Machines (JVMs) • Entire objects can be passed and returned as parameters • Unlike many other remote procedure call based mechanisms requiring either primitive data types as parameters, or structures composed of primitive data types • New Java objects can be passed as a parameter • Can move behavior (class implementations) from client to server and server to client

4. 0.2 RMI: Benefits • 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) • Safe and Secure • RMI uses built-in Java security mechanisms • Easy to Write/Easy to Use • A remote interface is an actual Java interface • Distributed Garbage Collection • Collects remote server objects that are no longer referenced by any client in the network

5. 0.3 RMI: Implementation

6. 0.4 Developing RMI • 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.RemoteException.

7. Developing RMI • Implement the remote interface • Develop the server • Create an instance of the RMISecurityManager and install it • Create an instance of the remote object • Register the object created with the RMI registry • Develop the client • First obtain a reference to the remote object from the RMI registry

8. Developing RMI • 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

9. Outline • 1.0 The Object Management Group and Introduction • 2.0 Object Management Architecture • 3.0 CORBA Communication • 4.0 Implementation, “Hello World” Example • 5.0 RMI vs CORBA Comparison

10. Remember: Conceptual Framework • Architecture. • Accessing components from programming languages. • Interfaces to lower layers. • Component identification. • Service invocation styles. • Handling of failures.

11. CORBA • Object management architecture. • Accessing remote objects. • ORB interface. • Object identification • Activation strategies. • Request vs. notification. • Handling of failures.

12. 1.0 The Object Management Group • 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.

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

14. CORBA/IIOP Java Client Cobol Client Java Object C++ Object CORBA/IIOP CORBA/IIOP 1.2 CORBA: A Specification • Takes care of cross-language issues automatically • Uses OMG IDL (Interface Definition Language • Runs over IIOP (Internet Inter-Orb Protocol)

15. 1.3 CORBA Concepts • CORBA’s theoretical underpinnings are based on three important concepts; • An Object-Oriented Model • Open Distributed Computing Environment • Component Integration and Reuse • CORBA Provides • Uniform access to services • Uniform discovery of resources and object names • Uniform error handling methods • Uniform security policies

16. 1.4 . The OMG Object Model • The OMG Object Model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. • 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).

19. 1.5 About CORBA Objects • 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 • A CORBA object is a virtual programming entity that consists of an identity, an interface, and an implementationwhich 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

20. 1.6 Objects and Applications • 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 only one instance. 

21. 2.0 Object Management Architecture (OMA) Application Objects CORBA facilities Object Request Broker CORBA services

22. 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) • OMA groups objects into four categories • CORBAservices • CORBAfacilities • CORBAdomain • Application object O M A CORBA

23. 2.2 CORBAservices • 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 • CORBA facilities (sometimes called Horizontal CORBAfacilities) • Between CORBAservices and Application Objects • Potentially useful across business domains • Printing, Secure Time Facility, Internationalization Facility, Mobile Agent Facility.

24. 2.3 OMA model • Domain (Vertical) CORBAfacilities • Domain-based and provide functionality for specific domains such as telecommunications, electronic commerce, or health care. • Application Objects • Topmost part of the OMA hierarchy • Customized for an Individual application, so do not need standardization

25. 2.4 CORBA Architecture Client Object Implementation Dynamic Invocation Client Stubs ORB Interface Server Skeleton Object Adapter ORB Core

26. CORBA Architecture Object Implementation Client (Servant) Dynamic Static Object Skeleton Skeleton Adapter Dynamic ORB Stub Invocation Interface Object Request Broker (ORB) Interface identical for all ORB implementations Up-call interface There maybe multiple object adapters There are stubs and skeletons for each object type Normal call interface ORB-dependent interface

27. 2.5 CORBA Architecture • 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 • Optional request context • Results (the results values returned by operation) IIOP Request Request from a client to an object implementation

28. 2.6 CORBA Architecture • CORBA is composed of five major components; • ORB, • IDL, • Dynamic Invocation Interface (DII), • Interface Repositories (IR), • Object Adapters (OA), • Inter-Orb Protocol (IIOP) • CORBA provides both static and dynamic interfaces to its services • Happened because two strong proposals from HyperDesk and Digital based on a Dynamic API & from SUN and HP based on a static API. “Common” stands for a two-API proposal

29. 2.7 Object Request Broker, ORB • 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, VisiBroker from Inprise, JavaIDL from javasoft)

30. 2.8 CORBA Architecture: ORB • 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 • 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.

31. 2.9 CORBA Architecture: Stubs,Skeletons • 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 are as many stubs as there are interfaces!) • Server Skeleton • provides static interfaces to each service exported by the server. Performance unmarshalling, and the actual method invocation on the server object • ORB Interface • Interface to few ORB operations common to all objects, e.g. operation which returns an object’s interface type.

32. 2.10 CORBA Architecture: Servant &Clients • Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. • 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. • 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.

33. 2.11 CORBA Architecture: DII • 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

34. 2.12 CORBA Architecture: DSI • 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

35. 2.13 CORBA Architecture: IR • 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

36. 2.13 CORBA Architecture: OA • 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

37. 2.14 Implementation Repository • Provides a run-time repository of information about classes a server supports, the objects that are instantiated and their IDs • Also serves as a common place to store additional information associated with implementations of ORBS • e.g. trace information, audit trails and other administrative data

38. 2.15 Summary of CORBA Interfaces • 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 Decsribes includes includes • Descriptions of object implementations are maintained as objects in the implementation repository

39. 2.16 Accessing Remote Objects Client Object Implementation Dynamic Invocation Client Stubs ORB Interface Server Skeleton Object Adapter ORB Core

40. 2.17 Client Side Clients perform requests using object references Clients May issue requests through object interface stubs (static) or dynamic invocation interface (Dynamic) Client Clients may access general ORB services: • Interface Repository • Context management • List Management • Request Management Dynamic Invocation Client Stubs ORB Interface

41. 2.18 Implementation Side (Server side) • 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 ORB Interface Server Skeleton Object Adapter

42. 3.0 CORBA Communication • 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 • GIOP maps ORB requests to different transports • 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

43. 3.1 CORBA Communication • GIOP contains specifications for • Common Data Representation (CDR) • Message formats (Reply, Request, LocateReply, LocateRequest, CancelRequest, etc) • Message transport assumptions • Connection-Oriented • Reliable • A Byte Stream Protocol

44. 3.2 Communication: Inter-Orb Architecture CORBA IDL Object Request Semantics General Inter-ORB Protocol (GIOP) Transfer and Message Syntax Internet Inter-ORB Protocol (IIOP) TCP/IP Others for example OSI and IPX/SPX Transports Internet

46. 3.3 Other Features • 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

47. 3.4 New Features • Two newer, enhanced mechanisms are introduced • CallbackThe 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 • PollingThe 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)

48. 4.0 Implementation Implementation

49. 4.0 How to Write CORBA Applications Create IDLdefinition idl load Example Servant Client IDL Stub Server Skeleton Interface repository is used by Implement Client Implement Servant Object Adapter javac instantiates javac Start client Implementationrepository Start server Server Client

50. 4.1 Example: Hello world ID module HelloApp { interface Hello { string sayHello(); }; };