Rich Internet Applications: State of the Union

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 know 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.

Java

Even though the Java programming language became popular largely because of applets and the famous dancing Duke (http://java.com/en/download/help/testvm.xml ), applets haven’t become Java’s main use pattern. The main reason: the large footprint of the required JVM (currently 16MB). And there are other drawbacks. For instance, although Java Swing pushed a platform-independent look-and-feel, absent any good-looking off-the-shelf GUI widgets it was hard selling it to the public. In this regard Flash and Flex creators did a much better job with their eye-candy components. Or take audio and video integration. Today people are used to having streaming audio and video components embedded in Web pages. But the multimedia Java API remains rudimentary, to say the least.
There are some efforts to minimize the size of the JVM used by Web browsers and the Java Browser Edition project now needs “only” about 3MB to run a primitive Hello World applet. But this can’t compete with Flash Player 9, which managed to accommodate two virtual machines in a 1.2MB download that can run any RIA however complex.
Another issue with Java applets is that they don’t offer a seamless download of the proper version of the JVM along with the applet. Flash Player’s express install does precisely that.
Having said that, I must acknowledge that Java Swing is a very mature and robust technology for creating GUI applications delivered either over the Web or installed on the desktop. You can do literally anything with Java Swing – if you can afford it. No, you don’t pay licensing fees, but because of the longer development cycle and need to engage expert programmers, industrial-size Swing projects are usually quite expensive to build and maintain.

Adobe Flex 2

Flex 2 applications run cross-platform in a ubiquitous Flash Player 9 that’s a lightweight virtual machine. The platform includes:

  • an XML-based language called MXML that supports the declarative programming of GUI components targeting designers;
  • the standard object-oriented programming language, ActionScript 3.0, based on the latest ECMAScript specification;
  • server-side integration via Flex Data Services giving client applications transparent access to the world of J2EE;
  • charting components, access to multimedia controls, etc;
  • and an Eclipse-based full-featured IDE with automated deployment, debugging, and tracing facilities.

The Flex 2 platform is easily extendable and integrates well with server-side Java, ColdFusion, PHP, Ruby, ASP, and the like.The SWF file format is open, and there are third-party open source products that offer tools for creating RIAs delivered by Flash Player like OpenLaszlo from Laszlo Systems. This is what comes at no cost with Flex 2:

  • MXML – an XML-based declarative programming language for creating GUI.
  • ActionScript 3.0 – an object-oriented language similar to Java.
  • Flash Player 9 – a virtual machine with a tiny footprint that lives inside a Web browser and runs your compiled bytecode (.SWF).
  • Command-line compilers and debugger.
  • Flex Framework, which includes a library of well-designed GUI component: buttons, tab folders, data grids, tree controls, animated effects, and more.
  • Flex Data Services Express (FDS) – a template Web application deployed in a J2EE server to communicate with ActionScript client application run by Flash Player. FDS Express is limited to a single CPU, which makes it useful only for learning purposes.

The following Flex tools require a purchased license:

  • Flex Builder – the Eclipse-based IDE
  • Charting component
  • Flex Data Services Departmental, 24×7, 100 concurrent users
  • Flex Data Services Enterprise, 24×7, unlimited users

In a nutshell, the process of creating a basic Flex 2 application consists of the following steps:
1. Design application by adding MXML components like this button:
<mx:Button label=”Place Order” click=”processOrder(event)”/>
If you use Flex Builder IDE, you can apply drag-and-drop techniques. Alternatively, you can write the MXML as text.
2. Write the code in ActionScript per your functional specification, for example:
private function processOrder (event:Event):void{
//The business logic goes here
}
3. Compile the code: The Flex compiler automatically converts MXML into ActionScript and creates bytecode output in a form of an SWF file to be run in Flash Player 9 or above. You’ll enjoy a fully automatic compilation process if you use the Flex Builder IDE.
4. Deploy the SWF file and the wrapping HTML page in the Web server of your choice. The deployment process and creating the wrapped can be completely transparent if you use the Flex Builder IDE.
More advanced Flex applications can include interaction with the server-side systems through FDS, which provides remote access to server-side Java objects and Java EE components, extensive messaging support (including JMS integration), synchronization with persisted data, and integration with other persistent technologies.
WPF

Recently released Microsoft’s Windows Foundation Platform, or WPF uses an XML-based declarative programming language called XAML to create GUIs and C# as a general-purpose programming language. WPF is suitable for creating both RIA and desktop applications. XBAP stands for XAML Browser Application and it’s a WPF way of creating RIAs that runs in Internet Explorer.
Microsoft has released a Beta version called WPF/E that will run on some non-Windows platforms (this version uses substitutes C# with JavaScript). While living in a sandbox, XBAP will have access to all .NET 3.0 functionality but WPF/E won’t. Common Language Runtime (CLR) is the client’s WPF engine.
To create WPF applications, developers can use Microsoft’s Visual Studio 2005 IDE with installed .NET 3.0 extensions. The next version of this IDE, called Orcas, will include a visual GUI designer. WPF developers use the same code base for writing XBAP and desktop applications: they just enclose the code sections that aren’t allowed in XBAP into the ifdef blocks.
Microsoft XAML code looks similar to Adobe’s MXML. Even though today’s Flex 2 is a lot more mature than WPF, Microsoft has an established developer base, while Adobe traditionally catered to designers, and its main goal today is to convince enterprise developers (particularly the Java camp) that Flex can be a tool of choice for creating business RIAs.

AJAX

While the term AJAX was coined by Jesse James Garret in February of 2005 and is partly rooted in the asynchronous XmlHttpRequest implemented by Mozilla, lots of developers have used Microsoft’s version of XMLHttpRequest and alternative techniques like IFrame since 1999. These techniques facilitate synchronous and asynchronous communications between the script in a page and server-side code. The main problem with AJAX is that despite its popularity it has no technical foundation. While the other solutions we mention here are based on rock-solid virtual machines, there’s no standard VM for AJAX. Each browser implements AJAX building blocks differently. There’s a chance that deployed AJAX application will require code changes with each new browser release. Wait, let’s rephrase that: there’s a chance that a deployed AJAX apps may run as is on a new browser release. Do you want to take chances with your business?
That said, Internet giants like Google, Yahoo, and Amazon are building AJAX apps on top of their own abstraction layers such as Google Web Toolkit (GWT). Because of the immature level of the technology, these abstract layers need constant vendor attention as soon as changes appear.

AJAX Shortcomings

An ability to create flicker-free Web apps without buying more software is AJAX’s big appeal. You may have heard the chant “AJAX is free.” Here’s the simple translation: no commercial AJAX tool is worth paying for. There are hundreds of libraries, toolkits, and control sets that give you the impression that AJAX applications are cheap to develop and strategically safe since there’s no vendor lock-in. Actually, there is vendor locking because you won’t manually write JavaScript code and will have to pick an AJAX library of some vendor. Now think about it: starting from the ground up you need a communication layer, messaging and remoting mechanisms, an HTTP sniffer, a library of UI components with shared objects and event models, a visual IDE that understands these components in design time, and a debugger that accommodates all this stuff. On top of that, there’s internationalization support, accessibility for the disabled, and support for automated testing tools.
You really think you’re safe with mix-and-match from different vendors? If the answer is yes, you must be working for a software company in the RIA business. Coming to reality, long development cycle, lack of free quality GUI components, and the shortcomings listed below make AJAX less appealing and, actually, the most expensive way of creating RIAs.
These are some of AJAX’s current drawbacks:

JavaScript development tools are limited due to the dynamic nature of the language, and debugging any DHTML/JavaScript mix is a pain. Yes, Google’s GWT can spare you from writing JavaScript manually, but at the end of the day, it’s still JavaScript that has to be deployed in production. When the system isn’t working and time is limited, what are you going to use to debug it – the real page of Java mock-up?

Tons of JavaScript source code has to go over the wire to the client to be interpreted by the browser. We’re talking about business applications, not some proof-of-concept demo.

Web browsers will happily display your application even if a piece of JavaScript didn’t arrive at the client. You won’t know of a problem exists until you execute the particular use case.

A simple right-click followed by the “View Source code” menu option would reveal your business application code. Better yet, all this code resides as plain text in the browser cache on disk. Because of this, you have to drop all the code comments and use obfuscators to protect your code from being stolen.

HTML rendering is slow: think of a data grid that contains 5,000 records. How long are you ready to wait for your sales report?

Any data manipulation by JavaScript is inherently slow because JavaScript is an interpreted, not a compiled language. We’re talking thousand of times slow.

The code is more vulnerable to hacker attack, a fact that was proved recently by a worm that stole a bunch of mail addresses from Yahoo address books.

AJAX doesn’t support server push. The server-side application can’t publish the data directly to the client. AJAX applications have to poll the data from the server at specified time intervals without knowing if the data is there or not.
It’s not easy to find good AJAX programmers.

To summarize, if you’re developing a new enterprise business RIA from scratch, AJAX may not be the way to go. Choose a solid application development environment that offers a virtual machine at runtime like Flex/Flash, Java, or WPF. Any of these environments is more productive than AJAX. If you already have AJAX applications you can nicely integrate new Flex RIAs in existing AJAX applications using tools like FABridge from Adobe for communicating between AJAX and Flex.

During AJAX’s first year of life, every article or book on the subject mentioned Google Maps and Gmail, and various type-ahead samples: you enter the first zip code digit in a text field, and it suggests your possible choices based on your input without a page refresh. Today, you can read about a number of AJAX applications, including ones that work with photo images loaded from the popular flickr.com Web site.

Lastly, I’d like to make it clear that popular comparisons of Flex versus AJAX are simply wrong, since Flex is a framework and complete development platform, while AJAX is a set of techniques. To compare apples to apples, you should compare products like Flex against GWT (Google) and the like.
Other RIA Solutions

OpenLaszlo

OpenLaszlo from Laszlo Systems is an open source product that lets you create applications that can be deployed as DHTML or Flash Player files. The ability to generate DHTML code made it a good candidate for developing applications for mobile devices, and Sun Microsystems has recently partnered with Laszlo Systems to bring this technology to the Java mobile space. This is direct competition for Adobe Flash Lite.

GWT

GWT stands for Google Web Toolkit lets you write programs in Java and convert them to JavaScript so they can be delivered as AJAX Web applications.
An interesting GWT feature is that it compiles Java into various versions of JavaScript to accommodate the specific needs of different Web browsers. GWT comes with a library of extensible components. The number of these components was limited, but that will probably change soon, because it’s Google.

NexaWeb

NexaWeb offers a Java-based thin client that doesn’t require any additional installation on the user’s desktop. The application’s state is controlled by a small Java applet running on the client. This applet communicates with the NexaWeb Java EE application as needed. To avoid issues related to the version of the Java Runtime Environment installed with the Web browser, NexaWeb uses JRE 1.1 for its applet.

Some Pragmatic Flex/Java Considerations

Cool technologies come and go. Only some of them settle down in the toolbox of a professional programmer working on enterprise business applications. The technical excellence of any software is important, but it’s not the only component in its success.

The Learning Curve: Reuse of Skills and Code

One important concern of any development manager is the availability of a large pool of people who know a particular software. There are plenty of Java programmers with the skills required to develop Web applications, and the good news is that enterprise Java developers with servlet/Java EE programming skills or Java Swing experience will find the Flex path very easy.
Java and ActionScript 3 are very similar; Eclipse is a familiar environment for many Java developers. Since Flex piggybacks on Java EE and browser technologies, a server-side Java programmer should be able to correlate his current skills with the development process in Flex. Java Swing developers will instantly spot similarities to Java event and layout models. In our experience, the typical ramp-up time for motivated Java developer is two weeks. The best part is that Flex seamlessly integrates with existing Java server code of any flavor – POJO, EJB, Hibernate/Spring, or JMS, so the server-side part can literally remain unchanged.
Application Security
Another important consideration is the security of Flex/Java applications. Flex server-side security management is quite extensive, and it lets you use either container offerings or custom security providers via declarative XML binding. There are a couple of challenges since Flex supports multiple protocols, so Java EE security that relies only on HTTP sessions has to be extended, but it’s a simple and well-documented process. On the client side, it builds on Flash Player security that’s known for its lack of serious security flaws. You have a built-in security manager that has all the standard protection for cross-domain and zone access. Corporations can further restrict the code they get from third parties by wrapping the code loaders in additional security managers.
Flex GUI Performance
Java Swing is a tried and true tool for developing responsive GUIs in demanding applications like stock trading and online auctions. Flex is capable of providing near-real-time data rendering to the GUI and very high refresh rates on large data sets. Flash Player 9 is the high-performance modern virtual machine with precompiled optimized code and a just-in-time (JIT) machine code compiler.

Shorter Development Cycle
It’s very possible to build the client side of a real-time portfolio display integrated with news feeds and graphs in about 200 lines of Flex 2 code. A similar Swing program (even if it’s created with commercial IDEs) would be several times larger.
A decent Flex developer should be able to prototype (short of server processing) most of the UI for a specific trading system by the end of the first week. If you’re lucky and system integration went okay, you can add the collaboration features and multimedia – with the total client code base for the whole project coming within 1,000-1,500 lines. This is definitely not possible with Swing. Of course, some people will say modern Java IDEs generate lots of boilerplate code automatically, but this is still the code that someone has to read, understand, and fix if needs be.
Having said all this, there is a big difference between an application prototyping and delivering a final product – you still need to write code, create new components extend ActionScript classes and implement interfaces. Flex is not a magic wand.
Flex: Room for Improvement

While many programmers who dealt with previous versions of Flex are really happy now that they have a professional Eclipse-based IDE, Java programmers are spoiled by the variety of excellent and responsive IDEs. Flex Builder helps a lot in writing Flex code, but it’s not as Flex Builder helps a lot in writing Flex code, but it’s not as sofisticated and elegant as it could have been. It’s even not as good as its daddy Eclipse.

While you can use Flex just to connect to your existing applications written as JSP or any other HTTP-compatible technologies, you’ll get performance gain if you’ll use Flex remoting and messaging that is build on fast Adobe proprietary protocols called AMF3 and Real Time Messaging Protocol (RTMP). To take advantage of these benefits you have to purchase Flex Data Services licenses, while may not be affordable for small businesses.

Connection Management

Flex provides an extensive infrastructure for managing connections between the Web browser and the server. It lets you specify all the protocol details for the RTMP, HTTP, HTTPS as well as plain socket connections. You can then specify the order in which the protocols should be tried due to availability/firewall issues. You also get alternative real-time push or pull connections on additional protocols, a direct socket API, and tons of low-level hooks that let you build any protocol you want.

Flex and Agile Development

In mid-‘90s PowerBuilder and Visual Basic were the tools of choice in the client/server field. Software developers didn’t really worry about what was under the hood, but more importantly, they were business users’ best friends. They could do stuff quickly, or using the modern jargon, they were agile programmers without even knowing it. They’d ask the business user Joe, “How do you usually do your business? What would you like to have on this screen? Describe the steps of your business process.” Most likely Joe wouldn’t know all the answers, but this was okay, because developers could come back to the user the next day with a working prototype. This was easy with PowerBuilder’s DataWindow. When Joe-the-user saw the prototype, his glassy look all of a sudden would become friendly and understanding. Now Joe was back in control: “No, you did this part wrong, I wanted it different.” No problem, developers would return with the changes the next day (not next month, but the next day!).
Developers didn’t really know how DataWindow worked, but they trusted this component. PowerBuilder used event-driven programming model, which was clean and simple. Object A triggers event XYZ on object B, and this event can carry a payload – the data that object B needs to operate. Using modern jargon it’s called Inversion of Control or Dependency Injection design pattern. What’s important is that the object B doesn’t know about object A. On the same note, if object B needs to return the result of some internal function back, it would broadcast this result “to whom it may concern” by triggering one of its own events. This is loose coupling in action.
The mentality of many Java programmers was different. They’d assign lower priority to the user’s windows and spend most of their time designing a multi-tier system that didn’t depend on any specific look-and-feel and could be universal. Meetings with Joe would be rare because they couldn’t create a decent prototype fast. Fancy IDEs with GUI designers like Matisse weren’t in the picture yet and, more importantly, Java programmers were thinking big: UML, design patterns, application servers, and clustering. They enjoyed the programming process for itself. They didn’t like the mindset of old-fashioned PowerBuilder or Visual Basic programmers who were thinking windows and screens.
With Flex you started to care about the business users again. You can change the prototype twice a day, and Joe can do the same with his business requirements. No pile of project documentation is needed. The napkin is back and it works. Flex architects can give the server-side Java team the final okay only after Joe is 100% happy.
Besides, with Flex we can have the best of both worlds: the source code of the Flex framework is available, we can learn how it works inside, and override some functionality with what suits our needs better.
Working with Flex promotes agile development, where the people we build the software for are the driving force. Agile development methodology suggests minimizing each development cycle to mitigate the risk of delivering something to the users that they don’t want. Agile development encourages frequent face-to-face meetings with the end users as opposed to preparing and sending documents back and forth.

Summary

This quick overview of major RIA-enabling technologies and various approaches to making Web applications richer. It’s by no means a complete list: new commercial and open source RIA frameworks and components arise every day. Regardless of what RIA tools you are going to select, start your evaluations now to get a competitive edge.

Yakov Fain

5 thoughts on “Rich Internet Applications: State of the Union

  1. wow, what an excellent overview :-)

    Just to let you know, there seems to be something missing in the “Flex: room for improvement” paragraph: “a lot in writing Flex code, but it’s not as
    While you can use Flex just to connect to your existing”

    .. something between “as” and “While”.

    Maybe it’s something about Refactoring? ;-) I know I for one miss the capabilities that exist in IntelliJ IDEA.

  2. Thanks for this overview. I agree with you in most parts, but I think that Java solutions can be attractive for some situations. e. g. for intranet applications. Depending on the needs of the application, UltraLightClient, a Swing based UI library THIN clients on the server side could also be worth to look at.

  3. Good round up of RIA options. I would like to add a new option that we announced recently, called Dekoh. Available at http://www.dekoh.com.

    Dekoh is a combination of an AJAX/Flash/Java RIA platform on the desktop and a sharing platform through Dekoh Network. It provides the best opportunitiy to all developers and designers familiar with DHTML, CSS, Javascript, Ajax, Flash and server-side Java to use their familiar programming skills, to build a new class of webified desktop applications. Dekoh is optimized and packaged for desktop functioning and normally installs in less than a minute. We have attempted to simplify install, deploy, upgrade process. The platform will be open sourced and developer related information will be available at http://www.dekoh.org.

Comments are closed.