Using CORBA and Java IDL

• About CORBA
• About Java IDL
• CORBA Concepts in a Nutshell
• Defining and Implementing CORBA Objects
• Client Implementation
• Java IDL Transient Name Server

CORBA (Common Object Request Broker Architecture) is the standard distributed object architecture developed by the Object Management Group (OMG) consortium. Since 1989 the mission of the OMG has been the specification of an architecture for an open software bus, or Object Request Broker (ORB), on which object components written by different vendors can interoperate across networks and operating systems. This standard allows CORBA objects to invoke one another without knowing where the objects they access reside or in what language the requested objects are implemented. The OMG-specified Interface Definition Language (IDL) is used to define the interfaces to CORBA objects.

CORBA objects differ from typical programming language objects in these ways:

• CORBA objects can be located anywhere on a network.
• CORBA objects can interoperate with objects on other platforms.
• CORBA objects can be written in any programming language for which there is a mapping from OMG IDL to that language. (Mappings currently specified include Java, C++, C, Smalltalk, COBOL, and Ada.)

The Java 2 Platform, Standard Edition, v1.3, provides a CORBA 2.3.1-compliant Object Request Broker (ORB) and two CORBA programming models that utilize the Java CORBA ORB and Internet InterORB Protocol (IIOP). The two programming models are the RMI programming model, or RMI-IIOP, and the IDL programming model, or Java IDL. For more information on these programming models, read CORBA Technology and the Java Platform.

Should I use RMI-IIOP or Java IDL?

This is a fundamental question and it's important to understand the distinction between these two ways of integrating the Java programming language with CORBA.

RMI-IIOP is for Java programmers who want to program to the RMI interfaces, but use IIOP as the underlying transport. RMI-IIOP provides interoperability with other CORBA objects implemented in various languages - but only if all the remote interfaces are originally defined as Java RMI interfaces. It is of particular interest to programmers using Enterprise JavaBeans (EJB), since the remote object model for EJBs is RMI-based.

Java IDL is for CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA IDL. This is "business as usual" CORBA programming, supporting Java in exactly the same way as other languages like C++ or COBOL.

Both Java IDL and RMI-IIOP include the full functionality of a CORBA Object Request Broker (ORB). The good news for developers is that the Java^TM Standard Edition, v1.2 and higher includes a fully-functional ORB that is available in every deployment of the Java 2 Platform, Standard and Enterprise Editions. Now you can write Java CORBA code without having to license any other software!

About RMI-IIOP

Java RMI-IIOP is an Object Request Broker and a compiler, rmic -iiop, that generates IIOP stub and tie classes. With RMI-IIOP, developers can write remote interfaces in the Java programming language and implement them simply using Java technology and the Java RMI APIs. These interfaces can be implemented in any other language that is supported by an OMG mapping and a vendor supplied ORB for that language. Similarly, clients can be written in other languages using IDL derived from the remote Java technology-based interfaces. Using RMI-IIOP, objects can be passed both by reference and by value over IIOP.

About Java IDL

The Java IDL ORB supports transient CORBA objects - objects whose lifetimes are limited by their server process's lifetime. Java IDL also provides a transient name server to organize objects into a tree-directory structure. The name server is compliant with the Naming Service Specification. Transient objects and the name server are discussed later in this page.

No interface repository is provided as part of Java IDL. An interface repository is not required because under normal circumstances, clients have access to generated stub files.

CORBA Concepts in a Nutshell

The concepts introduced in this section are more completely discussed in the CORBA/IIOP Specification.

The diagram below shows a method request sent from a client to a CORBA object implementation in a server. A client is any code (perhaps itself a CORBA object) that invokes a method on a CORBA object. The servant is an instance of the object implementation - the actual code and data that implements the CORBA object.

The client of a CORBA object has an object reference for the object and the client uses this object reference to issue method requests. If the server object is remote, the object reference points to a stub function, which uses the ORB machinery to forward invocations to the server object. The stub code uses the ORB to identify the machine that runs the server object and asks that machine's ORB for a connection to the object's server. When the stub code has the connection, it sends the object reference and parameters to the skeleton code linked to the destination object's implementation. The skeleton code transforms the call and parameters into the required implementation-specific format and calls the object. Any results or exceptions are returned along the same path.

The client has no knowledge of the CORBA object's location, implementation details, nor which ORB is used to access the object. Different ORBs communicate via the OMG-specified Internet InterORB Protocol (IIOP).

A client may only invoke methods that are specified in the CORBA object's interface. A CORBA object's interface is defined using the OMG Interface Definition Language (IDL). An interface defines an object type and specifies a set of named methods and parameters, as well as the exception types that these methods may return. An IDL compiler such as idlj translates the CORBA object definitions into a specific programming language according to the appropriate OMG language mapping. Thus, the idlj compiler translates IDL defintions into Java constructs according to the IDL-Java language mapping.

