One thing is using AJAX to dynamically refresh a small piece of a single page; all another thing is designing a whole presentation layer to be partially refreshed in every possible operation against the server. An individual feature can be happily and nicely coded using a smart piece of JavaScript; a whole Web presentation layer will cost you a lot more if done entirely in JavaScript.

Sure, new productivity tools are created every day (from the popular jQuery library to the upcoming ASP.NET AJAX 4.0 framework), but the most effective way of adding AJAX to applications continues to be the subject of research and begins to look like the Holy Grail of Web software.

Based on what common sense suggests and looking at what vendors (including Microsoft) are doing in the AJAX arena, I feel to say that two main approaches exist to AJAX. Simply put, the two approaches differ for how much work they require you do on the client. There’s the “traditional” approach that preserves the server-side lifecycle and just finds a smart way to bypass the browser standard actions. And there’s the “pure” AJAX approach that tells you to move most of the workload and application logic on the client.

However, these two approaches are nothing more than a guideline and needs be translated into architectural patterns to be really helpful and drive a new generation of Web applications.

No recognized names exist (that I’m aware of) to indicate the aforementioned architectural patterns. So I’ll take the initiative of referring to them as the “AJAX Server Pages” and the “AJAX Service Layer” pattern respectively.

AJAX Web Architectures

At the highest level of abstraction, Web applications are client/server applications that require an Internet connection between the two layers. Before AJAX, this connection was incorporated in the special client application—the browser. The browser opens the connection, clears the user interface, and then updates the screen with the results of a server operation.

With AJAX, the client code has the ability to bypass the browser and can handle the connection itself. This enables the client to enter user interface updates without fully refreshing the displayed page—a great step forward towards usability and rich user experiences.

To make the usability of Web applications grow as close as possible to that of desktop applications, the overall software platform must fulfill two key requirements. One is a client-side infrastructure that can manage the Internet connection with the server. The other requirement is the availability of a public and known programming interface on the server—the AJAX-specific service layer.

The “AJAX Service Layer” Pattern

Any AJAX solution is made of two main layers neatly separated, but communicating—the JavaScript and HTML presentation layer and a service layer that acts as a façade of HTTP endpoints. Figure 1 gives an overview of the architecture.

Figure 1: A typical AJAX architecture.

The presentation layer is hosted in the browser and communicates via HTTP with an ad hoc façade made of URLs. Behind the URLs, you have server code at work. The server code can be exposed in a number of ways according to the programming API of choice—for example, Windows Communication Foundation (WCF) services.

The data being exchanged between the presentation and the HTTP façade depends on the client and server API and their capabilities. Most of the time, albeit not always and not necessarily, the serialization format of choice is JSON.

The communication between the HTTP façade and the rest of the system happens either locally or over a protected network environment where only trusted callers are allowed.

The HTTP façade just reworks a more convenient API for the presentation layer to call. The API is built on top of application services and workflows. The HTTP façade just scripts these middle-tier components from the client.

The architectural relevance of the HTTP façade is all in that it decouples the middle tier from a very special presentation layer such as an AJAX presentation layer. An AJAX presentation layer is special essentially because it is a partial trust Web client.

For security reasons, service technologies hosted on the Web server require special adjustments to enable JavaScript callers. In addition, it is likely that some of the application services you have in the middle tier run critical procedures. Any piece code bound to a URL in the HTTP façade, instead, is publicly exposed over the Internet. Not an ideal situation for a business-critical service. So decoupling application services from the AJAX presentation layer is a measure of design but especially security.

The HTTP façade is the list of public URLs known to, and managed by, the AJAX presentation layer. In an AJAX scenario, the presentation layer is only made of JavaScript code. All the logic you can’t, or don’t want to code in JavaScript, must be referenced on the server. Public HTTP endpoints are the only point of contact between AJAX clients and server applications. In the .NET Framework 3.5, you can write endpoints callable by AJAX clients using a number of technologies including WCF, ASMX Web services, ADO.NET Data Services, and in general any way you have to expose public URLs including plain old ASP.NET HTTP handlers.

ASP.NET AJAX 3.5 provides an excellent infrastructure for building around the “AJAX Service Layer” architectural pattern. You get free JavaScript proxies to invoke mapped services from the client and a couple of powerful client libraries (Microsoft AJAX library and jQuery) to arrange the part of your application logic you put on the client.

With ASP.NET 4.0, the client-side equipment will be empowered to support (and very well indeed) the most common scenario—rich data binding.

The “Active Server Pages” Pattern

