# RMI-IIOP Programmer's Guide

# Copyright information

Note: Before using this information and the product it supports, be sure to read the general information under Notices.

This edition of the RMI-IIOP User Guide applies to the RMI-IIOP, as described below, and to all subsequent releases, modifications, and Service Refreshes, until otherwise indicated in new editions.

(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.

(c) Copyright International Business Machines Corporation, 1999, 2005. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

# Preface

This document discusses how to write Java(TM) 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 (see Restrictions when running RMI programs over IIOP), your RMI programs can access CORBA objects. RMI-IIOP gives you RMI ease-of-use coupled with CORBA/IIOP language interoperability.

# Contents

Copyright information
Preface
Background reading
What is RMI-IIOP?
RMI
IIOP, CORBA, and Java IDL
RMI-IIOP
The rmic compiler
The idlj compiler
How to make RMI programs use IIOP
Connecting IIOP stubs to the ORB
Restrictions when running RMI programs over IIOP
Other things you should know
Servers need to be thread safe
Interoperating with other ORBs
When do I use UnicastRemoteObject vs PortableRemoteObject?
Known problems
Notices
Trademarks

# Background reading

Here are some sites to get you up to speed with this technology:

- 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 Javadoc HTML contains the most up-to-date RMI API documentation.
- The Java IDL web page will familiarize you with Sun's CORBA/IIOP implementation.
- The Java IDL Trail in the Java Tutorial.

# What is RMI-IIOP?

## RMI

With RMI, you can write distributed programs in the Java programming language. RMI is easy to use, you do not need to learn a separate interface definition language (IDL), and you get Java's inherent "write once, run anywhere" benefit. Clients, remote interfaces, and servers are written entirely in Java. RMI uses the Java Remote Method Protocol (JRMP) for remote Java object comunication. To get a quick introduction to writing RMI programs, see the RMI tutorial web page, which describes writing a simple "Hello World" RMI program.

RMI lacks interoperability with other languages, and, because it uses a nonstandard communication protocol, cannot communicate with CORBA objects.

## IIOP, CORBA, and Java IDL

IIOP is CORBA's communication protocol. It defines the way bits are sent over a wire between CORBA clients and servers. CORBA is a standard distributed object architecture developed by the Object Management Group (OMG). Interfaces to remote objects are described in a platform-neutral interface definition language (IDL). Mappings from IDL to specific programming languages are implemented, binding the language to CORBA/IIOP.

The Java 2 Platform, Standard Edition (J2SE) V5.0 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

Previously, Java programmers had to choose between RMI and CORBA/IIOP (Java IDL) for distributed programming solutions. Now, by adhering to a few restrictions (see Restrictions when running RMI programs over IIOP), RMI server objects can use the IIOP protocol, and communicate with CORBA client objects written in any language. This solution is known as RMI-IIOP. RMI-IIOP combines RMI ease of use with CORBA cross-language interoperability.

## The rmic compiler

The RMI-IIOP software comes with an rmic compiler that can generate IIOP stubs and ties and emit IDL, in accordance with the Java Language to OMG IDL Language Mapping Specification.

The rmic options that provide support for RMI-IIOP are:

-iiop

  Using rmic with the -iiop option generates stub and tie classes. A stub class is a local proxy for a remote object. Clients use stub classes to send calls to a server. Each remote interface requires a stub class, which implements that remote interface. The client's reference to a remote object is a reference to a stub. Tie classes are used on the server side to process incoming calls, and dispatch the calls to the proper implementation class. Each implementation class requires a tie class.

  Stub classes are also generated for abstract interfaces. An abstract interface is an interface that does not extend java.rmi.Remote, but has methods that 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.

-iiop -poa

  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 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 that are invoked by the POA itself and may be overridden by the user to control aspects of servant behavior.

-idl

  Using rmic with the -idl option generates OMG IDL for the classes specified and any classes referenced. This option is required only if you have a CORBA client written in another language that needs to talk to a Java RMI-IIOP server.

  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 of 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. Java and C++ are such languages. For a complete description, see the Java Language to OMG IDL Mapping Specification.

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

  Forces regeneration even when existing stubs, ties, or IDL are newer than the input class. Valid only when -iiop or -idl options are present.

-noValueMethods

  The -noValueMethods option ensures that methods and initializers are not included in valuetypes emitted during IDL Generation. These are optional for valuetypes and are otherwise omitted. Only valid when used with -idl option.

-idlModule<fromJavaPackage<.class>> <toIDLModule>
  Specifies IDLEntity package mapping. For example:

      -idlModule foo.bar my::real::idlmod

  Only valid when used with -idl option.

-idlFile <fromJavaPackage<.class>> <toIDLModule>
  Specifies IDLEntity file mapping. For example:

      -idlFile test.pkg.X TEST16.idl

  Only valid when used with -idl option.

For more detailed information on the rmic compiler, refer to the RMIC tool page (Solaris Version/Windows version).

## The idlj compiler

The RMI-IIOP software includes an IDL-to-Java compiler. This compiler supports the CORBA Objects By Value feature, which is required for interoperation with RMI-IIOP. It is written in Java, and so can run on any platform. See the IDL-to-Java Compiler User's Guide for details of how to use this compiler.

## How to make RMI programs use IIOP

The following steps are a general guide to converting an RMI application to RMI-IIOP.

1. If you are using the RMI registry for naming services, you must to switch to CosNaming:
   1. In both your client and server code, create an InitialContext for JNDI using the following code:

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

   2. Modify all uses of RMI registry lookup(), bind(), and rebind() to use JNDI lookup(), bind(), and rebind() 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 plug-in. Replace the above code with:

          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 must have some other way of bootstrapping your initial remote object reference. For example, your server code might 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. When doing this in RMI-IIOP, you must also ensure that object references are connected to an ORB before serialization and after deserialization. The following code example shows how to do this.

   On the server side, use the PortableRemoteObject.toStub() call to obtain a stub, then use writeObject() to serialize this stub to an ObjectOutputStream. If necessary, use Stub.connect() to connect the stub to an ORB before serializing it. 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. Before using the deserialized stub to call remote methods, it must be connected to an ORB. You could do this 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);

   As you can see, the JNDI approach is much simpler, so use it whenever possible.