The stub and skeleton files are generated by the idlj compiler for each object type. Stub files present the client with access to IDL-defined methods in the client programming language. The server skeleton files glue the object implementation to the ORB runtime. The ORB uses the skeletons to dispatch methods to the object implementation instances (servants).

Defining and Implementing CORBA Objects

The goal in CORBA object development is the creation and registration of an object server, or simply server. A server is a program which contains the implementation of one or more object types and which has been registered with the ORB. For example, you might develop a desktop publishing server which implements a "Document" object type, a "Paragraph" object type, and other related object types.

CORBA Object Interfaces

All CORBA objects support an IDL interface; the IDL interface defines an object type. An interface can inherit from one or more other interfaces. IDL syntax is very similar to that of Java or C++, and an IDL file is functionally the CORBA language-independent analog to a C++ header file. IDL is mapped into each programming language to provide access to object interfaces from that language. With Java IDL, these IDL interfaces can be translated to Java using the idlj compiler. For each IDL interface, idlj generates a Java interface and the other .java files needed, including a client stub and a server skeleton.

An IDL interface declares a set of client accessible operations, exceptions, and typed attributes (values). Each operation has a signature that defines its name, parameters, result, and exceptions. A simple IDL interface that describes the classic "Hello World" program, follows.

module HelloApp
{
  interface Hello
  {
    string sayHello();
    };
};

An operation may raise an exception when an error condition arises. The type of the exception indicates the kind of error that was encountered. Clients must be prepared to handle defined exceptions and CORBA standard exceptions for each operation in addition to normal results.

Java Language-based Implementation

Once the IDL interfaces have been defined and the idlj compiler run on the .idl file, .java files containing the method implementations may be written. The .java implementation files are then compiled and linked with the idlj -generated .java files and the ORB library to create an object server.

An object implementation defines the behavior for all the operations and attributes of the interface it supports. There may be multiple implementations of an interface, each designed to emphasize a specific time and space trade-off, for example. The implementation defines the behavior of the interface and object creation/destruction.

Since only servers can create new CORBA objects, a factory object interface should be defined and implemented for each object type. For example, if Document is an object type, a DocumentFactory object type with a create method should be defined and implemented as part of the server. (Note that "create" is not reserved; any method name may be used.) The implementation of the create method can then use new to create the object. For example:

  DocumentServant document  = new DocumentServant():
  orb.connect(document); 

A destroy method may be defined and implemented on Document; or, the object may be intended to persist indefinitely. (Again, "destroy" is not reserved and any name may be used.)

The Java IDL ORB supports transient objects only - objects whose lifetime is limited by the server process lifetime. Although a transient object dissapears when its server process stops running, the object may be implemented to store its state in a file and to re-initialize itself from this file at creation time.

Client Implementation

Client code is linked with idlj-generated .java files and the ORB library. Examples of application and applet clients are provided in the Hello World example.

Clients may only create CORBA objects via the published factory interfaces that the server provides. Likewise, a client may only delete a CORBA object if that object publishes a destruction method. Since a CORBA object may be shared by many clients around a network, only the object server is in a position to know when the object has become garbage.

The client code's only way of issuing method requests on a CORBA object is via the object's object reference. The object reference is an opaque structure which identifies a CORBA object's host machine, the port on which the host server is listening for requests, and a pointer to the specific object in the process. Because Java IDL supports only transient objects, this object reference becomes invalid if the server process has stopped and restarted.

Clients typically obtain object references in the following ways:

• from a factory object. For example, the client could invoke a create method on DocumentFactory object in order to create a new Document. The DocumentFactory create method would return an object refererence for Document to the client.
• from the nameservice. For example, the client could obtain an object reference for the DocumentFactory by issuing a request on the nameservice.
• From a string that was specially created from an object reference

Once an object reference is obtained, the client must narrow it to the appropriate type. IDL supports inheritance; the root of its hierarchy is Object in IDL, org.omg.CORBA.Object in Java. (org.omg.CORBA.Object is, of course, a subclass of java.lang.Object.) Some operations, notably name lookup and unstringifying, return an org.omg.CORBA.Object, which you narrow (using a helper class generated by the idlj compiler) to the derived type you want the object to be. CORBA objects must be explicitly narrowed because the Java runtime cannot always know the exact type of a CORBA object.

The Java IDL Transient Nameservice is an object server provided with Java IDL. Use tnameserv at the command line prompt to start the Name Server. This object server conforms to the standard object implementation and invocation techniques described in the previous sections of this page.

The Name Server stores object references by name in a tree structure similar to a file directory. A client may lookup or resolve object references by name. Because the Name Server is an ordinary Java IDL transient server, the entire directory structure of names is lost each time tnameserv stops running.

See Naming Service for more information.