We’re all familiar these days with the AJAX buzz word – but while it’s relatively simple to use these browser technologies to implement a specific feature in an individual page, it is much more complex to build an entire application according to the Ajax paradigm.
Especially with the advent of ASP.NET, the world of Web programming has been commoditized. Frameworks offer a thick layer of abstraction over basic HTML and HTTP interaction. And all of it works on the assumption that the browser sends an HTML form to get back an HTML page. It is relatively easy to change the paradigm for a single feature in a single page. It may be quite hard to extend the paradigm to the whole application. Why? Because the world of Ajax programming has not been commoditized. Yet.
Today, you have a lot of great tools for Ajax programming, but we are still waiting for the killer framework that makes the Ajax paradigm available to everyone. ASP.NET MVC 3 is taking steps in the right direction and so are some commercial products. Beyond that, there’s a virtually endless list of tools and libraries you have to combine together to build your ideal recipe.
This article offers a brief overview of a few aspects you might want to take into account for building successful applications.
The First Law of Ajax Development
The Second Law of Ajax Development
With Ajax, the client code gains the ability to bypass the browser and can handle the connection itself. Which HTTP endpoints should Ajax clients call? They can’t certainly be the same HTTP endpoints you would call via the browser’s address bar or page links. Here’s the second law of Ajax development: give your applications an Ajax specific service layer.
In software architecture, the Service Layer pattern is defined as “a layer of services that establishes a set of available operations and coordinates the application's response in each operation.” The definition is adapted from Martin Fowler’s excellent book “Patterns of Enterprise Application Architecture.” The service layer is the next stop on the way to the back end of an application after a user action.
In an Ajax context, the service layer is a collection of HTTP endpoints that Ajax clients will call. It contains URLs callable from clicks and taps of the end user. An Ajax request doesn’t likely need an entire HTML page; it probably wants just a bunch of data, presumably XML or JSON. You need to have these endpoints readymade in a well done Ajax application.
The Third Law of Ajax Development
Most of the time, these endpoints are under your direct control as they configure as the application layer of your system. Sometimes, however, the Ajax presentation layer needs to call into external, cross-domain endpoints. Cross-domain calls are not supported by browsers regardless of what the servers actually hosting the endpoints may think.
JSONP is an approach that today represents the best possible compromise between Ajax calls and cross-domain sites. The W3C has something in the works to make legal, authorized cross-domain calls seamless. The W3C released a working draft of a protocol known as Cross-Origin Resource Sharing (CORS) according to which clients place a request with a particular header and server reply with an ad hoc response header. Lacking the response header, browsers should refuse the response. This behavior is expected to be incorporated into the XMLHttpRequest object. To be precise, most browsers already implement this with the notable exception of Internet Explorer, including upcoming version 9. IE does have its own solution for cross-domain calls but it is based on a proprietary object. Waiting for CORS to become a standard, JSONP or JSON with Padding is today the most reliable and common way to implement cross-domain calls for sites that support the protocol.
In addition to location, HTTP endpoints for Ajax calls may also implement long-running tasks. Typically, you might want to be able to monitor and perhaps interrupt these tasks if they hang. You will learn on your own that no standard exist for this and not even frameworks. The reason is that the problem is open and solutions seem to be constrained to a project. However, if the endpoint is aware of being long-running and therefore monitorable and interruptible, something can be done with a bit of creativity and infrastructure. For example, you can identify each long-running Ajax task with a GUID and spawn a parallel timer that periodically checks the status of the task using the GUID. This requires you have a server-side persistent infrastructure where the running task saves its state that polling services can read.
Remember me on this computer
For functions that are available only to authenticated users a cookie is created at the successful completion of the authentication process. The cookie has its own expiration and for the duration of it the user is allowed to access protected pages without having to retype credentials. If the cookie expires, on the next access the user will be automatically redirected to the login page and gently asked to reenter user name and password.
This pattern may get you problems in an Ajax scenario. Your page places an Ajax call and the server detects that the authentication cookie has expired. The server returns a HTTP 302 status which redirects the user to the login page. However, in an Ajax scenario it’s the XMLHttpRequest object—not the browser—that handles the request. XMLHttpRequest correctly handles the redirect and goes to the login page. Unfortunately, the original issuer of the Ajax call will get back the markup of the login page instead of the expected bunch of data. As a result, the login page will likely be inserted in any DOM location where the original response was expected.
There are a couple of approaches you can take to solve the problem. One consists in intercepting the authentication phase of the request and checking whether the ongoing request is an Ajax request. The other consists in adding code to the actual login page to detect the Ajax call and return only a compatible chunk of HTML.
Writing Ajax applications is not the picnic that the availability of powerful and rich libraries and framework may suggest. Writing Ajax applications is hard because we have tools but not common and consolidated strategies. Quite clearly, it’s the ASP.NET paradigm that is on a dead track and we are trying to develop practices that one day someone will incorporate into a new super framework. When this happens it will be the beginning of the era of commoditization for Ajax development.