Welcome!

SOA & WOA Authors: Yeshim Deniz, Salvatore Genovese, Mark O'Neill, Irfan Khan, Vikas Aggarwal

Related Topics: AJAX & REA

AJAX & REA: Article

Beyond AJAX and JavaServer Faces

Building an extensible AJAX-enabled component framework

First released in March 2004, the server-side component model introduced by JavaServer Faces (JSF) brought the promise of simplifying Web-user interface (UI) development. Then in February 2005, Jesse James Garrett coined the term AJAX (Asynchronous JavaScript and XML) and the simplicity of the JSF server-side component model was overshadowed by a flood of rich UI frameworks with a client-side tilt.

AJAX frameworks (including Dojo, Prototype, and Script.aculo.us) are spurring an evolution in human-computer interaction on the Web. The stale click-and-wait experience once associated with Web applications is no longer acceptable. Users now expect real-time updates and desktop-like functionality coupled with the ubiquitous nature of the Web. Consequently, developers are now stretching the limits of the JavaScript programming model and battling cross-browser idiosyncrasies to mimic desktop functionality over the wire. The result is an escalation in the complexity of Web development – a problem initially resolved by the elegance of the JSF component model. Luckily, JSF has evolved alongside AJAX and is proving not only to be an ideal solution to simplify traditional Web development but also rich Internet application (RIA) development. 

Simplifying AJAX with JSF
The flexibility of the JSF component model (that is, decoupled presentation, state, and behavior) makes it relatively easy to build components that not only render HTML, but also render other markup presentation languages, including DHTML and JavaScript. In their simplest form, AJAX-enabled JSF components use a custom render kit to push a JavaScript and markup presentation to a client browser. In this case, the content rendered not only represents the component, but also provides the necessary functionality in the form of supporting JavaScript objects that initiate XMLHttpRequests (XHR) and handle call backs. These XHR requests, made with JavaScript rendered to the client, are treated as first-class citizens in the JSF life cycle. Tight integration with the JSF life cycle enables JavaScript objects to invoke operations on managed beans, which contain server-side application logic. The beauty of this model lies in its ability to encapsulate the intricacies of AJAX with a simple, cohesive, and reusable component. Moreover, the layer of abstraction afforded by a server-side component model eliminates the need to tinker with JavaScript, DHTML, XML, JSON, or other technologies required to develop RIAs with AJAX. Instead, a single API can be used to develop rich, interactive applications that leverage the underlying technologies that make AJAX possible.

Having a single API for RIA development has many benefits, including encapsulation. But perhaps the most substantial benefit is a solution to the N-to-M problem: an overwhelming number of choices for AJAX frameworks (N), and the fewer, but still substantial number of server technologies (M) used to build AJAX-based RIAs, such as Java, Ruby, .NET, and PHP. According to Ajaxain.com, as of May 22, 2007, there were more than 210 AJAX-based networks in use, and an estimated 1.5 frameworks are added each week. The abundance of possible combinations is daunting. Fortunately, using JSF in combination with AJAX eliminates the guesswork of deciding which AJAX technology to use with which server-side process. In this scenario, a single API delivers not only an AJAX-based presentation, but also a tightly integrated server-side implementation. Moreover, server-side technologies like JSF conform to the Java Enterprise Edition 5 industry standard, and are available through a wide vendor base (including IBM, Oracle, Sun Microsystems, Backbase, ICEsoft, and ILOG).

At a glance, it’s apparent that there are a few good reasons to consider a marriage between JSF and AJAX. However, as in any relationship, it takes significant depth to construct a lasting bond, particularly one that builds on the strengths of each party involved to create a mutually beneficial outcome. It’s easy to develop AJAX-enabled JSF components that operate in isolation or use single threads of execution, but systems that function in this way can be superficial and can serve as a veneer to abstract the complexities of AJAX. A far more daunting task, and one that truly builds on the strengths of the technologies involved, is to build a framework of AJAX-enabled components that go beyond simply delivering an AJAX-enabled presentation. Instead, these components use the JSF-rendering facility to deliver a complete and independent client-side JavaScript component model that compliments the server-side JSF component model.

Distributing Event Handling
One benefit of providing component representation on both the client and server sides is that Java events are triggered and handled on the server, while JavaScript handles events on the client, eliminating many previously required round-trips to the server. The following example illustrates this point. When a user selects a node in a collapsible tree, a tabbed panel or other component on a browser screen is updated and a partial page refresh occurs. Before client-side JavaScript, page updates necessitated a round-trip to the server, even when advanced JSF component sets, such as Apache Trinidad, were used.

However, with a JavaScript representation of the tree, a user selection triggers a client-side event to fire. The event is processed on the client by a listener associated with the tabbed panel, eliminating the need to invoke an operation on the server.

Rendering with a Helping Hand
The ability to balance client- and server-side event handling is not the only advantage gained by a deep and meaningful marriage between AJAX and JSF. With the inclusion of the server in the rendering process, performance becomes another benefit. Unlike JSF, most pure AJAX frameworks, such as Dojo, handle rendering on the client. As a consequence, JavaScript is executed to render a component or widget, and every client component has the ability to re-render itself on the client. Execution also typically includes geometry management and population of a client-side structure, which contains objects to handle the behaviors and states associated with each component. Unfortunately, an immense amount of JavaScript must be executed to initially render a page comprised of multiple components. Excessive JavaScript execution consumes browser- and client-machine resources, fattening the JavaScript thin client. Depending on individual machine configuration, the extra consumption of resources causes performance variability and results in slow initial page rendering. For the end user, the result is a perceived stall in execution that cannot be masked with distractions such as animated images because the invocation of so much JavaScript code consumes too many resources to provide a smooth and meaningful feedback mechanism during page loading.

Using JSF to render the initial presentation substantially lightens the load because, unlike pure JavaScript frameworks, JSF can do initial rendering on the server and then delegate incremental updates to the client or a combination of client- and server-side interactions. One advantage of server-side rendering is that while the server is preparing the presentation for delivery, the browser has ample resources available to provide feedback to the user, indicating that some process is being executed. A more substantial benefit of server-side rendering is the reduction in the JavaScript code necessary to render the page. This results in less client-side resource consumption and ultimately less time to render a page.

To demonstrate this concept, let’s look at the difference in the code execution necessary to render a simple form button in Dojo and an AJAX/JSF framework.

More Stories By Ric Smith

Ric Smith is director, business and product strategy at Kaazing. provides Kaazing Corporation with a wealth of experience in product management and consulting for enterprise products and services. Prior to joining Kaazing, Ric was a principal product manager for Oracle's Fusion Middleware at Oracle's Headquarters in Redwood Shores, CA. In his role as a Principal Product Manager he was responsible for the evangelism and product direction of Oracle's AJAX and Java EE Web Tier offerings. Before joining the Fusion Middleware team, Ric worked for Oracle's consulting business as a principal consultant where he led development of mission-critical applications for prominent organizations within the defense/intelligence industry. In addition, Ric won consecutive awards for technical achievement for each year of his tenure as a consultant. Ric is a frequent speaker at international events and has written articles featured in leading industry publications such as Java Developer's Journal and AJAXWorld Magazine. He is also a representative to the OpenAjax Alliance and an honors graduate of the University of Arizona.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Bruno 09/19/07 03:28:03 AM EDT

Hello Ric,

Ever heard of Google Web Toolkit ? This framework *really* provides an unified API (client and server side in Java), where JSF needs to know about HTML, JSP, JSF, Java and XML.

Bruno