Web services test code generator
Klaus Berg has recently released a test-code generator for JUnit-based Web service clients. If you're developing Web services using Axis2 and XMLBeans this wizard could turn your JUnit test client coding into a powerful code generation process. It also has uses for those using GUI-based testing tools like soapUI.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Empower RMI with TRMI

Transparent RMI simplifies distributed application development

By Guy Gur-ari, JavaWorld.com, 08/09/02

The Java RMI (Remote Method Invocation) API provides us with a clean way to build distributed Java applications. The components that make up these applications communicate with each other by invoking methods on their remote counterparts. Transparent RMI (TRMI) extends the RMI API to simplify distributed application development by eliminating most of the standard API's overhead.

This article details the benefits of using TRMI in place of standard RMI. It shows how distributed software developers can provide a cleaner design for their applications and focus on the problem at hand rather than on the details of remote invocation. The article also discusses how TRMI allows developers to easily retrofit an existing application with remote objects. I assume that you are familiar with the basics of RMI and Java's proxy mechanism.

Before describing RMI's drawbacks, let's review the steps required for creating a distributed application using RMI:

  1. Create an interface that will be called remotely. This interface must extend java.rmi.Remote. Furthermore, its methods must all declare that they throw java.rmi.RemoteException in case of an invocation problem.
  2. Create an implementation class that implements this interface. The implementation class should extend java.rmi.server.UnicastRemoteObject, which implements all the setup required of an RMI server object.
  3. Create a server program that initializes the implementation object and binds it to a unique URL using java.rmi.Naming.
  4. Clients wanting to use the remote instance look it up using that URL and can then call its methods. A method call is marshaled and passed over the network to the remote object, which unmarshals it, executes it locally, and returns the result (or propagates the exception, as the case may be) to the caller.


A developer wishing to create a nontrivial application using RMI faces several difficulties:

  • Because of the requirements imposed on remote interfaces (they must implement Remote, and their methods must throw RemoteException), interfaces not designed with RMI in mind cannot be used remotely.
  • Calls to remote interfaces prove cumbersome, as they must be enclosed in a try/catch block for catching the possible RemoteException. Therefore, you must scatter exception-handling code throughout the application. To avoid doing so, developers usually limit remote invocation to a small portion of their programs.
  • The nuisance of RemoteExceptions also makes it difficult to use interfaces designed for remote execution locally.
  • No convenient approach can generically handle disconnections from a server in a single location. (An example of such handling might include looking up the remote object again and trying to reinvoke the method.)
  • Implementations of Remote interfaces cannot easily extend arbitrary classes, since they normally extend UnicastRemoteObject. (You could avoid this limitation with some effort, by reimplementing UnicastRemoteObject.)


Enter transparent RMI

Transparent RMI overcomes these difficulties by using Java's reflection and proxy mechanisms. Before delving into TRMI's details, let's see what a program that uses TRMI looks like. (Note that the code presented here is a slightly modified version of the code you can download from Resources.) Suppose we want to call the Hello interface from a remote JVM:

Resources