Forte for Java: RMI Module
Requirements

Version: 0.1
Author: Martin Ryzl, Sun Microsystems/NetBeans

Abstract:
This document briefly describes the requirements for RMI (Remote Method Invocation) module. This module adds support for developing RMI (and RMI over IIOP) applications into the IDE. Remote Method Invocation is a standard Java extension that makes possible to access Java objects remotely.
Document History:
[04/08/2000] : version 0.1 : First version of the document
Contents:
1. Introduction
2. Presentation in the explorer
3. RMI Specific Compilation
4. RMI Specific Execution
5. RMI Registry Browser
6. New RMI Objects Creation
6.1 Wizard
6.2 Templates
6.3 Other

1. Introduction

RMI (Remote Method Invocation) is a standard Java extension that possibilty to access objects in another JVM on another computer. A remote object must implement remote interface. Remote interface is interface that extends java.rmi.Remote and all its methods must be remote methods. It means that all parameters and return types must be serialiable and the method must throw either java.rmi.RemoteException or some of the superclass of RemoteException (java.io.IOException, java.lang.Exception).

There are some predefined implementations of the remote object that may be extended. The first one is java.rmi.server.UnicastRemoteObject. It is an implementation that provides point-to-point TCP/IP connection. The second one is java.rmi.activation.Activatable which provides implementation with lazy actiovation. It means that activatable object is registered in activation system and it is instantiated and exported when it is requested for the first time. Since jdk1.3 javax.rmi.PortableRemoteObject is available to the user. It provides RMI over IIOP functionality.

Parameters of the remote call are passed by value. If the parameter implements Remote, it is passed by reference. Classes for types that are used by the remote interface must be presented at client, the rest can by dynamicaly downloaded.

RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements. In the JDK 1.2 an additional stub protocol was introduced that eliminates the need for skeletons in Java 2 platform-only environments. Instead, generic code is used to carry out the duties performed by skeletons in JDK 1.1. Stubs and skeletons are generated by the rmic compiler.

The RMI system uses the java.rmi.registry.Registry interface and the java.rmi.registry.LocateRegistry class to provide a well-known bootstrap service for retrieving and registering objects by simple names. A registry is a remote object that maps names to remote objects. Any server process can support its own registry or a single registry can be used for a host.

2. Presentation in the explorer

Remote implementation, stub and skeleton will appear as a one node in the explorer.

3. RMI Specific Compilation

RMI specific compilation adds stub/skeleton generation. It is done by rmic compiler and necessary parameters are destination folder and class for which stubs/skeletons should be generated. Compilation provided by the RMI module should also detect innerclasses that implements a remote interface and generate stubs/skeletons for them as well.

4. RMI Specific Execution

Remote methods may be invoked by code that runs in another JVM, possibly on untrusted host. Thus, it is necessary to set an appropriate security manager. Such implementation of remote object should be run using JVM with corresponding security policy. RMI Specific execution should also set all parameters that are required by dynamic class downloading via internal http server (java.rmi.server.codebase and java.rmi.server.hostname).

5. RMI Registry Browser

RMI uses rmiregistry for bootstraping the remote object. RMI registry stores pairs - name and reference to a remote object. RMI Registry Browser should make possible to browse an RMI registry, display list of all registered remote objects and possibly show remote interfaces of the registered remote object. Also there should be a possibility to start an RMI Registry inside the IDE. Note: only one instance of RMI Registry is allowed inside one JVM. The reason is that every rmi service is characterized by host, port and unique object ID in the JVM. RMI Registry as a well know service has assigned well-known object ID.

6. New RMI Objects Creation

There should be some mechanisms that makes possible to create a new RMI application in an easy way. It could be done by wizards, templates or special code generator.

6.1 Wizard

RMI Wizard should assist to user when creating a new application. It should be possible to create a new remote interface, add remote methods and finally to select an appropriate implementation of the remote object. The wizard should be configurable so that the user would be able to generate customized code.

6.2 Templates

Another method how to create a new applicatio are templates. There should be templates for remote interface, simple client and following implementations: plain implementation that is used mainly for callbacks, implementation based on UnicastRemoteObject, implementation based on Activatable and implementation for RMI over IIOP. It should be also possible to use group templates for creating whole RMI application in one click.

6.3 Other

A very good idea is to generate code that makes possible to create lookup code from already registered service. Such an action should be available in RMI Browser and lookup code could be generated in clipboard. User then can paste lookup code into client code.