The categories Gartner outlined weren't comprehensive and excluded some important considerations, but they did provide a good basis on which to start evaluating various frameworks. The projections it outlined were also useful because they focus on how businesses are likely to adapt to this emerging technology. What I think needs closer attention is why this is likely to be the case and from that what are some of the additional considerations that have to be weighed?

Too Many Hands in the Cookie Jar
When you step back and look at the various layers that are involved in a modern Web application, it's actually quite remarkable that we've been as successful as we have at constructing them. To build a modern Web application, you have to be fairly proficient at HTML or a derivative such as XHTML to structure the content semantically or realistically, depending on your persuasion. CSS enters the mix for most of your styling needs; of course not all browsers support it equally well so you have to fight battles here and there. Before AJAX came along, JavaScript was commonly used in small doses throughout an application to do things like browser type and version checking, simple client-side data validation or toggling the background color of fields to indicate a conditionally required state. And that's just the things you have to deal with in the browser.

On the server, you have to figure out how to slice and dice the HTML/CSS and JavaScript so that it generates a series of properly formed pages. Not only do you typically add a server language to the mix, it's common to see a template language such as Java Server Pages (JSP) used to help manage proper page generation. After that you still have to deal with inbound data that's submitted via forms, manage the proper flow of Web pages for error and non-error states, and determine what application state needs to persist between pages. After addressing all of these concerns effectively, you can focus on implementing the actual business side of your application.

Now let's take a look at what the traditional Web application stack looks like after you add a client-centric AJAX framework and some widgets; essentially what Gartner defined as Level 1 and Level 2 AJAX (see Figure 3).

For starters, it's important to think about the differences in how an AJAX application works compared to a traditional Web application. There are two main differences, the client side has interactive and responsive elements and the content on a page can change or be loaded incrementally from the server on-demand. To do this on top of a traditional stack, you usually leverage a client-side AJAX framework that tries to simplify the work involved in modifying a page dynamically. Depending on the framework and your needs, a set of widgets may be available as an add-on to provide things like tree and calendar controls. If not, it's not uncommon to add a second AJAX framework to the stack that provides the widgets and visual effects.

In the traditional approach you write your application entirely from a server-centric perspective, but using this approach you end up splitting the development into two separate environments: the server-side part of the application with its state and the new client-side part of the application that has state of its own. The server-side part maintains many of the same things you see in a traditional stack. You generate your page the same way and you handle page flow and application state in pretty much the same manner. Sure, you have to include extra references to the client-side frameworks and the client-side JS files you write for the page, but doing that is pretty straightforward.

The only real difference on the server is that you now have a set of special request handlers called end points that you have to create to serve content to the client-side part of the application as needed. The end-point handlers are usually implemented like standard request handlers, it's just that they return data and incremental content rather than a whole page. They can be a combination of Web Services, simple XML over HTTP, JSON data, HTML fragments, or any other form of content that the client-side part of your application is designed to handle.

On the client side, the story is completely different. AJAX wrestles parts of the user interface away from the server's control and plants it firmly on the client side. The more AJAX-ified you make your application user interface, the more control you end up wrestling away from the server. Ultimately, this drives the complexity of the client-side JavaScript well beyond the basic data validation that you've used it for in the past. It usually starts out simple. You add a couple asynchronous calls to the server to populate a dropdown, hide a couple fields on the screen when a user chooses yes or no, integrate a grid control that populates with search results when a user enters some criteria, but before long you end up in a situation where you're writing large portions of your application in JavaScript.

As a result, you can no longer treat JavaScript as a toy language; you have to treat it as a first-class citizen in your development efforts. A debugging strategy that works across multiple languages and execution environments has to be worked out and you have to start structuring your client-side code like you would your server-side code so that it's readable and maintainable. However, suddenly treating JavaScript as a first-class language and adding it to the mix of all the things that you have to manage in an AJAX application can be cumbersome.

