From MemberWiki

This is a temporarily staged version of an article ultimately destined for AJAXWorld magazine's October edition.

Note that the deadline for proposed wiki-based editing changes was end of day (California time) on Thursday, August 10, 2006, which has now passed. Simultaneous with member comments, IBM's byline editing team has reviewed the text and proposed changes. Their proposed editing changes have now been added to this wiki page. However, going forward, the "master" document is likely to be a forked version of this document that is developed offline from the wiki. Therefore, all further changes to this wiki page may not be noticed and are not likely to effect the AJAXWorld articles.

Open and Interoperable: The OpenAjax Technology Vision

By Jon Ferraiolo (on behalf of the OpenAjax Alliance)

Industry leaders have joined together to form the OpenAjax Alliance, whose mission is to accelerate customer success with AJAX by promoting a customer's ability to mix and match solutions from AJAX technology providers and by helping to drive the future of the AJAX ecosystem.

The members of the Alliance have worked together to produce a shared AJAX technology vision that is described in this article. The most fundamental aspects of the technology vision were established during the two-day kickoff meeting for the alliance (May 15-16, 2006). The rest of the vision is the result of the Alliance's committee work since the kickoff meeting.

First and foremost, the OpenAjax Alliance’s technology vision represents a commitment towards open technologies. The Alliance believes that a large part of industry excitement over AJAX is due to its promise of rich user experiences through open technologies; therefore, open technologies are central to the OpenAjax technology vision.

Another reason for industry excitement with AJAX is that it promises the benefits of Web 2.0 through incremental adoption of new application development techniques while retaining the existing back-end infrastructure that has been set up around HTML. But AJAX frameworks deliver AJAX benefits in many different ways. Some AJAX frameworks do most of the AJAX work on the client, while other times do most of the work on the server. Some AJAX frameworks integrate tightly with server application frameworks such as JSF; others move large parts of the application logic to the client. The OpenAjax Alliance embraces this diversity because it promotes innovation and provides customers with a rich set of choices, thereby enabling them to choose the AJAX technology approach that best matches their needs and preferences.

In this article, I provide an overview of the OpenAjax technology vision, focusing on the Alliance's commitment to open technologies and introducing some of the architectural options for delivering Web 2.0 applications using AJAX. In a sidebar, I describe the OpenAjax Hub, one of the Alliance's early technology initiatives that will be key to enabling the ability to mix and match multiple AJAX technologies within the same Web application.

Open Technologies

Open standards

OpenAjax builds on the open technologies that are native to browsers. Most of the base technologies are official Web standards, while many of the rest have been implemented widely in browsers but have not been formally recognized by a standards body. Standards include JavaScript, HTML, CSS, DOM, DOM Events, XMLHttpRequest, XML and SVG.

Open source and commercial products

While open source software is not mandatory for AJAX projects, a large part of AJAX's momentum is due to the open source community's commitment to AJAX. OpenAjax embraces open source alternatives and seeks partnership with both AJAX open source initiatives and commercial products.

Platform independence (OS, server, browser, IDE)

One of the main attractions of AJAX is that it does not lock developers to a particular hardware platform, operating system, application server, web browser or IDE. Developers are free to choose among many technology providers, commercial and open source, to find the products or open source technologies that best match their unique requirements and preferences, while achieving the key benefit of write-once, run-everywhere, across multiple computing devices, operating systems, and web browsers.

Typically, AJAX toolkits deliver cross-platform and cross-browser functionality by providing a platform-neutral and browser-neutral abstraction layer to the developer. This layer is sometimes delivered as a set of client-side JavaScript libraries, and other times in the form of server-side software (e.g., Java).

Open Architectures

Multiple architecture options

AJAX developers have the ability to choose among multiple technical approaches to find the ones whose programming model best fits their needs. The following are some of the ways to categorize AJAX toolkits and frameworks.

Client-side vs. server-side

Most AJAX technologies transform a platform-independent definition of the application (usually consisting of a combination of markup and logic) into the appropriate HTML and JavaScript content that is then processed by the browser to deliver a rich user experience. Some AJAX designs perform most of their transformations on the client. Others perform transformations on the server.

Client-side AJAX transformations

The diagram below shows a common approach to client-side AJAX.

The developer provides the green-color components, the AJAX toolkit provides the orange-colored components, and the yellow-colored components represent the final HTML DOM after the AJAX runtime library has performed its client-side transformations.

For client-side AJAX, the application server usually requires no additional AJAX-specific server software. All AJAX transformations come from the client-side AJAX runtime library.

One advantage of this option is the independence from the server side technology. The server code creates and serves the page and responds to the client's asynchronous requests. This way either side can be swapped with another implementation approach.

Server-side transformations

Server-side AJAX sometimes follows the model shown below:

