Architecture & DesignAJAX: Asynchronous Java + XML?

AJAX: Asynchronous Java + XML?

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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 approach1. 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.

Figure 1: Classic Web Application Model: Full page refresh and Synchronous Communication

Figure 2: 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.

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

Considering that AJAX represents a Web application model that is defined by partial screen update and asynchronous communication, there are different technologies for building the AJAX client engine, of which JavaScript, Java, and Flash are the most commonly used. Likewise, these three technologies are the most widely used in building AJAX applications.

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:

The JavaScript/DHTML approach (“Asynchronous JavaScript + XML”)

The JavaScript/DHTML approach typically uses a browser-based lightweight JavaScript library for client side processing, such as performing partial screen refresh and asynchronous background network communication. In this approach, the UI is typically defined by using DHTML and client-side application logic is programmed using JavaScript.

Some examples include Google Map (http://map.google.com) and Google Suggest (http://www.google.com/webhp?complete=1&hl=en).

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:

Option Strength Weakness
Java

  • Robust performance and reliability
  • Ease of maintenance due to object-oriented programming
  • Good for Java developers
Requires Java programming skills
DHTML/JavaScript

  • Fits well with existing HTML Web sites/Web applications
  • Good for DHTML Web developers

  • JavaScript/DHTML code is hard to maintain and not designed for team development
  • Performance and functionality limitations
Flash

  • “Sexy” animations
  • Good for graphics designers

  • ActionScript code is hard to maintain and not designed for team development
  • Performance and functionality limitations

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 DHTML/JavaScript approach fits well with existing HTML Web applications. It is natural for an existing HTML developer to write JavaScript, and the least expensive way of adding interactivity to an existing HTML application. In general, this approach requires the download of (potentially large) JavaScript libraries to compensate for the differing capabilities of the client browsers. The resulting applications are as rich as the underlying browser will allow. This approach can be problematic in large scale business applications due to difficulties developing and maintaining JavaScript, as well as performance/functionality limitations of DHTML.

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.

Conclusion

AJAX represents a generic application model that would enable more interactive, more responsive, and smarter Web applications. AJAX is not tied to a particular programming language, data format, or network object and is defined by two core attributes: partial screen update and asynchronous communication. There are three approaches to build and deploy AJAX applications: DHTML/JavaScript (Asynchronous JavaScript + XML), Java (Asynchronous Java + XML), and Flash (Asynchronous ActionScript + SWF). Each approach has its strengthes and weaknesses; as such, customers should evaluate and choose carefully.

Endnote

1. http://www.adaptivepath.com/publications/essays/archives/000385.php

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 cwei@nexaweb.com

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories