O'Reilly logo

Java RMI by William Grosso

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

The Architecture Diagram Revisited

While the printer application is simple enough so that the RMI-based application is similar to the socket-based application, RMI does add one more conceptual wrinkle. Recall that in the socket-based version, we used a set of constants to help the client find the server:

public abstract class NetworkBaseClass {
	public static final String DEFAULT_SERVER_NAME = "localhost";
 	public static final int DEFAULT_SERVER_PORT = 2100;
	public static final int DEFAULT_SERVER_BACKLOG = 10;

That’s a bad design strategy. If the server is moved to another computer, or if you want to use the same client to talk to multiple servers, you need to deploy a new version of the client application.

A much better strategy is to have a centralized naming service. A naming service is an application that runs on a central server and functions like a phone book. In order for a client to connect to a server, it must do two things:

  1. It must connect to the naming service and find out where the server is running.

  2. It must then connect to the server.

At first glance, a naming service appears to suffer from the same design flaw as NetworkBaseClass. Instead of hardwiring the location of the server into our client code, we’re hardwiring the location of the naming service. There are, however, a number of differences that combine to make this a more palatable solution. Among the most significant are:

  • Naming services are fairly simple applications that place limited demands on a computer. This means that the server running a naming service doesn’t need to be upgraded often.

  • Naming services are stable applications with simple APIs. They are not updated or revised often.

  • The application may actually have several servers. Rather than hardwiring all their locations into the client application, we need only one predetermined location.

The first two are especially important. Some common reasons for moving a server application to a new machine include scaling the application or providing for changes in application functionality. In the case of a naming service, however, the hardware will likely be sufficient to handle the load for quite a long period of time. Moreover, because the naming service is a simple and well-understood application that rarely changes, chances are that the implementation is a reliable piece of code. In other words, a computer running a naming service can often be set up and left alone.

In RMI, the default naming service that ships with Sun Microsystem’s version of the JDK is called the RMI registry.[23] Messages are sent to the registry via static methods that are defined in the java.rmi.Naming class. Including the RMI registry in our printer application architecture leads to the diagram in Figure 4-2.

Adding an RMI registry to the architecture diagram

Figure 4-2. Adding an RMI registry to the architecture diagram

While we’ve introduced only one new server into our application, we’ve added two new types of messages to those that are flowing across the network:

The registry must be told about the printer server.

This must happen before any other types of messages can be sent. Note that the printer server is a remote object, so what really gets passed to the registry is a stub (recall that stubs are serializable and can therefore be passed by value). This stub knows on which computer the printer server runs, and on which port the skeleton receives messages. Thus, the stub can relay method calls to the printer server’s skeleton.

The client must communicate with the registry to find out how to connect with the printer server.

The client must do this before the client can actually request that a document be printed. As a result of this, the client will obtain a copy of the stub that the server originally sent to the registry.

And, of course:

The client must send print requests to the printer server.

All of the communication in the socket-based version of the printer server is of this type.


In order to provide distributed garbage collection, RMI also sends other types of messages dealing with renewing leases. We will cover these messages (which are sent automatically and don’t require any work by application developers) in Chapter 16.

[23] More often referred to as simply “the registry.”

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required