We are now using an applet front end and we need a mechanism for the applet to communicate with the servlet. We need to capture the information a student enters and somehow pass it to the servlet. Since servlets support the HTTP/CGI interface, we can communicate with the servlet over HTTP socket connections. The applet simply opens a connection to the specified servlet URL. Once this connection is made, the applet can get an output or input stream on the servlet.

The applet can send data to the applet by using a GET or a POST method. If a GET method is used, the applet must URL-encode the name/value pair parameters into the actual URL string. For example, if we wanted to send the name/value pair of LastName=Jones, our servlet URL would resemble:

http://www.foo.com/servlet/
TestServlet?LastName=Jones

If you have additional name/value pairs, they are separated by an ampersand (&). If we add a name/value pair of FirstName=Joe, our revised servlet URL would resemble:

http://www.foo.com/servlet/
TestServlet?LastName=Jones&FirstName=Joe

We would have to URL-encode each name/value pair for the student's contact information. To send a GET method to a servlet, the applet can use the java.net.URLConnection class. The code fragment below shows you how.

String location = "http://www.foo.com/servlet/TestServlet?LastName=Jones";

URL testServlet = new URL( location );
URLConnection servletConnection = testServlet.openConnection();

inputStreamFromServlet = servletConnection.getInputStream();

// Read the input from the servlet.
. . .

Once the applet has opened a connection to the URL, the input stream from the servlet is accessed. The applet can read this input stream and process the data accordingly. The type and format of the data returned depend on the servlet. If the servlet is returning custom information, a custom messaging protocol has to be created for the applet and servlet to communicate. I won't go into the details of a custom protocol, however, as I'll present an elegant solution later in the article.

To POST data to a servlet, the java.net.URLConnection class is used again. This time, however, we must inform the URL connection that we will send data over the output stream. The POST method is powerful because you can send any form of data (plain text, binary, etc.). All you do is set the content type in the HTTP request header. The servlet must be able to handle the type of data that the applet sends, however.

The code in Listing 1 shows how to send a POST method to a servlet URL. The details of transmitting the data are discussed later in the article.

As you can see, applets can communicate with servlets using the GET and POST method.

Communicating with Object Serialization
In our application we want to provide a higher level of abstraction. Instead of passing each parameter of student information (e.g., last name, first name) as name/value pairs, we'd like to send it as a true Java object. Our Java application already has a Student class that encapsulates all of the information about a student (see Listing 2). This information is gathered from the New Student dialog box and a Student object is created. When we register a new student, we'd simply like to send the Student object to the servlet. Upon receipt of the Student object, the servlet would add the new student to the database. We also want the servlet to send the applet an updated student list as a vector of student objects. This will allow the applet to display the student list quickly and easily.

You may ask how we can accomplish this. It's easy, thanks to Java 1.1's object serialization, which allows an object to be flattened and saved as a binary file. The values of the data members are saved so the state of the object is in fact persistent or serialized. The object can be loaded or deserialized later from the binary file with the values of its data members intact. Object serialization is fascinating because it frees the developer from the low-level details of saving and restoring the object.

How does this relate to applet-servlet communication? Well, object serialization is not limited to binary disk files. Objects can also be serialized to any output stream. This even includes an output stream based on a socket connection. So you can serialize an object over a socket output stream! As you've probably guessed by now, a Java object can also be deserialized or loaded from a socket input stream.

For a Java object to be serializable, its class must implement the java.io.Serializable interface. You won't have to actually implement any methods for this interface, however, because the interface is empty. The java.io.Serializable interface is simply a tag for the Java Virtual Machine. We can create a custom class as follows:

class Foo implements java.io.Serializable
{
// normal declaration of data members,
// constructors and methods
}

The following code fragment shows you how to serialize an object to an output stream. In this example we already have a socket connection to a host machine and are simply serializing the object, myFoo.

outputToHost = new ObjectOutputStream(hostConnection.getOutputStream());

// serialize the object
Foo myFoo = new Foo();
outputToHost.writeObject(myFoo);

outputToHost.flush();
outputToHost.close();

Notice in this example that an ObjectOutputStream is created. This class is responsible for serializing an object. The object is actually serialized when the writeObject() method is called with the target object as its parameter. At this time a binary image of the object is written to the output stream. In this case the output stream is based on a socket connection. This example wouldn't be complete, however, without code on the host machine to read the serialized object. The next code fragment shows you how to deserialize an object from an input stream.

inputFromClient = new ObjectInputStream(clientConnection.getInputStream());

// deserialize the object, note the cast
Foo theData = (Foo) inputFromClient.readObject();

inputFromClient.close();

An ObjectInputStream is created based on the client's socket connection. The object is deserialized by simply calling the readObject() method. But we must cast the object to its appropriate class, in this case the class Foo. At this point the object is available for normal use.

