CORBA

Packages

JavaIDL: org.omg.CORBA, org.omg.CORBA_2_3, org.omg.CORBA_2_3. portable, org.omg.CORBA.DynAnyPackage, org.omg.CORBAORBPackage, org.omg.CORBA.portable, org.omg.CORBATypeCodePackage

CosNaming: org.omg.CosNaming, org.omg.CosNaming. NamingContextPackage, org.omg.SendingContext

RMI-IIOP: javax.rmi.CORBA, org.omg.stub.java.rmi

Use: J2SE (JDK 1.2)

Overview

The Common Object Request Broker Architecture, or CORBA, is a distributed object communication architecture. In simplest terms, it's a way for an application to request services from another application by calling remote methods.

CORBA pretty much provides the ultimate in interoperability. Many programming languages support the CORBA standard, and the architecture is defined so that a client and server written in different CORBA-compliant languages can interact without knowing or caring about remote implementation details.

Central to the architecture is the Object Request Broker, or ORB. The ORB functions as the router for all distributed communication. Every client and server in a system depends on an ORB for messaging.

To interact with the ORB, CORBA participants map their code to IDL, the Interface Definition Language. IDL is a platform-neutral language used to define calling interfaces for CORBA participants. This is key to the magic behind client-server communication. IDL provides a description of the contract between a client and server. In this way, a client knows what methods it can invoke, but does not know what language the methods will be written in.

The CORBA framework uses the Internet Inter-ORB Protocol (IIOP) to manage its distributed communication. This lower-level protocol was introduced in recent revisions of the CORBA specification to enable distributed communications across the most pervasive of networks—the Internet.

Java and CORBA

The Java API was created to allow Java programs to interoperate with the CORBA model at several levels. Three CORBA-related technologies are represented in Java APIs: JavaIDL, CosNaming, and RMI-IIOP.

JavaIDL – JavaIDL represents direct CORBA capabilities in the Java programming language. The API, with its associated compiler tool, provides a way to map between Java code and the Interface Definition Language. Practically speaking, this means that Java code can use the API to function as a CORBA client or server module. In broader terms, the API allows a Java program to interact with an ORB, effectively allowing Java programs to leverage the power of CORBA.

CosNaming – The CosNaming service provides a way for Java programs to use a CORBA naming service. CORBA’s naming service pretty much does what you'd expect it to do—it keeps track of an object with a string representing the object's name.

A Java server using CosNaming will register its remote objects with the service; a client will look them up and use them. This is sort of like the services provided by the Java Naming and Directory Interface—well, actually, it's identical. CosNaming was introduced before JNDI to accommodate Java CORBA applications. JNDI has subsequently integrated CosNaming as one of its possible services. This means that you can write CORBA programs that use the original API to implement Cos-Naming, or you can use JNDI to access the CosNaming services.

RMI-IIOP – RMI-IIOP was a recent addition to the batch of CORBA technologies. It allows RMI programs to communicate using CORBA’s underlying protocol. Originally, RMI used a protocol called the Java Remote Method Protocol (JRMP) to provide transport capabilities. This protocol was developed by Java and for Java; there are no other technologies that use or support it. IIOP, on the other hand, which is CORBA’s communication protocol, is very widely supported. It makes sense, given Java's goals of universality, to use a protocol like IIOP for interapplication communication.

205

It’s a tribute to the RMI architecture team that they were able to transparently swap out JRMP for CORBA’s IIOP. There are no changes to developer code at all; it's all done behind the scenes. You can convert an existing RMI application to IIOP without changing a line of code.

Together, these three technologies compose the CORBA functionality in Java. Actually, Java developers use very few of the classes in the packages when writing code. For JavaIDL, the ORB class is the one that is used in the majority of applications. For CosNaming, there are about half a dozen classes and interfaces which are commonly used. And RMI-IIOP solutions rarely use any of the classes defined in the packages.

So what about all the CORBA classes and interfaces? What happens to them? The CORBA APIs have a total of 143 classes that provide support services. That is, the classes are used by code that is generated by associated CORBA utilities, such as idl2java.

Pattern Use

The CORBA APIs in Java implement a few basic design patterns.

Singleton (see page 34): The ORB is supposed to provide a single point of contact for CORBA communication in a JVM. This means that there can only be one instance of an ORB in any running Java application. To satisfy this requirement, the API uses the Singleton pattern. The ORB class in the org.omg.CORBA package provides an implementation of the Singleton pattern. Its init method provides a single-instance ORB resource for use in Java applications.

Factory Method (see page 21): The ORB class provides many create methods, since it is the main resource provider for CORBA solutions. A number of these methods satisfy the requirements for the Factory pattern, producing objects that can be flexibly specified during the creation process.

206