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
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
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