The next opportunity for boosting revenue in web connected businesses is upon us. Rich internet applications delivered by Ajax, and server push (Comet) bring real improvements in data input through real time validation, real improvements in sales conversions, and great experiences that customers pay for with Software as a Service (SaaS) providers. However, if that increased revenue is to yield increased profit rather than get overwhelmed by increased costs, engineering and IT managers need to avoid the two primary ways of falling into a money pit: inappropriate server scaling methods, and reinventing the communications wheel.

First, let us explain the source of the Java server scaling problem, and how to solve it through incremental improvements. The industry's primary Java servers allocate resources such as processing threads and memory on a per user basis. They do those allocations synchronously. That is, as long as the request from a user is outstanding, all of those resources are unavailable to other users regardless of whether the server is actively processing some business process, or just waiting for a slow moving database or web service to respond. This method was straightforward to implement, and quite effective for the static web of old. That synchronous method worked because even for moderate sites of perhaps 10,000 simultaneous users, only approximately 200 would actually have an outstanding request at any particular moment. The rest of the users would be reading text, filling out a form, or looking at images. Only the user could initiate a request, and no real time updates were possible.

In today's world, however, to move to a real time responsive application, requests and interactions stay open perhaps for minutes at a time, and nearly all users will be active from the perspective of the server. Today's hardware cannot generally allocate threads and memory on the scale required to scale yesterday's synchronous methods for today's applications' needs. At Webtide, we have found that scaling the synchronous methods into real time Comet applications can increase server requirements 10x or more. An alternative way to look at the problem is that there are few applications that have a business case running only a few dozen or hundred users on a server.

Moving incrementally to asynchronous methods, such as with Jetty's asynchronous servlets (also known as continuations), managers can maintain usage of open implementations of open standards, and vastly improve the scalability of their servers for Web 2.0 rich applications. Threads and memory are used only while actively processing work related to a request. While waiting for the next bit of information, or response from a database, they can be put to sleep and freed for other processes to use. They can then rapidly be woken as needed to continue interactions. We have found that rather than 10x+ increase in server requirements, applications can be deployed with only a few percent increase. This increase in efficiency brings rich internet applications firmly into the realm of the feasible.

Feasible, that is, as long as developers don't fall for the second trap: directly using the browser's communication mechanisms. When they directly connect with the server using the XML requester, developers nominate themselves to be middleware maintainers, and comms traffic cops. What can seem like a simple request for XML can get more complicated with browsers that are limited to two connections to a server. If a user is watching multiple auction items in tabs or if an application is repurposed into a mash-up or portal, then managing those connections while maintaining responsiveness can take some creativity.

All too often those ramifications are not thought of until it is too late to deal with them cheaply. Instead, users should examine the Cometd implementation of the open Bayeux protocol (http://cometd.com). In a few kilobytes, users get a bidirectional message bus over HTTP. Intricacies of connection sharing, efficiencies of request batching, and security improvements such as filters on communications channels (to screen out potentially malicious entries) all come along with decreased development time. Developers of financial, gaming, or other applications should hopefully be able to focus their efforts on their differentiating value, rather than recreating internal middleware plumbing that should be common to nearly all applications.

Application providers should certainly move to rich internet applications through Ajax and Comet. The increase in profits for existing programs, and opportunities for entirely new businesses are compelling. Taking a moment to consider the impacts on the server side, and the proper ways to handle the increase in complexity of message traffic will pay rich dividends and save you from headaches down the line when you move from prototype to deployment. Otherwise, exposing applications to real world loads can bring some nasty surprises. ENS