Remote Method Invocation (RMI)
- 1 General
- 2 Implementing an RMI programm
- 3 Some further techniques
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.
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.
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.
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 methods 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 method overloading
Implementing an RMI programm
The next few paragraphs will describe the basic steps of how to implement a simple RMI program. The source code of a simple example program can be found at http://www.informatik.hu-berlin.de/~westmeie/rmi
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 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.
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.
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.
Some further techniques
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.
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
- 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.
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.