The Big Shift with AJAX and Web Service Bus Architectures

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:

In general this evolution can be summarized as moving from homogenous, language- and vendor-centric solutions, to the mixed environment, heterogenic systems typical of a business information system. (Figure 1)

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.

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.

© 2008 SYS-CON Media