Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

ICEfaces Offers a Novel, Pure Java Approach to the Rich vs. Thin Dilemma

Fat, thin, fat, thin. As the pendulum of distributed application architecture prepares to swing back toward fat, one vendor offers a thin client solution that uses Java Server Faces to get around tricky HTML and Javascript issues.


advertisement
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).



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap