CSCI A348/A548

Lecture Notes 23

Fall 1999

Java Servlets continued and Introduction to Java RMI

First, we need to start talking about the projects and schedule all steps. Second we need to discuss the Java servlets exercises that have been posted as part of lab notes 12, and we'll take the ATM example and understand it well. We'll discuss ways in which we can improve it. We then move to describe Java RMI. Before we do that though, we need to point out that the lecture notes of last week (the big picture lecture notes) are required reading for big picture questions on the final exam.

Also note the WebTechniques lab note on Java Server Pages (JSP, related to ASP, see big picture lecture notes). The JServ installation article covers JSP. Also here's the Java RMI recipe.

Note: for this lab's work please create a directory:

(where username is your username) and work inside it.

Also use your hostname (where I use tucotuco) and your 3990x port number wherever you see mine being used (it will appear as follows: 39904). Note that you have to use the port number both in the client and in the server-side application.

Weather Station by Java RMI

We will implement/simulate a client/server weather station in the lab using Java RMI.

Assume we have a computer system (this will be for me) that is physically connected to all sorts of weather-monitoring equipment: rain gauges, thermometer, anemometer, barometer, and so on. This will be our server system; it monitors the temperature and weather in the burrow cluster.

We will let our users connect to our web server, get an applet (that will start running on their system) and use the applet to query the weather server (which is a Java application we'll write) to obtain the current weather in the area monitored by the server (i.e., the burrow cluster).

The first thing we need to clarify, if we are going to use remote method invocations, is what methods our server will export. This happens to be the first in the list of steps that we have listed as necessary in order to produce a RMI application:

1. Create an interface that defines the exported methods that the remote object implements (that is, the methods that the server implements and that clients can invoke remotely). This interface extends the java.rmi.Remote interface.

Each method in the interface must be declared to throw a java.rmi.RemoteException which is the superclass of many more specific RMI exception classes.

So here's the interface: cat

import java.rmi.*; public interface weatherInf extends Remote { public String read() throws RemoteException; }
This means that our Java server will export one method, read.

Here's the Java application that will implement the weather server.

It implements the interface just described. cat

import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; public class weatherInfImpl extends UnicastRemoteObject implements weatherInf { public String read() { System.out.println("Sending Data..."); return "The time is: " + new java.util.Date().toString() + "... and the weather is fine."; } public weatherInfImpl() throws RemoteException { System.out.println("Initializing Weather Server"); } public static void main (String args[]) { Registry reg; System.setSecurityManager(new RMISecurityManager()); try { weatherInfImpl WII = new weatherInfImpl(); reg = LocateRegistry.createRegistry(39904); // your port here reg.bind("WeatherInfo", WII); System.out.println("Server Ready"); } catch (RemoteException e) { System.out.println("General Server Error: " + e); System.exit(0); } catch (AlreadyBoundException e) { System.out.println("Name is already bound: " + e); System.exit(0); } } }
This covers steps 2 and 3 in our RMI recipe:

2. Define a subclass of java.rmi.server.UnicastRemoteObject that implements your Remote interface. This class represents the remote object (or server object). Other than declaring its remote methods to throw RemoteException objects, the remote object does not need to do anything special to allow its methods to be invoked remotely. The UnicastRemoteObject and the rest of the RMI infrastructure handle this automatically.

3. Write a program (a 'server') that creates an instance of your remote object. Export the object, making it available for use by clients, by registering the object by name with a registry service. This is usually done with the java.rmi.Naming class and the rmiregistry program. A server program may also act as its own registry server by using the LocateRegistry class and registry interface of the java.rmi.registry package.

Now we compile the server and its interface: ls -l
total 10
-rw-r--r--   1 dgerman  students     179 Nov  4 09:53 info.html
-rw-r--r--   1 dgerman  students     934 Nov  4 10:05
-rw-r--r--   1 dgerman  students     116 Nov  4 09:55
-rw-r--r--   1 dgerman  students    1027 Nov  4 10:37 javac
And then steps 4 and 5 in the recipe read:
4. After you compile the server program (with javac) use rmic to generate a 'stub' and 'skeleton' for the remote object. Invoke rmic with the name of the remote object class (not the interface) on the command line. It creates and compiles two new classes with the suffixes _Stub and _Skel. rmic weatherInfImpl ls -l total 24 -rw-r--r-- 1 dgerman students 179 Nov 4 09:53 info.html -rw-r--r-- 1 dgerman students 934 Nov 4 10:05 -rw-r--r-- 1 dgerman students 273 Nov 4 13:30 weatherInf.class -rw-r--r-- 1 dgerman students 116 Nov 4 09:55 -rw-r--r-- 1 dgerman students 1599 Nov 4 13:30 weatherInfImpl.class -rw-r--r-- 1 dgerman students 1027 Nov 4 10:37 -rw-r--r-- 1 dgerman students 1489 Nov 4 13:57 weatherInfImpl_Skel.class -rw-r--r-- 1 dgerman students 1856 Nov 4 13:57 weatherInfImpl_Stub.class
With RMI the client and the server do not communicate directly. On the client side the client's reference to a remote object is implemented as an instance of a 'stub' class. When the client invokes a remote method, it is a method of this stub object that is actually called. The stub does the necessary networking to pass the invocation to a 'skeleton' class on the server. This skeleton translates the networked request into a method invocation on the server object, and passes the returned value back to the stub, which passes it back to the client. This can be a complicated system but fortunately application programmers never have to think about stubs and skeletons; they are generated automatically by the rmic tool.
5. If the server uses the default registry service provided by the Naming class you must run the registry server, if it is not already running. You can run the registry server by invoking the rmiregistry program. Note however that, as we mentioned at step 3 a server program may also act as its own registry server by using the LocateRegistry class and registry interface of the java.rmi.registry package so you need to run the registry server (or make sure it is running) only if the server uses the default registry service provided by the Naming class.
In this lab we use the second method.

We can now write the client (an applet): cat
import java.rmi.*; import java.applet.*; import java.awt.*; public class weatherApplet extends Applet { private TextArea status; weatherInf WI; public void init() { add (status = new TextArea(5, 50)); add (new Button("Retrieve")); status.setEditable(false); status.setText("Starting Connection"); try { WI = (weatherInf)Naming.lookup( "rmi://" + getCodeBase().getHost() + ":39904/WeatherInfo" ); // your 3990x port here } catch (Exception e) { System.out.println("Error: " + e.toString()); status.setText("Error: " + e.toString()); } } public boolean handleEvent (Event e) { if ( instanceof Button && == Event.ACTION_EVENT) { try { status.setText( + "\n"); // replaced append } catch (RemoteException ex) { status.setText("Error: " + ex.toString()); } } return false; } }

Notes from the recipe's step 6:

1. The client must first obtain a reference to the remote object exported by the server by using the Naming class to look up the object by name.

2. The name is typically an rmi: URL.

3. The remote remote reference that is returned is an instance of the Remote interface for the object (or more specifically a 'stub' object for the remote object). Once this client has this remote object it can invoke methods on it exactly as it would invoke the methods of a local object.

4. The only thing that it must be aware of is that all remote methods can throw RemoteException objects, and that in the presence of network errors, this can happen at unexpected times.

5. RMI uses the serializaton mechanism to transfer the stub object from the server to the client. Because the client may load an untrusted stub object, it should have a security manager installed to prevent a malicious (or just buggy) stub from deleting files or otherwise causing harm. The RMISecurityManager class is a suitable security manager that all RMI clients should install.

We now compile the client: javac
Note: uses a deprecated API. Recompile with "-deprecation" for details. 1 warning
Prepare a way of distributing it: cat info.html
<html> <head> <title> RWI (Remote Weather Info) </title> </head> <body bgcolor=white> <applet code=weatherApplet.class width=400 height=300> </applet> </body> </html>
And start the server: ps 
 11546 pts/1    0:01 csh netstat -a | grep 29800 java weatherInfImpl &       
[1] 14369 Initializing Weather Server
Server Ready ps -f
 dgerman 14369 11546  6 14:28:04 pts/1    0:03 /usr/bin/../java/bin/../bin/sparc/native_threads/java weatherInfImpl
 dgerman 11546 11531  0 09:39:04 pts/1    0:01 -csh
Now you can run it and when you do, watch the text window in which you started the server as well. Our next goal will be to combine servlets with RMI technology in the broader context of applet-servlet communication. We'll start on that next lecture.

Last updated: November 16, 1999 by Adrian German