Documentation Contents

RMI-IIOP Programmer's Guide

This document discusses how to write Java Remote Method Invocation (RMI) programs that can access remote objects by using the Internet Inter-ORB Protocol (IIOP). By making your RMI programs conform to a small set of restrictions, your CORBA clients in any language can access RMI-IIOP servers. RMI-IIOP gives you RMI ease-of-use coupled with CORBA/IIOP language interoperability.

What is RMI-IIOP?

RMI

RMI lacks interoperability with other languages because it does not use CORBA-IIOP as the communication protocol.

IIOP, CORBA, and Java IDL

The Java SE CORBA/IIOP implementation is known as Java IDL. Along with the idlj compiler, Java IDL can be used to define, implement, and access CORBA objects from the Java programming language.

The Java IDL web page gives you a good, Java-centric view of CORBA/IIOP programming. To get a quick introduction to writing Java IDL programs, see the Getting Started: Hello World web page.

RMI-IIOP

Table of Contents

• The rmic Compiler
• The idlj Compiler
• How to Make RMI Programs Use IIOP
• Restrictions When Running RMI Programs Over IIOP
• Other Things You Should Know

The rmic Compiler

Here are the primary rmic flags that support the CORBA/IIOP functionality:

The following options are used in conjunction with the -idl option.

For more detailed information on the rmic compiler, read the rmic documentation.

The -iiop Flag

Stub classes are also generated for abstract interfaces. An abstract interface is an interface that does not extend java.rmi.Remote, but whose methods all throw either java.rmi.RemoteException or a superclass of java.rmi.RemoteException. Interfaces that do not extend java.rmi.Remote and have no methods are also abstract interfaces.

QUESTION: I have a RMI-IIOP application which was running on Java SE. When I generate new stubs and skeletons using rmic -iiop -poa <RMI Interface>, it does not work. Why ?

ANSWER: There are 2 different ways to compile and run RMI-IIOP programs, which are listed below. We do not recommend that you combine these.

1. The default RMI-IIOP behavior. An example of an application that uses the default RMI-IIOP behavior can be found at Tutorial: Getting Started Using RMI-IIOP.
2. POA-based RMI-IIOP. An example of an application that uses the non-standard POA-based RMI-IIOP behavior can be found at Getting Started Using RMI-IIOP: Example Using POA-based server-side model.

The -iiop -poa Flag

Using the -iiop flag with the -poa option changes the inheritance from org.omg.CORBA_2_3.portable.ObjectImpl to org.omg.PortableServer.Servant. This type of mapping is nonstandard and is not specified by the Java Language to OMG IDL Language Mapping Specification.

The PortableServer module for the Portable Object Adapter (POA) defines the native Servant type. In the Java programming language, the Servant type is mapped to the Java org.omg.PortableServer.Servant class. It serves as the base class for all POA servant implementations and provides a number of methods that may be invoked by the application programmer, as well as methods which are invoked by the POA itself and may be overridden by the user to control aspects of servant behavior.

The -idl Flag

Note: After the OMG IDL is generated using rmic -idl, use the generated IDL with an IDL-to-C++ or other language compiler, but not with the IDL-to-Java language compiler. "Round tripping" is not recommended and should not be necessary. The IDL generation facility is intended to be used with other languages such as C++. Java clients or servers can use the original RMI-IIOP types.

IDL provides a purely declarative, programming language independent means for specifying the API for an object. The IDL is used as a specification for methods and data that can be written in and invoked from any language that provides CORBA bindings. This includes Java and C++ among others. See the Java Language to IDL Mapping (OMG) document for a complete description.

Note: The generated IDL can only be compiled using an IDL compiler that supports the CORBA 2.3 extensions to IDL.

The -noValueMethods Flag

See the RMIC tool page (Solaris, Linux, or Mac OS X version/Windows version) for a complete rmic description.

The idlj Compiler

How to Make RMI Programs Use IIOP

1. If you are using the RMI registry for naming services, you need to switch to CosNaming. In the createORB() method, do not pass the org.omg.ORBClass property. Instead, use ORB.init( args, null ). You need to do the following:
   1. In both your client and server code, you need to create an InitialContext for JNDI using the following code:

               import javax.naming.*;
               ...
               Context ic = new InitialContext();
      

   2. Modify all uses of RMI registry lookup() and bind() to use JNDI lookup() and bind()instead. For example, instead of your RMI server using:

               import java.rmi.*;
               ...
               Naming.rebind("MyObject", myObj);
      

      use:

               import javax.naming.*;
               ...
               ic.rebind("MyObject", myObj);
      

   3. If the client is an applet, the client applet needs to pass this to the JNDI CosNaming plugin. Replace the above code with the following:

              import java.util.*;
              import javax.naming.*;
              ...
              Hashtable env = new Hashtable();
              env.put("java.naming.applet", this);
              Context ic = new InitialContext(env);
      

