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" (see Resources), 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

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): <a name="code-text"><mx:Button label="Submit"</mx:Button></a>

While with OpenLaszlo, you can code the following in LZX (LasZlo XML): <a name="code-text"><button<Submit</ button></a>

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.

Back to top

IBM Workplace Managed Client and Lotus Expeditor

The IBM Workplace Managed Client and the Lotus Expeditor are both built upon the open source EclipseRPC code base. EclipseRPC is a technology base derived from the Eclipse development tools workbench, the common platform for development tooling that eclipse.org manages and controls. If you have a business requirement for disconnected operations and you can install components on the client machine, Workplace Managed Client and/or Lotus Expeditor are the best technologies on which to build and deploy the application.

IBM Workplace Managed Client is a component of IBM's Workplace family of products. It combines various collaborative services under one integrated framework, or under one desktop environment. It provides capabilities, such as document management, messaging (including instant messaging), Web browsing, a direct interface to Notes® 7, eLearning, team spaces, Web conferences, and an activity explorer for tracking threads that are related to work tasks. Lotus Expeditor provides a rich client platform that supports enterprise applications, transactions, device management, and Web services. While there are numerous reasons for you to choose Workplace Managed Client or Lotus Expeditor, Workplace Managed Client is typically the best choice if your application is collaborative in nature. However, if the application is more transactional in nature, Lotus Expeditor is typically recommended.

Both Workplace Managed Client and Lotus Expeditor enable developers to create rich client applications that reside on the client machine, and develop them to support disconnected operations. Since the application is client-resident, the client can take full advantage of the power of the workstation on which it is running, enabling you to create a compelling, highly interactive user experience. The Eclipse base that both the Workplace Managed Client and the Lotus Expeditor offerings share provides an OS-independent platform that shields you from OS-specific nuances, yet leverages the native OS services where possible. This allows you to develop a single Java code base that runs on both Linux™ and Windows™ and, in the future, Macintosh.

To take advantage of this technology, you need to design your applications to utilize the Eclipse plug-in architecture. The user interface components are built using SWT (Standard Widget Toolkit) widgets or jFace components. SWT is a widget set and graphics library integrated with the native window system but with an OS-independent API, while jFace is a UI toolkit implemented using SWT that simplifies many common UI programming tasks. jFace is window-system-independent in both its API and implementation, and is designed to work with SWT without hiding it. The end result is a higher interactive user experience that looks and feels like other native OS applications familiar to the user.

Lastly, their ability to be server-managed differentiates Workplace Managed Client- or Lotus Expeditor-based applications from native Windows applications. This key feature eliminates most, if not all, systems management costs associated with client-resident application code. As a result, the enterprise deploying the application gets all the ownership benefits of a server-deployed Java EE application, while the user gets the user experience of an OS-specific, client-resident application; a win-win for most organizations.

Back to top

Faces Client Components

JavaServer Faces (JSF) is a Java EE 1.4 component that was originally developed as JSR 127. This technology's key goal was to lower the skill level for Java developers when developing user interfaces for their Java EE applications. Since JSF is a framework, it provides many out-of-the-box capabilities that, in the past, developers needed to hand-code when they build the same user interface with JavaServer Pages (JSPs).

For example, let's say you have a large JDBC™ result set that you need to display to the user. The JSF framework provides a DataTable widget that you can use to display the data. If you had built the user interface using simple JSPs, you would have to manage the user's interaction with the table and determine what rows of data should be displayed to the user.

With the JSF DataTable, when the user hits Next to display the next x rows of data in the table, the JSF framework will process the Next request and you don't need to code anything on your own. While JSF makes it easier for you to create richer HTML-based user interfaces, JSF is by design a server-based technology. The request for the next x rows of data flows from the browser to the server, where JSF framework code handles it. JSF requires a roundtrip to the server.

To improve upon the base JSF widgets, IBM's Rational® Application Developer V6 introduced the Faces Client Components. Faces Client Components is an extension to the JavaServer Faces technology that enables you to perform some JSF framework services on the client side. For example, if you used the DataGrid Faces Client component in the above example, the display of the next x rows of data would not require a roundtrip to the server.

Using the Faces Client Components will come naturally to a Rational Application Developer JSF developer. To use the Faces Client Components, you create a Faces JSP page and select "Basic with client-side data caching" as the model. Then when you construct the user interface in Rational Application Developer, you just select the appropriate UI controls from the Faces Client Components drawer in the tool palette in Rational Application Developer.

A lot goes on under the covers of a Faces Client Component.You download JavaScript implementations of the JSF controls to the browser and use the emerging industry standard Service Data Objects to communicate between the browser and the server. However, as it should be, this is all hidden from the user; he simply notices that his application responds much faster than the typical browser-based application.

