Rich Internet Applications and AJAX - Selecting the best product

There are hundreds of criteria for evaluating RIA and AJAX products. So many that it’s easy to lose focus and misjudge priorities. This essay proposes a decision tree that leads through an evaluation process. It asks for the most distinctive requirements and product features in a top-down sequence, discussing the essential differences between technology options.
Figure 1: Decision Tree
The focus is entirely on questions you should answer when evaluating RIA products. There is no assessment of specific products, because the individual features of products tend to obscure fundamental issues. Notice that RIA and AJAX are sometimes used as synonyms. This is not entirely correct: AJAX is short for “Asynchronous JavaScript And XML”, which essentially limits the term to the set of RIA solutions based on JavaScript. I will adhere to this latter definition, although I fully agree with authors who argue that the concepts proposed by AJAX are by no means limited to JavaScript [1].
Simple User Interface?
The first and most important question to ask is whether the user interface (UI) of your application is simple enough for HTML. If the answer is yes, then HTML is your best option because it enables ubiquitous end user access via browser.
Simple enough for HTML means that the UI has modest interactivity requirements. However, if any of the following features improves your UI, you should consider RIA technology:
Partial screen updates Asynchronous communication Server push Widgets supporting direct manipulation Multiple coordinated windows Modal dialogs Menus Keyboard navigation
RIA technology provides rich client capabilities in a web infrastructure. The goal is to combine the advantages of desktop applications with those of web applications. There are three fundamentally different technology options to achieve this: JavaScript, Java, and Flash. Their respective core advantages lead to the next level of the decision tree.
Ubiquity, Industrial Strength, or Fancy Animations?

Figure 2: RIA Technology Subtree
The question that differentiates RIA technology is whether unconditional end user access via browser (ubiquity), industrial strength, or fancy animations are most important. If ubiquity is the answer, a JavaScript/AJAX based solution will be the favorite, because JavaScript is available “out-of-the-box” in every popular browser. If industrial strength characteristics like maintainability, reliability, availability, scalability, performance and security are the top requirements, a Java solution is likely to be the front-runner. Java is unquestionably superior to the scripting alternatives in these areas. Last but not least, if fancy animations are your primary requirement, the attractiveness of Flash may outweigh the arguments speaking for the alternatives. The following sections look closer at these three technology options and present questions you should ask when assessing corresponding products.
Ubiquity: JavaScript/AJAX

Figure 3: JavaScript/AJAX Branch
AJAX is neither a product nor a new technology but a new branding for RIA technology that is based on JavaScript, XML, and other technologies. Since most JavaScript based products have adopted the AJAX terminology, it’s reasonable to put them in a single category. JavaScript/AJAX products are appropriate in situations where the user expects an application to work unconditionally in browsers. When buying a DVD or booking a flight, for instance, nobody will want to install a plug-in.
Plain HTML remains the best solution for simple UI requirements. Yet, DVD stores or travel booking applications with simple UIs are often vexing or even useless. Anyone who has tried to book an itinerary with multiple flights, hotels, and rental cars will agree that current websites are painful to use. JavaScript/AJAX could help here. Unfortunately, there’s only a handful of “killer” applications that show what’s possible: Google Suggest and Google Maps are among them. Cited as the key examples by Jesse James Garrett in his defining article on AJAX [2], they are arguably the most popular JavaScript based RIAs on the web.
Selecting RIA products based on JavaScript/AJAX is challenging. The issue is that JavaScript is hard to deal with. It’s no coincidence that it took the skills and funds of Google to come up with “killer” applications. Internet giants like Amazon or Ebay are not leveraging the potential of JavaScript/AJAX, although the technology has been around for years and would potentially improve their websites substantially. Just imagine how their sites would profit by “search as you type”, scrolling lists, partial screen updates, or browseable category trees.
The following questions will help in deciding whether an RIA product based on JavaScript/AJAX is suitable for your needs.
Browsers and OS supported?
JavaScript implementations are not standardized across browsers and operating systems. This means that programs must be aware of the browser, the operating system, and their respective versions. Programs must execute different code depending on specific combinations thereof, which is a developer’s nightmare. The most essential characteristic of a JavaScript/AJAX product is, therefore, how well it handles these combinations and shields the developer from the complexity of managing them in application code. The combinations supported by the Google applications may serve as a benchmark for evaluation. Google Maps and Google Suggest support:
IE 6.0+ on Windows Firefox 0.8+ on Windows, Mac, Linux Safari 1.2.4+ on Mac (Google Suggest 1.2.2 or newer) Netscape 7.1+ on Windows, Mac, Linux Mozilla 1.4+ on Windows, Mac, Linux Opera 8+ on Windows, Mac, Linux (Google Suggest 7.5.4+)
RIA Functions?
JavaScript was designed for scripting rather than full-fledged rich client development. For this reason, a JavaScript/AJAX product may not necessarily support all RIA functions mentioned. Partial screen updates, asynchronous communication, modal dialogs and menus will probably be available. But other RIA goodies may be severely limited in functionality or missing altogether. Typically, the set of rich UI widgets that supports direct manipulation will be poor compared to those we find in toolkits for desktop applications. Important questions to ask include:
how does the widget set compare to standard sets like those of Java Swing? is the look&feel adaptable? is there an API for the development of new widgets? is it possible to integrate third-party widgets? what is the market for third-party widgets? is there support for Accessibility?
How Strong?
Industrial strength characteristics like maintainability, reliability, availability, scalability, performance and security are a challenge for JavaScript/AJAX products because they have to rely on a scripting language and must work in a heterogeneous set of execution environments. It is unrealistic to expect the kind of industrial strength that can be found in a homogeneous Java product. Yet, there is a wide range of options regarding the amount of code that needs to be executed in the shaky JavaScript environment. The complete range of architectures shown in Figure 4 is feasible.