As you can see, object serialization is very straightforward and easy. Now we'll use the technology to pass objects back and forth between our applet and servlet.

Sending Objects from an Applet to a Servlet

With the information presented so far, we can send a Java object to a servlet. In our Student Tracking application the applet sends a Student object to the servlet when a new student is registered. Figure 3 displays the object interaction between the servlet and the applet.

The code fragment shown in Listing 3 is used by the applet to send the Student object to the servlet. The applet is actually sending a POST method to the servlet. This client-side code fragment opens a URL connection to the servlet URL. We inform the servlet connection that we're sending output data over the connection and receiving input. Other methods are called so the connection will not use cached versions of the URL. An important call in this code fragment is setRequestProperty(). This method sets the content type in the HTTP request header to the MIME-type application/octet-stream, which allows us to send binary data, in this case our serialized Student object. The next couple of statements create an ObjectOutputStream that actually writes the object to the connection stream.

We're not finished yet. Recall that our application is in the process of registering a new student. The servlet has to read this student object and update the database accordingly. Thus we need code on the server side to receive a serialized Student object.

The code fragment in Listing 4 displays the servlet code for reading a Student object from an applet. The servlet handles POST methods by implementing the doPost() method and acquires an ObjectInputStream from the requesting applet. From there it is simply a matter of reading the Student object from the stream. At this point the Student object is loaded and available for registration in the database. Please note the small number of statements on the server side for reading in a serialized object. You have to agree it's quite simple and straightforward.

Sending Objects from a Servlet to an Applet
The servlet in our Student Tracking application is now capable of receiving a student object and registering it in the database. Now the servlet has to return an updated list of registered students that is then returned as a vector of student objects. This interaction is also illustrated in Figure 3.

When the servlet returns the vector, there's no need to iterate through the vector and serialize each Student object individually. The servlet can serialize the entire vector in one step since the class java.util.Vector also implements the java.io.Serializable interface.

The code fragment shown in Listing 5 is used by the servlet to send a vector of Student objects to the applet. The sendStudentList() method is passed to an HttpResponse parameter and a vector of Student objects. Since the applet initiated the HttpRequest, the servlet can respond to the applet by using the HttpResponse parameter. Thus an ObjectOutputStream to the applet is created based on the HttpResponse object. The student vector is actually serialized and sent to the vector with a call to outputToApplet.writeObject(studentVector).

As we've seen before, code is needed by the applet to handle the data sent from the servlet. The applet uses the code fragment shown in Listing 6 to read in a vector the Student objects from the servlet. The applet opens a URL connection to the servlet's location. Appropriate methods are called to ensure that the applet doesn't use cached versions of the URL connection. Next, an ObjectInputStream is created based on the servlet's input stream socket connection. All the switches have been flipped now and we can easily read in our vector of Student objects. Again, remember that we have to cast the object to the appropriate type.

Congratulations! You've successfully read in a vector of student objects. This vector is now available for refreshing the AWT List component.

Conclusion
This article goes beyond the normal method of sending name/value pairs over the HTTP/CGI protocol. The techniques presented leveraged the features of Java object serialization, providing an elegant way to transmit serialized Java objects over network connections.

I must inform you, however, that this article discussed communication using the HTTP/CGI protocol only. There are a number of other mechanisms for applets to communicate with server-side processes - Java's Remote Method Invocation (RMI), for example.

RMI allows a client application to call methods on a remote object as if the object was local. In fact, RMI uses object serialization to pass objects back and forth between the client application and the remote object. All the low-level details of network connections and serialization are hidden from the developer using RMI. If your project requires a large amount of applet-servlet communication, I'd recommend that you take a close look at RMI and the features it has to offer.

The second mechanism of communicating with server-side process is CORBA (Common Object Request Broker Architecture). Like RMI, CORBA allows you to make method calls on remote objects. If you have legacy server-side code written in a different language, you can wrap it as a CORBA object and expose its functionality. CORBA provides a rich framework of services and facilities for distributing objects on the network.

By now, you should understand the concepts and techniques for communication between applets and servlets. If you'd like to get more information on distributed computing with RMI and CORBA, visit the Web sites listed below. In this article I demonstrated how an applet uses a POST method to send a serialized object to a servlet. The appropriate server-side code for the servlet was provided for reading in a serialized object. Our Student Tracking applet used this communication method to send a true Java object to a servlet. The servlet was also enhanced to return a vector of student objects to the applet. Likewise, the appropriate applet code was provided for reading in a vector of student objects.

As you can see, applet and servlet communication is straightforward with the techniques presented in this article. You can now add an applet front end to your servlet-based application.

URL References:
Remote Method Invocation (RMI):
www.javasoft.com/products/rmi
CORBA: www.omg.org
Student Tracker Source Code: www.
j-nine.com/pubs/applet2servlet