hen it comes to their GUIs, distributed applications have always observed a pendulum effect. The early enterprise distributed application comprised a heavy centralized server with a dumb terminal for data entry. As the personal computer evolved, the model changed; increased power at the desktop led to heavier and more sophisticated client applications. But the need to maintain such high computing and presentation power on the desktop led to a huge increase in the costs of deployment and management of such applications.
When the Internet, and in particular, the Web browser came along, the pendulum swung back toward a centralized model with a thin client. While this certainly helped with the cost of managing large scale systems, it came at a cost?that of user experience. A Web-based application, designed and implemented in HTML, cannot match the user interface experience of a desktop application. Various add-ons to HTML, such as JavaScript, can improve the experience, but these solutions can be onerous and expensive.
Today, it would appear that the pendulum is poised to swing back again, evidenced by the advent of heavy client APIs including the Windows Presentation Framework (Avalon), Microsoft’s toolkit for building rich UIs in the upcoming Windows Vista. Users have come to expect richness in applications, and developers need to deliver it.
But there is another way. In this approach, Java Server Faces is used to provide a centralized, server-based model that preserves richness at the client. Sounds perfect, right? Almost. This model depends on a markup-based presentation and the existing Web application model, thus making it prone to the same limitations of Web-based apps, including development and maintenance difficulties.
 | |
| Figure 1. The Direct-to-DOM Model: Using this scheme only the portions of the application that require DOM changes are transmitted. |
ICEfaces, from ICEsoft Technologies,is an attempt to improve this model?harnessing the Asynchronous Java and XML (AJAX) methodology to JSF in order to create a client-light, high-performance, rich user experience. For those who haven’t already heard of them, ICEsoft is a provider of Web applications and toolkits for Java developers, having previously released ICEbrowser, a 100 percent pure Java Web browser; ICEreader, an HTML rendering engine for Java developers; and ICEpdf, a PDF rendering engine for Java developers.
What makes ICEfaces different is its Direct-to-DOM rendering, which builds on the JSF renderkit architecture and provides a separation between JSF components and the markup that represents them in the presentation layer. In a regular JSF application, a component is defined in the JSF component tree and the renderkit generates the appropriate markup for that component on that specific client; in other words, it produces a different result for a standard (HTML) Web browser or for a WML-based mobile device.
In Direct-to-DOM rendering a JSF component tree is rendered directly into a W3C DOM data structure. During the JSF render pass, this tree is traversed, and the appropriate output is generated for each component on the server. The changes to the DOM that result are packaged up and delivered to the browser via an AJAX bridge and used to create the presentation for the application (see Figure 1).
Understanding Direct-to-DOM
ICEfaces adds this Direct-to-DOM model to the JSF framework. The result is that only elements that change need to be delivered to the client-side and rendered. Changes to the state of the GUI, then, do not require complete page refreshes. This allows for a number of rich features that aren’t typically available with standard Web-based apps, including:
- Asynchronous Presentation Updates
Using the XMLHttpRequest aspect of AJAX you can set up an asynchronous request that gets a response upon an application state change. When the renderkit gets a new set of nodes to send to the client via the AJAX bridge, the application changes its state based on an external stimulus, asynchronously! - Partial Submission and Intelligent Processing of Forms
The typical Web application only validates user-entered data after submission. This can take time, as well as leading to transactional problems. A rich application is capable of filtering your data in real time?a very desirable feature. With ICEfaces and the Direct-to-DOM model, you can do partial submission of forms to the server. For example, a value entered in a field can be submitted to the server via an AJAX bridge, triggering an application state change and responding with a new definition for the GUI.
 | |
| Figure 2. Server Time Zone Application. The time zone application keeps accurate time and submits user-entered data fields without a full page refresh. |
One example (Figure 2) is the Server Time Zone application, which demonstrates many of ICEfaces’ features and advantages. Asynchronous updates keep the clicks ticking, and clicking on the checkboxes for the timezones does a partial submit of forms giving you only the rows that you are interested in. This is all built using basic stock JSF components with the ICEfaces framework added-on.
In the download for the product, you’ll find a useful tutorial that evolves this time zone application from a standard JSF application through several steps of enrichment using ICEfaces. You’ll learn how to:
- Build the basic JSF application
- Integrate ICEfaces
- Use dynamic updates to make the clocks tick
- Render and update dynamic tables
- Apply styles
The process is intuitive and well documented and it’ll help you turbocharge your existing JSF applications or start building new ones from scratch.
I stepped through the tutorial and worked through the example that it gives, and found it to be an excellent and valuable learning experience. The only caveat that I would put forward is that you need to be pretty knowledgeable around Java Server Faces to understand and get the most from the tutorial, never mind the product. In some ways this narrows its reach?if you are into JSF, you’ll probably love it; if you aren’t you might find a lot of it a bit daunting. As I’m familiar with JSF, but far from an expert, a lot of it went over my head. Another possible drawback is that it only works (at present) with Apache Tomcat, and it isn’t clear whether or not you can adjust it easily to work with other application servers such as WebLogic, WebSphere, or JBoss.
The bottom line that I found with this product is that if you are currently using JSF, it’s a slam dunk to upgrade your UI and make it more asynchronous and responsive. If you aren’t, this great GUI technology may be a great motivation to start.
This is an evolutionary product, that is bringing a new layer of complexity to your applications?and as a result I would strongly recommend that you do a thorough evaluation before deciding to purchase. There isn’t a commercial release yet, just the early access version, so you’ll have to work with that for now. Company executives told us the basic ICEfaces framework will be free for development and distribution. ICEfaces Enterprise Edition will be released in Q2 2006 and will be priced between $1,500-$3,000 per server. A commercial release of the basic product is in development, but won’t be ready for a year.
If you’ve ever built JSF applications you’ll love ICEfaces. It integrates cleanly with the framework, is straightforward to use, and lets you add levels of GUI sophistication that were previously available in a thin client. If you’ve never used JSF, there is likely to be a bit of a learning curve, but it is certainly a worthwhile undertaking if you have the requirement to deliver rich, thin clients.
