Web 2.0 user interface technologies

Imagine that you are tasked to create a new application that will live in the Web 2.0 world. Some of your users are perfectly happy with HTML-based user interfaces while others expect every application they use to behave like Excel. Your business sponsor expects a productivity-enhancing user experience, but your CIO won't allow you to develop anything that a user needs to manually deploy. You know HTML won't cut it, but what else is out there?

This article explores a series of Web 2.0 user interface technologies that enable you to build applications with better-than-browser user experiences. As a result, you can centrally deploy and manage them just like any other Java 2 Enterprise Edition (Java EE) application.Today's enterprise application developer feels pressure from both users and operations camps when it comes to user interfaces. At one end of the spectrum, business units that represent users want their applications to have a rich user interface that maximizes user productivity. This group wants all their applications to behave like Microsoft's Excel or another client-resident application. They want the application to provide them with instantaneous response time. If they have multiple views of the same data (for example, a table and a graph view) and one changes, they want the other view on display to instantaneously reflect that change.Alternatively, the IT operations group loves the pure server-based delivery model. While it acknowledges that the HTML user experience is less robust than a native operating system (OS)-based user interface, this group believes the cost of installing, configuring, and managing client-resident code is too high for the improved user experience it provides.

Many people in IT organizations lived through the client/server deployment model of the 1990s and don't want to go through that experience again. In fact, many Java 2 Enterprise Edition (Java EE) applications might never be built if a client-resident component existed, as the cost would kill the application's business case. The server-delivered deployment model gives IT organizations the reach and range they desire in a cost-effective manner, one only dreamed about in the '90s. Most organizations that have experienced the economics of a server-deployed Java EE application will never consider deploying code that they have to install on individual client machines, unless forced to.So what is the poor enterprise developer to do? Users don't want to lose productivity with a multiple-second delay in server-response time, and IT groups don't want to go back to the old way of deploying and managing code on client machines. How can you meet these, on the surface, conflicting requirements in a manner that satisfies both organizations?Fortunately, technologies exist that enable you to deliver a better-than-browser user experience without having to manually install code on client machines. Applications built with these technologies are sometimes referred to as Web 2.0 applications. In his article, "What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software", Tim O'Reilly states: We're entering an unprecedented period of user interface innovation, as Web developers are finally able to build Web applications as rich as local PC-based applications.

Web 2.0 applications provide the best of both worlds: the cost-effective, server-based deployment model combined with rich user experiences that are comparable to most user experiences with client-resident applications.Here are the different technology options for you to create compelling user experiences for today's Java EE applications:

· Flex and OpenLaszlo

· IBM® Workplace™ Managed Client and the IBM Lotus® Expeditor

· Faces Client Components

· Ajax

· HTML

Flex and OpenLaszlo are similar declarative approaches to creating better-than-browser interfaces for Java EE applications. Flex is a product offering from Adobe/Macromedia while OpenLaszlo is an open source offering originally created by Laszlo Systems Inc. In both environments, you use a unique technology-specific, XML-based grammar to lay out and create the user interface.

For example, to use a button in Flex, you can code the following in MXML (Multimedia XML):WhilewithOpenLaszlo,youcancodethefollowinginLZX (LasZlo XML): To allow different UI elements to interact and communicate with the server, you write scripts in either ActionScript (Flex) or JavaScript (OpenLaszlo).

While the two technologies have many similarities, one key difference is the runtime infrastructure they require. For the client to exchange data with the server, Flex requires a Flex Data Services Server, which communicates with the client running in the Flash Player plug-in. The server essentially mediates all communications and exchanges of data from the client to the application's server component.

OpenLaszlo's latest version has made some runtime changes that might make it more attractive to developers. One change is that Version 3 introduced a SOLO deployment mode, which eliminates the requirement for the Laszlo Presentation Server in some deployment configurations. Another major new development is the client runtime environment. The most recent release, OpenLazlo 4 now in beta, enables Laszlo-based applications to run without the Adobe/Macromedia Flash Player plug-in. Many companies concerned with being locked into a proprietary plug-in, such as Flash Player, will welcome this change.

How do you decide which is better for your organization? With Flex, the key advantage is that you have a fully supported product from Adobe/Macromedia, but you will incur costs to license the Flex Data Services Server.  For some companies,  the license cost is well worth having a fully supported product. Adobe Flex 2 applications also require Flash Player plug-in V9. While Flex can create a compelling user experience, the cost, as well as this plug-in requirement, might be an issue for some companies.

The OpenLaszlo technology was originally released as a commercial product, but in 2004, Laszlo Systems chose to open-source the technology, licensing it under the Common Public License (V1.0). Laszlo Systems does offer support subscriptions and since it's an open source project, you can choose to support it using the freely available source. With OpenLaszlo, cost is obviously not an issue, but some organizations have rather firm policies against using open source software so OpenLaszlo might not be an option for you.