The Benefits of Using RMI in Applets

• RMI is part of the core Java 1.1 specification, as well as Java 2 Standard Edition. This means that your RMI applet will be supported by every JDK 1.1 and 1.2-compatible client, so you don't have to worry about creating your own communications classes and packaging them with your applet.
• Included in standard Java^TM 1.1 and 1.2 runtime packages (JDK and JRE) is an executable version of the RMI registry, the server responsible for providing access to RMI objects. This allows you to deploy RMI-based server applications without needing an expensive application server or other add-on for the server side.
• Although RMI typically makes a direct connection between applet and server, it will also tunnel its transaction through HTTP if necessary. This allows users who are connected to the Internet through an HTTP proxy server to use RMI applets.
• RMI allows your applet code to execute server-side operations with simple function call syntax, so it's incredibly simple to write the code for such a distributed application.

The Limitations of RMI Applets on the Internet

• Despite supporting the majority of the Java 1.1 specification, the most popular web browsers -- Netscape Navigator and Microsoft Internet Explorer -- do not adequately support RMI. Navigator supports RMI on most platforms but does not support HTTP tunneling, so Netscape users connected to the web through a proxy server can't use an RMI applet. Meanwhile, Netscape for the Macintosh does not support RMI at all. Internet Explorer 4.0-5.0 also lacks RMI support, although a patch is supposedly available to add the missing classes (the RMI classes are available from Microsoft's web site, but instructions for installing them is not provided). As a result, a large percentage of Internet surfers can't use RMI applets in their current browser.
• The RMI registry can experience problems when handling connections via the Internet. A bug that causes the registry to stop accepting new connections occurs all too frequently with web-based RMI clients, requiring that the registry be shut down and restarted. Also, in Java runtime environments prior to JDK 1.2.2, server sockets created to handle connections from Internet-based RMI clients can live on indefinitely (consuming server resources) even after those clients are shut down.
• The RMI registry is not as flexible as most server applications, answering only to client connections made to one specific hostname. This means that your RMI server application cannot support multiple domains on a single web server, which limits your deployment options.
• Many applications may require that data exchanged between client and server be encrypted, compressed, or handled in some other fashion. Doing this with RMI is simple enough, requiring only that you implement your own socket classes and an RMI socket factory that creates your special sockets. However, overriding the default socket factory disables RMI's ability to do HTTP tunneling, thereby preventing access by proxy server users.
• Deploying an RMI server application requires additional network firewall configuration. By default, RMI objects are bound to random, "anonymous" server port numbers, making it impossible to predict the ports that must be available to Internet clients. RMI functionality new to Java 2 allows you to specify a port number when creating a remote object, but deployment still requires that firewalls allow access to ports not typically used by web-based applications.

Sample Application

The following graphic illustrates the original architecture of the application:

The server side of this illustration is a Java application that does three things: it creates an RMI registry, creates an instance of the database access object (UserDatabaseImpl), and binds the object to the registry to make it available to remote clients. Here are the lines of code from the server application that accomplish these tasks:

// Create the registry on port 1099
Registry reg = 
 java.rmi.registry.LocateRegistry.createRegistry(
 1099);
// Create the database object
UserDatabaseImpl db = new UserDatabaseImpl();
// Bind the object to the registry as "DB1"
java.rmi.Naming.rebind("DB1", db);

UserDatabase db; //The remote database object
...
String host = this.getCodeBase().getHost();
String name = "//" + host + "/DB1";
db = (UserDatabase)java.rmi.Naming.lookup(name);

public interface UserDatabase 
 extends java.rmi.Remote 
{
	public String createUser(
	 UserData data) throws RemoteException;
	public void editUser(
	 String userid, UserData data) 
	  throws RemoteException;
	public void deleteUser(
	 String userid) throws RemoteException;
	public UserData getUser(
	 String userid) throws RemoteException;
	public Hashtable listUsers(
	 ) throws RemoteException;
}

Overview of Changes

• Make all transactions object-based. In other words, to accomplish a task you want to send whole objects to the server and receive one or more objects in return. RMI allows you to easily do this via function calls, and in your changes you want to maintain this object-oriented exchange.
• Use HTTP for all applet/server communications. By using only HTTP, you can make your applet as compatible as possible with proxy servers and network firewalls.
• Make zero changes to your RMI server application. Instead of rewriting your server code you just want to add a servlet layer to facilitate applet communication, so you shouldn't have to touch the server objects that you've already implemented.
• Write a bare minimum of new code. Again, you don't want to do any more work than you have to.

