The Community OpenORB - RMIoverIIOP

Chris Wood

Jerome Daniel

Michael Rumpf


Table of Contents

Introduction
History
Future
How to get involved
User
Technical Writer
Developer
1. Overview
2. Compilation
3. Installation
4. Configuration
5. Deployment
RMI over IIOP Tutorial
Testing RMI over IIOP for OpenORB
RMI over IIOP survival notes !
Java to IDL Tool reference
6. Frequently Asked Questions
A. Appendix

List of Tables

1. Release History

Introduction

History

The Community OpenORB has its roots in the Distributed Object Group's JavaORB, a pure-Java, open-source CORBA ORB.

The JavaORB project was initiated by Jerome Daniel in October 1998. Only six months later, in April 1999, version 1.0 was released. In the same month he founded the Distributed Object Group (DOG) together with Xavier Blanc, Nicolas Charpentier, and Vincent Vallee. In May 1999 negotiations with ExOffice Technologies, Inc., about a strategic partnership started for cooperatively developing new versions of the JavaORB project. In July 1999 version 2.0 of the JavaORB was released. During the following months several CORBA services and various enhancements to the JavaORB's core were added. In February 2000 Olivier Modica joined the DOG team and until May 2000 the whole DOG became part of ExOffice Technologies, Inc., Around the same time Chris Wood, an employee aith ExOffice Technologies, Inc., joined the team. In June 2000 the company ExOffice Technologies, Inc., was renamed to Intalio, Inc., In July 2000 the DOG at Intalio, Inc., was extended by another member, Marina Daniel. [1]. The whole team was working on a new version of the JavaORB which was later renamed to OpenORB. After several months of in-house development OpenORB was released at www.openorb.org.

Table 1. Release History [2]

VersionRelease Date
1.0.0February 5th 2001
1.0.1March 9th 2001
1.1.0May 8th 2001
1.2.0August 15th 2001
After nine months the OpenORB project had proven to be successful. Public visibility was increasing steadily and the community had grown to a respectable size.

Then the dot.com bubble bursted and many companies, incl. Intalio, Inc., had to focus on their core business, in order to survive. It became obvious to the community that the project is going to drown with the dot.com bubble as the traffic on the mailing list was fading steadily. That was the time when a few OpenORB community members decided to get more involved into the project. The movement was led by Steve McConnell and Michael Rumpf. The problem was trying to get Intalio to turn the OpenORB project into a real, i.e. community driven, open-source project after the example of many Apache projects. Unfortunately the strategy of getting Intalio into the boat was not successful. The consequence was a fork of the OpenORB project at SourceForge the Community OpenORB. The new project was founded by Steve McConnell, Michael Rumpf, Shawn Boyce, Jesper Pedersen, J. Scott Evans, and Viacheslav Tararin on January 8th 2002.

Soon after the formation of the Community OpenORB project version 1.2.1 of the OpenORB suite was released on January 11th 2002. This version included many bug-fixes over the Intalio source base that had been released on August 15th 2001 for the last time.

On June 8th 2002, Ashish Agrawal, VP. of Engineering at Intalio, Inc., send a mail to the open-source communities of the various projects that had been sponsored by Intalio over the past [3]. The part about OpenORB was: "We support the project on Sourceforge and recommend any contributors to contribute to this project. OpenORB will no longer be hosted on Exolab."

Since the beginning of the Community OpenORB project substantial changes have been made to the source base. Since early 2002 the circle of active developers grew to over 10, not including the people contributing patches eventually. The number of users, subscribed to the openorb-user mailing-list, grew to over 100, the downloads have passed 15.000. On September 30th version 1.3.0 was released to the community.

Future

We are working to make OpenORB a part of the Apache project. We have already adopted the Apache community rules [4] and we are just waiting for the current copyright holder, Intalio, Inc., to donate the source base to the Apache Foundation. Once the politics are completed we will move the project over to the Apache facilities making OpenORB a full member of the Apache Software community.

Independently of these efforts we are trying to make OpenORB the best open-source CORBA ORB around. In order to achieve this goal we need your help. Either if you are a user, a technical writer, or a developer we will appreciate any help.

As a user you could help by answering other users's questions, by proposing new features, or by submitting bug reports.

Open-source projects often lack high quality documentation. New users depend on good documentation and it definitely helps to reduce the traffic on the user mailing-list. So if you are good at writing documentation you are extremely welcome to join the team.

As a developer you can help by doing the usual things: fix bugs, add new features, write test-cases, improve the build-system, or any other task of which you think should be improved.

This leads to the question: "How do I get involved?"

How to get involved

User

