Greg Wilkins of the Jetty Servlets Project also contends that the browser only provides two HTTP connections. So if one is always-on for instant information feeds, the other must be left for traditional request/response processes like getting images, files, and information that need not be sent instantly.

The exciting thing from a developer or architect's point-of-view is that persistent HTTP can blur the dividing line between client and server so that very low-latency events and messages at the client become the equivalent of events and messages at the server. And the conceptual diagrams of distinct client and server actors working across an Internet cloud get replaced with an "event cloud" in which both the connected clients and servers exist using server-side and client-side message buses to publish information to topics so that other parts of the system subscribing to those topics can intercept and handle the information accordingly.

Assuming support for 10,000 concurrent connections, the benchmarks being reported by vendors mean a single CPU implementing these techniques can be just as scalable as today's application servers doing request/response handling. I personally wouldn't use this technique if I were Google or Yahoo, both of which serve millions of users concurrently. However, for business productivity solutions where end-user communities are typically far less than 10,000, message- and event-based application architectures have much to offer as a general implementation technique for AJAX RIAs.

Having such a capability opens a wide range of potential applications and solutions that could be deployed using AJAX and further diminishes the gap between what's feasible in a browser and what requires pre-installation of specific runtimes or client software. Real-time applications like chat, streaming stock quotes, alerts and notifications in dashboards, and other types of collaborative applications become feasible, while avoiding the high cost of desktop-installed software or the overhead and user disdain of downloading and upgrading plug-ins. Moreover, such capabilities over HTTP are far more firewall-friendly than applet or plug-in approaches that may require additional firewall ports being opened - something business security folks abhor. Further messaging concepts also include the notion of queues, which are not only useful in real-time data solutions, but also when combined with offline persistence. Multiple AJAX toolkits have shown offline data capabilities. For example, Firefox now has native support for this capability and Internet Explorer allows 1MB of storage per domain. These capabilities assist in tasks like synchronization when a user goes back online.

So AJAX event and message paradigms can also ease the composition of GUIs in much the same way that Visual Basic development is streamlined by registering listeners for various events. Consider an application architecture where both services as well as GUI components can publish and subscribe to topics. On the client side, there's an event and message bus implemented in JavaScript connected via request/response. And there are persistent HTTP connections to the server-side message bus that connects the services through common governance, policy management, and SLA infrastructure. In such an architecture, instead of procedurally coding a request/reply to a service that explicitly handles the response data and updates the GUI, a user can use the publish/subscribe and asynchronous call interfaces in various AJAX toolkits to set up event listeners and event handlers that wrap calls to the services. That object then becomes a reusable bit of code that can be dropped into various solutions. Next, a GUI component, such as a data grid, can be configured to listen for the availability of new information from that service and so too can a history list, a log, and detail windows subscribed to information from those services. Thus, when data comes back from the service, an event is thrown and the GUI objects listening for that event handle it.

These approaches enable faster and more manageable development, and enforce reusable modular design patterns that facilitate efficient work among development team members. This leads to greater reuse of assets with much less chance of getting tangled in procedural JavaScript hairballs of code.

Enterprise Service Bus and Beyond
The highly visible, visual, and easy-to-find Google Maps remains the harbinger of AJAX for many in the industry. And while Google Maps certainly helped popularize the idea of AJAX through the unique experience it offered end users, equally noteworthy is the underlying service Google exposes to overlay information on the maps. The service interfaces are savvy, accepting input in many variations of addresses, landmarks, and cities, resolving those close-to-natural-language phrases and returning the relevant data sets in milliseconds. Kudos to Google for not only exposing the breakthrough GUI capabilities of AJAX to the masses, but also for backing it with scalable services that could handle the ways in which humans want to ask for information (not to mention the data store behind the system with all that information). Google Maps stands out because the solution is non-trivial at all these levels and should be heralded for its accomplishments.

