CORBA Case Study

BySrinivas Narayanabhatta

21st March 2002

                   

What is CORBA ?

Common Object Request Broker (ORB)Architecture

CORBA is OMG standard (Object Management Group)

to make better use of distributed systems to use object-oriented programming to allow objects in different programming languages to

communicate with one another

Evolution of CORBA

CORBA 1.1 (1992) Basic ORB, Naming, Interface Repository, C bindings,

Events, Basic Object Adapter,…

CORBA 2.0 (1995) Internet Inter-ORB Protocol (IIOP), C++ bindings,

Transactions, Security,…

CORBA 3.0 (and 2.2) (1998) Messaging (MOM), Portable Object Adapter (POA),

CORBA/DCOM interoperability, Java bindings, Objects by Value, Component Model,…

Object Management Architecture(OMA)

The main components of the CORBA architecture

client server

proxy

or dynamic invocation

implementation repository object

adapter

ORBORB

skeleton

or dynamic skeleton

client program

interface repository

Request

Replycorecore for A

Servant A

The CORBA architecture is designed to allow clients to invoke methods in CORBA objects

clients and objects can be implemented in a variety of programming languages

it has the following additional components compared to Figure 5.6 object adapter, implementation repository and interface repository

Figure 17.6

ORB coreThe role of the ORB core is similar to that of the communication module of Figure 5.6.

In addition, an ORB core provides an interface that includes the following:

- operations enabling it to be started and stopped;

- operations to convert between remote object references and strings;

- operations to provide argument lists for requests using dynamic invocation.

Dynamic invocation interface In some applications (e.g. browsers), a client without the appropriate proxy class may need to invoke a method in a remote object.

CORBA does not allow classes for proxies to be downloaded at run time as in Java RMI.

The dynamic invocation interface is CORBA’s alternative. (we will discuss it later with the Interface Repository)

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 Fig. 5.6–more about the object adapter later.

Skeletons–skeleton classes (for OO languages) are generated in the language of the server by an IDL compiler.–remote method invocations are dispatched via the appropriate skeleton to a particular servant, –the skeleton unmarshals the arguments in request messages and marshals exceptions and results in reply messages.

Client stubs/proxies– these are in the client language. – an IDL compiler for the client language uses an IDL interface to generate one of the following:

for object-oriented languages the class of a proxyfor procedural languages a set of stub procedures.

– as before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies.

Implementation repositoryactivates registered servers on demand and locates running servers uses the object adapter name to register and activate servers.more about this later

CORBA RMI CORBA's Object Model

Clients are not necessarily objects The CORBA Object – refers to remote object implements an

IDL interface. CORBA IDL

Specifies a name and set of methods that clients can request

CORBA objects are passed by reference and primitives and constructed types are passed by value.

The CORBA Naming Service CORBA pseudo Objects

Implementations of CORBA provide some interfaces to the functionality of ORB. E.g.. ORB and its methods init, connect

CORBA IDL

Same lexical rules as C++ but has additional keywords to support distribution. E.g. interface, in, out, inout, readonly, raises

IDL Modules Allows interfaces and other IDL type definitions to be

grouped in logical units. IDL Interfaces

Describes the methods that are available in CORBA objects that implement that interface.

IDL Methods in parameter passed from the client to the invoked CORBA

object out parameter is passed back from the invoked CORBA

object to client.

CORBA IDL contd.. inout – indicate value may be passed in both directions oneway – indicates client invoking the method will not be

blocked while the target object is carrying out a method. raises – indicates user-defined exceptions that can be

raised. IDL Types

IDL supports fifteen primitive types. Object – indicates values of remote objects.

Attributes These are like public class fields in Java.

Inheritance IDL interfaces may be extended (multiple inheritance). All IDL interfaces inherit from type Object No operation overloading.

IDL Examplestruct Rectangle{ 1

long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; 4interface ShapeList { 5

exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;

};

From IDL to Java Stubs

CORBA language Mappings

The primitive types in IDL are mapped to the corresponding primitive types in Java

Structs, enums and unions are mapped to Java classes

Sequences and arrays in IDL are mapped to arrays in java.

The mappings in C++ are similarly straight forward.

The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3

import org.omg.CORBA.*;class ShapeListServant extends _ShapeListImplBase {

ORB theOrb;private Shape theList[];private int version;private static int n=0;public ShapeListServant(ORB orb){

theOrb = orb; // initialize the other instance variables

}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; theOrb.connect(s); return s; }

public Shape[] allShapes(){ ... }public int getVersion() { ... }

}

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

a servant class extends the corresponding skeleton class (e.g. ShapeListImplBase)

a servant class implements the methods in the interface (ShapeList). newShape is a factory method. It creates new CORBA objects. It uses the connect method to inform the ORB about the new CORBA object. (it has a remote reference module)

