No Turning Back from Rich Internet Apps

Rich Internet Application (RIA) describes what much of the software development community aims to do: break out of primitive Web delivery to deliver robust functionality, exciting data visualization, and "thicker" role-based and process-oriented user interfaces. RIAs have been made possible by the fast-growing use of development approaches such as Ajax. The trend satisfies demand from end users that their Web applications appear and function like any native application on their desktop, offering drag-and-drop functionality, dynamic interaction, state management and seamless communications with their client platform of choice.

RIAs have made the Web a legitimate platform for corporate America, with the best of these applications looking very similar, if not identical, to native counterparts. The limitations of static HTML presentation and demand for continuous connectivity are being eliminated. Indeed, interest in RIA has lead to a glut of technology start-ups, all looking to capitalize on this emerging market.

This article explains the advantages of RIAs and their essential architectural differences with conventional Web applications. After reviewing benefits and potential drawbacks, we'll also review the dominant approaches to building RIAs, including Ajax and Flex. Whether RIAs are in your short-term or long-term road map, there's no doubt that they represent the future of enterprise development.

The Case for RIAs
The term "Rich Internet Application" was introduced in a Macromedia whitepaper in March 2002, though the concept had been around for a number of years before that under different names, including remote scripting (Microsoft), X Internet (Forrester Research), rich Web clients, and rich Web applications. There are several reasons to move toward RIA:

