1. (C) 2003 University of ManchesterCS31010 Lecture 14: CORBA

2. (C) 2003 University of ManchesterCS31011 CORBA Common Object Request Broker Architecture CORBA is the OMG’s component model. “How can distributed oo systems implemented in different languages and running on different platforms interact?” OMG did not settle on binary standards... so CORBA-compliant products have to engage in costly high-level protocols In defining CORBA, OMG was trying to address the problem: i.e. how to enable open interconnection of a wide variety of languages, implementations and platforms instead of interoperating (efficiently) on a binary level

3. (C) 2003 University of ManchesterCS31012 Object Request Broker (ORB) At the heart of CORBA is the object request broker (ORB). Client Object implementation ORB The ORB provides a client with all the facilities for remote object implementation:

4. (C) 2003 University of ManchesterCS31013 ORB Mechanism for Object Request Client object reference Server Network ORB locates server ORB For simplicity we assume that the client and the server both use the same ORB.

5. (C) 2003 University of ManchesterCS31014 Client ORB marshals parameters parameters Server Network method call ORB unmarshals parameters

6. (C) 2003 University of ManchesterCS31015 Client ORB unmarshals return value return value Server Network return value ORB marshals return value

7. (C) 2003 University of ManchesterCS31016 An ORB-based system looks like this: Invocation interface ORB interface ORB interface Object adapter obj.m(args) object method 1 method n Language/implementation/platform barrier Object Request Broker (ORB) The Elements of CORBA Apart from the ORB, CORBA has two other parts: a set of invocation interfaces a set of object adapters

8. (C) 2003 University of ManchesterCS31017 Invocation interface ORB interface ORB interface Object adapter obj.m(args) object method 1 method n Language/implementation/platform barrier Object Request Broker (ORB) method invocation requires late binding method chosen by receiving object enables various degrees of late binding marshals and transports an invocation’s arguments locates the receiver object unmarshals the arguments and invokes the requested method on the receiver object

9. (C) 2003 University of ManchesterCS31018 For invocation interfaces and object adaptors to work: all object interfaces must be described in a common language all languages used must have bindings to the common language OMG IDL this enables us to construct generic marshalling and unmarshalling algorithms this allows calls from/to a particular language to be related to the common language This common language is of course the OMG Interface Definition Language (IDL). Bindings to OMG IDL are available for many languages, e.g. C, C++, Smalltalk, Java (even COBOL!)

10. (C) 2003 University of ManchesterCS31019 OMG IDL Example Module Example { struct Date{ unsigned short Day; unsigned short Month; unsigned short Year; } interface Ufo { readonly attribute unsigned long Id; readonly attribute string Name; readonly attribute Date FirstContact; unsigned long Contacts (); void RegisterContact(Date dateOfContact); } syntax mostly borrowed from C++ with some modifications contains only declarations of interface signatures but no programming statements. distinguishes between data types and CORBA object references Data types include integers, floats, characters, strings, structures, sequences and multi-dimensional fixed-size arrays All data types are passed by value. CORBA objects themselves cannot be passed.

11. (C) 2003 University of ManchesterCS310110 CORBA and OMG IDL ORB Invocation interface ORB interface Object adaptor IDL compiler IDL source Server programs Interface repositoryImplementation repository Interface Repository An interface defined in IDL is compiled by an IDL compiler, and deposited in an interface repository, which every ORB must have. Compiled interfaces can be retrieved from the interface repository via the ORB interface. Implementation Repository Compiled program fragments that provide implementations of compiled interfaces can be registered with the ORB’s implementation repository. These are called object servers.The ORB can load and start an object server on receiving invocation requests for an object of that server. The object adaptor is responsible for telling the ORB which new object is served by which server.

12. (C) 2003 University of ManchesterCS310111 CORBA and OMG IDL Object Request Broker (ORB) Invocation interface IDL stubs ORB interface IDL skeletons Dynamic skeleton interface Object adaptor Client programs IDL compiler Server programs IDL source Dynamic invocation interface Stubs and Skeletons For efficient marshalling and unmarshalling of arguments, an ORB-specific OMG IDL compiler must be used to generate stubs and skeletons. A stub can be instantiated to look like a local object, but it forwards all invocations via the ORB to the real target object. A skeleton receives invocations, unmarshals arguments, and directly invokes the target method. It also accepts return values, marshals them, and sends them back to the stub for marshalling and final returning. DII and DSI To allow runtime selection of methods, CORBA provides a dynamic invocation interface (DII) and a dynamic skeleton interface (DSI). These interfaces allow for dynamic selection of methods either at the client’s end (DII) or at the server’s end (DSI). They both use a universal data structure for arguments in order to cater for methods of arbitrary signature. Object Servers Once an object server is registered with an ORB, the ORB `knows’ how to activate that server when needed. To determine on which machine to activate the server, each registered object has a home machine that is used to start the server on. also called a client-side proxy object also called a server-side stub

13. (C) 2003 University of ManchesterCS310112 The stubs and skeletons generated from IDL are ORB-specific, and they communicate with the ORB via proprietary protocols. Different ORBs need to communicate via: CORBA Interoperability Protocols stub ORB1 ORB1 PP skeleton ORB2 ORB2 PP GIOP / IIOP the General Inter-ORB Protocol (GIOP) or the Internet Inter-ORB Protocol (IIOP)

14. (C) 2003 University of ManchesterCS310113 CCM is likely to be the most important evolution of CORBA. The CORBA Component Model (CCM) Implementation of CCM is currently immature. One of its aims is to define a common middle-tier infrastructure The core of the CCM is the container, into which components are installed. along the lines of Microsoft’s Transaction Server (MTS) and Sun’s Enterprise Java Beans (EJB) (see later).

15. (C) 2003 University of ManchesterCS310114 Summary It is based on the OMG IDL and the ORB. Stubs and skeletons on the same ORB communicate via the ORB. Stubs and skeletons for object invocation and implementation are generated from IDL interfaces. They communicate via GIOP and IIOP if they reside on different ORBS. Implementation of the CORBA Component Model is currently immature. CORBA is essentially a RMI service.