Web Application Availability

Web Application Availability

Web Application Availability

Free Online Articles Directory

Why Submit Articles?
Top Authors
Top Articles
AB Answers

Publish Article

0 && $.browser.msie ) {
var ie_version = parseInt($.browser.version);
if(ie_version Hello Guest

Login via

My Home
Sign Out



Remember me?
Lost Password?

Home Page > Computers > Software > Web Application Availability

Web Application Availability

Edit Article |

Posted: Feb 16, 2010 |Comments: 0


Application availability is the first quality encountered by customers, but the last one to be determined by the development process, because it depends on the quality of everything else that happens during application design, development, and load testing. A chain is only as strong as its weakest link, and developing RIAs will uncover any weaknesses in an enterprise’s development and SLM processes.

RIAs inevitably involve running complex code on the client, and use more complex and application-specific strategies to manage the communication between browser and server. Making such complex code efficient and bugfree is not a task to be taken lightly. Better tools are needed to help us meet the challenges of creating and managing robust applications; today, while the Adobe suite of Flash tools is a little more mature, Ajax development and testing tools are still in their infancy. The Open Ajax initiative may help to address this issue. Therefore 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 Web-based application in which all application logic is executed on the server. Enterprises that decide to employ the technology must be prepared to invest more in design, development, testing and management to make it successful.

“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.” —Todd Spangler

Responsiveness: Achievable, but not Guaranteed

According to their proponents, RIAs will be more responsive applications. Web server requests will be limited to the bare minimum required to do the job, reducing the size and frequency of data exchanges between browser and server. The reality, however, is less straightforward, as we discuss in the following sections.

Improving Responsiveness Involves Tradeoffs

RIA design can be complex, magnifying the risk of failure should the designer miscalculate. Generally, optimizing any design to speed up one class of work always makes some other workload slower. Unless you consider and test for a wide range of use cases, what seemed to be a clever way to reduce network traffic may sometimes turn out to be slower than the older and simpler design. A simple design applied well beats a clever design misapplied.

Even if the application serves some users quickly, those whose usage patterns do not match the profile the application designer had in mind will probably not receive good service, and in the worst case, may abandon transactions before completing them. Apart from the lost opportunity to serve a customer, abandonment also wastes scarce server resources, because the allocations earmarked for now-abandoned transactions languish unused until finally freed by some type of timeout mechanism.

Making tradeoffs to deliver some responses faster may slow down others. It is essential to test a wide spectrum of usage scenarios. Users who abandon before completing transactions tie up server resources unnecessarily.

Clarity Requires Distributed Application Design

The site must be simple and natural—it must be easy to learn, predictable and consistent. RIA technology may indeed allow developers to create more natural interfaces, but it will not guarantee a better customer experience than a traditional Web application. To quote Garrett, “the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it”.

This advice might seem obvious, but the computing world has a tendency to forget its history, reinvent the wheel, repeat yesterday’s mistakes, and trip 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 Web-based (thin client) applications. Now the emergence of RIAs signals a return to the fat client model again. The difference between the client/server and RIA models is that “sneakernets” and static installation protocols have been replaced by Internet and Web technologies, which provide an almost universally available platform for distributing functions to client desktops dynamically.

But the overoptimistic claims being made today for RIA technology resemble those of 15 to 20 years ago, when client/server enthusiasts predicted the mainframe’s imminent demise, which, by the way, did not happen. As broadband penetration increases, the richer user interaction models of RIAs will inevitably take hold. Customers expect Web sites to keep up with the prevailing user interface models, and penalize those that fall behind. To stay current, enterprises must not underestimate the effort needed to use the newest technologies effectively.

Utility Depends on Everyone’s Contribution

Does a site deliver the information or service customers want? While it is doubtful that switching to an RIA design would ever lessen the utility of a site, neither does it assure increased utility. The synchronous browser communication model may have been a simple one, but its simplicity has not prevented most companies from doing business successfully over the Web using a standard browser.

A few applications such as online gaming and some types of online trading required users to download and install proprietary client software, but these examples were the minority. However, a Web performance and site’s utility diminishes over time as customer needs and expectations change. RIA technology continues to evolve, and as fast broadband connections become the norm, new interfaces and behaviors will become popular because they deliver

Pages: 1 2 3 4 5 6