RIAs have been popularized as a mainstream Internet experience by the likes of NetFlix and Google (see "The 'Google Effect'" sidebar, and this has helped fuel demand for potential enterprise applications. While Salesforce.com is the primary example of the pervasiveness of software as a service (SaaS) applications, there are thousands of SaaS players today that offer up everything from logistics processing to background checking software, all on demand, with user interfaces delivered over the Web. Many of these vendors are looking toward RIA as a means of finally closing the gap between traditional enterprise software, with a native look and feel, and emerging SaaS. Indeed, Ajax seems to be the primary direction for many of the SaaS players, and many have launched Ajax-enriched production sites or beta sites.

Technology and Architecture

So, what is technically different about RIAs? The classic Web architecture was not designed for application delivery, but for content or document delivery. Conventional Web applications rely heavily on client/server architecture, with a very thin client and a very fat server (see Figure 1). In this approach, almost all of the processing is done on the server; the browser simply displays the content (HTML). To emulate a dynamic application, several documents are pushed to the user interface, all being processed by the back-end server.

What's so limiting about this approach is that all of the processing has to occur on the server, and thus users spend their time waiting for server responses. The architecture (see diagram at right) functions something like this:

In contrast, RIAs get around these limitations by taking advantage of client-side processing (see RIA Architecture diagram at right), eliminating the slower, synchronous route taken in a conventional Web app. A RIA is still client/server, in essence, but the client is fatter, and thus the interface experience delivered to the end user is much richer, native-like and more productive. Therefore, the new RIA architecture functions something like this:

All RIAs share a common feature: The client engine. The client engine can be any number of mechanisms and in many cases is downloaded into the client computer. Java and Flash/Flex are in this category, and downloads may occur unseen by the user. It's the job of the client engine to act as an add-on to the browser, providing access to RIAs that offer a complete end-user experience. The client engine provides the interface for the end user and mediates the connection with the back-end server, abstracting the complexity of the connection.

Another feature is the notion of asynchronous communications between the client and the server. Indeed, as the client engine processes, the interface messages are being dispatched back to the server and received from the server. This frees the user from having to wait for entire sets of data to be synchronously sent to the server and results returned. In short, this feature is analogous to internal message-passing architectures employed by native operating systems, such as Windows XP. However, in this case, the message passing is extended to remote, Internet-hosted servers.

Benefits and Drawbacks

Other benefits of RIA go beyond the user experience to offer a better paradigm for processing and performance. Indeed, the client/server model for RIA offers a better balance for using computing resources. Since everything is not about the server, the processing is more evenly loaded. Thus, overall performance, as well as end-user satisfaction, should improve.

The asynchronous communications model assures that RIA users won't have to wait for screens to return. The interface is constantly carrying on a conversation with the back-end server, both checking and validating data, and even pre-fetching information, anticipating future needs of the user.

Finally, this architecture is much more network efficient. For most RIAs, network traffic is actually reduced, since you're only sending the necessary information to and from the server; thus redundant HTML does not have to come along for the ride.

There is always a downside to anything new, and RIA is no exception. In some instances, RIAs don't perform well on older computers, as they process scripts using interpreted languages like JavaScript. Faster processors and faster networks solve this problem, but counting on all clients to be speedy enough for RIA may be a bit premature.

Performance tends to be more of a problem with Ajax clients than with Java and Flash clients. The latency that occurs when downloading client engines and scripts can be a bit annoying as well, though RIA technology providers are working on better caching and compression mechanisms to get around this problem. Another challenge you may encounter if you deploy RIAs is the fact that you're in a sandbox and won't be able to access other native resources directly. Also, RIAs may not run if browsers have very strict security policies such as disabled scripting.

RIAs may present ongoing development challenges as well. For instance, the use of the asynchronous communications paradigm is much more complex to manage. This makes it more difficult to isolate problems than when using traditional HTTP/HTML. Development is a bit more difficult as well. The power of RIA is liberating for many developers and application architects, but the development model is much more complex, and, thus, more bugs are going to come out of the woodwork as RIAs become the standard.

RIA Approaches

While there are many technology approaches to RIA today, the most used are JavaScript/Ajax, Adobe Flash/Flex, Java and ActiveX. Each is very different in the mechanisms they provide, but with the same primary benefits to the RIA user.

Ajax (Asynchronous JavaScript and XML) has been made popular by Google (see sidebar) and by at least two dozen well-funded startups looking to capitalize on the popularity of the approach. Ajax uses a client-side script processing paradigm, with asynchronous communications to the back-end system. So much is written about Ajax that it doesn't make sense for us to get too deep here. However, it is safe to say that this approach has the most momentum by far.

Adobe Flash, a popular method of providing dynamic and interesting content to Web sites, is also used to build and deploy RIAs. The Flash Player is a widely-supported virtual machine that executes byte-code downloaded into the browser. (In one example of the technology in use in a BI application, Microstrategy recently introduced a Dashboarding module powered by Flash.) Adobe Flex, using the same technology and technique, was created by Adobe to provide a better structured programming model and data services data services (see related "Debriefing" interview with Adobe's Jeff Whatcott). Adobe is developing better integrations between Flex and Ajax with the next release so you can combine techniques.

ActiveX has been around for the longest time, providing a component that downloads into Internet Explorer to offer RIA capabilities to the browser. This was Microsoft's answer to Java applets and debuted before Ajax became the most popular way to offer RIA. Many find ActiveX to be too Microsoft centric, albeit most browsers support ActiveX controls, Microsoft or not.

Microsoft's movement in the RIA space is interesting as well. With the Vista release, Microsoft will introduce "Windows Presentation Foundation," formerly code-named "Avalon." It unifies all presentation resources such as documents, images, audio/video, and applications under Windows. Presentation Foundation lets developers construct applications by writing XML-based code called "XAML," and applications can run on Windows as well as Web browsers.

Java applets, like ActiveX controls, run in standard HTML pages providing RIA capabilities, and appear to support a wider array of platforms and brands of browsers. The paradigm is the same as ActiveX and Flash: Download the code and execute in a virtual machine. The Only Direction

What's important to remember about RIAs is that they are indeed changing the way we view and use browser-based applications, blurring the line between native desktop applications and those that are Web-delivered. In fact, once users are introduced to the power of RIAs, it's difficult to make them return to traditional Web applications.

The reasons you use RIAs are many, but most find that the ability to get the value of software without having to go through an installation procedure to be a huge benefit. You always have the best and most current version of the software, and you don't have to update or maintain the software through its lifecycle. This is the value of SaaS as well as RIA.

RIA are heterogeneous and don't require that you localize an application for multiple platforms and interfaces. The Web becomes the platform, and software providers need only test and deploy using a single approach and architecture. Resources that would otherwise be spent on localization and optimization for specific platforms can be channeled elsewhere.

RIAs are not just a step in the right direction, they are the direction. What you see in your browsers will change forever, and more enterprise applications will be Rich Internet Applications. Count on it. In the not too distant future, you won't be able to tell your RIAs from your conventional apps.

Application integration and service oriented architecture expert David Linthicum heads the SOA strategy and implementation consulting firm The Linthicum Group. He's also a contributor to the upcoming book Real-World AJAX: Secrets of the Masters.