The Architecture Diagram Revisited

methods, readObject and writeObject , which the serialization mechanism will call instead of using the automatic encoding for the object. Note that if an argument is a remote object e.g., a server, the skeleton doesnt send a serialized copy of the server. Instead, it creates a stub that serves as a reference to that object and sends a serialized copy of the stub over the wire. What about arguments that are neither serializable nor remote? Well, if its a primitive datatype, it is passed by value as well. But if its an object and is neither serializable nor remote, an exception is thrown.

4.2 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; .... } Thats 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, were 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 doesnt 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 Microsystems version of the JDK is called the RMI registry. [ 4] 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 Figur e 4- 2 . [ 4] More often referred to as simply the registry. Figure 4-2. Adding an RMI registry to the architecture diagram While weve introduced only one new server into our application, weve 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 servers 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 dont require any work by application developers in Chapt er 16 . A Note on Application Topology As we mentioned earlier, the RMI registry is the naming service that comes with RMI. Its a small application with a minimal interface and some very curious restrictions. Among the most severe of those restrictions is this: launch code the code that binds servers into the registry has to be running on the same computer as the RMI registry. This restriction was implemented for security reasons. If there are no restrictions on what can be bound into the registry, then it becomes very easy for malicious code to subvert a registry. For example, a malicious application could use this weakness to replace the real servers with counterfeit ones. However, this causes fairly significant difficulties™ getting servers bound into the registry becomes somewhat convoluted. In most cases, well want to replace the registry with a more flexible naming service well talk about this in much greater detail in Chapt er 14 and Chapt er 15 . Until we do so, however, Ill present these examples with little thought to these restrictions.

4.3 Implementing the Basic Objects