As we assess different push mechanisms it'll be important to understand how they address the connection-sharing problem, since it's complex and beyond the scope of what the typical application developer should be exposed to. As an aside, browser vendors could drastically reduce the complexities of connection sharing by allowing two connections per window or providing XmlHttpRequest with control over HTTP pipelining, thereby allowing distinct windows to share a single connection.

Application Server Scalability
When we examine the open connection issue from the perspective of the application server, we see a variation on the problem. It turns out that modern application servers can handle a large number of connections efficiently, but under the existing servlet model, each of those connections requires a thread for execution. If these connections become long-lived due to sporadic server-initiated updates, server scalability is severely compromised by thread pool exhaustion.

While standards activities related to asynchronous communication in the servlet model progress in JSR 315, the industry has tackled the problem in disparate, non-standard ways. The lack of a standard mechanism is discouraging because any scalable push mechanism will need to be tightly integrated with the underlying server mechanism, requiring deployment-specific implementations. The good new is that a variety of solutions has emerged across open source applications servers, which we'll survey.

Tomcat 6 provides Asynchronous Request Processing (ARP) through an additional servlet interface, org.apache.catalina.CometProcessor. The CometProcessor enables the servlet to receive events when data is available for reading, rather than consuming a thread during a blocking read. The event-based mechanism gives the developer fine-grained control over asynchronous I/O processing unlike the normal service() method. Tomcat 6 also provides a CometFilter interface that enables a filter chain that's invoked when comet events are processed.

Glassfish V2/Grizzly provides ARP through the class com.sun.enterprise.web.connector.grizzly.comet.CometEngine. Applications can register to receive events through a CometHandler and, like Tomcat 6, process READ events when data becomes available, versus performing a blocking read.

Jetty 6 provides a continuation mechanism that supports ARP in the existing servlet API. The org.mortbay.util.ajax.Continuation class provides suspend/resume members that suspend the request processing and let it asynchronously resume later, potentially on a different thread. When suspend() is called from inside the servlet's service() member, an exception is generated, which is caught by the Jetty server and used to identify the request to be resumed. Resuming the request reinvokes the service() method, which can then proceed with writing the response. One complication with continuations is that the service() method must be implemented specifically to support the double invocation. The advantage is that standard servlet filtering can be applied, although filters must handle double invocation as well.

ICEfaces Asynchronous HTTP Server (AHS) is not an application server at all, but co-exists alongside any application server to provide ARP to ICEfaces applications. Unlike the previously described mechanisms, there's no programming API associated with the AHS and its functionality is specific to ICEfaces. The AHS is configured to handle the asynchronous communication channel, matching updates with pending requests using a bounded thread pool. It can be deployed in clustered environments and includes a servlet mode that can be used to handle AJAX Push in portal environments.

Development Models
A basic understanding of the push mechanism and its associated complexities leaves the developer pretty far away from actually implementing push-style applications. We'll now turn our attention to open source AJAX technologies that specifically facilitate push-style application development.

Dojo/Cometd/Bayeux provides a client-centric programming model and a general-purpose publish/subscribe mechanism that extends to the server. Unique channels can be defined for specific message classes, and clients to those channels can exist in the browser and server. JavaScript application logic is implemented to handle messages pushed from the server and update the UI appropriately. From the server's perspective, a push channel is defined and server-side application logic publishes events over that channel. Cometd is a flexible mechanism that supports both Java and Python implementation at the server. Cometd has been integrated with Tomcat 6, Grizzly, and Jetty 6. Browser connection sharing is possible using a shared cookie mechanism that supports bulk data transfers between windows. Essentially, the Cometd approach yields a loosely coupled distributed system and as such requires that the application developer address associated complexities such as security and maintainability.

DWR/Reverse AJAX provides a client-centric programming model based on Remote Procedure Calls (RPC). Basically, DWR facilitates calling server-side Java objects from the client via JavaScript stubs, and Reverse AJAX facilitates calling JavaScript objects from server-side Java objects. For a push interaction, a JavaScript implementation is required to handle the specific update, and the sever-side Java logic must invoke that JavaScript appropriately. The DWR servlet handles the marshaling of RPC calls over the HTTP connection, but the connection-sharing problem hasn't been addressed in the JavaScript implementation. DWR is integrated with Jetty 6.

ICEfaces/AJAX Push provides a server-centric programming model based on JavaServer Faces (JSF). The ICEfaces extensions to JSF enable a transparent AJAX bridge that delivers incremental changes to the browser based on the standard execution of the JSF life cycle. A simple extension API allows application logic to request a page render based on some asynchronous event, and the resulting incremental changes are propagated to the browser over the bridge. ICEfaces provides APIs to support group renderers, where logical groups of browser clients can receive the same updates. It also provides a RenderHub that handles synchronization and optimizes performance of the low-level asynchronous rendering mechanism. ICEfaces can be configured to use ARP mechanisms from Tomcat 6, Grizzly, and Jetty, as well as the ICEfaces AHS. The ICEfaces bridge supports connection sharing through a shared cookie mechanism, and when configured with the AHS in servlet mode supports AJAX Push in portal environments.

Conclusion
We have characterized Web 2.0 as a platform for spontaneous and instantaneous social networking, and have examined the complexities associated with delivering the required push-style capabilities using lightweight Web-based techniques. While most of the existing AJAX technologies do nothing to address the problem, a small handful of open source technologies have emerged that deliver the necessary capabilities. So, yes, Web 2.0 is possible today with existing open source technologies. Further standardization will help, and next-generation browser implementations will ultimately alleviate some of the complexities. If push-style Web applications and Web 2.0 are on your horizon, dive in and see what is possible. A word of caution, though, you should carefully examine your existing development best practices and deployment constraints, and devise an approach that will empower you to focus on application development, not low-level push infrastructure development.