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.
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.
Source:
http://dotnetslackers.com/articles/ajax/Where-is-the-Right-Way-to-AJAX.aspx
