Chapter 17

CORBA case study

17.1 Introduction 17.2 CORBA RMI
Client and server example Architecture CORBA IDL CORBA object references

17.3 CORBA Services

Introduction to CORBA The Object Management Group (OMG) was formed in 1989. Its aims were:
to make better use of distributed systems to use object-oriented programming to allow objects in different programming languages to communicate with one another

The object request broker (ORB) enables clients to invoke methods in a remote object CORBA is a specification of an architecture supporting this.
CORBA 1 in 1990 and CORBA 2 in 1996.

Introduction to CORBA
The main components of CORBAs RMI framework are: 1. An interface definition language known as IDL. 2. An architecture. 3. The General Inter-ORB protocol (GIOP) defines
an external data representation, called CDR specifies formats for the messages in a request-reply protocol. including messages for enquiring about the location of an object, for cancelling requests and for reporting errors.

1. The Internet Inter-ORB protocol (IIOP) defines a standard form for remote object references.
IIOP is GIOP implemented in TCP/IP

CORBA services - generic services useful in distributed applications e.g. Naming Service, Event Service.

CORBA RMI
CORBA RMI is a multi-language RMI system. The programmer needs to learn the following new concepts:
the object model offered by CORBA; the interface definition language and its mapping onto the implementation language.

CORBA's object model

similar to the remote object model in Chapter 5 clients are not necessarily objects a client can be any program that sends request messages to remote objects and receives replies.

The term CORBA object is used to refer to remote objects.

a CORBA object implements an IDL interface, has a remote object reference and its methods can be invoked remotely.

A CORBA object can be implemented by a language without classes.

the class concept does not exist in CORBA. therefore classes cannot be defined in CORBA IDL, which means that instances of classes cannot be passed as arguments.

CORBA IDL interfaces Shape and ShapeList

struct Rectangle{ long width; long height; long x; this struct is used in long y; defining another struct. }; struct GraphicalObject { string type; Rectangle enclosing; boolean isFilled; };

