Transcript CORBA

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
ORBs
CORBA
Server
Object
CORBA
Client
Stub
IIOP ORB
RMI IIOP
Client
Stub
RMI IIOP
Server
Object
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 multilanguage; 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
Java
IDL
Compiler
C++
Stubs &
Skeleton
Java
Stubs &
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
Consumer
Producer
Event Queue
Producer
Consumer
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 & forget
Lots of supporting services: naming, time
services, event services, concurrency,
security, etc
A nerd’s playground