RIA Characteristics


The Behavioral Characteristics of Rich Internet Applications


The Evolution of the Web Page


The Web was originally intended to help researchers share documents as static pages of linked text formatted in HTML. From there, Web pages quickly evolved to include complex structures of text and graphics, with plug-in programs to play audio and video files or to stream multimedia content. Web developers supplement the basic browser function of rendering HTML by invoking code (scripts) on the user’s computer (the client). These scripts can create interface elements such as rollover effects, custom pull-down menus, and other navigation aids. They can also execute UI methods, for example, to validate a user’s input in an HTML form.

These script capabilities, while they enhance a user’s interaction with individual Web pages, do not change the fundamental model in which application logic runs on the server and executes between Web pages after the user clicks. This behavior is said to be synchronous, that is, after each click the user waits while the server handles the input and the browser downloads a response page. In e-commerce, a typical user interaction involves a series of Web pages, which represent steps in a larger process that comprise a Web application or WebApp. While a WebApp may involve many pages, it still uses the traditional synchronous approach


From Web Pages to Rich Internet Applications


Recently, Web developers have been evolving a new model—the Rich Internet Application (RIA) , which is “a cross between Web applications and traditional desktop applications, transferring some of the processing to a Web client and keeping (some of) the processing on the application server”

As with most computing advances, several technologies are vying for acceptance as the de facto standard way to build RIAs. The main contenders are Adobe’s Flash suite, Java applets, and the collection of Web technologies known as Ajax, a term coined in 2005 by Adaptive Path’s Jesse James Garrett . Garrett explained that “Ajax is 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.

In practice, we can think of Ajax as a development concept or approach, as various technologies can substitute for those specified by Garrett. Some developers even claim that “Flash is Ajax” , and others advocate using them together. See AFLAX Complicating any analysis of RIA technology is the massive amount of hype surrounding both “Web 2.0” (a superset of RIA) and Ajax (a subset of RIA). Figure 1 illustrates these relationships.


The RIA Behavior Model


A reference model is useful for establishing a shared frame of refer­ence or conceptual framework to structure subsequent discussions of a subject. Figure 1 introduces the RIA Behavior Model, which represents the principle elements to be considered in any discussion of RIA behavior, and in particular RIA performance and management.

Note that the model does not address the complex human forces that determine perceptual, cognitive, and motor behaviors. It merely represents a few behavioral outcomes that are relevant in the context of an interaction between a human user and a Rich Internet Application.

At the highest level, the model illustrates three major aspects (indicated by the color coding in the figure), each of which influences application performance:

• The application’s design and usage environment, or context (upper row, green)
• The user’s expectations and behavior (lower left, yellow)
• The application’s behavior when used (lower right, blue)

We now describe the model by stepping through what happens during a user interaction with a browser-based application. In the process, we note some key issues that affect the responsiveness of RIAs.


The RIA Behavior Model


In a traditional synchronous Web application, this process repeats several times. Because applications usually require an exchange of information, at least one of the requests the browser sends to the server will typically be an HTTP POST (as opposed to the much more common HTTP GET request), to upload some data a user has entered into a form. Consider, for example, shopping at Amazon.com as a return visitor. At minimum, even if the application recognizes you from a cookie, you must reenter your password to confirm your identity. But after that, the site already has your personal information and you can complete your transaction by clicking on the specified buttons on each page as they are presented to you.


Server-Side Elements


Servers must field requests concurrently from many users. No matter how powerful the server, every concurrent user consumes a small share of the server’s resources: memory, processor, and database.

Web servers can respond rapidly to stateless requests for information from many concurrent users, making catalog browsing a relatively fast and efficient activity. But a user’s action that requires the server to update something (such as clicking a button to add an item to a shopping cart) consumes more server resources. So the number of concurrent transactions—server interactions that update a customer’s stored information—plays a critical role in determining server performance.

In the model, the grey arrows and the boxes labeled Users and Transactions indicate that server performance is strongly influenced by these concurrency factors. Servers typically perform uniformly well up to a certain concurrency level, but beyond that level (the knee of the curve), transaction performance quickly degrades as one of the underlying resources becomes a bottleneck. As a result, seemingly small changes in application behavior or in the infrastructure serving the application may have a significant effect on the user’s experience of response time if those changes extend transaction durations. People who design and test back-end systems already know that behavioral variables such as user think-time distributions and abandonment rates per page have a significant influence on the capacity and responsiveness of servers under load. Now RIAs (as indicated by the dotted lines in Figure 2) give application designers the flexibility to design applications that attempt to take account of such behavioral variables.