2. If you are not using the RMI registry for naming services, you have some other way of bootstrapping your initial remote object reference. For example, your server code may be using Java serialization to write an RMI object reference to an ObjectOutputStream and passing this to your client code for deserializing into an RMI stub.

   On the server side, use the PortableRemoteObject.toStub() call to obtain a stub, then use writeObject() to serialize this stub to an ObjectOutputStream. The code to do this looks something like:

   org.omg.CORBA.ORB myORB = org.omg.CORBA.ORB.init(new String[0], null);
   Wombat myWombat = new WombatImpl();
   javax.rmi.CORBA.Stub myStub = (javax.rmi.CORBA.Stub)PortableRemoteObject.toStub(myWombat);
   myStub.connect(myORB);
   // myWombat is now connected to myORB.  To connect other objects to the
   // same ORB, use PortableRemoteObject.connect(nextWombat, myWombat);
   FileOutputStream myFile = new FileOutputStream("t.tmp");
   ObjectOutputStream myStream = new ObjectOutputStream(myFile);
   myStream.writeObject(myStub);
   

   On the client side, use readObject() to deserialize a remote reference to the object from an ObjectInputStream, with code like:

   FileInputStream myFile = new FileInputStream("t.tmp");
   ObjectInputStream myStream = new ObjectInputStream(myFile);
   Wombat myWombat = (Wombat)myStream.readObject();
   org.omg.CORBA.ORB myORB = org.omg.CORBA.ORB.init(new String[0], null);
   ((javax.rmi.CORBA.Stub)myWombat).connect(myORB);
   // myWombat is now connected to myORB.  To connect other objects to the
   // same ORB, use PortableRemoteObject.connect(nextWombat, myWombat);
   

3. Either change your remote implementation classes to inherit from javax.rmi.PortableRemoteObject, or explicitly export implementation objects after creation by calling PortableRemoteObject.exportObject(). For more discussion on this topic, read Connecting IIOP stubs to the ORB.
    
4. Change all the places in your code where there is a Java cast of a remote interface to use javax.rmi.PortableRemoteObject.narrow().
    
5. Don't depend on Distributed Garbage Collection (DGC) or use any of the RMI DGC facilities. Use PortableRemoteObject.unexportObject() to unexport objects that are no longer in use.
    
6. Regenerate the RMI stubs and ties using the rmic command with the -iiop option. This will produce stub and tie files with the following names:

        _<implementionName>_Tie.class
        _<interfaceName>_Stub.class
   

7. Before starting the server, start the CosNaming server (in its own process) using the following command:

        orbd -ORBInitialPort port#
   

   You must specify the port number when starting ORBD.
8. When starting client and server applications, specify the following system properties:

        java -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
             -Djava.naming.provider.url=iiop://<hostname>:1050
              <appl_class>
   

   This example uses the name service port number of 1050. If you specified a different port in step 7, you need to use the same port number in the provider URL here. The <hostname> in the provider URL is the host name that was used to start the CosNaming server in step 7.
   
   
9. If the client is an applet, specify the following properties in the applet tag:

        java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
        java.naming.provider.url=iiop://<hostname>:1050
   

   This example uses the name service port number of 1050. If you specified a different port in step 7, you need to use the same port number in the provider URL here. The <hostname> in the provider URL is the host name that was used to start the CosNaming server in step 7.

For tutorials that describe creating a new RMI-IIOP application, link to Getting Started Using RMI-IIOP: Example Using POA-based server-side model or Tutorial: Getting Started Using RMI-IIOP.

Connecting IIOP stubs to the ORB

The PortableRemoteObject.exportObject() call only creates a tie object and caches it for future usage. The created tie does not have a delegate or an ORB associated. This is known as explicit invocation.

The PortableRemoteObject.exportObject() happens automatically when the servant instance is created. This happens when a PortableRemoteObject constructor is called as a base class. This is known as implicit invocation.

