View source

<span style="color:red">''NOTE: This wiki page holds one of the 4 white papers that are under collaborative development by the Marketing Committee. Together these 4 white papers will represent the 2nd generation set of white papers produced by OpenAjax Alliance. When completed, the white papers will be posted as HTML and PDF files on the OpenAjax Web site.''</span>

= Abstract =

The OpenAjax Alliance has assembled a set of white papers as a guide to help Web developers and IT managers understand and evaluate Ajax, define a successful Ajax strategy, and become familiar the important role OpenAjax plays in the development of the Ajax market. 

The white papers are: 

* [[WP2 - Introducing Ajax and OpenAjax | Introducing Ajax and OpenAjax]]
* [[WP2 - When Does Ajax Make Business Sense | When Does Ajax Make Business Sense]]
* [[WP2 - Next-Generation Applications Using Ajax and OpenAjax | Next-Generation Applications Using Ajax and OpenAjax]]
* [[WP2 - Successful Deployment of Ajax and OpenAjax | Successful Deployment of Ajax and OpenAjax]]

= Successful Deployment of Ajax and OpenAjax =

== Multiple architecture options ==

The Ajax community provides a rich and diverse set of product offerings from hundreds of suppliers. The various options reflect the diversity and innovation within the arena of Ajax products and services, with strong competitive product offerings across multiple market segments. This diversity provides IT managers and Web developers with the ability to choose the optimal architectural approach and best products among multiple vendors in order to meet their particular requirements and fit in with their existing practices.

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.  

[[Image:ClientSideAjax.gif]]

With client-side Ajax, the Ajax engine runs on the client. The server delivers Web content (HTML, CSS, JavaScript, etc.) which is processed by the client-side Ajax engine into revised Web content. The browser renders the revised HTML/etc. content that comes out of the Ajax engine.

With this architecture, the application development team typically provides the following server-side components:

* Web pages (e.g., *.html, *.php, *.jsp, *.asp)
* application logic (e.g., Java)
* data management (e.g., via a SQL database and/or Web Services)

and the following client-side components:

* client-side user interface logic, such as event handlers for UI events
* client-side data management (e.g.., manage client-server data communications and update user interface elements to reflect new data)

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:

[[Image:ServerSideAjax.gif]]

For server-side Ajax, an Ajax server component performs most or all of the Ajax transformations. The server component generates the necessary Web content (HTML, CSS, JavaScript, etc.) to deliver the desired user experience. Often, the server-side Ajax toolkit downloads its own client-side Ajax library which communicates directly with the toolkit's server-side Ajax component.

With this architecture, the application development team typically only provides server-side components (Web pages, application logic, and data management) and entrusts client-side logic to the Ajax toolkit.

The main benefit of this approach is that it allows the use of server-side languages for debugging, editing, and refactoring tools with which developers are already familiar, but 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. 

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.

== 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 (same image as shown for [[#Client-side_Ajax_transformations Client-side Ajax transformations]]):

[[Image:ClientSideAjax.gif]]

The figure below shows a detailed view of how an Ajax runtime library might manipulate the HTML DOM:
 
[[Image:SingleDOM.gif]]

In this example, the developer is using tree widgets from an Ajax runtime library. On the left, you see both the original HTML markup (unshaded) and the additional HTML markup inserted by the Ajax toolkit (shaded). On the right, you see the DOM objects that correspond to the elements in the HTML markup (e.g., the DOM object that represents a particular <code>&lt;div&gt;</code> element), where JavaScript/DOM objects from unshaded objects correspond to original HTML markup and shaded objects are ones that have been inserted by the Ajax toolkit. Typically, the Ajax toolkit inserts various rendering constructs such as <code>&lt;img&gt;</code> , <code>&lt;div&gt;</code>, and <code>&lt;p&gt;</code> elements, inline within the original HTML markup (e.g., adding child elements to an existing <code>&lt;div&gt;</code> element), thereby providing the various graphics and text necessary to produce the desired visual representation for the tree widgets. The shaded sections on the right reflect the private data that Ajax libraries typically add to various DOM and JavaScript objects in order to store private data, such as run-time state information.

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:

[[Image:ClientSideAjaxDualDOM.gif]]

The figure below shows a detailed view of how the two DOMs might work (i.e., the HTML DOM and the XML DOM corresponding to the Ajax-specific XML markup for the user interface elements):

[[Image:DualDOM.gif]]

The above example shows a separate file, "myapp.abc", which contains the user interface definition for the tree widgets, which in this case are to be placed into the HTML tree inside the &lt;div&gt; element with id="abctarget". Even though the example shows the use of a separate file, some Dual-DOM Ajax runtime libraries support inline XML. In either case, a Dual-DOM Ajax runtime library builds a separate DOM tree, typically using its own XML parser rather than relying on the browser's HTML parser. Sometimes (as shown in the example) the separate DOM tree is attached to the 'window' or 'document' objects.

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:

[[Image:ServerSideAjaxDualDOM.gif]]

The key difference between Server-side Dual-DOM and Client-side Dual-DOM is that, with Server-side Dual-DOM, the Ajax DOM and most user interface logic is managed on the server. In this scenario, the primary job of the client Ajax engine is to reflect back to the server any interaction state changes, deferring data handling, UI state management and UI update logic to the server.

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

== Procedural vs. declarative client-side frameworks ==

Most Ajax runtime toolkits combine procedural and declarative approaches.

With the procedural approach, the application developer directs the toolkit almost exclusively using JavaScript APIs to handle all the events and manipulate widgets. 

With the declarative approach, the application developer directs the toolkit almost exclusively via HTML or XML markup to define the components on the page and the relationships between them. Custom XML tags are often defined in the framework's namespace. JavaScript code may be required in some circumstances, but one of the framework's goals is to minimize the need for procedural logic.

== Conclusion ==

Ajax provides several architectural approaches, and each approach is supported by various commercial software products and/or open source projects. The architectural diversity provides IT managers and Web developers with the ability to choose the optimal architectural approach and best products in order to meet their particular requirements  and fit in with their existing practices.

OpenAjax Alliance embraces this diversity because it promotes more efficient application development and speeds delivery of innovative new products and services, both of which lead to increased customer benefit. The Alliance's role is to foster Ajax interoperability within this environment of innovation and choice such that customers realize the benefits in a way that lowers costs and fits within the strategic objective of using open technologies.