Ajax Push has always been an integral capability of the ICEfaces framework,
but for the longest time it was not a primary consideration of the average technology evaluator. We always found this surprising, because the impact that push can have on a web application is far more profound than Ajax's primary claim to fame - eliminating the full page refresh. In recent months, however, we have seen a marked change in demand for push technology within the ICEfaces community, and we are now involved with a large number of projects where Ajax Push is front and center on the requirements list. So when people are evaluating their options for achieving web-based push, what makes them decide on ICEfaces?
Simply put - ICEfaces provides the most comprehensive open source solution in the industry for lightweight (plugin-free), push for web applications. Now, I will back up that statement with the supporting facts.
To begin with, while there are hundreds of open source Ajax libraries out there, only a small handful offer push capabilities - namely Dojo/Cometd, DWR/Reverse Ajax, and ICEfaces/Ajax Push. All three mechanisms are based on the same fundamental concept of HTTP protocol inversion - holding an open request from the browser, and responding to that request when something is available to be pushed. Normal and inverted HTTP connections are illustrated in the figure below.
So if all push mechanisms are based on this low-level protocol inversion, then how can they be fundamentally different from the developer's perspective? With ICEfaces we have strived to provide a natural extension to the JSF programming model in support of push style application development, and have sheltered the developer from the low-level mechanics for Ajax-based push. ICEfaces provides an application-level managed bean, the RenderHub, that orchestrates push events within the JSF lifecycle. Basically, you define groups of client sessions that need to receive the same push events, and register those render groups with the hub. Some trigger point in application logic can then request a render on a given render group, and the hub will make it all happen. The hub is responsible for executing the render phase for each session in the group, coalescing requests and maximizing throughput with multiple parallel render threads. Furthermore, the RenderHub architecture supports clustered deployments. This basic push architecture is illustrated below.
From the developer's perspective, it is a clean, natural mechanism for implementing push logic using pure Java programming techniques. What is less obvious (and rightly so) are some of the intricacies that the underlying push mechanism handles. The first relates to the browser and connection limits for the same URL. One connection from the browser is required for the push channel, and a second is required to handle user initiated requests, so an application requires 2 connections, which happens to be the maximum allowable in Internet Explorer. The connection usage for a single view onto the application is illustrated in the leftmost schematic in the diagram below.
Now if you attempt to open multiple views onto the same web application you will not have sufficient connections to support it, as each view needs a connection to support its push channel. With ICEfaces, the push mechanism in the Ajax Bridge provides connection sharing that allows multiple views to share a single connection for push updates. It is based on shared cookies where a single view marshals updates for all views, and if the controlling view is closed, another view takes over. The connection sharing for multiple views support is illustrated in the center schematic in the diagram below.
The connection problem is amplified in a portal deployment where you might have multiple portlets from different web applications looking to share the same push connection. In this case, not only do you need connection sharing at the browser, but also at the server. And because the server side connection management needs to communicate with multiple web applications you need some IPC mechanism to support it. With ICEfaces we have adapted the Asynchronous HTTP Server to handle connection management for portlets. The portal deployment support is illustrated in the rightmost schematic in the diagram below.
Now if we turn our attention fully to the server-side connection issues related to push we see scalability concerns with multiple open connections at the Servlet level. Each connection requires a dedicated threat to handle it, so thread exhaustion can occur quickly within the application server. Efforts to address the asynchronous communication path within application serves has begun, and will ultimately be standardized under JSR 315. To date we have seen independent solutions emerge for Tomcat 6, Jetty 6, and most recently Glassfish/Grizzly.
All of these application servers support scalable asynchronous communication, and ICEfaces is integrated to work will all of them. Additionally, ICEfaces includes the Asynchronous Http Server, that can be deployed along side any application server and provides scalable handling of the push requests.
Because ICEfaces handles all of the connection related intricacies at the framework level, the developer is free to focus on application development, and to that end, has a straightforward Java API to work with. Without question, ICEfaces is the only solution in the market that provides such a comprehensive feature set and an easy to use programming model. The industry is definitely catching on to the revolutionary value of push, and when enterprises decide they need push, they are flocking to ICEfaces. Ajax Push has definitely come of age in ICEfaces.
Technorati Tags:
ajax
ajax push
java
icefaces
jsf
comet
cometd
reverse ajax
dojo
dwr