interface Shape { long getVersion() ; GraphicalObject getAllState() ; // returns state of the GraphicalObject }; an interface specifies a name and a set of methods

this struct is used as a parameter or result type in methods in the remote interfaces.

sequences and arrays in typedefs typedef sequence <Shape, 100> All; interface ShapeList { interface ShapeList exception FullException{ }; Shape newShape(in GraphicalObject g) raises (FullException); All allShapes(); // returns sequence of remote object references long getVersion() ; Exceptions defined by raises and set the }; parameter of newShape is an in parameter and of type Graphical Object The return value is an Figure 17.1 extra out parameter of type Shape. by throw. They can have arguments.

Parameters in CORBA IDL

Passing CORBA objects:
Any parameter or return value whose type is specified by the name of a IDL interface, e.g. Shape, is a reference to a CORBA object (see newShape) and the value of a remote object reference is passed.

Passing CORBA primitive and constructed types:

Arguments of primitive and constructed types are copied and passed by value. On arrival, a new value is created in the recipients process. E.g., the struct GraphicalObject (argument of newShape and result of getAllState)

Note: the method allShapes returns an array of remote object references as follows:
typedef sequence <Shape, 100> All; All allShapes();

Type Object - is a supertype of all IDL interfaces (its values are object references).

CORBA Naming Service

It is a binder that provides methods including
rebind for servers to register the remote object references of CORBA objects by name (e.g. rebind (path, Object) resolve for clients to look them up by name.(e.g.Object = resolve(path))

The names are structured in a hierarchy,

a path is an array of NameComponent (a struct with a name in it) the path starts from an initial context provided by CORBA This makes access in a simple example seem rather complex!

The name service is present in all CORBA installations. (Its role is like the Java RMI registry) Its use will be shown in program examples

CORBA pseudo objects

Implementation of CORBA provides some interfaces to the functionality of the ORB that programmers need to use. They are called pseudo objects. Because they can not be used like CORBA objects. ORB is the name of an interface. It includes:
The method init, which must be called to initialize the ORB The method connect, which is used to register CORBA objects with the ORB Other methods which enable conversions between remote object references and strings.

CORBA client and server example Illustration of CORBA with a Java client and server The interface compiler is called idltojava, when given an IDL interface, it produces:
the equivalent Java interfaces (e.g. ShapeList below) server skeletons for each idl interface (e.g. _ShapeListImplBase) proxy classes or client stubs (e.g. _ShapeListStub) a Java class for each struct e.g. Rectangle, GraphicalObject helper classes (one for each of the types defined in the IDL interface) and holder classes (for out and inout arguments which can not be directly map on to java)

public interface ShapeList extends org.omg.CORBA.Object { Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException; Shape[] allShapes(); Figure int getVersion(); }

The ShapeListServant class of the Java server program for the CORBA interface ShapeList.
import org.omg.CORBA.*; class ShapeListServant extends _ShapeListImplBase { ORB theOrb; private Shape theList[]; a servant class extends the corresponding private int version; skeleton class (e.g. ShapeListImplBase) private static int n=0; public ShapeListServant(ORB orb){ theOrb = orb; CORBA objects are instances of servant classes. // initialize the other instance variables In non-OO languages implementations of CORBA } objects cant be classes. public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { version++; Shape s = new ShapeServant( g, version); if(n >=100) throw new ShapeListPackage.FullException(); theList[n++] = s; a servant class implements the methods in the theOrb.connect(s); interface (ShapeList). return s; newShape is a factory method. It creates new } CORBA objects. It uses the connect method to public Shape[] allShapes(){ ... } register it with the ORB. (it has a remote object public int getVersion() { ... } } reference)

A Java server has classes for its IDL interfaces (e.g. Shape and ShapeList). Here is the class ShapeListServant

Java class ShapeListServer (the server class)

1. it gets org.omg.CosNaming.*;Naming Service, it a reference to the import The server class contains the main method first get a root naming context import org.omg.CosNaming.NamingContextPackage.*; 2. narrows it to NamingContext- from Object import org.omg.CORBA.*; it creates and initialises the ORB 3. makes a NameComponent containing the public class ShapeListServer { it creates an instance of ShapeListServant class - a Java public static void name ShapeList main(String args[]) { object - which is made a CORBA object 4. makes atry{ path by null); ORB orb = ORB.init(args, using the connect method to register it with the ORB 5. uses rebind to register the name and object ShapeListServant shapeRef = new ShapeListServant(orb); reference orb.connect(shapeRef);
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path[] = {nc}; ncRef.rebind(path, shapeRef); java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait();} it waits for client requests } catch (Exception e) { ... } } }

Figure

Java client program for CORBA interfaces Shape and ShapeList

import org.omg.CosNaming.*; 1. it contacts import org.omg.CosNaming.NamingContextPackage.*;the NamingService for initial context 2. Narrows it to NamingContext import org.omg.CORBA.*; it creates and initialises an ORB 3. It makes a name component public class ShapeListClient{ 4. It public static void main(String args[]) { makes a path 5. It gets a reference to the CORBA object called try{ ShapeList, using resolve and narrows it ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); it uses one in the CORBA object to in an array it invokes the allShapes methodof the remote references getthe array to NamingContext ncRef = NamingContextHelper.narrow(objRef); invoke the getAllState method in the corresponding containing remote references to all of the GraphicalObjects currently NameComponentCORBA object whose type is Shape nc = new NameComponent("ShapeList", ""); stored NameComponent path [] = { nc }; by the server the value returned is of type GraphicalObject ShapeList shapeListRef = ShapeListHelper.narrow(ncRef.resolve(path)); Shape[] sList = shapeListRef.allShapes(); GraphicalObject g = sList[0].getAllState(); } catch(org.omg.CORBA.SystemException e) {...} Figure }

The main components of the CORBA architecture

language of to server by IDL compiler. ORB compiler for bridges the communication to of theanan object adapter theCORBA between module of to IDL need to invoke method gap objects The proxy classmay core is similarinathat oflanguage uses object. interfaceFigure 5.6. role invoke methods the clientthe inanremote an IDL a generate objectsrepositoryIDL interfaces in one of the following: method Interfaceclients andcore provides an interface that are dispatchedat run time repository remotecan be implementedanda variety of programming In addition, Implementationclasseswithinvocations includes the following: appropriate an ORB CORBA objects for proxies to be downloaded via the CORBA doesfor object-orientedalanguages the class of a proxy not skeleton to particular servant, allow programming servers about languagestheto be started and stopped; registered IDL interfacesservers the interface repository provides informationinterfaces of andcorresponding servant clients activates registered languageon demand the locates running to classes. - operations enablingprocedural languages a set of stub procedures. in request messages as in Java RMI. it the skeleton unmarshals the arguments for and it hasthat does the work adapter name reference and despatcher modules in Fig. 5.6 servers the require object of the remote to register and activate Figure 5.6 it following additional components compared to servers. uses and it. interface is object references and replywill - operations as before, the client stubs/proxiesand results inarguments in to convertthe marshals exceptions marshal the strings; between remote CORBAs alternative. (we The dynamic invocation more aboutimplementation repository and interfacemessages. the it object withrequests object adapter later. repository discuss tolater adapter, Interface Repository) using dynamic invocation. - operations invocation argumentand unmarshal exceptions and results in replies. provide the lists for requests

Client stubs/proxies Skeletons Dynamic invocation interface is designed to allow clients The CORBAskeleton classes (for OO languages) are generated in the ORB someapplicationsadapter language. without the appropriate core these are in(e.g. client the Object architecture client In browsers), a

client

implementation repository

interface repository

server object skeleton adapter ORB core Servant A

client proxy program for A

ORB core

Request Reply

or dynamic invocation

Figure

or dynamic skeleton

Object adapter
an object adapter bridges the gap between
CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant (classes). it does the work of the remote reference and despatcher modules in RPC.

An object adapter has the following tasks:

it creates remote object references for CORBA objects; it dispatches each RMI via a skeleton to the appropriate servant; it activates objects.

An object adapter gives each CORBA object a unique object name.

the same name is used each time an object is activated.
it is specified by the application program or generated by the object adapter.

Each object adapter has its own name - specified by the application program or generated automatically. CORBA 2.2 standard for object adapters is called POA.

Implementation repository Implementation repository

it activates registered servers on demand and locates running servers it uses the object adapter name to register and activate servers. it stores a mapping from the names of object adapters to the pathnames of files containing object implementations.
when a server program is installed it can be registered with the implementation repository. when an object implementation is activated in a server, the hostname and port number of the server are added to the mapping.

Implementation repository entry:

object adapter pathname of object hostname and port number of server implementation name

- not all CORBA objects (e.g. call backs) need be activated on demand - access control information can be stored in an implementation repository

Interface repository
it provides information about registered IDL interfaces
for an interface of a given type it can supply the names of the methods and for each method, the names and types of the arguments and exceptions. a facility for reflection in CORBA. if a client has a remote reference to a CORBA object, it can ask the interface repository about its methods and their parameter types the client can use the dynamic invocation interface to construct an invocation with suitable arguments and send it to the server.

the IDL compiler gives a type identifier to each IDL type a type identifier is included in remote object references this type identifier is called the repository ID
because the interface repository stoes interfaces against their IDs

applications that use static invocation with client proxies and IDL skeletons do not require an interface repository.
Not all ORBs provide an interface repository.

CORBA IDL IDL provides facilities for defining modules, interfaces, types, attributes and method signatures.
examples of all of the above, except modules, is shown in Figure IDL interfaces shape and shape and shapelist.

IDL has the same lexical rules as C++ but has additional keywords to support distribution,
for example interface, any, attribute, in, out, inout, readonly, raises.

It allows standard C++ pre-processing facilities. e.g. typedef for All. The grammar of IDL is a subset of ANSI C++ with additional constructs to support method signatures.

IDL module Whiteboard Modules allow interfaces and IDL type definitions to be grouped. A module defines a naming scope, which prevents names define within a module clashing with names defined outside it.
Figure
module Whiteboard { struct Rectangle{ ...} ; struct GraphicalObject { ...}; interface Shape { ...}; typedef sequence <Shape, 100> All; interface ShapeList { ...}; };

IDL method signatures

[oneway] <return_type> <method_name> (parameter1,..., parameterL) [raises (except1,..., exceptN)] [context (name1,..., nameM)]

each parameter is labelled as in, out or inout, e.g.

void getPerson(in string name, out Person p);

oneway e.g. oneway void callback(in int version)

the client will not be blocked and maybe semantics is used at-most-once call semantics is the default

The optional raises expression indicated user define exceptions The optional context expression is used to supplies mapping form string names to string values

Inheritance

IDL interfaces may extend one or more interfaces an extended interface may add new methods, types, constants and exceptions It may redefine types, constants and exceptions but not methods Interface A{}; Interface B: A{}; Interface C{}; Interface Z: B and C{};

Figure IDL constructed types 1

Type sequence string Examples
typedef sequence <Shape, 100> All; typedef sequence <Shape> All bounded and unbounded sequences of Shapes String name; typedef string<8> SmallString; unbounded and bounded sequences of characters typedef octet uniqueId[12]; typedef GraphicalObject GO[10][8]

Use
Defines a type for a variable-length sequence of elements of a specified IDL type. An upper bound on the length may be specified. Defines a sequences of characters, terminated by the null character. An upper bound on the length may be specified. Defines a type for a multi-dimensional fixed-length sequence of elements of a specified IDL type.

array

Figure IDL constructed types 2

Type record Examples
struct GraphicalObject { string type; Rectangle enclosing; boolean isFilled; }; enum Rand (Exp, Number, Name); union Exp switch (Rand) { case Exp: string vote; case Number: long n; case Name: string s; };

Use
Defines a type for a record containing a group of related entities. Structs are passed by value in arguments and results. The enumerated type in IDL maps a type name onto a small set of integer values. The IDL discriminated union allows one of a given set of types to be passed as an argument. The header is parameterized by an enum, which specifies which member is in use.

enumerated union

CORBA remote object references

CORBA 2.0 specifies a format for remote object references that is suitable for use, whether or not the object is activatable. References using this format are called 'interoperable object references'

(IORs).

First field species the type name of the IDL interface of the CORBA object Second field specifies the transport protocol Third field is used by the ORB to identify a CORBA object

IOR format IDL interface type name Protocol and address details interface repository identifier IIOP host domain name port number Object key adapter name object name

CORBA remote object references cont...

Transient IORs are for objects that last as long as the host process they contain the address of the server hosting the CORBA object
The server ORB core receives the request message containing the object adapter name and object name of the target. It uses the object adapter name to locate the object adapter, which uses the object name to locate the servant.

Persistent IORs last between activations they contain the address of the implementation repository the implementation repository receives the request and uses the object adapter name to activate the object, then gives the server address to the client the client sends subsequent invocations to the server

CORBA language mappings

Primitive types in IDL are mapped to the corresponding primitive types in Java Sequences and arrays in IDL are mapped to arrays in Java Structs, enums and unions are mapped to Java classes An IDL expression is mapped to a Java class IDL allows methods to return several separate values vis output parameters, where as Java can have only single result. The holder classes are provided to overcome this difficulty

17.3 CORBA services

Naming Service Event Service and Notification Service Security service Trading service Transaction service and concurrency control service Persistent object service

CORBA services cont...

Naming Service
It allows names to be bound to the remote object references of CORBA objects within naming context In fig CORBA objects are shown in the normal way, but naming contexts are shown as plain ovals Initial naming contexts provides a root for a set of bindings Each name is consist of two strings, one for the name other for the kind of the object

CORBA services cont... Naming Service cont...

CORBA services cont... CORBA Event service:

Defines interfaces allowing objects of interest, called suppliers to communicate notification to subscribers, called consumers Notification are communicated as arguments or results Notification may be propagated either by being pushed by supplier to the customer or pulled by the consumer by suppliers.

CORBA services cont... CORBA Notification service:

Extent the CORBA Event Service retaining all of it's features It includes a filtering events that specify exactly which events they are interested Notification may be define as data structure Event subscriber are provided with a mean of discovering the events the consumers are interested in Event consumers can discovered the event type offered by the suppliers by the channel Possible to configure the properties of a channel, a proxy or a particular event An event type repository is an optional extra

CORBA services cont...

CORBA Security service:

Authentication of principals (users and servers); generating credential for principals (i.e. certificate stating their rights) Access control can be applied to CORBA objects when they receive remote method invocations. Auditing by servers of remote method invocations Facilities for non-repudiation.

CORBA services cont... Trading service:

allows CORBA objects to be located by attribute Attribute is a name value pair The service type is a name It's database contains a mapping from service types and their associated attributes onto remote object references of CORBA objects Trading servers can perform quires on behalf of one another's clients.

Transaction service and concurrency control service

TS provides flat or nested transactions Client specifies a transaction as a sequence of RMI calls Which are introduce by begin and terminated by commit or rollback (abort). ORB attaches a transaction identifier to each remote invocation CCS provides locking of CORBA objects

CORBA services cont... Persistent object service:

for storing the state of CORBA objects in a passive form and retrieving it The CORBA POS is intended to be suitable for use as an persistent object store as an CORBA object. Each persistent object has an identifier which includes the identity of its data store and object number of that store. The implementation of persistent CORBA object must choose a protocol for communicating with data store E. g. The direct access protocol allows CORBA objects to access the attributes of persistent objects in the data store.