The “AJAX Server Pages” pattern refers to the working style of ASP.NET pages that employ a new generation of AJAX-enabled server controls. These controls work over the classic postback model of ASP.NET, except that use asynchronous requests and exchange a mix of script and markup.

According to the “AJAX Server Pages” pattern, AJAX capabilities of a page mostly result from the individual AJAX capabilities of constituent controls.

The biggest difference between classic ASP.NET controls and AJAX-enabled server controls is in the amount of JavaScript code emitted. Whereas smartest among classic ASP.NET controls (i.e., validation controls) only emitted small chunks of JavaScript code, AJAX-enabled server control link a full client-side object model realized in JavaScript.

For example, an AJAX-enabled Label control will group in a JavaScript function a set of methods for client code to refresh the rendered markup. Here’s a brief excerpt written using the Microsoft AJAX Library.

A client-side object model for each control is essential in an AJAX application that uses server controls. An AJAX-enabled control differs from a classic ASP.NET control because it emits markup and JavaScript. However, the emission of JavaScript is not limited to just the few lines required to support a specific feature (such as quick validation checks on user input), but cover the whole behavior of the control, especially including the interaction with the user and the postback.

In the “AJAX Server Pages” pattern, an AJAX control that governs its own postbacks returns (a description of) the updated delta of its markup and maybe of other controls in the page. The updated markup is then easily applied on a per control basis if each control has its own client object model.

Having a JavaScript model for each control also makes it easier to arrange data binding and updates that merge in the page DOM data calculated by server methods. Realistically, to have a JavaScript model for each control you need to pick up a commercial library. (ASP.NET 4.0 may, however, reserve some pleasant surprises on this side. Not much of it is known, though, at the time of this writing.)

Products for the “Active Server Pages” Pattern

In ASP.NET 3.5, you have partial rendering that allows taking a group of controls, binding them to postback triggers and refresh their content. How is “Active Server Pages” different from partial rendering? By “Active Server Pages” I intend a pattern whereas partial rendering is a concrete technology that to some extent implements the pattern. So it can be called as the ASP.NET idiom for the “Active Server Pages” pattern.

Beyond this, though, partial rendering is a bit rudimentary and suffers from a couple of important limitations: ViewState transmission and simultaneous calls. The partial rendering approach transmits the entire ViewState of the page and doesn’t allow for simultaneous calls. A library may improve on these aspects by segmenting the ViewState and implementing a queue for concurrent requests. It must be noted, in fact, that the “AJAX Server Pages” pattern works atop the classic postback model and as such can’t really handle multiple requests at a time.

Let’s see how a commercial library—Gaiaware—implements the AJAX Server Pages pattern.

The latest Gaia AJAX library features server controls whose level of abstraction is really close to that of standard ASP.NET controls. Most of the Gaia AJAX controls inherit from their ASP.NET counterparts. This means, for instance, that every single property you have in, say, System.Web.UI.WebControls.Button will also be available in the Gaia AJAX Button control.

In a certain way, Gaia AJAX doesn’t simply provide a library to do some good AJAX programming—it really replaces ASP.NET basic controls with new controls that support AJAX from the grounds up.

All of these controls fire a server-side event when their state is changed on the client. The connection with the server is obviously asynchronous and nearly identical to a classic ASP.NET postback. As a developer, you don’t need to write a single line of JavaScript code and no markup is explicitly returned to the client.

Asynchronous postbacks and no markup returned? Where’s the magic?

Quite simply, Gaia AJAX controls record their server changes and have an internal component to serialize changes through JavaScript code to run on the client. Here’s an example:

When you click the button, the following managed code is run:

Is this really AJAX? Isn’t it plain ASP.NET, instead? In any case, it delivers AJAX to your customers. Under the hood, a Gaia control emits JavaScript code to be evaluated and executed on the client. This JavaScript code records all changes operated server-side on Gaia controls. The ViewState is not transmitted entirely; only the section of it that changed is returned.

With Gaia you can place multiple calls simultaneously and have the library queue them and execute sequentially. All of this happens silently and automatically.

Summary

It will come a day when we talk of the Web without feeling the need to further characterize it by adding the word AJAX. This day we will probably have one clear and mostly unique way to trigger and complete asynchronous operations over the Web. Two architectures exist today; products and frameworks can’t really be anything much different.

About Dino Esposito

Dino Esposito is one of the world's authorities on Web technology and software architecture. Dino published an array of books, most of which are considered state-of-the-art in their respective areas. His most recent books are “Microsoft ® .NET: Architecting Applications for the Enterprise” and “... This author has published 31 articles on DotNetSlackers. View other articles or the complete profile here.