[This prescient article first appeared on SYS-CON.com nearly 12 months ago.]

We are entering an era of Rich Internet Applications (RIA),  and many enterprise development managers are facing the dilemma - which way to go - remain with  tried and true Java or .Net technologies or less known yet AJAX, Flex, OpenLaszlo or a number of other vendors.  This article is an attempt to give a brief overview of what's out there on the RIA market.

Historically there have been major shifts in the software industry. We moved from mainframes with dumb terminals to client/server. Users gained in convenience and productivity, and mainframe systems were patronizingly labeled as legacy. With the availability of the World Wide Web industry visionaries turned the tables: vendors and corporate IT had been eager to get rid of the complexity of client/server version management and technologists were sold on multi-tier computing. This time client/server was called legacy. Excited with server multi-threading, messaging, persistence, and similar toys, we pretend not to think that, at the end of the day, we'd have to trade user experience and productivity for the transparency of application deployment. And to make us feel better, we proudly called the new breed of applications "thin client."

Now we are entering an era of RIA, which restores the power of desktop applications...inside downloadable Web page. RIAs run in a virtual machine (i.e., Adobe Flash Player or Java VM) and have the potential of becoming a full-featured desktop application soon. As opposed to just simply displaying Web pages delivered from some server machine, RIA really run on the client. Many of the data manipulation tasks (sorting, grouping, and filtering) are done locally like in the old client/server days. In three or four years most newly developed projects will include RIA technologies.
A rich Internet application combines the benefits of using the Web as a low-cost deployment model with a rich user experience that's at least as good as today's desktop applications. And, since RIAs don't require that the entire page be refreshed to update their data, the response time is much faster and the network load much lower. Think of a globally available  client/server application.

Let's illustrate the difference between "legacy" Web and RIA with a shopping cart example. Non-RIA Web applications are page-based. Since HTTP is a stateless protocol, when the user moves from one page to another, a Web browser doesn't "remember" the user's actions on the previous page. As a common treatment of this "amnesia," a user state is stored on the server side in the form of the HTTP session.
Consider the case of an online shopping session. It can go as follows:

1. The user initiates a search for an item on Web page #1.
2. The server processes this request and returns page #2 that may (or may not) contain the required item.
3. The user adds an item to a shopping cart that takes yet another trip to the server to create the shopping cart and store it on the server side. Then the server responds with page #3 so the user can either continue shopping (repeating the first three steps) or proceed to the checkout - page #4.
At the checkout the server retrieves selected items from the session object and sends page #5 to the user for shipping info. The data entered travels back to the server for storage, and the client gets back page #6 for billing information. After that page #7 will confirm the order and only then goes to the order completion page.

This simplest of online purchases consisted of seven roundtrips to the server. In striking difference to desktop applications, a few-seconds-per-page refresh is considered fast(!) for a typical Web application, and the commonly acceptable delay is up to eight seconds. Is the user motivated enough to complete the purchase? Think again, because your system gave him a chance to reconsider seven times in a row. Now assume that the network and/or server are slow...your potential customer went elsewhere.

Rich Internet applications eliminate the roundtrips and substantially improve system performance by doing a lot more of the processing on the client than a thin client Web application. Besides, RIAs are stateful: they accumulate the information right on the client! To put it simply, RIA isn't a set of pages controlled by the server; they are actual applications running on the client's computer and communicating with servers primarily to process and exchange data.

 Both consumer-facing and enterprise applications benefit from being RIAs. It's a well-known fact that e-commerce Web sites such as online ticket reservation systems and online retailers are losing revenues because users abandon shopping carts on non-responsive Web sites during the checkout process. Such Web sites result in lots of calls to the call center, a major operational expense in and of itself. The performance of any system operated by employees is critical to company productivity and RIAs provide a performance boost over HTML applications, while reducing operating and infrastructure costs.
  
RIA Platforms: The Major Choices

There's more than one way to create RIAs that run in the client's browser with the help of some kind of client engine. These are the most popular products or technologies:

• A Java programmer can create Java applets. As mentioned, this solution has been available since 1995.
• Using Adobe Flex you can create an ActionScript application for the ubiquitous Flash Player, a high-performance multimedia virtual machine that runs bytecode files in the SWF format (pronounced swif). The player's JIT compiler converts the SWF bytecode to native machine code for fast performance. The later facility is specific to Flex 2, available since 2006. Although early versions of Flex were out in 2004, they didn't support just-in-time compilation.
• Microsoft Windows Presentation Foundation (WPF) was released as part of .NET 3.0 in November of 2006 and can be used to create both Internet and desktop applications (it also has the Everywhere version  - WPF/E).
• AJAX, a k a DHTML, born circa 1998. This solution was recently boosted with XMLHttpRequest API support for all major browsers. AJAX served as a wake-up call for the user and developer communities. It is often the first step on the migration path from the legacy Web to the world of RIA despite being seriously handicapped by having to support browser incompatibilities and a poor programming model.