For server-side AJAX, an AJAX server component performs most or all of the AJAX transformations into appropriate client-side HTML+JavaScript. Often, the server-side AJAX toolkit downloads its own client-side AJAX library which communicates directly with the toolkit's server-side AJAX component.

The implementation strategies of server-based AJAX frameworks vary. At one side of the spectrum, the server handles all the application events. On the other side of the spectrum, many events are handled on the client. For some frameworks, the development and debugging phase handles all events on the server, but in production mode many events are handled on the client.

The main benefits of this approach are that it preserves back-end server-resident infrastructure, eliminates the need for extensive JavaScript programming, and preserves developer core competencies, development practices, and tools because it allows the use of server-side languages for debugging, editing, and refactoring tools with which developers are already familiar. This can be at the price of dependence on a particular server-side technology. As a general rule, server-side AJAX frameworks expect application code to be written in the server-side language (e.g. Java or RoR). These frameworks typically hide all the JavaScript that runs in the browser inside widgets, including their events. If pre-built capabilities don’t suffice, however, new component development exposes the programmer to JavaScript.

Single-DOM vs. Dual-DOM (client-side and server-side)

Single-DOM

Some AJAX runtime toolkits use a Single-DOM approach where the toolkit uses the browser's DOM for any original source markup and any HTML+JavaScript that results from the toolkit's AJAX-to-HTML transformation logic. The following example illustrates the Single-DOM Approach:

The Single-DOM approach is particularly well-suited for situations where the developer is adding islands of AJAX capability within an otherwise non-AJAX DHTML application, as the programming model matches the traditional approach used in DHTML applications.

Dual-DOM (client-side)

Other AJAX runtime toolkits adopt a Dual-DOM approach that separates the data for the AJAX-related markup into an "AJAX DOM" tree that is kept separate from the original "Browser DOM" tree. The image below illustrates the Dual-DOM (client-side) approach:

With this approach, in model view controller (MVC) terms, the AJAX DOM can be thought of as the model, the Browser DOM as the generated view, and the AJAX runtime toolkit as the controller.

It is usually necessary to establish bidirectional event listeners between the AJAX DOM and the Browser DOM in order to maintain synchronization. Sometimes having a separate AJAX DOM enables a more complete set of XML and DOM support, such as full support for XML Namespaces, than is possible in the Browser DOM.

The Dual-DOM approach has two flavors: Client-side Dual-DOM and Server-side Dual-DOM. With Client-side Dual-DOM, the second DOM tree typically consists of a separate tree of JavaScript objects. With Server-side Dual-DOM, the second DOM tree is stored on the server. The following section describes Server-side Dual-DOM.

Dual-DOM (server-side)

Some AJAX technologies combine server-side AJAX transformations with a Dual-DOM approach:

In this scenario, the primary job of the client AJAX engine is to reflect back to the server any interaction state changes. Most of the UI logic is handled on the server.

Server-side Dual-DOM enables tight application integration with server-side development technologies such as Java Server Faces (JSF).

Conclusion

The OpenAjax Alliance has a commitment to open technologies and architectural diversity.

A key part of the Alliance technical work are its technology initiatives focused on AJAX interoperability. The OpenAjax Hub, one of the Alliance's first interoperability initiatives, prevents collisions and enables linking together of multiple AJAX technologies within the same Web application.

SIDEBAR: OpenAjax Hub: Enabling AJAX Togetherness

The OpenAjax Hub is a set of standard JavaScript functionality defined by the OpenAjax Alliance that addresses key interoperability issues that arise when multiple AJAX libraries are used within the same web page. The OpenAjax Hub represents a key part of the initial technical work of the OpenAjax Alliance.

The following features have been identified for the first version of the OpenAjax Hub:

AJAX library loading and unloading control - The Hub will have APIs that AJAX libraries must invoke when those libraries are initialized, identifying load and unload callback functions which are invoked at document load and unload time. The Hub manages and coordinates the invocation of these callback functions. The callback functions must be non-destructive outside of the global objects that the library has registered with the Hub (see next item). Markup handling should not occur as part of the load event callback function; instead, markup handling should occur via callback functions that are invoked by the Hub's markup scanner (see below).
Techniques and tools to minimize JavaScript object collision - The AJAX libraries must register with the Hub at initialization time a full and accurate list of all global objects and functions that they define when included in a page. The Hub will include run-time error check logic that can be turned on to verify that AJAX libraries are not colliding due to attempting to manage the same global objects.
Event hub - The event hub allows libraries to publish and subscribe to events in a reliable manner in order to coordinate actions across components from different AJAX libraries.
Markup scanner - The OpenAjax Hub controls markup scanning at the highest level. At initialization time, AJAX libraries identify to the Hub the pattern matching criteria for the markup that the given library controls. When the Hub scans the document, whenever it encounters markup that matches the criteria, it invokes the library's appropriate callback function.

AJAXWorld 2006 October Technology