The advent of AJAX as a Web application model is significantly changing the traffic profile seen on the server side. The typical Web pattern usage of a user sitting idle on a Web page filling out fields and hitting the submit button to the next link is now transforming into sophisticated client-side JavaScript and rich user interfaces that constantly communicate with the server whenever an event is posted on a form such as a checkbox click, key press, or tab focus.

Think about the amount of data transmitted from the client to the server. From a usability standpoint, the user gets rich user interfaces on a thin-client browser without having to install anything. However, there is a price to pay when scaling these applications on the server. Your typical capacity-planning numbers for AJAX applications can shift significantly in the magnitude of three to four times than that of standard Web applications.

One might ask how would this impact the WebLogic Server. For every HTTP request to WebLogic, an execute thread is consumed. Given the nature of AJAX programming and many short-lived HTTP requests in the form of polling, this behavioral pattern can potentially bombard the server with client requests. For several years now, WebLogic has taken this into consideration and built a wonderful feature called the FutureResponseServlet. This paradigm builds off the notion of asynchronous servlets. From version 6.1 onward, this functionality has allowed developers to have the ability to provide true asynchronous notification from the server without the client polling for events and consuming an execute thread on the server. BEA was not too keen to make this class public until 9.x.

How can one leverage this class in the real world? Well, let's look at an example. Suppose you have a business requirement to build a Web-based application that presents server data in near-real time without refreshing the browser. Such an application can submit a request to the server that can take a long time to process, and still be able to receive asynchronous events about its status, as well as listen for events. From a technology standpoint, there are many ways you can build this. One way is to use a Java Applet that communicates with a Java Servlet to get asynchronous information. This is nice but becomes inconvenient to the user because they have to download a JVM and carry the baggage and weight of downloading an applet to the browser. Moreover, a persistent socket connection must be maintained from the client to the server to receive asynchronous events. Imagine: if there are 1,000 users using the applet, there are 1,000 execute threads that are mostly idle waiting to send event notifications back to the client. Yes, there are other approaches such as building polling mechanisms from an applet or AJAX application to check for new data every so often. If data is not received that often, it is useless to poll and waste server resources and consume execute threads. Instead, the server can poll periodically and relay events back to the client and maintain the socket threads without consuming a persistent execute thread. This is very similar to how Java NIO works. Ideally, you would want to build an application, whether it is an applet or a thin AJAX-based Web application, that "asynchronously" receives event notifications from the server without consuming a persistent execute thread on the server.

One solution to this problem is to create a servlet that extends the FutureResponseServlet class. The browser establishes a single connection to the FutureResponseServlet and registers itself as a listener in a different thread. Whenever an event is received on the server, the thread notifies the client with the event. The server maintains the client asynchronously without having to consume a persistent execute thread. This model can scale several concurrent users.

This article does not describe how to build an AJAX application. There are several articles available that discuss this topic. It discusses the importance of asynchronous processing for presentation layers, such as AJAX, applets, or any front-end application. Listing 1 shows an example.

As you can see, this example is extremely trivial. The AsynchronousServerResponseServlet class extends FutureResponseServlet and overrides the service method. A single thread, the Notifier class, processes all client connections response. For every HTTP request, the servlet registers the socket connection to the Notifier thread and returns. Asynchronous events get delivered to the client while the persistent socket connection is maintained.

A single thread can manage multiple client connections!

The run() method can be used to call back events to the client based on some message selection criteria. This example just performs a server-side push operation and is very simplistic in nature. Thread pools can be utilized for certain types of event processing.

In conclusion, when processing long running tasks, the FutureResponseServlet is a good feature that allows developers to increase performance and process responses in separate threads and minimize overhead. This approach allows scalability when building asynchronous applications.