1. Common Object Request Broker Architecture CORBA

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

3. Object Request Brokers Like HLA, CORBA has a conceptual “bus” that is used to pass data between hosts, called the ORB Host AHost B ORB

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

5. ORBs CORBA Server Object RMI IIOP Server Object CORBA Client Stub RMI IIOP Client Stub IIOP ORB

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

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

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

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

10. CORBA IDL File C++ IDL Compiler Java IDL Compiler C++ Stubs & Skeleton Java Stubs & Skeleton

11. IDL interface DeckIF { Card dealCard( ); void shuffle( ); }; valuetype Card { const long HEART = 0; const long DIAMOND = 1; …

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

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

14. Event Queues One interesting feature of CORBA is event queues Suppose we have producers and consumers Producer Event Queue Consumer Producer

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

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

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