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.
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:
- “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.
- 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:
- “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.
- 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.
Figure 1: Classic Web Application Model: Full page refresh and Synchronous Communication
Figure 2: Ajax Model: Partial UI Updates and Asynchronous Communications
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.
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:
- Use of a client-side engine as an intermediate between the User Interface (UI) and the server;
- User activity leads to program calls to the client-side engine instead of a page request to the server;
- XML data transfer between server and the client-side engine.
The client engine is the key to the AJAX model. Without this engine, every user event must go back to the server for processing. User interaction is tightly coupled with server communications—the client engine unlocks this dependency. This engine, while running inside a Web browser, gives the browser the “extra” intelligence to perform a “partial screen update” instead of a “full page refresh.” This engine also communicates with the server in the background, decoupling user interaction from server communications.
Figure 3: Classic Web Application Architecture
Figure 4: Ajax Architecture
Different Technology Options for AJAX
The Java approach (“Asynchronous Java + XML”)
The Java approach typically uses a browser-based lightweight Java engine for client side processing, such as UI rendering, performing partial screen refresh and asynchronous server communication. In this approach, the UI can be defined using XML, whereas client-side application logic is programmed using standard Java.
Examples available over the Internet include:
- Artstor.org (http://www.artstor.org): a digital library of hundreds of thousands of pieces of art work and related tools.
- Map of the Market (http://www.smartmoney.com/marketmap/): an interactive map showing an aerial view of 1,000 U.S. and international stocks
The Flash approach (“Asynchrounous ActionScript + SWF”)
The Flash approach typically uses a browser-based Flash engine with an ActionScript library for client side processing. In this approach, the UI is typically defined using SWF (a Macromedia proprietary binary format for defining Flash based movies) on the client side, and the client-side application logic is programmed using ActionScript.
Some examples include BroadMoor Hotel (http://www.broadmoor.com/), a Flash-based interactive hotel reservation system.
Strength and Weakness of Different Options
Each of the three AJAX options has its own strengths and weaknesses, making each one suitable for different applications. The following table summarizes their strengthes and weaknesses:
|Requires Java programming skills|
The Java approach is capable of delivering good performance and functionality due to binary execution, multi-threaded computing, and the industrial strength of Java Virtual Machine. Applications written in Java are easy to develop and maintain because of the object-oriented programming nature of Java. It is good for enterprise Java developers who have Java programming skills. On the other hand, the Java programming skills requirement is also its weakness, because developer skill set requirements are higher than scripting. Historically, JVM compatibility in various browsers has been a significant issue for this approach. However, there are solutions available for these problems. One solution is to utilize a lightweight, JDK 1.1-compatible Java engine that is guaranteed to run inside all browser-based JVMs. This Java engine would abstract developers away from the traditional problems, enabling the development and universal deployment of Web applications by leveraging the strength of Java.
The Flash-based approach is good for applications that require a “sexy” look and feel. It is a natural option for graphics designers. Flash enables developers to create very rich user interfaces, given Flash’s heritage as a “movie engine.” To date, Macromedia has targeted Flash for three use cases in the context of applications: guided selling, guided forms, and dashboards—primarily consumer facing or data visualization applications. Flash applications can access Java and .NET objects running on the server asynchronously. The major limitations of this approach are ActionScript and the limited capability of the Flash engine. ActionScript is a proprietary scripting language developed by Macromedia. It is easier to do scripting than programming for simple tasks, but developing and maintaining many scripts is difficult and expensive for more complex applications. Flash is not an industrial-strength virtual machine like JVM or .NET CLR; as a result, there are functionality and performance limitations for Flash-based applications.
There is no doubt that all three approaches are viable and each has success stories to prove it. However, choosing the wrong approach for the job also can be devastating.
Taking AJAX a Step Further
AJAX addresses some of the problems of the Web today, but there are still significant problems that AJAX does not address. For example, how do you make Web applications offline available? How do you enable server-initiated communications? How do you guarantee consistent performance, as well as reliability for Web applications, given that HTTP is not reliable and Internet performance is inherently limited by network conditions?
AJAX itself is not the destiny, but rather a leading indicator of how the Web application model is evolving. All of the above problems must be addressed for the Web to become a truly available, reliable, and performance infrastructure for software applications.
About the Author
Coach K. Wei, Founder and CTO, Nexaweb Technologies combines in-depth IT industry expertise with extensive education and research experience at MIT to provide the vision for Nexaweb. He founded Nexaweb in 2000 and served as CEO until summer 2003. At Nexaweb, Coach is responsible for driving technology innovation and business direction that successfully enables enterprises to securely migrate large-scale enterprise applications to the Web — commonly known today as Rich Internet Applications (RIAs).
Before founding Nexaweb, Coach architected and designed enterprise software for managing storage networks at EMC Corporation. As a graduate researcher at MIT, Coach developed software and hardware systems for non-destructive evaluation as well as signal/image processing algorithms. Coach was a finalist in the 1999 MIT $50K entrepreneurship competition and is the holder of several US Patents. He holds an MS in Information Technology from MIT.
Coach has published numerous articles on various topics including AJAX, J2EE and .NET, RIA development, XML, signal/image processing, composite materials, ultrasonic imaging and software. Additionally, he has spoken at leading industry events, such as JavaOne and Web Services Edge. You can contract Coach Wei at email@example.com