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.