NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Tuesday, March 07, 2006

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:
Traditional and Ajax Application Models
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".
Synchronous and Asynchronous Client/Server Communications
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: 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: 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!

2 Comments:

Blogger Gizmo said...

I was a javascript/DHTML or as today called AJAX a very long time and I found another way to work around the cancer factor as I call it (javascript development). I call it WebGui and it is my new development environment it is basically WinForms like API combined with a AJAX unique communication layer making it possible to create complex applications like "Outlook Web Access" as simple as creating a WinForms application...

See my webcast here here

3/09/2006 06:41:00 AM  
Blogger Chris Loosley said...

Guy, thanks for your feedback, it is good to know that someone is reading! Although I am not in a position to evaluate it as a product, your WebGUI tool certainly looks interesting. It is an early example of the kind of RIA development tool I expected to see appear over the next couple of years, and I encourage other readers to check it out.

You might want to consider contributing information to the open Ajax initiative, which one local commentator described a "an organization of everyone who is not Microsoft!"

Also, I discovered when searching on Google that you may have a conflict with the name WebGUI, because there is already a well-established open source content management tool with the same name.

Finally, I could not actually see the video portion of your webcast -- do I need a particular plug-in to view it? Anyway, I got a good idea of your product by browsing your blog and your WebGUI site -- which I see quotes liberally from the IDC white paper by Josh Duhl that I recommended at the end of my post. I'm glad to see you liked his work too, but if you are using such long quotes, you really should include an acknowledgement ;-)

3/10/2006 07:15:00 AM  

Post a Comment

Links to this post:

Create a Link

<< Home