Figure 1. Axes of Ajax
Published on dev2dev (http://dev2dev.bea.com/)
http://dev2dev.bea.com/pub/a/2006/11/exploring-ajax.html
See this if you're having trouble printing code examples
by Gary Horen
12/06/2006
The browser technologies that led to the current Ajax wave have been available since early 1999. But the programming interfaces they originally presented were very low-level and painful to work with, and the browser and JavaScript tricks that comprised Ajax could often demand more of the client machine than it had to give. With the additional memory, processor, and network bandwidth capacities that have become ubiquitous on the client machine in the last few years, Ajax has become a realistic way to develop rich user interfaces for Web applications. One effect of this is that a host of Ajax runtime frameworks has popped up that tries to present the developer with a more workable application programming model.
This article attempts to sort through these frameworks and map some of the characteristics by which they can be compared. The hope is that the reader will come away with some tools to use for breaking down the collection of Ajax offerings in ways that make it easier to understand distinctions between them, narrowing down the subset that needs to be looked at, and making better-informed choices.
Disclaimer: This article is focused on the Java EE world. Lots of interesting things can be said about other technologies from other genres, like .NET and Ruby, but these are beyond the scope of this article.
Ajax is an acronym that stands for Asynchronous JavaScript And XML. It's one possible technology that you can use to create a type of Web application that the press has come to call a rich Internet application (RIA). RIAs are "rich," in the first place, because they appear to behave more like desktop applications than traditional page-refreshing Web applications. For example, controls on the page are interconnected in a fine-grained way (changing a value in a listbox may result in another control on the page being enabled or disabled, or disappearing altogether). Ajax enables many other visual effects that have not been possible in traditional Web applications. You can see a small subset of them here:
Another equally important characteristic of a rich application is that the UI communicates with its data source (that is, with the server), without requiring the page refresh associated with a traditional Web application.
Using Ajax is not the only way to create a rich Web application. You can use Adobe's Flash plug-in, which is found in a very large subset of the browsers out in the world today. Another alternative is one of the browser-specific rich UI technologies like XAML for Internet Explorer, and XUL for Mozilla. The principal advantage of Ajax is that it really is the zero-footprint solution: It works across the vast majority of modern browsers, and it uses only what it finds on the client. No additional plug-ins on the client machine need to be kept in synch with the server side of an Ajax application.
This is not to say that there are no differences in Ajax technology implementations among browsers. The native browser APIs are not standardized, at either the syntactic or behavioral levels. The reason that Ajax applications generally don't have to worry about implementation differences among browsers is that the Ajax runtime frameworks do the worrying for them.
At the lowest level, without a framework, raw Ajax programming requires:
XMLHttpRequest object does not examine the dataflow, it can be any representation that the client and server both
agree upon. JSON (JavaScript Object Notation) is a popular alternative.Development using raw Ajax is difficult because of inter-browser variability, and also because of the relative immaturity and the browser-dependent state of the art of the available development tools that work at this level. So, a large number of Ajax runtime frameworks have sprouted up. This article tries to provide an overview of the space, and a way to break the frameworks down and understand their similarities and differences.
Ajax runtime frameworks come in many forms and have a wide variety of goals. Some simply intend to paper over the differences in browser interfaces, and provide a common API for sending and receiving server messages. Others are mostly concerned with UI widgetry and/or special visual effects. Other frameworks try to address both concerns. One tool that I've found useful for making comparisons among frameworks is to view them along a set of different axes, as shown in Figure 1. You could come up with quite a large number of these, but this article will focus on just the four that appear in the figure below. I'll discuss them one at a time. Keep in mind that the distinctions I make are shades of gray; they are general rules for which you will always be able to find exceptions.
Figure 1. Axes of Ajax
Open-source versus commercial is a distinction that anyone who lives in the Java EE world is quite familiar with already. Commercial frameworks are often more mature, because a commercial offering is usually part of the vendor company's mission and commands the owning organization's full attention. The vendor usually has a stronger commitment to backward compatibility from release to release. These products are more often designed to be comprehensive end-to-end solutions. They characteristically have better documentation and commercial-quality support.
Open-source frameworks are often more uneven: They can be excellent in areas in which the community of developers focuses its efforts, and weaker in areas that receive less focus. The attention paid to a feature is often driven by the needs of its contributing developer. Support and documentation can be causes for concern, and if you decide to adopt an open-source framework for your project, you need to make sure that the license under which it is offered is suitable for your planned use for it. If your application is designed to be shipped to customers, rather than be used strictly within your own organization, then you must make sure that you have the right to redistribute any framework-owned artifacts that your application requires.
On the other hand, since an open-source framework is usually designed to invite contributions from the community, it's often easier to add functionality that you may find missing to one of these than to add it to a commercial product. Furthermore, if you choose an open-source framework with an active community behind it, support can be excellent.
Ajax runtime component offerings run the gamut from scraps of sample code that you find on the Web and that you can cut and paste into your own application, to comprehensive frameworks. Just above the level of code scraps are individual JavaScript components that present an API for a specific purpose. Some of these represent UI widgets that will appear on a Web page, like the Dojo Button, and others are for solving lower-level, plumbing-related issues like communicating with the server or manipulating the browser DOM (for example the Prototype APIs).
A comprehensive framework is a collection of these encapsulated objects that want to be a complete solution for an Ajax development project. Many of these assume that they "own" the Web page on which they run with regard to Ajax—that is, they often don't easily accommodate the notion of sharing the page with components from outside sources.
Making a choice along this axis is often related to the age of an application: A new one generally has an easier time dealing with the assumptions made a by a comprehensive package. To make incremental improvements to an existing Web application, it can often, although not always, be easier to integrate code scraps or objects. Scraps and individual components can require more programming, because they operate at a lower level. Comprehensive frameworks make assumptions that make them harder to integrate with each other, and are harder to use in a portal (because sometimes their assumptions conflict with ones made by the portal container).
The declarative versus procedural distinction has to do with the programming model that the framework offers for authoring Web pages. Declarative ones want to provide a language in which the developer describes the layout of the UI on the page, and the relationships between them, so that the framework knows how to handle events that pass between UI widgets just from the description provided by the application developer. Procedural frameworks offer programming language APIs, and the programmer provides procedural code that handles UI events.
In Example 1 below, you can see the beginning of the declarative layout of a data table done with the ICESoft framework. The column shown is both a display for dynamic data and a command link; data bindings for both retrieving the data and passing the command to the server refer to JSF backing beans, and are specified in JSF expression language.
<ice:datatable>
<ice:column>
<ice:commandLink actionListener="#{catalog.selectBook}">
<ice:outputText value="#{book.title}" />
</ice:commandLink>
</ice:column>
...
Example 1. Declarative layout and event handling: ICEFaces
In Example 2 I use Dojo, a more procedural
framework, to handle a button-pressed event in JavaScript, and to specify another JavaScript function, onServerResponse(), that
will be called when data I request from the server arrives.
<script>
function helloPressed()
{
dojo.io.bind({
url: 'response.txt',
handler: onServerResponse
});}
...
</script>
<button dojoType="Button2" widgetId="helloButton">
Hello World!
</button>
Example 2. Procedural event handling: Dojo
The client-centric versus server-centric distinction also is about the programming model, and is one of the most interesting ones. Early runtime frameworks were almost all focused on the client side: The Ajax part of a Web application executed in the browser, and communicated with server-side components that were independent of the Ajax framework. Recently, some frameworks have begun to offer an application programming model that uses the server-side language (for purposes of this discussion, Java), and, to varying degrees, blurs the apparent distinction between the server and browser environments.
If you look at the diagrams in Figure 2 below, you can see that in the server-centric model, the application programmer develops the entire application in what appears to the programmer to be server-side code. Of course, DHTML and JavaScript are involved when the application runs, but the framework does not expose these to the programmer. The framework provides both a server-side and client-side Ajax engine. The server-side engine generates HTML and JavaScript that is served into the browser along with a client-side engine, which provides APIs used by the generated code to manipulate the browser DOM, receive events, and push them back to the server-side engine, which communicates events back to the application.
Often, a server-centric framework will hold a representation of the widget DOM on both the server and the browser sides of the connection, and keep them in synch by sending deltas back and forth across the connection. Of course, this costs something in terms of server-side memory, but it can make it much easier to persist and restore the state of an Ajax session when the user disappears and then comes back sometime later and wants to resume work where it was left off.
A client-side framework, on the other hand, expects the application programmer to write both the server side of the application and the part that will run in the browser. The client-side code is served into the browser along with the Ajax engine, which performs the same intercession functions between the DOM and the application code that it does in the server-centric model. The application code initiates requests to the server through calls to engine APIs.
Figure 2. Server-centric vs. client-centric framework architecture
Figure 3 breaks this axis down further. The differences between the two client-side columns of the table are mostly about the level at which the framework expects programming to be done. The right-most entries are essentially JavaScript libraries, which are usually more concerned with plumbing than UI. UI layout using these can be expressed in either JavaScript code or standard HTML. In the next column to the left are higher-level frameworks that actually include an Ajax rendering engine. These expect the user to express the widget tree in some framework-specific XML dialect, which the engine parses and uses to construct the browser DOM that the end user actually sees and manipulates.
On the server side of the table, the distinction is a little different. An application written using a framework from the right column looks like a Web application: UI layout is expressed in terms of tags, and event handling that is not expressed in declarative terms in the layout tags is written in Java. The frameworks listed in this column offer JSF as a programming model, and data binding works in the standard way, using the JSF expression language and managed backing beans. JavaScript is involved, of course, when the application runs in the browser, but it is completely encapsulated by the framework and isn't visible to the application programmer.
The programs for frameworks in the left-most column actually don't look like Web applications any more. They present a Java API that looks a lot like Swing or SWT but runs in the browser rather than on the desktop. The developer constructs the UI by instantiating Java objects and nesting them inside one another. All event handling is done in Java. Again, JavaScript is involved, but it's not exposed to the programmer. This model has the greatest potential to be disruptive to Web application development, because it's Web programming without markup. These frameworks can sometimes even offer to run the resulting application either in the browser as a Web application, or as a desktop application that's completely independent of the browser.
Figure 3. Server-centric vs. client-centric framework table
In both server-centric models, if programmers need functionality that's not provided by the framework, they can add new widgets, and in this case they may be programming in JavaScript. But adding a new widget is not the role that the framework envisions for most of its clients; it's supposed to be the exception rather than the rule.
Does all this indicate a trend away from the browser, toward the server? A class of applications will be well-suited to server-centric frameworks. For example, a data-entry application like a travel Web site may well find enough richness in a server-centric framework to satisfy its requirements. The SWT-like API is a very interesting alternative. Applications that need wild special effects and a lot of fast event processing on the client that's not supplied in an encapsulated widget will probably gravitate toward the client side for the foreseeable future.
|
Now I'll take a glance at a couple specific frameworks, placed along these axes. When a framework falls clearly at one end of an axis or the other, it will appear as a circle placed at the appropriate end. When its placement is more ambiguous, I'll try to show a bar to represent its approximate position, and explain further.
Prototype is a low-level library of JavaScript functions. Its principal concerns are things like
papering over the variations among JavaScript implementations in various browsers, giving the
developer enhanced tools to navigate and manipulate the DOM, and providing browser-independent access to
the XMLHttpRequest object. A number of frameworks more focused on widgetry have been built on
top of Prototype: OpenRico and Scriptaculous
are examples in the open-source world, and the commercial JSF framework
ICEFaces incorporates Prototype and Scriptaculous.
Figure 4. Prototype
Direct Web Remoting (DWR) is a package that's primarily focused on making it easy to marshal data between the browser and a Java Web server (see Figure 5). It papers over browser differences in the client-to-server pipe but leaves the UI concerns to the programmer. It's free and open source, and has an interesting position along the programming model axes: The application programmer defines server-side Java classes, and then the framework generates JavaScript classes that embody the corresponding data structures on the browser side. So I characterize it as mostly procedural but somewhat declarative in the sense that the programmer decorates Java classes with annotations to generate the marshalling objects. Its APIs are located on both client and server.
Figure 5. DWR
In Figure 6, you see Dojo, an open-source, client-centric framework that some people use as a comprehensive framework but others adopt just at the lowest layer, for its plumbing features, without using the UI components. The API is for the most part procedural.
Figure 6. Dojo
In Figure 7, I show Backbase, a commercial framework that offers both a client-centric version in its Community Edition, and a server-centric one in its Java Server Edition. It wants the application programmer to specify the layout and behavior of the application declaratively (although it also accommodates procedural code), and its widget set is quite comprehensive.
Figure 7. Backbase
The Google Web Toolkit (GWT) is a comprehensive framework (see Figure 8). The programming model is server-centric and procedural; the API looks a lot like SWT. This framework has one of the most interesting architectures out there: The Java application code is debugged by running it in the "hosted web browser" tool shipped with the framework. When you want to run the application in an actual browser, you use the framework's compiler to convert the part of the application that will run in the browser to JavaScript, and then serve it into a Web page. The runtime part of the framework is free and open source; the two development tools that come with it (the hosted Web browser and the compiler) are closed source but are free with the runtime distribution.
Figure 8. Google Web Toolkit
The great divide in tooling requirements in the framework space occurs when you cross from the client to the server side. Client-centric frameworks require JavaScript and browser-oriented tools: a JavaScript editor, debugger, and validator, a browser DOM inspector, message tracing, and so on. Two promising sources for these kinds of tools are the Mozilla Foundation, which offers a DOM inspector, a JavaScript debugger, and a host of free add-on plug-ins available from the Internet, and the Eclipse Ajax Tooling Framework (ATF) project, available in prerelease form as of this writing. The ATF incorporates the Mozilla tools, and adds a validator and editor.
On the server side, because the frameworks hide browser programming from the developer, you can use same the Eclipse Java and JSP tooling that you would use for a traditional Web application.
In all this, the thing that has most obviously been missing up to this point is a tool that supports visual page construction. Two very recent developments though, show that this situation is about to change. I'll give you a brief tour of a couple examples of new Eclipse-based tooling that work with runtimes that fall on the server-centric side of the programming model divide. Because these runtimes offer programming models for which relatively mature tooling already exists, the amount of work required to produce functional page construction tools is less than it would be for client-centric frameworks, which have less of an existing base to build on.
The first one is BEA Workshop Studio for JSF, with a small amount of code to adapt it to a specific JSF-oriented Ajax runtime. The second example is GWT Designer, a recent release from Instantiations Inc. that provides page construction tooling for the Google Web Toolkit.
In Figure 9, you see a prototype version of BEA Workshop Studio, a tool for building pages visually using Workshop Studio integrated with ICEFaces, a commercial Ajax framework from ICESoft. Since ICEFaces offers a JSF programming model, it can be readily adapted to existing JSF tooling.
The right side of the view is the combined Design and Source view of the page layout. The tool supports full two-way editing: Changes in the Source pane are immediately reflected in the Design pane, and vice versa.
The Tag Libraries palette is located in the lower-left part of the window. Clicking one of the ICEFaces tags in the palette will add it to the source file at the current cursor position, and consequently to the Design view as well. The Smart Editor, just above the palette, understands all the attributes associated with the tag, and helps the user bind appropriate atributes to JSF backing beans.
Figure 9. Workshop Studio JSF Tooling
Instantiations Inc. recently released a product called GWT Designer, which provides page construction in Eclipse for the Google Web Toolkit. Since the GWT's programming model is mechanically identical to SWT or Swing—the UI is laid out by constructing Java objects and adding them to container objects—and since Instantiations already offered a very rich page construction product called WindowBuilder Pro for both Swing and SWT, they had a solid base ready to build the GWT Designer on top of. In Figure 10, you can see the Design pane of the tool: the design surface on the right, the widget palette in the middle, and a view of the widget tree in the upper left, as well as an editor for all the properties of the selected widget in the property sheet in the lower-left pane. Again, the tool keeps the source and design views in sync, and the user can make arbitrary edits to the source that are preserved throughout whatever changes the user makes via the design pane. Since the programming model for the GWT is pure Java, the designer tool can run using only the base Eclipse installation (no Web tools required), and the Java tooling already present in the platform provides all the error discovery, type system navigation, refactoring, and so on.
Figure 10. Instantiations GWT Designer
The Ajax runtime framework space is currently an embarrassment of riches. There are so many options to choose from that exploring it can be a bit bewildering. Tools for it are following close behind, but, particularly in the client-centric world, these aren't as advanced as the runtime offerings in many cases. Many different considerations are involved in making choices: the suitability of a given programming model to the development team that will work with it, available tools, licensure, cost, documentation and support. The shakeout will clearly continue for some time before it settles down. This article has tried to provide some guidance in exploring the space, the tools for understanding how frameworks compare, and a view of what some of the trends are, even if I haven't been very willing to predict where they will ultimately lead. :-)
Gary Horen is the Program Manager for Ajax and Languages on the BEA Workshop team
Return to dev2dev.