Introduction


What is RMI

The Distributed Calculator:
A Simple Example

Scaling Up: Enterprise Concerns

Scaling the Calculator

RMI Future

Scaling Up - Enterprise Concerns

by Bill Murray and Yoonju Kim

Remote Method Invocation was introduced with the 1.1 release of Java. Aside from general performance concerns, the most immediate short-coming noted were

  • Remote Garbage Collection
  • Server Binding and Object Persistence
  • Registry Management

Though garbage collection has always been an issue with Java, it is more acute in distributed applications because one is never sure if the object is truly no longer needed, if the fault lies with a dropped network connection or if the client VM crashed. It such cases, a server object can be garbage-collected even though the client still has need for it. Or, in the other extreme, a server object may persist even though the client VM has crashed and been restarted. This also gets in the issues of server binding and object persistence.

In Java 2, several changes were introduced to address these changes.

Garbage Collection is now done on an "expirable lease" basis. This works by having the Reference Layer keep expirable lease on an object. The object becomes a candidate for garbage collection when:

  • the client stub goes out of scope
  • the object's expiration time is reached

Though expirable leases helps conserve resources, it alone does not adequately address the issues of server binding.

The other major RMI-related improvement in Java 2 is the ability for a client to instantiate a server object(s) by one of two ways:

  • a registered activation method
  • inclusion in an activation group

Specifically, when a server registers itself, it may declare the calling method that can instantiate it. Thus, the act of registering does not instantiate the server object until the specific client method to invoke it is made.

This can also be accomplished using Activation Groups -- a collection of objects that become instantiated in one virtual machine upon a call from a client.

Once activated, these objects may be restarted they exit normally, be destroyed by garbage collection or destroyed by a network/system failure.

On a practical scale, improved programming techniques have lead to changes in how the RMI registry is managed.

In this snipet of code from a banking example in Java Enterprise In A Nutshell, each time a new account is created, each time a new account is created for remote management, it is bound to the registry

Registry local = LocateRegistry.getRegistry();
local.bind("Abrams,John",new AccountImpl("John Abrams"));
local bind("Barts,Homer",new AccountImpl("Barts Homer"));

Because its not possible to know ahead of time how many accounts will be created this is a very impractical method, registry overhead not withstanding.

As a solution, programming technique has been improved to use factory classes to dynamically create objects in such circumstances.

Using remote method calls on factory classes, clients can create dynamically request creation of new remote objects without needing to individually register with the server registry

Here's the banking example using factory classes:


import java.rmi.Remote;
import.jave.rmi.RemoteException;
public interface AccountManager extends Remote {
public Account getAccount(Sting name) throws RemoteException;
public boolean newAccount(Account s) throws RemoteException;
}

RMI and JNI (Java Native Interface)

Using JNI, it is possible to wrap C/C++ code in a native interface and export this interface remotely through RMI. Essentially stub contains conversion and call to program residing natively on server. Doing so, however requires fairly extensive coding and changes to the JavaSecurity Manager.

RMI and IIOP?

RMI over IIOP combines the usability of Java Remote Method Invocation(RMI) with the interoperability of the Internet Inter-ORB Protocol (IIOP). It provides you with the ability to communicate directly with a remote CORBA object regardless of the implementation language of that object; furthermore, any CORBA object may directly interact with an RMI object.

The reference implementation of RMI-IIOP was developed jointly by Sun and IBM. It runs both on JDK 1.1 (from release 1.1.6 onwards) and also o n Java 2. The RMI-IIOP reference implementation shipped in June 1999 and is available for free download from the Sun Microsystems RMI-IIOP home page. RMI-IIOP is also integrated into IBM's Java implementations on OS/390, AIX and OS/2 from JDK release 1.1.8 onwards.

References:
http://www.ibm.com/java/jdk/rmi-iiop
http://g.cs.oswego.edu/dl/java/docs12/guide/idl/ RMI w/CORBA 
Java Enterprise In A Nutshell, page 78).