Overall, dealing with the complexity that AJAX brings to the crowded Web development stack is one of the biggest hurdles facing anyone looking to adopt the technology. Architected carefully, you can scale this approach up to some very large applications. You just have to do a lot of bookkeeping and testing to make sure everything works correctly and performs as expected. Cutting through all that bookkeeping and simplifying the development stack is what a Level 4 framework such as ThinWire is all about.

More than One Way to Skin a Cat
The Rich Internet Application (RIA) term has technically been around for quite sometime. A few years back, different companies made a go at creating sophisticated RIA frameworks on top of technologies such as Java applets, ActiveX and Flash. For many of the reasons that I outlined at the top of this article, none of those approaches ever panned out. Today when we talk about RIA frameworks, it's usually in terms of RIA frameworks that use AJAX techniques to provide the rich application experience. Generally speaking, the goal of an RIA framework is to provide a simplified Web development platform that you can use to construct highly interactive and responsive user interfaces. Different frameworks approach this goal in unique ways that offer varying benefits. I'm going to use the ThinWire framework to demonstrate some of the benefits you can gain by using an RIA framework because as the architect I know it the best. While my descriptions are not entirely general, conceptually they can be applied to approaches taken by other frameworks.

For those of you who haven't heard of ThinWire, it's an open source development platform that lets you easily build applications for the Web that have responsive, expressive, and interactive user interfaces without the complexity of the alternatives. To show you what I mean, take a look at the layers that make up a ThinWire application (see Figure 4).

Notice how there's no mention of the Web browser. In a typical ThinWire application, you never write any HTML, CSS, or client-side JavaScript code for anything. A ThinWire application is constructed entirely on the server side, using primarily a single language on top of an event-driven component model. That single server-side language is usually Java, but it can also be any scripting language that runs on top of Java such as Jython or JRuby. And, since you get to wipe your hands clean of the Web browser side of things, the framework can focus on optimizing the communication and rendering in a way that's generally more efficient than what you could do by hand. And as we add more intelligence to the framework's predictive routines, your application can leverage those improvements without you having to change any code.

Further benefits to this approach become clear when you look at how this simplifies the development and debugging cycle. With ThinWire, you can use your existing Java debugger to walk through any part of your application. Essentially there are only two possible failure points. Either your server-side code has a glitch or the framework version you're using has a glitch. And since the framework is already in production use at a top-10 U.S. bank, it's been proven out quite significantly. Therefore, in most cases you can be confident looking strictly at your server-side code.

The steps for constructing a rich application in ThinWire are straightforward. You construct your user interface components and position them on the screen using either exact positioning or one of the layout management approaches included in the framework. Then you add event listeners to the components on which you want to be notified of a user action. For example, you might listen for a checkbox to have its 'checked' property changed or listen for a 'click' action to occur on a button. Once you have your event listeners tacked on, you simply write the code for what's supposed to happen when the event you're listening for occurs. So, for instance, when the 'checked' state changes, you might show or hide a set of fields on the screen by toggling their 'visible' property. After you've written the code, just configure the Web.xml so it points to the entry point of your application and start up the server. The framework will handle the rest.

The Right Tool for the Job
For all the great things that AJAX adds to the Web developer's toolbox, it can also add layers of complexity to a Web development stack that is already bursting at the seams. The difficultly in choosing the right AJAX development framework for your needs is complicated by the large number of options that are currently available. Understanding the four levels of AJAX frameworks that Gartner has identified can help you make a better decision. However, you must ultimately align your applications needs with the capabilities of the framework you use, so make sure you understand both your near-term and long-term needs.

While a Level 4 RIA framework like ThinWire can simplify the development effort required to build an effective AJAX application, your application may have specific needs that a Level 1 or 2 framework addresses more effectively. In the end, AJAX is about creating better applications that engage the user in a way that Web applications fell short. Back when Netscape was still king of the Web and Navigator was all that mattered, there were many discussions about how a Web application would be dynamic, interactive, and visually compelling. After all these years, AJAX has arrived to finally make it a reality.