Back to top

Ajax

Ajax (Asynchronous JavaScript and XML), a term Jesse James Garrett coined, is a standards-based technique/design pattern for developing better-than-browser user experiences for server-deployed applications. Ajax is server-technology agnostic and can work with Java EE applications, .Net applications, and others. With Ajax, you write JavaScript code to augment standard HTML to create a rich, interactive user experience. For example, the JavaScript can perform local user input validation, provide different views of the same data (line graph verses table verses pie chart), or asynchronously interact with an application's server component through the browser's XMLHTTPRequest object.

According to Gartner Group's Hype Cycle for Emerging Technologies 2000 report (July 18, 2006), Ajax has already reached the "Peak of Inflated Expectations" and is falling into the "Trough of Disillusionment." You can also measure the hype by the many Ajax books sold at bookstores. In my opinion, three things have helped push Ajax across Geoffrey Moore's technology chasm:

1. Modern browsers. In the past, developers writing JavaScript had to cope with numerous incompatibilities between Netscape, Internet Explorer, and other browsers. In some cases, even different versions of the same browser had incompatibilities. While some incompatibilities still exist, most intranet applications typically require Internet Explorer 5.5 or later and/or Firefox 1.0 or later, where most incompatibility problems that previously existed have been fixed. An open industry consortium, OpenAjax, was also recently formed to address incompatibilities with Ajax as well as to address other Ajax-related issues.
2. Ajax toolkits. In the past, most developers who wanted to use Ajax had to practically start from scratch, doing a lot of the heavy lifting that Ajax toolkits can now perform. The toolkits provide various pre-built JavaScript-based user interface controls (widgets) to make it easier for developers to create Ajax-based user experiences.The toolkits also typically provide a higher level of abstraction that shield the developer from the browser incompatibilities mentioned above.
3. Tools. Until recently, most JavaScript developers had virtually no development tools to help them debug and generally make their life easier. Since its release, the Firefox browser has had some useful plug-ins for Ajax developers, and IBM recently integrated a series of useful technologies into the Ajax Toolkit Framework to help address this problem. The ATF (Ajax Toolkit Framework), freely downloadable from the Apache site, provides an Eclipse-based Ajax development environment. ATF provides tools, such as a JavaScript syntax sensitive editor, a JavaScript console, and an XMLHTTPRequest object viewer. ATF also comes with three pre-built personalities: Dojo, Zimbra, and Rico.

Lastly, in my opinion, the true tipping point for Ajax came when Google released the beta version of its Ajax-based Google Maps application. Anyone who had previously used a mapping Web site quickly saw the advantage Google's mapping software had over other mapping sites on the Internet. While non-technical people were amazed and wondered how Google did it, programmers who looked under the covers found Ajax and began to ponder how they could use Ajax-based techniques to improve the usability and responsiveness of their own applications.

Back to top

Pure HTML

As much as developers think that all users, like themselves, have the latest Firefox browser with the 10 most popular plug-ins, the reality is that many machines still use Netscape 3.x or Internet Explorer 4.x to access the Internet. This level of browser might be required in order to use a particular application (whose source has been lost and cannot be modified) or might simply be in the home of a change adverse user who continues to use Internet Explorer 4.0 because he applies an "if it ain't broke, don't fix it" approach to browser upgrades.

While HTML clearly can't deliver a user experience as rich as one that these other technologies can deliver, HTML-based user interfaces will continue to have a long-term role. No other technology enables an application to reach as many users as a pure HTML user interface can. As a result, many applications will continue to provide such user interfaces for many years to come.

Back to top

In conclusion

In general, the strong momentum in the industry today is to improve the user experience of server-delivered applications. Ajax, while still a bit immature, has gathered tremendous momentum and many enterprises, both small and large, are starting to use it in production. The other technologies mentioned in this paper have small pockets of support, but none have emerged as a sure bet at this point.

Other user interface technologies, both commercial and open source (such as Nexaweb, Backbase, and JackBE) also exist, but were not mentioned in this paper to keep the paper reasonably concise. The key is that none of these technologies is one size fits all, and thus, none is a perfect fit for all situations. Each of the above technologies has its own merits and can be a good fit depending on the circumstances.

So how to choose? For starters, nothing can beat good old HTML if the driving force behind your technology selection is to reach as many users as possible. At the opposite extreme, if you require disconnected operations and you can install your application's software on the user's machine, one of the EclipseRPC-based alternatives, Workplace Managed Client or Lotus Expeditor, is the best fit.

