There's a common misconception among many end users, consumers, and developers that AJAX is the ultimate solution for the Web and that it can provide all the same functionality as a rich desktop solution. Sure, AJAX can cover most of our expectations for a rich client, mimicking functionality provided by a desktop application, but there's still one area that has yet to be fully integrated ­ scalable server-initiated message delivery.

With server-initiated message delivery, all end users of a particular application are simultaneously notified of any changes to the application state, e.g., at the stock exchange a stock is dropping fast and the trading application has to inform all traders about the sudden change in price.

Server-Initiated Message Delivery
Let's use the trading application as an example for server-initiated message delivery. Each broker has his own preferences in stocks and bonds and requires instant notification of changes in the market. A desktop client for a distributed enterprise application typically registers interest in specific kinds of server messages so the server can notify the desktop client when they occur. This lets the desktop application efficiently use the network on a need-to-know basis instead of having the client actively ask for information.

This approach won't work for a traditional Web-based AJAX application since the server can't initiate a direct connection to the browser because of browser security, firewalls, and Web proxies.

Sure, it's possible with AJAX to "notify" a Web client that a change has occurred on the server using a technique called "polling." By creating a Web application that polls every now and then the end user believes that he's been notified by the server, when in fact it's repeatedly asking for updates like any child asking for candy ­ Can I get it now? Can I get it now? Can I get it now? You get the picture.

Of course, this impacts network bandwidth since there's traffic for each polling request even when no updates are available from the server. We need a way for Web clients to register interest in certain types of messages and then let the server initiate delivery of those messages, pushing them to each browser.

There's a Twist
OK, OK, OK, there is a twist ­ you can't actually "push" messages to a Web-based AJAX application unless you maintain an open connection from the client to the server. However, a thread is kept alive on the server for each open connection so messages can be delivered to the browser immediately.

The fact that you'd even try to maintain an open connection per user to a server would have heads rolling down the corridors in most IT departments. Just imagine thousands, or even hundreds of thousands of connections, using the thread and process pooling models provided by most Web Servers today, keeping each thread alive on the server just to be able to send a message to the client ­ it doesn't scale! Let's come back to that one later.

HTTP Connection Limitations
Today most frameworks leveraging AJAX are using the XMLHttpRequest object, which allocates an HTTP connection for the duration of the request. The HTTP 1.1 specification recommends that browsers support a maximum of two open connections to the hosting server. This presents a problem for highly interactive AJAX Web applications, especially on Microsoft Internet Explorer, which enforces this recommendation.

If there are more than two AJAX frameworks or components using the XMLHttpRequest on the same Web page then there will probably be contention for the two open connections, causing requests to queue. The result will be blocked and ineffective communication, defeating the main purpose of having AJAX on the Web page. There's a need to share server communications over two HTTP connections at most.

Next-Generation Web Communication
The main reason a Web server allocates one thread per connection is because it expects the request to be highly active and short-lived. However, maintaining an open connection to the server is extremely long-lived and activity is mostly dormant. We also need a way to meaningfully share server communications to address the browser connection limit. Thankfully, there are several projects in process addressing the limitations of traditional AJAX Web applications. Let's have a look at some of these projects.

Comet - The Never-Ending Request
First we need a way to create message-driven Web applications that require the server to notify the client about server-side events. This is where Comet comes in as described by Wikipedia:
Comet is a programming technique that enables Web servers to send data to the client without having any need for the client to request it.

Comet provides the means for the server to initiate a response to a client request, and later send a message to that client using the same response ­ for example, in the browser a message will "just" appear. Comet also provides clients with a way to register interest in specific types of messages. When the server publishes a message, it's delivered only to clients that previously registered interest in that kind of message.

Comet doesn't solve everything; in fact it creates some new problems. Using Comet means lots of outstanding requests, ideally one per client, and introduces similar scalability issues at the server as the AJAX polling technique. Keeping a separate thread allocated for each open request will exhaust the server's resources, so for this model to work properly, the Web server has to handle multiple requests without allocating one thread per request.

Asynchronous Request Processing
The idea behind Asynchronous Request Processing (ARP) is to manage incoming servlet requests asynchronously. Rather than committing a separate Java thread to synchronously process each servlet request, a single thread leverages Java NIO to detect when new information needs to be written to the response of any outstanding request. This technique provides a huge scalability win for the Comet use case, giving excellent performance even when there are a large number of outstanding, mostly dormant, requests at the server.

Although there's no standard defined for ARP several teams and projects are providing ARP solutions, such as Jetty Continuations and Grizzly. We take our hats off to these visionary teams providing everyday developers with ARP and Comet solutions.

Note: There's hope that ARP will be standard in the Servlet 3.0 and Java EE 6 specifications.

The Comet Messaging Protocol
With Comet and ARP we now have the means to build message-driven Web applications but, as mentioned earlier, W3C recommends at most two active connections from the browser to the Web server at any one time. Therefore, we'd prefer to have a single active connection being used for Comet notifications, leaving the other connection free to download images, CSS, and JavaScript or communicate with the server. This requires a way to manage multiple logical channels of information over a single shared Comet notification response.