Managing Rich Internet Applications [3]

This is the third post in a series devoted to the challenges of Service Level Management (SLM) for Rich Internet Applications (RIAs). In these applications, some processing is transferred to the Web client while some remains on the application server. Previous posts introduced the subject, and listed the topics I plan to address.

RIA Technologies
Before diving into the management issues posed by Rich Internet Applications, I will introduce the two principal technologies used to implement RIAs -- Ajax and Flash -- and provide a few links I have found useful.

I am going to begin with Ajax, because the seminal article defining the term "Ajax," Jesse James Garrett provides such a clear introduction to the subject. After explaining that ...

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
  
• dynamic display and interaction using the Document Object Model;
  
• data interchange and manipulation using XML and XSLT;
  
• asynchronous data retrieval using XMLHttpRequest;
  
• and JavaScript binding everything together.

... he uses two figures that reveal the essential differences between a classic Web application and one implemented using Ajax:

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client... This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

Figure 1 illustrates how Ajax is different:

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

While this diagram refers to Ajax technology, its structure describes RIAs in general. Garrett explains that the RIA model:

... eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. ... At the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf".

Figure 2 (below) illustrates how the addition of a client-side engine ... "allows the user’s interaction with the application to happen asynchronously — independent of communication with the server".

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom)

In the best case, a client-side engine can mean that users spend less time waiting for the server to respond. Like all writers making the case for Ajax and RIAs, Garrett assumes that this architecture guarantees a more responsive user experience -- but the reality is more complicated. In practice, an RIA's responsiveness will depend on several factors that I will be exploring in this series of posts.

For more detailed discussion of the history of RIAs and Ajax, I recommend Aleksandar Šušnjar's Wikipedia page about RIA and AJAX. For more technical details, see these Sitepoint articles:

• Take Command with AJAX
  
• AJAX: Usable Interactivity with Remote Scripting
  
• Painless JavaScript Using Prototype

What about Flash?

You may feel I should have started with Flash, because it came first, but opinion is divided on that point. It is true that Macromedia announced their Flash MX product line in 2002 (see Developing Rich Internet Applications with Macromedia MX for a good summary), whereas the term Ajax was coined only in February 2005. However, the underlying RIA techniques have been in use for much longer. For example, on his Wikipedia page Aleks cites the pioneering work of the now defunct company, Desktop.com. In 1999, Dave Winer wrote in his blog:

Want a vision of where the Web is headed? Check out Desktop.Com. Launched in beta a couple of weeks ago, this stunning site changed my point of view on what can be accomplished with JavaScript, ActiveX and whatever other kinds of mysterious code-doo-dads they're using... Desktop.Com says the Web is a desktop, just like the desktops on the Mac and Windows. Icons down the left edge of the browser window, menus at the top of the window, double-click to open a directory, double-click to edit a file. -- Dave Winer

If you need to compare Ajax and Flash, here are four links you may find interesting:

• Weighing the alternatives
  
• Flash RIAs vs. Javascript RIAs
• Ajax vs Flash, Round 1 and Round 2

Any search engine will turn up plenty more material on this subject, and I will return to it when discussing aspects of RIA measurement and management.

You can download many reports and papers about Flash and RIAs from the Adobe (formerly Macromedia) Web site -- for example, these. Not included in that list is one of the most readable introductions to Rich Internet Applications, a 2003 paper sponsored by Macromedia and Intel and written by Joshua Duhl of IDC, an excellent writer who I once worked with (in the early 90's) at ONTOS, a Boston-based Object DB company. Another former colleague from Boston, Alan Sarasohn, used to claim that the computer industry is run by just 300 people, but they keep moving around. I'm starting to believe him!