CORBA objects are instances of servant classes.In non-OO languages implementations of CORBA objects can’t be classes.

This class has to create CORBA objects of type Shape. How does it do that?

Java class ShapeListServer (the server class)

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListServer {

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null);

ShapeListServant shapeRef = new ShapeListServant(orb); 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();}

} catch (Exception e) { ... }}

}

Figure 17.4

The server class contains the main method

it creates and initialises the ORB

it creates an instance of ShapeListServant class - a Java object - which is made a CORBA object by using the connect method to register it with the ORB

it waits for client requests

1. it gets a reference to the Naming Service 2. narrows it to NamingContext- from Object 3. makes a NameComponent containing the name

“ShapeList” 4. makes a path

5. uses rebind to register the name and object reference

Java client program for CORBA interfaces Shape and ShapeList

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListClient{

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", "");NameComponent path [] = { nc };ShapeList shapeListRef =

ShapeListHelper.narrow(ncRef.resolve(path));Shape[] sList = shapeListRef.allShapes();GraphicalObject g = sList[0].getAllState();

} catch(org.omg.CORBA.SystemException e) {...} } Figure 17.5

it creates and initialises an ORB

1. it contacts the NamingService for initial context2. Narrows it to NamingContext3. It makes a name component4. It makes a path5. It gets a reference to the CORBA object called

“ShapeList”, using resolve and narrows it

it invokes the allShapes method in the CORBA object to get an array containing remote references to all of the GraphicalObjects currently stored by the server

it uses one of the remote references in the array to invoke the getAllState method in the corresponding CORBA object whose type is Shapethe value returned is of type GraphicalObject

Static and Dynamic Invocations

Interface and Implementation Repositories

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 name

pathname of object implementation

hostname and port number of server

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.

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

Fig. 5.6. 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 active CORBA object is registered with its object adapter,

which keeps a remote object table to maps names of CORBA objects to servants.

Each object adapter has its own name - specified by the application program or generated automatically.

CORBA remote object references

Transient IORs: Last only as long as the process that hosts them. Server ORB core receives the request, extracts object adapter

name from IOR, locates the servant through object name

Persistent IORs: Last between the activations of CORBA objects. Implementation Repository receives the request, extracts object

adapter name from IOR, attempts to activate if necessary, once activated returns its address details to the client ORB.

IOR format

IDL interface type nameProtocol and address details Object key

interface repositoryidentifier

IIOP host domainname

port number

adapter name object name

CORBA Services

CORBA specification includes a set of generic services that are useful for the distributed objects.

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

Naming Service

Example of Naming Graph

initial naming context

ShapeList

CD E

B

initial naming context

P

R S T

V

Q U

initial naming context

XX

Figure 17.10Part of the CORBA Naming Service NamingContext interface in IDL

struct NameComponent { string id; string kind; };typedef sequence <NameComponent> Name;

interface NamingContext {void bind (in Name n, in Object obj);

binds the given name and remote object reference in my context.void unbind (in Name n);

removes an existing binding with the given name.void bind_new_context(in Name n);

creates a new naming context and binds it to a given name in my context.

Object resolve (in Name n); looks up the name in my context and returns its remote object reference.

void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi);

returns the names in the bindings in my context.};

Event Service

The CORBA Event service specification defines interfaces allowing objects of interest, called suppliers, to communicate notifications to subscribers, called consumers.

Event Channels are CORBA objects that my be used to allow multiple suppliers communicate with multiple consumers in an asynchronous manner.

The notification itself transmitted as an argument or result whose type is any.

consumersupplier

proxy consumernotification

proxy supplier

event channel

notificationnotification

Event Service – Interactive Models

Notification Service

The CORBA Notification Service extends the CORBA Event Service.

Notification Service provides support for filtering events.

Notifications may be defined as data structures. Event consumers can specify exactly which events

they are interested in. Event suppliers are provided with a means of

discovering the events the consumers are interested in.

Event consumers can discover the event types offered by the suppliers on a channel.

Security Service

Authentication of users and servers, generating credentials.

Access control can be applied to CORBA objects when they receive remote method invocation.

Access rights may be specified using ACLs. The security service requires cooperation on

behalf of ORB to guarantee the security. To make a secure RMI, client’s credentials are

sent with the request. The access decision made by the consulting

object.

Platform Support for CORBA

Visibroker Leading CORBA ORB, Client integrated in Netscape

Orbix Leading CORBA ORB, was ported to LynxOS Arbacus Commercial ORB, free for non-commercial

use OmniORB Free from AT&T, has been ported to

LynxOS2.5.1 ILU Free from Xerox.

IONA – ORBIX Architecture

CORBA – Strengths and Weaknesses

CORBA strength is in interoperability: languages, platforms, public domain software.

Has a very rich and complete set of facilities and services.

One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability.

There are many services defined but their implementations are slow to appear

By its working method OMG is creating compromises.