Once you complete the changes your application's architecture will look like this:

The Servlets

Servlet Name	UserDatabase Method
UserCreateServlet	createUser()
UserEditServlet	editUser()
UserDeleteServlet	deleteUser()
UserGetServlet	getUser()
UserListServlet	listUsers()

Because your servlets will each execute a single RMI call, they will be extremely simple. Each servlet will perform the same basic tasks:

1. Get a reference to the database object from the RMI registry.
2. Read in parameter values from the client.
3. Execute the appropriate method on the database object.
4. Write the return value to the applet.

Here then is the code for DatabaseServlet, your servlet super-class:

public class DatabaseServlet extends HttpServlet
{
   String registry; // The path to the RMI 
   //registry
   UserDatabase db; // The database access 
   //object

    public void init(
     ServletConfig config)
       throws ServletException
	{
		super.init(config);
		// Get the location of 
		//the RMI registry.
		registry = config.getInitParameter(
		  "registry");
		// If undefined, assume the local host
		if (registry == null) registry = 
		  "//localhost";
		try {
		  // Now get the database object
		 String name = registry + "/DB1";
		 db = (UserDatabase)Naming.lookup(
		  name);
		 } catch (Exception e) {
			e.printStackTrace();
		} 
	}
}

Here's your first servlet, UserCreateServlet, which executes the createUser() database method on behalf of the applet:

public class UserCreateServlet 
 extends DatabaseServlet
{
	public void doPost( 
	  HttpServletRequest req, 
	    HttpServletResponse resp)
	throws ServletException, IOException
	{
	// Open the I/O streams
	ObjectInputStream in = new 
	 ObjectInputStream(
	  req.getInputStream() );
		ObjectOutputStream out = 
		 new ObjectOutputStream( 
		  resp.getOutputStream() );

		try {

	// 1. Read in parameters from 
	//the applet 
	      UserData data = (
		 UserData)in.readObject();

	// 2. Execute the RMI call
	String id = db.createUser(data);

	// 3. Write the result
	out.writeObject(id);

	} catch (
	 Exception e) { e.printStackTrace(
	  ); }

	// Close the I/O streams
	in.close();
	out.close();

	}
}

• You're using ObjectInputStream and ObjectOutputStream here because you want to maintain object-based transactions between the applet and server. In this servlet you could have returned the value of the result String instead of the entire String object, but sticking with an objects in/objects out approach makes your lives much simpler.
• Although you didn't declare or initialize the database object (db) in the code for UserCreateServlet, you don't need to. Again, this servlet extends DatabaseServlet, the parent servlet you defined above, so it gets a reference to the database object from the RMI registry when the servlet is initialized.

	// 1. Read in parameters from 
	//the applet 
	String id = (String)in.readObject();

	// 2. Execute the RMI call
	UserData data = db.getUser(id);

	// 3. Write the result
	out.writeObject(data);
	

  // 1. Read in parameters from 
  //the applet 
   String id = (String)in.readObject();
   UserData data = (
    UserData)in.readObject();

  // 2. Execute the RMI call
   db.editUser(id, data);

  // 3. Write the result
   // [no return value]
	

Client Proxy Object

In creating your proxy object, UserDatabaseProxy, you start with the UserDatabase interface that defines the available remote methods. The methods of your proxy object should be identical to the interface, which defines these methods:

 String createUser(UserData data) 
 void editUser(
  String userid, UserData data) 
 void deleteUser(String userid) 
 UserData getUser(String userid) 
 Hashtable listUsers() 
	

To help you accomplish this you'll be using a helper class called ServletWriter. This class manages the I/O streams between applet and servlet and executes the actual HTTP POST transaction. Like your servlets, ServletWriter uses ObjectInputStream and ObjectOutputStream to pass whole objects between client and server. The lone method defined by ServletWriter is:

ObjectInputStream postObjects(URL servlet, Serializable objs[]) where servlet defines the URL of the target servlet, and objs defines a list of Serializable objects to be written to the servlet. The method returns the ObjectInputStream from which your methods can retrieve return values from the servlet. See ServletWriter.java code for details. With ServletWriter at your disposal, here's what each of your proxy object methods will do:

