Common Object Request Broker Architecture

CORBA

CORBA

RMI is a simplified version of CORBA that does fairly well

CORBA is all-singing and all-dancing• Multiple languages• More complete set of features• Some fairly high performance

implementations (TAO/Ace) that some have used as a basis for an HLA implementation

Object Request Brokers

Like HLA, CORBA has a conceptual “bus” that is used to pass data between hosts, called the ORB

Host A Host B

ORB

Object Request Brokers

In reality an ORB instance runs on each host to handle communications

ORBs are standardized via the Internet Inter-ORB Protocol (IIOP), a standard for how ORBs communicate with each other. Most ORBs use that these days, though it’s possible to use others

CORBA can use IIOP standard on-the-wire format for message passing between hosts

In fact, RMI can be implemented via a subset of the IIOP, so you can make calls to CORBA objects via RMI interfaces, or have CORBA clients call RMI server objects

ORBsCORBAServerObject

RMI IIOPServerObject

CORBAClientStub

RMI IIOPClientStub

IIOP ORB

RMI-IIOP

If you implement RMI over IIOP, your Java clients can call CORBA server objects, or CORBA clients can contact RMI/IIOP server objects

You have to specify that your Java client and server objects use IIOP (-IIOP option to rmic)

Since CORBA objects have richer semantics than RMI, some CORBA objects may not be vendable to Java RMI-IIOP clients

RMI-IIOP

If you are using RMI over IIOP, the ORB will intercept your parameter objects and marshal them according to the IIOP rules rather than Java serialization rules. You don’t need to change anything on your side, mostly.

RMI can (mostly) hide whether it is using IIOP or the native communication scheme (Java Remote Message Protocol)

RMI is really an interface rather than an implementation

CORBA

How do you define the interface of a CORBA server object? Remember, CORBA is multi-language; C++ clients expect to use a C++ local object, while a Smalltalk or Java local object expect to see a Smalltalk or Java local interface for the same server object

We could define all object interfaces and object types in C++, but that is somewhat rude

CORBA

Instead the OMG defined a stand-alone interface definition language, IDL. The IDL language defines method calls, primitive types, structs, etc.

Every language has an IDL compiler that converts the IDL file into the desired language

C++ has an IDL compiler that converts the IDL file into C++ object interfaces; a Java IDL compiler converts the IDL file to Java stubs

CORBA

IDL File

C++IDL

Compiler

JavaIDL

Compiler

C++Stubs &Skeleton

JavaStubs &Skeleton

IDL interface DeckIF {

Card dealCard( ); void shuffle( );

};

valuetype Card {

const long HEART = 0; const long DIAMOND = 1;…

IDL

The IDL files are highly reminiscent of C++You can write IDL directly, or, the easy

way, generate IDL from a Java interface via rmic

rmic -idl DeckIF.java

Creates the IDL files, including Card

Compiling IDL

Use idl2java to compile the IDL to java (not needed if using rmic -iiop)

Various ugly details on getting a CORBA server to work; see the Sun Java tutorial

Event Queues

One interesting feature of CORBA is event queues

Suppose we have producers and consumers

ProducerEvent Queue

Consumer

ConsumerProducer

Event Queues

Event queues can run on the “push” model or the “pull” model, depending on which side is forcing the events to be delivered. With “Push” the supplier forces the transmission to consumers; with “pull”, the consumers ask for events

This also decouples the sender from the consumer; neither has to directly know of the other

Event queues can also be unreliable, which opens up using multicast with push

Event Queues

Effectively, you can add a piece of “middleware”--neither client nor server, instead living on the network--that handles distribution of events, and you can make tradeoffs of reliability vs. latency in that middleware

Latency is a big issue in real time applications, and getting it right is very hard

Single event queue instances running on a single host are effectively server-based architectures (not p2p) with the usual issues of latency and scalability

CORBA

CORBA is feature-rich, meaning it has lots of knobs to twiddle, with all the dangers that implies

One-way method calls: fire & forgetLots of supporting services: naming, time

services, event services, concurrency, security, etc

A nerd’s playground