Later, when PortableRemoteObject.toStub() is called by the application, it creates the corresponding Stub object and associates it with the cached Tie object. But since the Tie is not connected and does not have a delegate, the newly created stub also does not have a delegate or ORB.

The delegate is set for the stub only when the application calls Stub.connect(orb). Thus, any operations on the stub made before the ORB connection is made will fail.

The Java Language to IDL Mapping Specification says the following about the Stub.connect() method:

For servants that are not POA-activated, Stub.connect(orb) is necessary as a required setup.

Restrictions When Running RMI Programs Over IIOP

1. Make sure all constant definitions in remote interfaces are of primitive types or String and evaluated at compile time.
2. Don't use Java names that conflict with IDL mangled names generated by the Java to IDL mapping rules. See section 28.3.2 of the Java Language to IDL Mapping specification for the Java to IDL name mapping rules.
3. Don't inherit the same method name into a remote interface more than once from different base remote interfaces.
4. Be careful when using names that differ only in case. The use of a type name and a variable of that type whose name differs from the type name only in case is supported. Most other combinations of names that differ only in case are not supported.
5. Don't depend on runtime sharing of object references to be preserved exactly when transmitting object references across IIOP. Runtime sharing of other objects is preserved correctly.
6. Don't use the following features of RMI:
   • RMISocketFactory
   • UnicastRemoteObject
   • Unreferenced
   • The Distributed Garbage Collection (DGC) interfaces

Other Things You Should Know

Servers Need to be Thread Safe

Interoperating with Other ORBs

NOTE: Although it is true that ORBs written in different languages should be able to talk to each other, we haven't tested the interoperability of the Java ORB with other vendor's ORBs.

When do I use UnicastRemoteObject vs PortableRemoteObject?

Use UnicastRemoteObject as the superclass for the object implementation in RMI programming, which are scenarios where a distributed application is developed in a homogeneous Java environment and JRMP is used as the remote invocation mechanism. Use PortableRemoteObject when developing distributed applications where IIOP is the desired invocation mechanism, which provides a more standardized invocation substrate and allows interoperability with non-Java distributed application components. RMI-IIOP provides interoperability with distributed application components that are based on the OMG CORBA standards, and are developed in Java and other languages, such as C, C++, and Python.

A Java server component can also be structured to provide dual export of its services over both JRMP and IIOP simultaneously by designing the server to provide dual stack interoperability. Structure the server application component to use the exportObject methods of UnicastRemoteObject and PortableRemoteObject to "register" the service objects, which can then be invoked using JRMP and IIOP respectively. With this approach, distributed application developers use the exportObject method instead of inheritance to export their application objects. A server object that calls the PortableRemoteObject.exportObject() method to make its services available typically publishes a name for that object in the CosNaming service. A server object exported by the UnicastRemoteObject.exportObject() method typically has its name published in the rmiregistry, which provides a default naming service for RMI /JRMP (java.rmi.Naming).

The JMX framework provides this form of remote call duality.

Known Problems

• JNDI 1.1 does not support java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory as an Applet parameter.  Instead, it must be explicitly passed as a property to the InitialContext constructor. This capability is supported in JNDI 1.2.
• When running the Naming Service on Solaris, you must use a port number greater than 1024.
• On Solaris, you may experience an "out of file descriptors" problem when running RMI-IIOP applications.  This may occur if you are using too many file descriptors, which can happen because each JAR file in the classpath consumes one file descriptor and the JDK setup adds numerous JAR files to the classpath.  Before running applications, set the file descriptor limit to a number greater than its default value of 64.  For example, set the ulimit number to 90 or higher, as follows:

• ulimit -n 90
  

Background Reading

• The RMI-IIOP home page contains links to RMI-IIOP documentation, sample code, specifications, news, other related web sites, and more. Check it out!
• The RMI-IIOP Tutorial gives a step-by-step example for creating and running a simple RMI-IIOP application.
• The Java RMI home page contains links to RMI documentation, examples, specification, and more. Make sure you read this.
• The RMI trail in the Java Tutorial.
• The RMI API documentation.
• The Java IDL web page will familiarize you with Oracle's CORBA/IIOP implementation.
• The Java IDL Tutorial is the newest version of the IDL trail from the Java Tutorial.
• The Java Language to IDL Mapping, ptc/00-01-06 document is a detailed technical specification of RMI-IIOP. For further information on how the specification is implemented in this version of Java SE, see the compliance document.

---

Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.

Contact Us