Although we are permanently trying to improve the documentation you may have problems using OpenORB. In these cases you should follow the steps below:

  • Read this documentation and any related documentation carefully.

  • Search this module's FAQ and any related FAQs for answers to your questions.

  • Search the openorb-user mailing list archive

  • If your question is more of a general CORBA question, then you should also search the following newsgroup archives for answers: comp.object.corba, comp.lang.java.corba .

  • If your problem can't be solved by any of the steps above, then send a question to the openorb-users mailing-list. For spam protection the mailing-list has been restricted to subscribed members only. Therefore you need to subscribe to the mailing-list before you can send your question. In order to receive qualified responses it is important that your submission also passes a certain level of quality, i.e. include information like OS version, JDK version, OpenORB module version, exception stack traces, or any other information that might be useful to analyze the problem.

As an OpenORB user you are invited to share your knowledge with other community members when they are having problems. When you know the answer to another user's question feel free to respond to it. Doing so will help the developers, working on new features or fixing bugs, to concentrate on these tasks. A vital community is a fundametal requirement for OpenORB becoming an Apache project.

Technical Writer

As a technical writer you should be subscribed to the most important mailing lists: openorb-users and openorb-devel. The questions sent to the openorb-users mailing-list are a good indicator of which part of the documentation needs to be improved. The openorb-devel list is for internal development of the OpenORB modules and thus any discussion about writing documentation for OpenORB should go here.

Documentation for the OpenORB modules is divided into two major parts, the docbook documentation and the Javadoc documentation. The docbook documentation is created from XML files adhering to the docbook-xml standard [5]. The second part is the Javadoc documentation that is used for internal and external API documentation. Writing documentation includes fixing or writing Javadoc comments, extending the docbook manual, and adding FAQ items.

Developer

As a developer you should be subscribed to both mailing lists: openorb-users and openorb-devel. Any proposal for a new feature should be sent to the openorb-devel mailing list and will be discussed by the members of these lists . As a developer you should know what the user thinks of a certain feature and therefore subscription to the openorb-user mailing list is substantial. Another mailing-list that might be of interest to a developer is the openorb-commits mailing-list. The CVS server is sending the diffs of each cvs commit to this mailing-list. These notification mails keep you informed about what is going on and it supports improving code quality because other members of the list can instantly review any patch that is committed to the CVS tree.



[5] Currently only HTML documentation is created from the XML source files. The PDF generation has recently been disabled because the current Apache FOP implementations, both stable and dev, are having problems with the latest version of the docbook-xml and docbook-xsl combination.

Chapter 1. Overview

This document provides all information to run RMI over IIOP for OpenORB. In particular, it explains how to install, configure and test RMI over IIOP for OpenORB.

Then, this document provides a reference for the tools provided with this OpenORB extension. Finally, this document also explains how to develop an RMI application using RMI/IIOP.

To get the lastest information about OpenORB, its extensions and services, don't hesitate to frequently visit the OpenORB web site (openorb.sf.net) and/or to subscribe to the OpenORB mailing list.

This OpenORB extension is a fully compliant implementation of the RMI/IIOP OMG specification. Extension means that all existing applications could use this extension without having to be rebuilt !

Thanks to this extension, it could be possible to run any RMI application over CORBA in a completely transparent way. It means that your RMI applications exchange messages through IIOP, take advantage of CORBA scalability and reliability. Moreover, by using IIOP your RMI applications could be invoked from any programming language ( compliant with CORBA ) : for example a C++ applications !

This extension provides an utility called JavaToIdl which has the ability to generate an IDL description from a Java class and to generate stubs and skeletons for Java classes. This extension also provides a JNDI connector to bind your RMI object into the CORBA naming service.

Chapter 2. Compilation

It is assumed that OpenORB is previously installed on your system. The OpenORB ( openorb-{version}.jar ) and Tool ( openorb_tools-{version}.jar ) jar files must be added into your classpath.

Then, to build OpenORB RMI over IIOP :

  • set the JAVA_HOME env variable

  • start 'build.bat' ( for Windows ) or 'build.sh' ( for Unix )

if you want to see all build options, enter 'build help' ( 'build.sh help' for Unix ).

OpenORB RMI over IIOP is then built. The build process creates the Jar files, the examples and the tests. All of these elements are created in the 'dist' directory ( itself created by the build process ).

Chapter 3. Installation

This chapter explains how to install RMI over IIOP for OpenORB. We remind you that OpenORB is required and must be previously installed before you proceed to the next steps.

How to get RMI over IIOP for OpenORB ?

To get this OpenORB extension, please visit the Community OpenORB web site ( openorb.sf.net ). Then, go to the download section. Follow the instructions to download the RMIoverIIOP extension.

How to compile RMI over IIOP for OpenORB ?

The RMI over IIOP distribution contains an Ant script that can be used to generate it. Several dependances are required and located in the lib directory. If you use the build.bat ( for windows ) or build.sh ( for unix ) all dependances and required classpath are directly used.

