There have been numerous articles over the last year on how the complementary nature of AJAX and service-orientation together are rapidly transforming the way in which we design, architect, deploy, and manage applications. The ramifications of this change impact nearly every aspect of business application development, from design conception, architectural planning, and implementation to unit testing and monitoring. New methodologies, tools, and infrastructure are now emerging as the industry evolves from the three-tier system concepts that have dominated the last decade on the Web into the Service Oriented Architectures (SOA) currently being implemented.

Let's look at several major areas of application development and architecture that are shifting from three-tier implementation styles to AJAX and SOA implementation styles to deliver more powerful, high-performance, extensible, manageable, and cost-effective solutions:

• Client Side: Web pages are becoming applications.
• Web Protocols: Publish/Subscribe events and messages over HTTP are becoming peers with standard HTTP Request/Response.
• Server Side: Centralized, silo'd application deployments are getting plugged into Enterprise Service Buses to make way for massively distributed service deployments.
• Coding: Custom coding page-based GUIs is diminishing in favor of assembling solutions from ready-made parts and services.

Client Side: Pages Become Applications Unto Themselves
In many ways AJAX has provided the perfect complement to HTTP information services. AJAX is highly optimal at consuming raw information over HTTP, be it SOAP, XML, JSON, or other formats, and transforming that information into what the user sees on the screen. Both AJAX and SOA were born from taking the Hypertext Markup Language (HTML) out of Hypertext Transfer Protocol (HTTP) transmissions. Instead of a Web server generating an HTML page, it provides an XML, SOAP, or JSON data service with which any number of applications can communicate. And instead of a Web browser repeatedly, often redundantly, rendering a stateless, static HTML page received from the server, the browser gets and executes JavaScript to update portions or the entirety of the user interface within the stateful context of a single HTML page.

With the tremendous exploration of the relationship between AJAX and services that has occurred over the past 18 months, it's important to understand the difference between the ideas of "AJAX-enriched pages" and "AJAX applications." A quick peek at Yahoo!'s personalized homepages and Yahoo! Mail easily demonstrates the distinction. On the My Yahoo! page you get a variety of AJAX interactions within the page. You can drag-and-drop a content section to rearrange the layout, even remove an item from the page with an AJAX call in the background while it fades from view, then other content areas flow in to fill the gap. Pretty cool. But as soon as you click a content item, you go to a different page and so primarily navigate page to page to page. You go to the information, though some of it comes to you through AJAX without leaving the page. I call these AJAX-enriched HTML pages and the nuances they add atop static HTML are excellent enhancements.

Now try dropping in on Yahoo! Mail (beta). The experience there is akin to Microsoft Outlook. The semantics of the solution lack the concept of "page" altogether. Instead of navigating from page to page to page, information comes to you via tabs, alerts, windows, drag-and-drop, and the characteristics of robust software solutions. Of course the units of Internet advertising are based primarily on pages and navigating between them, so we'll certainly not see the page disappear. In addition, pages are great for documents, forms, reports, and lots more. At the same time, AJAX liberates us from the paradigms of the page so that we can deliver richer business productivity applications akin to the experiences of desktop installed software, but, of course, do so over the Web via the browser.

Where desktop-style applications were created in the past with VisualBasic, Java Swing, MFC, or the like, they can now be substantially created and deployed using AJAX techniques. And where GUIs for business productivity solutions were bound to the limited paradigms of HTML pages and forms, AJAX opens a whole new vocabulary of end-user interactions that go well beyond the tabbed pane and into sliders, editable grids, tree tables, hierarchical menus, modal dialogs, toolbars, vector graphics and charts, accordions, spinners, and date pickers.

AJAX libraries are already optimizing themselves for both AJAX pages and AJAX application-style implementations. Much the way that the Java language has .jsp for generating pages and that AWT, Swing and others have for generating software-style GUIs, AJAX is evolving with libraries focused on the value of enriched HTML pages or streamlining the process of creating richer, software-style GUIs. Therefore the question won't be "which AJAX library should I use" but "which collection of AJAX libraries should I use." For example, one of our customers (a large investment bank) uses Direct Web Remoting (DWR) for simple enhancements to HTML pages when it wants asynchronous access to its server-side Java environments and simple updates to the HTML elements with that data. In addition, it uses the Dojo Toolkit when it needs richer controls in those HTML pages. Finally, it uses TIBCO GI when it needs to deliver richer business productivity solutions as part of its core business processes. Three different kits used for three different problems. (Figure 2)

Web Protocols: Real-Time HTTP Messages and Events
Aside from the Web page, request/response communications are architecturally significant. This is what Web servers have been optimized to do for the last decade - get a request, send the response as fast as possible, and close the connection. Inherently, the HTTP protocol is much like flipping pages, going from one to the next, sitting idle in between. Accordingly, the user experience is diminished by the request/response limitation, coming up short relative to the streaming data and server-originating event capabilities of client systems that run outside the ubiquitous browser. (Figure 3)

One core limitation of going beyond request/response over HTTP has been that neither an HTML page nor JavaScript can currently register an IP address that a server can address messages to the way their thick-client cousins can. So AJAX vendors are working to provide solutions at the next best level - keeping the HTTP connection open so that as soon as data is available, it can be sent without getting a request from the browser first. The AJAX library DWR calls this "ReverseAJAX." Dojo is a contributor to the CometD project that's creating a persistent HTTP solution, and TIBCO is preparing to release its TIBCO AJAX Message Service product to extend message buses to the browser over an HTTP channel.

The persistent HTTP connection helps avoid the redundant polling loops approach that can tax a Web server with handling unnecessary requests, but nonetheless, traditional servlet contexts can face scalability challenges. The reality is that Web application servers are designed to get an HTTP request/response as fast as possible then close the connection. But just as the page is evolving into a stateful container for richer AJAX applications, the HTTP 1.1 protocol, now predominant in most application servers, provides the foundation for persistent HTTP connections capable of keeping a connection open so that multi-part information can be sent from the server to the client. The challenges aren't in the protocol itself, but in the server-side implementations as far as scale goes. The most scalable solutions today work outside the strict servlet specification's one-connection-to-one-thread rule by enabling thread pooling and hence more scale for pushing data through always-on connections. Besides, since there's a single pipe through which information must be pushed, savvier server-side implementations include notions of multiplexing - merging multiple streams of messages and events into a single stream through the single connection. Solutions using these techniques claim to have supported close to 10,000 concurrent connections on single-CPU machines and, at the same time, the servlet specification is under review with a view to shared threading.