Managing Rich Internet Applications [2]

This is the second 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.

In the first post in this series, I introduced the concept of a Rich Internet Application, and asserted that anyone planning to deploy RIA technology must be prepared to invest more in design, development, testing and management to make it successful. By that I meant that deploying an RIA successfully will demand more resources -- skills, tools, process, time, and (of course) money -- than would be required to deploy a more traditional version of a Web-based application in which all application logic is executed on the server.

I have reached this conclusion after studying this subject for the last three months, in the light of my prior experience in the field of software performance management. Factors leading to this conclusion include:

• the nature of much of the technology being promoted for building RIAs today (primitive)
• the stage of evolution of this new application architecture (early)
• the toolsets available to support RIA developers (incomplete), and
• the experiences of others developing RIAs (hard work).

This comment by Todd Spangler in Baseline Magazine neatly sums up the situation today:

Creating an Ajax application from scratch is like having to build a brick wall but first having to figure out how to create the bricks.

This reminds me of the days when I used to program in IBM Assembler -- funny how life in the world of computing seems to repeat itself every few years! (And I'll have more to say about that later). But while this is all fascinating stuff, it is not my primary focus; it is just the starting point for the SLM topics I want to discuss. So although I will devote some space to reviewing the state of RIA technology, I will try to keep those posts concise and provide useful links. If you want more, a few searches will turn up tons of reference material.

The questions I plan to explore in more depth in this series are:

• Why are RIAs so much more difficult to design, develop, and manage?
• How do you measure an RIA user's experience of response time?
• How do you test whether an RIA will perform acceptably in the production environment?
• How do you break apart the time it takes to complete a business transaction using an RIA into meaningful components?
• How do you monitor the performance of an RIA in the production environment, and alert when its behavior is abnormal?
• What kinds of development and systems management processes will maximize the chances of implementing an RIA successfully?

Before I get into any of these details, I'd like to acknowledge the contributions of two people who have helped shed light on these issues. This first is Victor Pavlov, a principal engineer and colleague at Keynote, who knows Web technology inside out, and can figure out how to measure anything. I am lucky that when I am noodling on a tricky question, I can sometimes run into Victor at the coffee machine.

The second is Aleksandar Šušnjar, who I met online after reading his contributions to the discussion of RIAs in Wikipedia, where he shared insights gained from his experience building a product first released in 2002 by his company, Hummingbird. This product, DM Webtop (later renamed DM Web Server) is a component of their Enterprise Document Management suite. In delivering desktop capabilities via the Web, it clearly predated much of today's thinking about the purpose of RIAs and how to build them.

Naturally, Aleks also discovered some potential pitfalls an RIA designer might run into, which I will be mentioning in later posts. Regrettably, many of his insightful contributions to Wikipedia (which can still be found in its history pages) were subsequently removed by other contributors who lacked either his intimate knowledge of the technology or his historical perspective. Rather than waging Wikipedia edit wars, which for a hot topic can continue interminably, he has simply posted his own page about RIA and AJAX.

I am not surprised by these events, because I have found that the computing world tends to attract people who have little sense of history. This explains why it is forever reinventing the wheel, repeating yesterday's mistakes, and tripping over previously solved problems. Rich Internet Applications are a case in point. Mainframe (thin client) computing was replaced by the client/server (fat client) model, which in turn was displaced by the Web-based (thin client) applications. Now the emergence of RIAs signals a return to the fat client model again. The only difference between the client/server and RIA models is that instead of Sneakernets and static installation protocols, Internet and Web technologies now provide an almost universally available platform for distributing function to client desktops dynamically. But many of the over-optimistic claims being made for RIA technology today mirror those popular 15-20 years ago, when everyone was jumping on the client/server bandwagon and predicting the imminent demise of the mainframe -- which, by the way, never happened.

So I'll end by reminding you of the famous saying of philosopher George Santayana: Those who cannot remember the past are condemned to repeat it. One of my goals in this series of posts about RIAs is to keep you from that fate, so I'm glad to be collaborating with people like Victor and Aleks whose common sense is grounded in a strong sense of history!