Thus, to compile RMI over IIOP for OpenORB, we advise you to enter the following command from the command line: build or build.sh

How to configure RMI over IIOP for OpenORB ?

You have just to add in your classpath the OpenORB RMI over IIOP Jar file : openorb_rmi-x.y.z.jar.

The configuration file named rmi.xml is embedded in the Jar file. It is automatically used by the RMI over IIOP engine. It means that you have no special configuration to set in order to run an RMI application with OpenORB.

In addition, all required IDL files are also embedded in the Jar file. It means that the RMI over IIOP compiler will be able to retrieve all needed descriptions without any other configuration.

How to complete the configuration ?

To complete the configuration, we are going to replace the embedded OpenORB configuration by the new one. For that purpose, please refer to the OpenORB Programmer Guide.

How to configure the JDK to use RMI over IIOP for OpenORB ?

For using OpenORB with JDK 1.2.x or 1.3.x you have to provide an ORB.properties file that contains some information to load OpenORB.

For using RMI over IIOP for OpenORB, you have to provide some additional information into ORB.properties. More precisely, you have three additional properties to set :

javax.rmi.CORBA.StubClass=org.openorb.rmi.system.StubDelegateImpl
			javax.rmi.CORBA.UtilClass=org.openorb.rmi.system.UtilDelegateImpl
			javax.rmi.CORBA.PortableRemoteObjectClass=org.openorb.rmi.system.PortableRemoteObjectDelegateImpl

Chapter 4. Configuration

Chapter 5. Deployment

RMI over IIOP Tutorial

This tutorial is divived into several steps that provide an overview of what is important to know to write RMI applications. All source code used for this tutorial is available in the examples directory of the distribution.

A first application : Hello world !

The source code of this first example is available in examples/hello. First, let's have a look at the remote interface description in the RemoteEcho.java file.

            package hello;

			interface RemoteHello extends java.rmi.Remote
			{
	  		    public void print( String message )
			    throws java.rmi.RemoteException;
			}
            

RMI over IIOP does not require additional rules to define remote interfaces:

  • Each remote interface has to inherit directly or indirectly from java.rmi.Remote
  • Each method has to throw the java.rmi.RemoteException

To implement a remote interface there is no specific requirement from RMI over IIOP. However, the server class which starts the application has to inherit from javax.rmi.PortableRemoteObject. Moreover, JNDI must be used to bind and to resolve an object reference.

The following source code implements the above interface.

            package hello;

			import javax.naming.InitialContext;

			public class HelloServer
			    extends javax.rmi.PortableRemoteObject
			    implements RemoteHello
			{
			    public HelloServer()
                    throws java.rmi.RemoteException
			    { }
			    public void print( String message )
			        throws java.rmi.RemoteException
			    {
			        System.out.println( message );
			    }
			    public static void main(String args[])
			    {
        	        try
			        {
                        java.util.Properties env =
			                new java.util.Properties ();
         	            InitialContext context = new InitialContext(env);
			            HelloServer helloObj = new HelloServer();
			            context.bind("hello", helloObj );
			        }
			        catch ( Exception ex )
			        {
			            ex.printStackTrace();
			            System.out.println(ex.getMessage());
			        }
			    }
			}
            

Now, we have to compile this application : javac *.java

To be used with RMI over IIOP, the RMI object needs to have a skeleton ( for the server side ) and a stub ( for the client side ). To generate the skeleton and the stub, we have to use a dedicated tool provided with RMIoverIIOP for OpenORB.

This tool named JavaToIdl, provides the following features :

  • create a stub and a skeleton for a remote interface
  • create an IDL description for a remote interface

For this example, we are going to generate the stub, the skeleton and no IDL description ( see the next example to know how to generate and how to use an IDL interface for a remote interface ). To generate these artifacts, use the following command line: java org.openorb.rmi.compiler.JavaToIdl -tie -stub -noidl hello.RemoteHello

Note

To be able to run the above command, don't forget to set into the classpath a way to find the hello.RemoteHello interface.

Now, two files have been generated:

  • _RemoteHelloTie.java which is the skeleton
  • _RemoteHelloStub.java which is the stub

Now, we have to compile these files... javac *.java The last step of this example is to write a client application.

            package hello;

			import javax.naming.InitialContext;

			public class HelloClient
			{
			    public static void main(String args[])
			    {
			        try
			        {
			            InitialContext context = new InitialContext();
			            Object obj = context.lookup ("hello");
			            RemoteHello hello = ( RemoteHello ) javax.rmi.PortableRemoteObject.narrow(obj, RemoteHello.class);
			            hello.print("Hello world !");
			        }
			        catch ( java.lang.Exception ex )
			        {
			            ex.printStackTrace();
			        }
			    }
			}
			