3. Either change your remote implementation classes to inherit from javax.rmi.PortableRemoteObject, or explicitly to 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. Do not depend on distributed garbage collection (DGC) or use any of the RMI DGC facilities. Use PortableRemoteObject.unexportObject() to make the ORB release its references to an exported object that is 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:

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

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

       tnameserv

   The CosNaming server uses the default port number of 2809. If you want to use a different port number, run tnameserv with the -ORBInitialPort parameter, for instance:

       tnameserv -ORBInitialPort 1050

8. When starting client and server applications, specify these system properties:

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

   This example uses the default name service port number of 2809. If you specified a different port in step 8, 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 these properties in the applet tag:

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

   This example uses the default name service port number of 2809. If you specified a different port in step 8, you must 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.

## Connecting IIOP stubs to the ORB

When your application uses IIOP stubs, as opposed to JRMP stubs, you must properly connect the IIOP stubs with the ORB before invoking operations on the IIOP stubs (this is not necessary with JRMP stubs). This section discusses the extra 'connect' step required for the IIOP stub case.

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. The servant instance is created when a PortableRemoteObject constructor is called as a base class. This is known as implicit invocation.

Later, when the application calls PortableRemoteObject.toStub(), the ORB creates the corresponding Stub object and associates it with the cached Tie object. But because 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 OMG IDL Mapping Specification says this about the Stub.connect() method:

"The connect method makes the stub ready for remote communication using the specified ORB object orb. Connection normally happens implicitly when the stub is received or sent as an argument on a remote method call, but it is sometimes useful to do this by making an explicit call (e.g., following deserialization). If the stub is already connected to orb (i.e., has a delegate set for orb), then connect takes no action. If the stub is connected to some other ORB, then a RemoteException is thrown. Otherwise, a delegate is created for this stub and the ORB object orb."

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

## Restrictions when running RMI programs over IIOP

To make existing RMI programs run over IIOP, observe the following restrictions.

1. Make sure all constant definitions in remote interfaces are of primitive types or String and evaluated at compile time.
2. Do not 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 OMG IDL Mapping Specification for the more information.
3. Do not inherit the same method name into a remote interface more than once from different base remote interfaces.
4. Be careful when using names that are identical other than their case. The use of a type name and a variable of that type with a name that differs from the type name only in case is supported. Most other combinations of names that are identical other than their case are not supported.
5. Do not 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. Do not use the following features of RMI, which do not work in RMI-IIOP:
   - RMISocketFactory
   - UnicastRemoteObject
   - Unreferenced
   - The Distributed Garbage Collector (DGC) interfaces

# Other things you should know

## Servers need to be thread safe

Because remote method invocations on the same remote object might execute concurrently, a remote object implementation must be thread-safe.

## Interoperating with other ORBs

RMI-IIOP should interoperate with other ORBS that support the CORBA 2.3 specification. It will not interoperate with older ORBs, because older ORBs cannot handle the IIOP encodings for Objects By Value. This support is needed to send RMI value classes (including strings) over IIOP.

Note:
Although ORBs written in different languages should be able to interoperate, the Java ORB has not been fully tested with other vendors' ORBs.

## When do I use UnicastRemoteObject vs PortableRemoteObject?

Use UnicastRemoteObject as the superclass for the object implementation in RMI programming. Use PortableRemoteObject in RMI-IIOP programming. If PortableRemoteObject is used, you can switch the transport protocol to either JRMP or IIOP during runtime.

## 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 Unix based platforms, you must use a port number greater than 1024. The default port is 2809, so should cause no problems.

# Notices

This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

- IBM Director of Licensing
  IBM Corporation
  North Castle Drive, Armonk
  NY 10504-1758 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

- IBM World Trade Asia Corporation Licensing
  2-31 Roppongi 3-chome, Minato-ku
  Tokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the information. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this information at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose of enabling (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

- JIMMAIL@uk.ibm.com
  [Hursley Java Technology Center (JTC) contact]

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

## Trademarks

IBM is a trademark of International Business Machines Corporation in the United States, or other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft, Windows and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.