Remote Method Invocation (RMI)

General

RMI (Remote Method Invocation) is an Java API that allows for calling remote methods. Remote methods are methods that run in a JVM different from the one of the caller. Basically there are two different implementations: RMI/JRMP commonly just referred to as "RMI" and a CORBA compliant implementation called RMI-IIOP.

Purpose

One of the foremost purposes of RMI is transparency. Network communication is hidden from the application programmer. Calling remote methods thus (almost) does not differ from invoking local ones as far as programming is concerned.

Technical Overview

When the client invokes a remote method a so called stub on the client side marhalls the invokation and sends it to the actual server. There the data is demarshalled and the remote method is called. The return value takes the same way back. The stub serves as a proxy to the client hiding the fact that the actual server is remote.

Restrictions

Although transparency is indeed accomplished to a high degree the programmer will still notice that he deals with remote methods since certain restrictions apply:

• remote methods must be defined in a Remote Interface
• Remote Methods must throw a RemoteException
• Arguments to or return values of remote methdos must be either serializable (i.e. implementing the Serializable Interface), Strings, primitive types, or remote objects themselves.
• each of these except the remote objects are passed by value. That means objects or values are copied and changes in the copy will not reflect in the original
• there is a call overhead
• security issues have to be considered

Some further restriction apply only to the IIOP-implementation:

• there is no distributed garbage collection available
• there is no dynamic class loading available
• there are no custom socket transports available
• underscores in identifiers should be omitted to avoid name collisions with IDL
• IIOP does not support overloading

Implementing an RMI programm

The next few paragraphs will describe the basic steps of how to implement a simple RMI program

The Remote Interface

The Remote Interface simply defines methods that are supposed to be remotely available. The interface has to inherit from java.rmi.Remote, methods must throw a RemoteException, and there are some restrictions concerning the arguments and return values.

The Server

The Server then has to implement the just defined Remote Interface. It usually inherits from either java.rmi.server.UnicastRemoteObject or from java.rmi.activation.Activatable, the latter being able to start upon a clients call, whereas the former always has to be running.

The Stub

In order to be able to communicate with the server the client needs the server stub in its classpath. This stub is generated by the tool rmic, which is part of the Java SDK.

The Client

When the client has a reference to the server (either having received it from the registry or maybe from a user) it can easily invoke methods on that server. It only has to to add the exception handling to the invocation since all remote methods throw a RemoteExcepion dsdsd

Some further techniques

Serialization

Serialization is how Java marhalls objects. In order to make an object serializable the progammer has to have it implement the java.io.Serializable interface. Objects of this category are just copied in the process of serialization whereas only the stub is serialized with remote objects.

Registry

RMI brings its own naming server rmiregistry, which is accessed by java.rmi.Naming's static methods:

• bind(...) - which binds a server with a logical name to the registry
• rebind(...) - binding is successful even if the logical name existed before
• unbind(...)
• lookup(...) - returns a reference to the client that wants to connect to a server with a certain logical name
• list(...) - returns an array of all servers currently registerd with the registry

Dynamic Class Loading

Dynamic Class Loading allows the client during runtime to load remote class definitions that can be made accessible by a http- oder ftp-server.

Activation

Subclasses of Activatable can be indirectly started by calling clients. As the instance of redirection serves here the RMI Activation Daemon "rmid".

Custom Socket Factory

This allows for monitoring or encrypting the network traffic

Distributed Garbage Collection

In contrast to the normal Garbage Collector the dgc keeps track even of remote references to objects. When there are no local or remote references anymore the object is collected.