However, let's get back to business and to the heterogeneous, diverse, and more complex reality that most of us creating business solutions must grapple with. While Google Maps stands out as exemplary, it's also an anomaly in the context of 99% of the business we do every day as creators and users of software solutions. Google has the advantage of being able to create, maintain, and optimize that one phenomenal service and publish that one sexy GUI for others to use or overlay in mashups with data from other data relevant to geographic contexts (and without having to generate revenue from it too). But what happens if you have five services to implement and manage? Probably doable without much other infrastructure, right? What about 50 or 500? What about 5,000 services? Not to mention the hundreds of application screens that will interact with those services. Those might seem like large numbers compared to simple use cases and solutions. But the reality for independent software vendors, solutions consultants, and corporate IT shops creating enterprise solutions is that support for hundreds (if not thousands) of services is or will soon be required as enterprises mandate interoperation with their SOA infrastructures in their procurement and vendor selection processes. (Figure 4)

When dealing with integration challenges due to the number of components in a system like those, it's been generally accepted that message bus architectures address these kinds of issues best. In fact, Sun's JSR-208 specification Java Business Integration (JBI) has an Enterprise Services Bus at its core, extended for use with a variety of Web Service types. Beyond Java, TIBCO's implementation of the JSR-208 specification in its recently announced ActiveMatrix product has demonstrated support for .NET containers and services as well on the same infrastructure. Thus the homogenous three-tier, platform-specific architectures of the past decade are giving way to heterogeneous service-oriented systems managed by service-bus architectures, even crossing the great Java versus Microsoft dividing line. Services can be implemented in a variety of languages, but are then normalized into XML, SOAP, JSON, or other formats for consumption by other systems of potential varying types. Systems with multiple service endpoints can leverage message bus architectures at the core to provide needed integration conduits between systems, enabling massively distributed systems with centralized governance and policy management by virtue of the bus. In contrast, from a policy and governance point-of-view, the three-tier Web application server world is inherently more difficult to manage across disparate systems that don't share the common infrastructure of the bus. The good news is that these bus architectures are designed so that you can plug your existing assets into them. So get on the bus.

Less Code, More Use of Ready-Made Parts
AJAX and SOA also pave the way to faster solution development. As described earlier, an implementation centered on event and message paradigms enables significantly more manageability around client-side and server-side components and fosters a greater opportunity for reuse of such components. Clearly, reuse is understood in the context of SOA where a single service can have multiple consumers and so greater value in relation to the cost of building and operating that service. One can see similar trends on the client side enabled by AJAX as well. Reusable AJAX GUI components like editable data grids, charts, sliders, color, and date pickers are now readily available. Instead of building these up from DIV and SPAN tags, you can now include the higher-level notion of an editable data grid and configure its behaviors as well as its look-and-feel. Numerous AJAX toolkits provide these kinds of ready-made widgets for use in applications. The mashup craze also makes this readily evident. For example, an investment in creating the orchestrating logic (not the service or the GUI components) enables you to take a GUI from location G, and overlay it with data from sources C and D.

But as we discussed before, in business environments things can get more complex, quickly. Google and craigslist have the enviable simplicity of being publicly accessible. In the business world, not everyone is privileged to access a service, do certain tasks, or see certain information. Here again, centralized policy management across a message bus architecture greatly reduces the complexity of creating AJAX and SOA solutions and deals with cross-domain security issues in a managed context.

Conclusion
AJAX and SOA will continue to erode the need to develop and deliver installed software solutions. Many developers are getting started in the evolutionary process by adding some AJAX and a few services to the basic three-tier infrastructure they have in place today. However, businesses seeking to gain greater benefits need to look to rich AJAX applications in concert with Enterprise Service Bus infrastructures capable of governing hundreds or thousands of services. In addition, the advent of scalable real-time protocols over existing HTTP connections will further enable rich client/server-style business applications to be implemented and managed more efficiently, further displacing installed runtimes and software.