We have discussed simple “unicast” servers in Chapter 7, and activatable servers in Chapter 10. This chapter describes how to write and implement RMI over IIOP (Internet Inter-ORB protocol). It discusses IIOP servers, dual-mode JRMP+IIOP servers, implementing the service and/or the client in another language, and lists the restrictions imposed by IIOP as compared to JRMP.

IIOP is the transport protocol adopted by the Object Management Group (OMG) for CORBA. It provides interoperability with CORBA object implementations in various languages.^[1]

Normally, the underlying transport for RMI is JRMP, ^[2] which is only understood by Java RMI programs.

RMI over IIOP allows Java programmers to program to the RMI interfaces but use IIOP as the underlying transport, so as to be interoperable with CORBA, and with any services which are interoperable with CORBA. Java RMI programmers can therefore participate in CORBA services networks with services and clients implemented in any of the languages supported by CORBA, subject to the restrictions defined in § 14.10.

Using Java RMI over IIOP allows developers to work completely in the Java programming language, without having to learn or use CORBA IDL. Having done so, they can then generate IDL from the working Java application or prototype, and proceed to develop other components in other languages. CORBA IDL can be produced automatically from remote RMI/IIOP interfaces, and these can be generated into stubs/skeletons/frameworks/whatever for any other programming languages supported by your Object Request Broker (ORB).

Enterprise Java Beans (EJBs) are server-side components of applications based on the J2EE platform. EJBs communicate via RMI interfaces—they are RMI remote objects. The EJB 1.1 specification recommends, and the 2.0 specification will require, that EJB implementations support RMI/IIOP.^[3]

The javax.rmi.PortableRemoteObject class is provided to help you define “portable remote objects”: RMI servers which communicate over RMI/IIOP. It is a precise analogue of java.rmi.server.UnicastRemoteObject, discussed in Chapter 7: it provides a constructor, an exportObject method, and an unexportObject method. The differences between portable remote objects and unicast or activatable remote objects are as follows:

In writing portable remote objects, you have three choices.

import javax.rmi.PortableRemoteObject;

public class MyIIOPServer extends PortableRemoteObject
       implements MyRemote
{
       public MyIIOPServer() throws RemoteException {}
       // implementations of remote methods not shown
}

import javax.rmi.PortableRemoteObject;

public class MyIIOPServer extends RemoteObject implements MyRemote
{
       public MyIIOPServer() throws RemoteException
       {
              PortableRemoteObject.exportObject(this);
       }
       // implementations of remote methods not shown
}

import javax.rmi.PortableRemoteObject;

public class MyIIOPServer /*extends java.lang.Object*/ implements MyRemote
{
       public MyIIOPServer() throws RemoteException
       {
             PortableRemoteObject.exportObject(this);
       }
       // implementations of remote methods not shown
}

As usual, you run rmic against the server class, but for IIOP you must specify the -iiop flag. This causes rmic to produce CORBA stub and “tie” classes, instead of the JRMP stub (and skeleton) classes.

If you need to generate IDL, run rmic with the -idl flag. You will need IDL if non-Java clients are to be produced. You may also need IDL with ORBs other than the one provided with Java.

Java also provides the idlj tool.^[4] This generates Java bindings from CORBA IDL interface definitions. The idlj tool operates in the IDL-to-Java direction, whereas rmic -idl operates in the Java-to-IDL direction. idlj is not used in RMI/IIOP. For more information about this tool consult the JDK documentation.

It is possible to write a portable remote object in such a way that it supports both IIOP and JRMP clients. You need to do the following:

Part of a dual-protocol RMI server for a remote interface MyRemote is shown in Example 14.4.

import java.rmi.*;
import java.rmi.server.*;
import java.util.Properties;
import javax.naming.InitialContext;
import javax.rmi.*;

public class MyDualServer /*extends java.lang.Object*/ implements MyRemote
{
       public MyDualServer() throws RemoteException
       {
              UnicastRemoteObject.exportObject(this);    // Export to JRMP
              PortableRemoteObject.exportObject(this);   // Export to IIOP
       }

       // implementations of remote methods not shown

       public static void    main(String[] args) throws Exception
       {
              System.setSecurityManager(new RMISecurityManager());
              MyDualServerserver = new MyDualServer();

              // Bind to RMI Registry
              Properties      jrmpProps = new Properties();
              jmpProps.put("java.naming.factory.initial",
                    "com.sun.jndi.rmi.registry.RegistryContextFactory");
              InitialContextjrmpCtx = new InitialContext(jrmpProps);
              jrmpCtx.rebind("MyRemote",server);

              // Bind to COSNaming
              Properties    iiopProps = new Properties();
              iiopProps.put("java.naming.factory.initial",
                  "com.sun.jndi.cosnaming.CNCtxFactory");
              InitialContextiiopProps = new InitialContext(iiopProps);
              iiopProps.rebind("MyRemote",server);
       }
}

RMI/IIOP is designed as the intersection of RMI and CORBA. It is not intended to contain all the features—the union—of both.

RMI/IIOP provides the ability to define services (servers) written in Java and export them to CORBA, to write Java clients for CORBA services, or both. The following restrictions apply to RMI/IIOP as compared to RMI/JRMP.

In theory, once you have produced the IDL for the remote service, you can implement the service in another language. In practice this depends whether your ORB vendor supports the Objects By Value feature of CORBA 2.3 for the language required. The Objects By Value feature is only defined for Java and C++.

As we have seen, an RMI client is remarkably like the client of a local object. The only real differences are the source of the object and the use of an intermediate interface to access the object so obtained.

Similarly, an RMI/IIOP client is remarkably like an RMI/JRMP client. Again, the only real differences are the source of the object and the use of an intermediate interface to access the object so obtained.

MyRemote myRemote = (MyRemote)object;

MyRemote myRemote = (MyRemote)PortableRemoteObject
                    .narrow(object,MyRemote.class);

import java.rmi.*;
import java.util.Properties;
import javax.naming.InitialContext;

public class MyRemoteClient
{
       public static voidmain(String[] args) throws Exception
       {
              System.setSecurityManager(new RMISecurityManager());

              // Lookup CosNaming via JNDI
              Properties  props = new Properties();
              props.put("java.naming.factory.initial",
                    "com.sun.jndi.cosnaming.CNCtxFactory");
              InitialContextctx = new InitialContext(props);
              Objectobj = ctx.lookup("MyRemote");

              // Got the object: perform the CORBA cast
              MyRemote      mr = (MyRemote)PortableRemoteObject
                                      .narrow(obj,MyRemote.class);

              // methods on mr can now be invoked
       }
}

A non-Java client can be written for a Java RMI/IIOP server. How you actually do this is dependent on your ORB. You will need to use an ORB other than the one provided with Java 2, and you will need the IDL to be generated from the remote interface, by using rmic -idl. Consult your ORB vendor's documentation for further information about how to write a client in your choice of language starting from an IDL interface definition.