The Client-Side Engine


Although implementations differ, all RIAs introduce an intermediate layer of logic— a client-side engine—between the user and the Web server. Downloaded at the start of the session, the engine handles display changes and communicates with the server. Adding this layer allows developers to build Web applications with characteristics that the Gartner Group has described as “between the fat but rich client/server model and the thin but poor Web based UI model.”

Adding a client-side engine does not prevent an application from implementing the traditional synchronous communication style. But it also allows the user’s interaction with the application to happen asynchronously—independent of communication with the server. Figures 3a and 3b illustrate how the asynchronous pattern of user-to-server communication implemented by RIAs differs from the synchronous behavior of a traditional Web application. In a Rich Internet Application:

• information can be fetched from a server in anticipation of the user’s input;
• in response to an input, the screen can be updated incrementally instead of all at once;
• multiple user inputs can be validated and accumulated on the client before being sent to the server;
• responses to some user inputs can be generated without communicating with the server;
• processing previously handled by servers can be offloaded to the client desktop.

Designers can exploit these possibilities to make their applications more responsive, and most writers advocating Ajax and RIAs assume that the architecture guarantees a more responsive user experience. Indeed, in the best examples, users will spend less time waiting for the server to respond; however, employing these techniques will inevitably lead to a more complex design than the traditional synchronous Web application. The challenge of SLM is to ensure that the outcome is actually a more responsive user experience. Despite the optimistic claims being made for Ajax and Flash, there are no guarantees. In practice, RIA responsiveness will depend on several factors that we discuss later in this paper.


Measuring RIA Responsiveness


Measurement Foundations


Before considering the particular challenges of measuring Rich Internet Applications, we first review some fundamental aspects of Web application measurement.


Reasons for Measuring Applications


As Keynote CEO Umang Gupta likes to say, “there are apps people and ops people.” This handy way of subdividing the world of information technology pinpoints an essential division that is reflected in many areas, such as users and systems, clients and servers, developers and administrators. Accordingly, the two main reasons for measuring the performance of a distributed application are to determine how quickly users can achieve their goals, and to discover how a system behaves under increasing load. The first focuses directly on the users’ experience, the second investigates underlying server behaviors that, in turn, will determine what users experience.

Within these two broad categories, measurement activities and tasks may focus on a variety of possible sub-goals. Ten of the most common motivations for measuring applications are listed in Table 1. Those addressing the first goal are conventionally called measurement, while those addressing the second are referred to as load testing, or simply testing. However, there is considerable overlap between them because they share many technical problems.


Active and Passive Measurement


A crucial factor in any measurement process is the target—in this case the particular mix of application software and hardware behaviors that are measured. A general term for such a mix is a measurement workload. A work load may be either real (produced by the actions of real users of the application), or synthetic (produced by computers that emulate user behaviors).

Measurements of real work loads are referred to as passive measurements, because the act of measurement involves simply observing an application’s behavior under normal usage conditions and recording what happens. Active measurements, in contrast, are obtained by generating synthetic application traffic. For example, one might measure a system’s maximum capacity by emulating a mix of user actions and increasing the number of simulated users until a component of the system saturates.

Note that the passive and active measurement approaches differ only in the way application traffic is generated—both still require mechanisms to measure how the system behaves in response to that traffic. Passive measurements must capture the behavior and experience of real application users, while active measurements must do the same for synthetic users. So both approaches must deal with the same set of technical complications created by the need to measure Rich Internet Applications.

Although active measurements do impose extra traffic, they rarely distort a system’s behavior sufficiently to affect the validity of the results. For a typical e-business application, the number of additional active measurements required to sample the system and obtain useful data is usually insignificant compared with normal traffic volumes. Thus normal levels of application responsiveness and availability can be measured using either active or passive methods. Load testing on the other hand normally involves active measurement of a portion of the system that is isolated from real users for the purpose of the test.


Ready to Start?

Tell Us About Your Project
Step 1 of 2


Email Address:

Go to next step

Guaranteed No Obligation Response
Within 12 Business Hours