What is a rich Internet application?
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. And to rub it in, good old desktop applications were labeled
“fat.” 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.” Meet the new challenge: we’re entering an era of rich Internet applications (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. Déjà vu indeed! Industry analysts predict that 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 a 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. Result? Your potential buyer 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 revenue 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. Finally, introducing well-designed RIAs lets companies build better “mousetraps.”
Macromedia introduced the expression rich Internet applications back in 2002 in contrast to the bleak condition of the “legacy” Web, known today as Web 1.0. And yet the first RIA applications were born as early as 1995 when Java was created. Java’s initial popularity manifested itself in a wave of small downloadable programs called Java applets. Applets, created with Java AWT (and later Swing) libraries, were run by the browsers’ Java Virtual Machine (JVM). Ironically, the very technology that made Java popular wasn’t exploited and today Java shines mostly on the server side and in mobile devices.
In 2004 Tim O’Reilly coined the catchy term Web 2.0. Which sites qualify for Web 2.0 status has never been clearly defined. If someone sees a cool-looking Web site, it’s invariably called Web 2.0. Labeling better-looking Web roducts “2.0” is pretty popular these days. Often it refers to social engineering sites that let people collaborate and build the site’s content themselves. Wikipedia has a lengthy article on Web 2.0 that may give you some idea what this term means. See http:// en.wikipedia.org/wiki/Web_2.0.
There’s now Web 3.0 too, which refers to the Semantic Web…but let’s stop playing this name game and return to the main acronym of this book: RIA.