Printer Friendly Version

Gmail, GoogleSuggest, and GoogleMap opened the eyes for millions of netizens to a "new" Web: a smarter, more responsive, and more interactive Web that does not employ a foolhardy "click, wait, and refresh" approach. For the first time, the vast majority realize the Web can be much better than what they have assumed.

Developers were the first to notice this. In fact, the developer community was jazzed about the technical approach that Google used. In February 2005, AdapativePath's Jesse James Garrett coined the phrase "AJAX" as "Asynchronous JavaScript + XML" to describe this approach. In particular, he pointed out the usage of "XMLHttpRequest" object for doing asynchronous communications as a key enabler. Ever since, the term "AJAX" has spread like wildfire.

However, given its widespread use, there is a lot of confusion around AJAX. For example, does AJAX have to be tied to a specific programming language such as JavaScript? Does the data used in an AJAX application have to be XML? What if the application wants to represent the data in a different format? Does AJAX have to be tied to a specific native object like "XMLHttpRequest"?

In other words, is AJAX simply "Asynchronous JavaScript + XML," or can AJAX include something else, such as "Asynchronous Java + XML?"

What Is AJAX?

Fundamentally, AJAX represents a generic application model that would enable more interactive, more responsive, and smarter Web applications.

The Web was originally designed for browsing HTML documents. As a result, the classic Web application model adopts a "click, wait, and refresh" user interaction paradigm and a synchronous request/response communication mechanism:

1. "Click, wait, and refresh" user interaction paradigm: A browser responds to a user action by discarding the current HTML page and sending an HTTP request back to a Web server. The server completes some processing and then returns an HTML page to the browser. The browser refreshes the screen and displays the new HTML page.

2. Synchronous "request/response" communication model: The browser always initiates requests, whereas the Web server merely responds to such browser requests. The Web server never initiates requests—the communication is always initiated one-way. The "request/response" cycle is synchronous, during which the user does not have to wait.

However, these two fundamental behaviors of the classic Web model do not work well for software applications. In the context of software applications, the classic Web application model creates many problems: slow performance due to "click, wait, and refresh;" loss of operation context during page refresh; excessive server load and bandwidth consumption due to redundant page refreshes; and lack of two-way, real-time communication capability for server initiated updates.

In the context of software applications, "click, wait, and refresh" and "synchronous request/response" result in slow, unreliable, low productivity and inefficient Web applications. These two basic behaviors must be altered to produce higher performance, more interactive, more efficient Web applications—precisely what the AJAX application model does. In the AJAX model:

1. "Partial screen update" replaces the "click, wait, and refresh" user interaction model. During user interaction within an AJAX-based application, only user interface elements that contain new information are updated; the rest of the user interface remains displayed without interruption. This "partial screen update" interaction model not only enables continuous operation context, but also makes non-linear workflow possible.

2. Asynchronous communication replaces "synchronous request/response model." For an AJAX-based application, the request/response can be asynchronous, decoupling user interaction from server interaction. As a result, the user can continue to use the application while the client program requests information from the server in the background. When new information arrives, only the related user interface portion is updated.

Classic Web Application Model: Full page refresh and synchronous communication.

Ajax Model: Partial UI updates and asynchronous communications.

Because the essence of AJAX is partial screen updates and asynchronous communication, the programming model is not tied to a specific data exchange format (such as XML), specific programming language (such as JavaScript), or specific communication mechanism. For example, Google could have developed GoogleSuggest using VBScript when running on Internet Explorer. In fact, most of the data exchanged in GoogleMap is actually in GIF image format, not in XML. In addition, much of the data exchange in Gmail is actually based on HTML, rather than on XML.

In summary, AJAX is not specific to a particular programming language, data exchange format, or network communications object. It is a Web application model that employs partial screen update and asynchronous communication.

AJAX Architecture

From a software architecture point of view, following are ways in which AJAX differs from today's Web application architecture by adding a client-side engine:

1. Use of a client-side engine as an intermediate between the User Interface (UI) and the server;
2. User activity leads to program calls to the client-side engine instead of a page request to the server;
3. XML data transfer between server and the client-side engine.

Classic Web application architecture.

Ajax architecture.

Page 2: Different Technology Options for AJAX