If you require a rich user experience that you can only deliver through the fidelity of Flash Player, you can probably justify using Flex or OpenLaszlo. If you build the application using JavaServer Faces, you're better off using some Faces Client Components.

Lastly, if your goal is simply to attack some usability hot spots in an existing HTML-based user interface or to deliver a standards-based, plug-in-free, better-than-browser user experience, Ajax is the way to go. At this point in the hype cycle, Ajax seems to be emerging as the most popular Web 2.0 technology choice, but I wouldn't discount the role the other technologies will play over time as they mature.

The key to selecting the right technology is to let the application requirements drive the technology choice for the user experience. While this seems like a basic, obvious recommendation, in many cases, developers will follow the reverse process, which can lead to many difficult implementation and deployment issues (causing significant delays and problems as they develop a project). Don't let that happen to you.

Resources

Learn

• What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software, (Tim O'Reilly, O'Reilly, Sept. 2005): Find out what is meant by Web 2.0.
  
  
• Workplace Managed Client: Deliver fully integrated server-managed collaboration for a rich user experience.
  
  
• Lotus Expeditor: Build, deploy, maintain, and integrate device- and network-adaptable rich client and mobile apps with a platform that provides the OSGi- and Eclipse-based, server-managed client platform, the tools, and the corresponding server-side components.
  
  
• Adobe Systems Flex: Create beautiful, scalable apps for nearly any platform on a rich Internet application framework based on Adobe Flash.
  
  
• OpenLaszlo: Create zero-install web apps with the user interface capabilities of desktop client software with an open source platform.
  
  
• Ajax: A New Approach to Web Applications (Jesse James Garrett, AdaptivePath, February 18, 2005): Read the article that coined the Ajax moniker and considered required reading for all Ajax developers.
  
  
• OpenAjax: Visit the OpenAjax Alliance, an organization of vendors, open source projects, and companies using Ajax that are dedicated to the successful adoption of open and interoperable Ajax-based Web technologies.
  
  
• JSR 127: JavaServer Faces: Simplify the creation and maintenance of Java Server application GUIs with JSF architecture and APIs.
  
  
• Faces Client Components Developer's Guide (Laurent Hasson, developerWorks, May 2005): Reduce the number of round-trip interactions with the server as you simplify the development of interactive Web pages and improve their usability and performance.
  
  
• Ajax Toolkit Framework: In this Eclipse Web Tools Incubator Project, try the Ajax Toolkit Framework (ATF), an extensible framework and exemplary tool set for building IDEs for different Ajax runtime offerings (such as Dojo, Zimbra, or Rico).
  
  
• Enable C++ Applications for Web Services using XML-RPC (Karthik Subbian and Ramakrishnan Kannan, developerWorks, June 2006): Build your own XML-RPC-based service for C++ programs with this a step-by-step guide to exposing C++ methods as services.
  
  
• The Architecture section on developerWorks: Find the resources you need to advance your skills in this arena.
  
  
• The Web development zone: Visit your resource center for all things Web 2.0, Ajax, wikis, PHP, mashups, and other Web projects.
  
  
• The technology bookstore: Browse for books on these and other technical topics.
  
  
• developerWorks Web development zone: Expand your site development skills with articles and tutorials that specialize in Web technologies.
  
  
• developerWorks technical events and Webcasts: Stay current in your field with these technology sessions.
  
  

Get products and technologies

• IBM product evaluation versions: Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  
• developerWorks RSS and Atom feeds: Find out more and build your own.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community.
  
  
• developerWorks forums: Participate in any of several Web-centered forums.
  
  

About the author

Sam Thompson joined IBM in 1980 and held various technical and management positions in VM product development. In 1992, Sam moved to the systems management development lab in Raleigh, N.C. and helped bring several SystemView products to market. When SystemView merged with Tivoli Systems, Sam traveled the world as a technical evangelist explaining the merger, the new Tivoli strategy and products, and the convergence strategy for the IBM and Tivoli workgroup products. In March 1997, he helped form IBM's Emerging Technologies jStart (jump start) group, which helps IBM clients architect and build solutions that utilize IBM's XML, Java, Web services, rich client, Web 2.0, and autonomic computing technologies.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Flex and OpenLaszlo
• IBM Workplace Managed Client and Lotus Expeditor
• Faces Client Components
• Ajax
• Pure HTML
• In conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Lotus Expeditor toolkit
• Webcast: A Smart Approach to Core Banking Renovation in a Tough Economic Climate
• Briefing: Smarter collaboration with IBM Lotus solutions
• Buy: Lotus Expeditor toolkit

My developerWorks community

Dig deeper into Web development on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers