Open Hypermedia Systems Working Group

Beans, RMI, Voyager

This document is organised as follows:

1. What is RMI?
2. What is RMI not?
3. RMI architecture
   1. Definition - how is a remote class defined?
   2. Naming - how is a remote class located?
   3. Transport - how are arguments and results passed back and forth?
   4. Security - what security measures exist?
   5. Transparency - how tranparent is it in use?
4. The RMI future

Remote Method Invocation (RMI) is a lightweight Java ORB architecture, written to provide easy access to objects existing on remote virtual machines. Once a reference to a remote object has been obtained, it can be treated almost as local objects. RMI performs the marshalling, transportation and garbage collection of remote objects transparent to the programmer, making it very easy to write distributed Java programs.

RMI became a part of the Java Development Kit starting from version 1.1.

RMI is not a general purpose ORB with global applicability. It is a Java-only technology and is as such not a direct competitor to Corba or DCOM which are not limited to one language.

In any ORB architecture there are several issues that must be dealt with. In the following the RMI approach to these issues will be described.

Rather than having a special purpose interface definition language such as IDL, interfaces to remote objects are defined using ordinary Java interfaces, a benefit of RMI being Java-only. The limitations on the remote interface are that it must:

• be public (there really wouldn't be much point in a server with no public methods),
• extend the interface java.rmi.Remote to signify that it is a remote interface,
• let all its methods declare java.rmi.RemoteException in their throw clauses,
• let all references to remote objects be references to the interface, not the implementation of the remote object.

• implement at least one remote interface,
• provide a constructor for a remote object (usually this means extending java.rmi.server.UnicastRemoteObject, which has the desired functionality),
• install a security manager (more on this in security),
• create at least one instance of a remote object (for instance itself),
• and register at least one of these remote objects with the RMI remot object registry (more on this in Naming).

The java.rmi.server.UnicastRemoteObject provides the required behaviour for a remote object. While RMI in the future will allow replicated remote objects, UnicastRemoteObject is non-replicated and the only available in JDK1.1.4.

Just as important as being able to create remote objects is the ability to address them. This is in RMI done with a URL-based naming scheme on the form rmi://my.host.edu/myServer. The last part being the name of the remote object. The registration of object is done through the RMIRegistry, which must be running on the server. It is through RMIRegistry that clients are given access to remote objects on the server. RMIRegistry however does not seem to implement more advanced directory services, such as forwarding or distributed registries.

Currently RMI utilises Java serialisation of objects and 'JRMP' (Java Remote Method Protocol) to send objects back and forth between remote objects. An interesting feature of the transport layer is that it will initially try to establish an ordinary socket connection between client and host. If however that fails (due to e.g. firewall restrictions), it will try HTTP and if that fails too ultimately use a cgi-script on the server and POST the data.

The security measures in RMI are currently limited to the loading of classes, and the limitations imposed on objects running on the server. This is all handled by the RMI security manager. Java security managers are well known from Java applets, where they constitute the 'sandbox', wherein applets (usually downloaded from the Internet) are contained. In the context of RMI, classes are also often loaded from the network and cannot be trusted as classes from the local file system would be trusted. Indeed if no security manager has been setup, RMI will only load classes from the local file system. The by JavaSoft supplied security manager restricts loaded classes to only communicate through RMI, and disallows the ability to fork processes, manipulate other threads than their own, access the AWT event queue, read/write local files, nor access the system properties (such as the clipboard). Foreign RMI classes are thus just as if not more restricted than applets.

Whereas security with regards to loading and execution of remote objects is thus fairly strict, there do not seem to be provisions for secure sockets and any other on the wire encryption in the RMI standard.

One of the design goals of RMI was to provide the Java programmer with a tool allowing for the easy deployment and use of remote objects. The team behind RMI seem to have been successful in this aspect as remote objects, once a reference has been obtained, behave and are used just as ordinary local objects. The on the wire issues of sending back and forth of data are transparent to the programmer.

Despite some speculation on the contrary, RMI has not been replaced by Corba and IIOP, and will not be so, according to Sun. RMI became a part of JDK1.1, and it seems highly unlikely that it will be removed at later date. However RMI will certainly (according to JavaSoft) be extended in the future with the ability to use IIOP as transport protocol.

Please send feedback to Niels Olof Bouvin. Last modified: Mon Dec 15 01:19:47 1997