The above bold line is a very important rule in the RMI over IIOP specification :

All casts must be replaced by a call to the javax.rmi.PortableRemoteObject.narrow(...)

After the compilation of the previous class, we have to run the example. First, the CORBA Naming Service must be started ( see your OpenORB documentation ).

To run this application, several elements must be taken into account :

  • to supply the OpenORB profile name that contains the RMI configuration parameters
  • to supply the system property to specify the JNDI SPI to use

Indeed, the RMI applications use JNDI to bind the provided object. For RMI over IIOP, a special JNDI SPI must be used in order to bind supplied objects in the CORBA naming service. To specify such a JNDI SPI, the system property to set is java.naming.factory.initial. In the case of RMI over IIOP for OpenORB, the value to supply is org.openorb.rmi.jndi.CtxFactory. Thus, the command line is :

To start the server: java -Djava.naming.factory.initial=org.openorb.rmi.jndi.CtxFactory hello.HelloServer

To start the client: java -Djava.naming.factory.initial=org.openorb.rmi.jndi.CtxFactory hello.HelloClient

A CORBA client for the previous RMI object The first step is to generate the IDL description for the RMI object : java org.openorb.rmi.compiler.JavaToIdl hello.RemoteHello

Note

Please, consult the Java To IDL specification to get the rules used to generate an IDL description from a RMI remote interface.

The CORBA client application is very simple :

  • it creates an ORB instance,
  • it resolves the remote object from the naming service,
  • it narrows the remote reference to the hello.RemoteHello IDL interface,
  • then it uses the remote object.

Here is the source code :

            public class HelloClient

			{
			    public static void main( String [] args )
			    {
			        System.out.println("Hello from CORBA...");
			        org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
			        org.omg.CosNaming.NamingContext naming = null;
			        try
			        {
			            org.omg.CORBA.Object obj =
			                orb.resolve_initial_references("NameService");
			            naming = org.omg.CosNaming.NamingContextHelper.narrow( obj );
			        }
			        catch ( org.omg.CORBA.ORBPackage.InvalidName ex )
			        { }
			        try
			        {
			            org.omg.CosNaming.NameComponent [] name = new
			            org.omg.CosNaming.NameComponent[ 1 ];
			            name[0] = new org.omg.CosNaming.NameComponent("hello","");
			            org.omg.CORBA.Object obj = naming.resolve( name );
			            hello.RemoteHello rmi = hello.RemoteHelloHelper.narrow( obj );
			            rmi.print("Hello World !");
			        }
			        catch ( java.lang.Exception ex )
			        {
			            System.out.println("Exception : " + ex.toString() );
			            System.exit(0);
			        }
			    }
			}
            

Testing RMI over IIOP for OpenORB

To test RMI over IIOP, you have to compile the test scripts provided with the distribution, it means to run the Ant script with the test keyword.

The tests provided with the distribution are developed to be run with JUnit. These tests check several aspects of the specification :

  • the exchange of primitive data types ( boolean, char, byte, .... ) and array of these primitive data types,
  • the exchange of complex data types ( string, vector, object, class, ... ),
  • the usage of special methods : serialization, ...

To apply the tests, please enter the following command : java org.openorb.rmi.test.RMIoverIIOPTest -execute

Note

The xxxx must be replaced by your profile name that includes the 'rmi' module. In addition, the CORBA naming service must be running.

RMI over IIOP survival notes !

To be able to use RMI over IIOP, there are few rules to know but they are very important.

How to cast an object reference ?

It is not possible to directly use a java cast to cast a remote reference to an interface type. The RMI over IIOP specification requires to use the javax.rmi.PortableRemoteObject.narrow operation to cast a reference.

How to activate or deactivate a RMI object ?

To activate an object, it means to export a RMI object to RMI over IIOP ( as a CORBA object ), you have to use the javax.rmi.PortableRemoteObject.exportObject operation.

In the same way, to deactivate an object, i.e. to un-export a RMI object, you have to use the javax.rmi.PortableRemoteObject.unexportObject operation.

Java to IDL Tool reference

The JavaToIdl tool is a very important piece of the RMI over IIOP extension. This tool provides two main features :

  • generates an IDL description for a Java class
  • generates the stub and the skeleton for a Java class

It is very important to understand how to use this tool, because its usage is a mandatory step in the development process of a RMI application over IIOP.

To run this tool, please enter the following command : java org.openorb.rmi.compiler.JavaToIdl

Note

To be able to correctly run this tool, your OpenORB.xml file must be configured with RMI over IIOP information as explained in the 'How to configure OpenORB for using RMI over IIOP' chapter.

The Java To IDL options can be seen by executing the tool without parameters.

Chapter 6. Frequently Asked Questions

Set

6.1. ?
6.1.

?

!

Appendix A. Appendix