150 likes | 380 Views
Lecture 14: CORBA. CORBA. Common Object Request Broker Architecture. CORBA is the OMG’s component model. In defining CORBA, OMG was trying to address the problem:. “ How can distributed oo systems implemented in different languages and running on different platforms interact ? ”.
E N D
Lecture 14: CORBA CS3101
CORBA Common Object Request Broker Architecture CORBA is the OMG’s component model. In defining CORBA, OMG was trying to address the problem: “How can distributed oo systems implemented in different languages and running on different platforms interact?” OMG did not settle on binary standards ... so i.e. how to enable open interconnection of a wide variety of languages, implementations and platforms CORBA-compliant products have to engage in costly high-level protocols instead of interoperating (efficiently) on a binary level CS3101
Object Request Broker (ORB) At the heart of CORBA is the object request broker (ORB). The ORB provides a client with all the facilities for remote object implementation: Client Object implementation ORB CS3101
For simplicity we assume that the client and the server both use the same ORB. ORB Mechanism for Object Request Server Client object reference ORB locates server ORB Network CS3101
Server Client parameters method call ORB marshals parameters ORB unmarshals parameters Network CS3101
Server Client return value return value ORB unmarshals return value ORB marshals return value Network CS3101
The Elements of CORBA object method 1 method n Apart from the ORB, CORBA has two other parts: • a set of invocation interfaces • a set of object adapters An ORB-based system looks like this: Language/implementation/platform barrier obj.m(args) Invocation interface ORB interface ORB interface Object adapter Object Request Broker (ORB) CS3101
Language/implementation/platform barrier obj.m(args) Invocation interface ORB interface ORB interface Object adapter object method 1 method n 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 unmarshals the arguments and invokes the requested method on the receiver object locates the receiver object CS3101
OMG IDL 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 this enables us to construct generic marshalling and unmarshalling algorithms This common language is of course the OMG Interface Definition Language (IDL). this allows calls from/to a particular language to be related to the common language Bindings to OMG IDL are available for many languages, e.g. C, C++,Smalltalk, Java (even COBOL!) CS3101
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 Data types include integers, floats, characters, strings, structures, sequences and multi-dimensional fixed-size arrays distinguishes between data types and CORBA object references contains only declarations of interface signatures but no programming statements. CORBA objects themselves cannot be passed. All data types are passed by value. CS3101
Implementation Repository Interface Repository CORBA and OMG IDL The object adaptor is responsible for telling the ORB which new object is served by which server. The ORB can load and start an object server on receiving invocation requests for an object of that server. Compiled program fragments that provide implementations of compiled interfaces can be registered with the ORB’s implementation 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. These are called object servers. IDL source IDL compiler Server programs Invocation interface ORB interface Object adaptor ORB Interface repository Implementation repository CS3101
Object adaptor DII and DSI Stubs and Skeletons Object Servers CORBA and OMG IDL It also accepts return values, marshals them, and sends them back to the stub for marshalling and final returning. A skeleton receives invocations, unmarshals arguments, and directly invokes the target method. A stub can be instantiated to look like a local object, but it forwards all invocations via the ORB to the real target object. For efficient marshalling and unmarshalling of arguments, an ORB-specific OMG IDL compiler must be used to generate stubs and skeletons. 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. 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. also called a client-side proxy object also called a server-side stub IDL source Client programs IDL compiler Server programs Invocation interface IDL stubs ORB interface IDL skeletons Dynamic skeleton interface Dynamic invocation interface Object Request Broker (ORB) CS3101
stub skeleton ORB1 PP ORB2 PP ORB1 ORB2 CORBA Interoperability Protocols The stubs and skeletons generated from IDL are ORB-specific, and they communicate with the ORB via proprietary protocols. GIOP / IIOP Different ORBs need to communicate via: • the General Inter-ORB Protocol (GIOP) or • the Internet Inter-ORB Protocol (IIOP) CS3101
The CORBA Component Model (CCM) CCM is likely to be the most important evolution of CORBA. One of its aims is to define a common middle-tierinfrastructure along the lines of Microsoft’s TransactionServer (MTS) and Sun’s Enterprise Java Beans (EJB) (see later). The core of the CCM is the container, into which components are installed. Implementation of CCM is currently immature. CS3101
Summary • CORBA is essentially a RMI service. • It is based on the OMG IDL and the ORB. • Stubs and skeletons for object invocation and implementation are generated from IDL interfaces. • Stubs and skeletons on the same ORB communicate via the ORB. • They communicate via GIOP and IIOP if they reside on different ORBS. • Implementation of the CORBA Component Model is currently immature. CS3101