Figure 4: RIA Architecture Options
JavaScript code can be limited to an application-independent presentation engine that comes with the product, as illustrated by the rightmost option in Figure 4. This pure thin-client approach has several advantages: applications can be written entirely in Java, with a single programming environment. Moreover, there is a homogeneous server-side programming model, and no need to distribute the application code between client and server, nor between different programming languages. This simplifies both development and testing substantially. Finally, the application code will execute primarily in the robust server-side environment.
Note that pure thin-client architectures are rare in JavaScript based UIs. The typical approach is to split the functionality between client and server individually for each application as shown by the three left-hand options in Figure 4: either within the presentation logic, within the business logic, or between business logic and data. The leftmost option represents a pure fat-client architecture where the entire application code is written in JavaScript. Fat-client or hybrid approaches may be appropriate for certain scenarios. But for industrial strength characteristics, a pure thin-client architecture is preferable. Crucial questions are, therefore:
what architecture is supported or enforced: thin, fat, or hybrid? is the programming model server-side or distributed? is application code written purely in Java or in a heterogeneous mixture of languages including JavaScript, Java, and proprietary XML languages? how much of the product’s code is JavaScript? how can security be handled?
Industrial Strength: Java

Figure 5: Java Branch
RIA products that are based entirely on Java have the best foundation for industrial strength. Java’s solid standards base, homogeneous technology, broad choice in high-quality tooling, and bright perspective regarding future enhancements ensure that a well-designed product can be maintained cost effectively and for any length of time in the foreseeable future. Reliability, availability, scalability and security are given on a wide array of platforms.
Designed for full-fledged productivity applications, Java’s UI technology leaves nothing to be desired regarding rich-client functions. There are comprehensive, customizable widget toolkits for desktops as well as mobile devices, and numerous third-party libraries.
In contrast to many JavaScript products, Java RIA offerings typically follow a thin-client approach as shown by the rightmost picture in Figure 4: the client is an application independent presentation engine that can be executed either as an applet in a browser, or as a Java program on the desktop, or even on a PDA.
The questions that distinguish Java RIAs ask for the JREs (Java Runtime Environment) supported, the UI libraries employed, and leverage of Java standards.
JRE Versions Supported?
Compared to the execution environments for JavaScript, JRE implementations are more standardized. Programs written with a specific JDK (Java Developer’s Kit) will usually run in the corresponding JRE, irrespective of whether this JRE is running within a browser, on a desktop operating system, or on a device like a PDA. The version issue is primarily raised on the level of the JRE and the target environments that support that JRE.
Most RIA products support multiple JRE versions. Some are based on JDK 1.1 with its AWT widget library and will run on JRE 1.1 or later. Others are using Swing and will run on JRE 1.2 or later. The respective pros and cons of earlier or later versions must be evaluated carefully, because the earliest version supported defines the “least common denominator”. A low “denominator” product based on the low-level AWT will often run on more JREs because later Java versions are fairly downward compatible. A high “denominator” product based on the higher-level Swing will be able to leverage the improvements of new Java versions. The most important questions are:
what are the target devices/environments for the end users? which JREs are available and easily installable on the targets? on which JREs does the product run? which JRE is the “least common denominator” of the product? does the product leverage improvements of later JDK/JRE versions?
UI Libraries Employed?
Java’s client-side UI technology has evolved substantially. The initial low-level library AWT has been complemented with the high-level Swing library, and the latter has substantially improved over the years. The Eclipse project has come up with its own low-level and high-level UI libraries SWT and JFace, respectively. RIA products offer the functionality of high-level libraries. Yet, some of them have chosen to implement the high-level functions themselves and use low-level libraries on the client. This has pros and cons. On the upside, a low-level approach can support multiple UI libraries on the client, under the condition that the functionality is limited to the “common denominator” of these libraries. On the downside, the low-level approach will lead to a layer of proprietary software that needs to be maintained. With a high-level library, the proprietary depth of a product can be reduced to a minimum. Even the API can be taken from the standard library, as described by Bernhard Wagner in his article on “Server-Side Swing” [3]. Such an RIA product will have a minimal proprietary footprint and will profit from enhancements of the standard Swing library as it evolves. Essential drill-down questions on the UI libraries are:
is the product based on low-level libraries (AWT, SWT) or high-level libraries (Swing, JFace)? low: does it support multiple UI libraries on the client? high: is the API proprietary or a server-side proxy approach?
what is the proprietary footprint of the UI technology? is there an extension API for the development of new widgets? is it possible to integrate third-party widgets? can the look&feel be customized? is there support for Accessibility?
Standards Leverage?
Java standards are a key driver for reducing the proprietary share in a software stack. We have seen that the proprietary footprint of an RIA product’s client-side UI technology can vary considerably. Similar assessments can be made for the server-side part of RIA products, and the communication between client and server. J2EE defines standards that limit client/server communication, for instance, to request/reply protocols and specific transports such as HTTP(S) or RMI/IIOP. Moreover, EJBs disallow multi-threading that is not managed by the container, thereby ensuring that scaling measures like clustering can be handled by the J2EE infrastructure. RIA products that come with their own servers/proxies or allow bi-directional communication violate these standards and will need proprietary software that replaces the corresponding functions of the standard infrastructure. In general, a product that fully leverages the Java standards should have no function of its own if that same function can be delegated to the standard infrastructure. The following questions help in assessing standards leverage:
is session handling delegated to the J2EE container or does the product come with a proprietary server/proxy? is clustering supported and delegated to the J2EE platform? is communication handled by J2EE compliant protocols? is deployment configurable and possible both in a servlet container and an EJB container? is deployment as a portlet possible, according to the JSR 168 standard? can the client part and server part be run in a single process for stand-alone deployment, leveraging the Java VM standards?
Fancy Animations: Flash