1. Create a URL for the target servlet.
2. Create an array of Serializable objects that contains the method parameters.
3. Call ServletWriter.postObjects() to execute the servlet transaction.
4. Read and return the result value.

URL webBase;// The URL to the servlet web server 

public UserDatabaseProxy(URL web) 
{
	webBase = web;
}

With that out of the way, you can now write each of the proxy object's methods. You'll start with createUser(), which posts data to UserCreateServlet:

public String createUser(
 UserData data) throws Exception 
{
// 1. Create a URL for the target 
//servlet
URL servlet = new URL(
  webBase,
    "servlet/UserCreateServlet");

// 2. Create an array of parameter 
//objects
Serializable objs[] = { data };

// 3. Execute the servlet 
//transaction
ObjectInputStream in = 
 ServletWriter.postObjects(
  servlet, objs);

// 4. Read and return the result value
 String id = (String)in.readObject();
 in.close();
 return id;
}

public UserData getUser(
 String userid) throws Exception 
{
// 1. Create a URL for the target servlet
URL servlet = new URL(webBase, 
  "servlet/UserGetServlet");

// 2. Create an array of parameter objects
	Serializable objs[] = { userid };

// 3. Execute the servlet transaction
ObjectInputStream in = 
  ServletWriter.postObjects(
  servlet, objs);

// 4. Read and return the result value
UserData data = (UserData)in.readObject();
in.close();
return data;
}

Applet Changes

UserDatabase db; //The remote database object
...
String host = this.getCodeBase().getHost();
String name = "//" + host + "/DB1";
db = (UserDatabase)Naming.lookup(name);
	

UserDatabaseProxy db; // The proxy 
//database object
	

URL codebase = this.getCodeBase();

// Get the host, protocol, and port
String host = codebase.getHost();
String protocol = codebase.getProtocol();
int port = codebase.getPort();

// Build the URL for the servlet 
//web server
URL servletBase = new URL(
   protocol + "://" + host + ":" + port);

// Create the proxy object
db = new UserDatabaseProxy(servletBase);

That's it—you're done. Your client applet can now use HTTP instead of RMI to communicate with the database access object on the server end, and you didn't even have to change a single line of your existing server code (and only a half dozen lines in the applet). With just these few changes you've made your applet more compatible, your server more flexible, and your communication much more reliable and Internet-friendly.

Beyond the Basics

Receiving Multiple Objects From One Call

Instead of waiting for your servlet to return an Hashtable, you can send the keys and values of that Hashtable as individual objects. To see how, here's the original doPost() method from UserListServlet, which retrieves the list of database users in your sample application:

public void doPost(HttpServletRequest req, 
   HttpServletResponse resp)
 throws ServletException, IOException
{
  ObjectInputStream in = 
    new ObjectInputStream(
    req.getInputStream() );
     ObjectOutputStream out = 
   new ObjectOutputStream( 
    resp.getOutputStream() );
   try {
		Hashtable database = 
		 db.listUsers();
		out.writeObject(database);
	} catch (
	 Exception e) { e.printStackTrace(
	   ); }
	// Close the I/O streams
	in.close();
	out.close();
}

public void doPost(
 HttpServletRequest req,
    HttpServletResponse resp)
 throws ServletException, IOException
{
  ObjectInputStream in = 
  new ObjectInputStream(
  req.getInputStream() );
  ObjectOutputStream out = 
   new ObjectOutputStream( 
    resp.getOutputStream(
	  ) );
	try {
          Hashtable database = 
	   db.listUsers();

	// Tell the client how many 
	//entries are coming
	  int num = database.size();
	   Integer numInt = new Integer(
		num);
	   out.writeObject(numInt);
	
	// Write each key and 
	//value of 
      //the Hashtable
         Enumeration keys = 
         database.keys();
	    while ( 
	     keys.hasMoreElements(
	      ) ) 
		{	
	      String nextKey = 
	      keys.nextElement();
              UserData nextData = (
	      UserData)database.get(
	       nextKey);
	      out.writeObject(nextKey);
	      out.writeObject(nextData);
		}
	} catch (
	 Exception e) { e.printStackTrace(
	        ); }
	// Close the I/O streams
	in.close();
	out.close();
}

Obviously, if you change your servlet like this you need to change your proxy object to deal these return values. Here's the original code from your sample application's proxy object:

public Hashtable listUsers(
 ) throws Exception 
{
     servlet = new URL(webBase, 
     "servlet/UserListServlet");
      Serializable objs[] = {};
      in = ServletWriter.postObjects(
      servlet, objs);
      Hashtable database = (
      Hashtable)in.readObject();
      in.close();
      return database;
}

public Hashtable listUsers(
 java.awt.Label label) throws Exception 
{
  servlet = new URL(
   webBase, "servlet/UserListServlet");
     Serializable objs[] = {};
     ObjectInputStream in = 
     ServletWriter.postObjects(
      servlet, objs);

    // Initialize the return value
    Hashtable database = new Hashtable(
     );

    // Get the number of data 
    //values coming
      Integer numInt = (
       Integer)in.readObject();
	int num = numInt.intValue();
	
	// Read each key/value pair and 
	//add to the Hashtable
	for (int x = 1; x <= num; x++)
	{
	  label.setText(
	  "Getting data (
	  " + x + "/" + num + ")...");
	  String nextKey = (
	   String)in.readObject();
	  UserData nextData = (
	   UserData) in.readObject();
	  database.put(
	   nextKey, nextData);
	}
	in.close();
	return database;
}

Combining Servlets

Here's a single servlet that implements all of the database method calls that your five servlets, using an integer code sent by the applet to determine the appropriate action:

public class UniversalServlet extends DatabaseServlet
{
  static final int LIST   = 0;
  static final int GET    = 1;
  static final int CREATE = 2;
  static final int EDIT   = 3;
  static final int DELETE = 4;

   public void doPost(
    HttpServletRequest req, 
       HttpServletResponse resp)
    throws ServletException, IOException
	{
	// Open the I/O streams
	ObjectInputStream in = 
	 new ObjectInputStream(
	 req.getInputStream() );
	 ObjectOutputStream out = 
	 new ObjectOutputStream( 
	 resp.getOutputStream(
	  ) );

   try {
// Find out which operation to perform
  Integer codeInt = (
      Integer)in.readObject();
	int code = 
	 codeInt.intValue();

    if (code == LIST) {
	Hashtable database = 
	db.listUsers();
	out.writeObject(database);
}
	else if (code == GET) {
	String id = (
	String)in.readObject();
	UserData data = 
	 db.getUser(id);
	out.writeObject(data);
}
	else if (
	 code == CREATE) {
	UserData data = (
	UserData)in.readObject();
	String id = 
	 db.createUser(
	 data);
	out.writeObject(id);
}
	else if (code == EDIT) {
	String id = (
	String)in.readObject();
	UserData data = (
	UserData)in.readObject();
	db.editUser(id, data); 
}
  else if (code == DELETE) {
   String id = (
   String)in.readObject();
db.deleteUser(id); 
  }
		
} catch (
 Exception e) { e.printStackTrace(
   ); }

// Close the I/O streams
in.close();
out.close();
	}
}

public String createUser(
 UserData data) throws Exception 
{
 URL servlet = new URL(
	  webBase,
 "servlet/UniversalServlet");
 Integer code = 
  new Integer(2); //CREATE
 Serializable objs[] = 
 { code, data };
 ObjectInputStream in = 
  ServletWriter.postObjects(
   servlet, objs);
 String id = (
 String)in.readObject();
 in.close();
   return id;
}

Handling Multiple Object Types

public UserData getUser(
  String userid) throws Exception 
{
 URL servlet = new URL(webBase, 
 "servlet/UserGetServlet");
 Serializable objs[] = { userid };
 objectInputStream in = 
 ServletWriter.postObjects(
  servlet, objs);

// Read the value as an Object
Object obj = in.readObject();

// Is it an Exception?
if (obj instanceof Exception) {
  throw (Exception)obj;
  }
  else {
	UserData data = (
	UserData)obj;
	in.close();
	return data;
}
}

Conclusion

Download Source Code

About the Author

Scott McPherson Scott McPherson is the founder and President of Maczieg Software, a Silicon Valley-based Java software company. Scott and his company recently launched MochaMail Online the Internet's first Java-based free email service.

Reader Feedback