Java allows you to improve the interaction between the client and the server. The HTTP protocol, the native language of the World Wide Web, is very specific and somewhat restrictive as far as the interaction between the client and server. Whenever a client needs to send data to the server, it must open up a network connection, send a set of headers and the request data, and then sit and wait for a response. The server has very few options for sending data to a client. It must wait for the client to send it information, and the only option it has for sending back multiple responses is the "multi-part" message, in which the server sends part of a response, and then later sends more of the response. Given the static nature of Web pages, this has always been considered acceptable. Also, because the network connection is closed after a server has sent a response back to the client, there is no notion of a session within HTTP. Clients and servers have had to come up with their own interesting ways of maintaining session information between requests. The Netscape Cookie protocol is one such method.

The server puts Netscape cookies in a Web page when it sends information back to the browser. The pieces of information are tagged as being cookies, which the browser watches for and saves for later use. The next time the browser accesses that server, it sends the cookies back to the server. This allows the server to save information at the client-side and then receive the information at a later time.

When you are writing serious applications, however, you need the interaction between client and server to be much more flexible. A client should be able to send information to a server at any time, and the server should be able to send data back to the client at any time. Java's networking support allows you to do this by creating a socket connection between the client and the server.

Look at an example of a real-world application and see how Java can improve yourapplications drastically.

Suppose you work for an airline and you are creating a program to display the current position of any of the company's aircraft. You would like this program to run on any Web browser within the company. Your server will be gathering aircraft position data and sending the information out to the browsers. You obviously want this to be a graphical program-you don't just want to list coordinates. You want the president of the company to be able to see immediately that flight 1313 is halfway between Cleveland and Detroit, without having to estimate its distance based on the latitude and longitude shown on some chart.

If you were to do this application using the traditional Web server and HTML forms, your server would have to generate entire images and send them to the client. Anytime a plane's position changed, you'd have to generate new images for each client that was watching that plane. Even if a plane's position changes once a minute, if you watch ten planes, you'll be receiving an average of one image every six seconds. That's an incredible burden to place on your server.

Now, suppose you were to create the same application in Java. The Java applet would download a blank map from the server and then open up a socket connection to the server. Anytime the Java applet wanted to watch a new plane, or stop watching a plane, it would send a message to the server. The server would track what clients were watching what planes. One of the keys here is that the connection between the client and the server stays up. This allows the server to keep track of clients based on their sockets. Now, suppose the server receives a position update for a plane. It looks through its tables and finds every client that was watching that plane and sends the new position down to that client. It does not have to perform any image generation. The amount of data sent to the client is probably 100-1,000 times smaller than the image that would be sent under the previous architecture.

The Java applet is responsible for creating the new image of the aircraft. Although this may take a little longer to generate on the client than on the server, the server is able to handle many times more clients than it otherwise would, because it doesn't have to do as much work for each client.

If you step back and take a look at this application, you'll see that the applet is really just implementing the user interface for the flight tracking system. The bulk of the work in gathering the flight data and analyzing it is done by the server. The interaction between the server and client is a clearly defined set of actions. The client starts watching a plane, the client stops watching a plane, the server sends a flight position to the client. That'sa pretty simply protocol! The client does what it does best-it interacts with the user. The server does what it does best-it gathers and analyzes information.

Keep this in mind as you design and develop new applications. Don't heap all the work on the applet, just let it do what it does best-interact with the user.

Realizing that applets are going to need a reasonable way to communicate with the actual applications, Sun added two important subsystems to Java. Remote Method Invocation (RMI) allows a Java object to invoke methods in another Java applet somewhere else on the network. You don't have to come up with your own way of transmitting data between the applet and the application on the server. The applet can simply invoke methods on the server using RMI.

RMI is a nice feature, and is very easy to use since it blends into your applet and application almost seamlessly. There is another way to invoke methods remotely, however.It's called the Common Object Request Broker Architecture, or CORBA. There are many differences between RMI and CORBA. One of the biggest is that CORBA is a multi-language protocol. You can use CORBA in an applet to invoke methods in a C++ application running on your server.

You will be able to choose between RMI and CORBA for your applets. They will both be supported as part of the core of Java. You can expect both mechanisms to be present in a Java-compliant Web browser, or any Java-compliant environment.