Figure 6: Flash Branch
Flash has its main strength in animations. This is not surprising, because it was created to animate websites. The core Flash technology includes an execution environment (the Flash player), a binary file format for movies (SWF), and a scripting language (ActionScript). Comfortable end-user tools that generate SWF and support ActionScript programming are available for designing movies and websites. Flash-based RIA products for application development are comparatively new. As a consequence, both the core technology and RIA tools are evolving. This emphasizes the importance of the version issue, not only for the execution environment, but the programming model and programming tools as well.
From an architectural perspective, the Flash-based approaches are close to those relying on JavaScript/AJAX. There is a scripting language that allows code to be sent to the client at run-time. Products can provide an array of architectural options, ranging from fat client to thin client as shown in Figure 4. The relevant questions are, therefore, close to those you should ask for JavaScript/AJAX.
Flash Versions Supported?
The core Flash technology is proprietary and tightly controlled by the vendor. Programs written for a specific version will run in the browsers and on the operating systems that are supported. The version issue is raised on the level of the Flash player, ActionScript, and the SWF format generated by an RIA product. The questions you need to ask are equivalent to those for the Java products:
what are the target devices/environments for the end users? which Flash players are available and easily installable on the targets? on which players does the product run? which player is the “least common denominator” of the product? does the product leverage improvements of later ActionScript/SWF/player versions?
RIA Functions?
ActionScript, SWF and the Flash player were originally not designed for full-fledged rich client development. For this reason, you should ask the same questions as for JavaScript/AJAX products:
how does the widget set compare to standard sets like those of Java Swing? is the look&feel adaptable? is there an API for the development of new widgets? is it possible to integrate third-party widgets? what is the market for third-party widgets? is there support for Accessibility?
How strong?
Relying on a scripting language like the JavaScript/AJAX approaches, Flash-based products have a similar range of options regarding the execution of code in the client-side environment. ActionScript can be limited to an application independent presentation engine that comes with the product, enforcing a pure thin-client architecture as shown in the rightmost picture of Figure 4. Alternatively, the developer can be given the option to write arbitrary application code with ActionScript, allowing for hybrid or fat client architectures. In general, a thin-client architecture will lead to superior industrial strength, as discussed above.
Current Flash-based RIA products don’t support a pure thin-client architecture. They provide a heterogeneous programming model and require a hybrid set of tools for the various programming languages that need to be combined. This can be acceptable for industrial strength if their scope is limited to creating animations rather than transferring substantial parts of the application code to the client. Useful questions for an evaluation are:
what architecture is supported or enforced: thin, fat, or hybrid? is the programming model server-side or distributed? is application code written purely in Java or in a heterogeneous mixture of languages including ActionScript, Java, and proprietary XML languages? how large, powerful and proprietary is the set of tools required? is usage of ActionScript and proprietary tools limited to the presentation layer of applications? how can security be handled?
Conclusion
RIA and AJAX are new terms for a technology that has been around for years. Given the hype for these terms, it is difficult to differentiate between products. They vary substantially in their technical foundation and their suitability for specific requirements. Careful product evaluation is essential. The decision tree presented in this essay helps asking the right questions and leads through the most important decisions.
References
[1] Coach K. Wey: AJAX: Asynchronous Java + XML?
http://www.developer.com/design/article.php/3526681
[2] Jesse James Garrett: AJAX: A New Approach to Web Applications,
http://www.adaptivepath.com/publications/essays/archives/000385.php
[3] Bernhard Wagner: Server-Side Swing for Rich Internet Applications,
http://javadesktop.org/articles/canoo/index.html
_xyz