ICEpush for Real-time Web Collaboration

http://www.icepush.org/ is now live and the open source ICEpush 2.0 alpha3 is available for download. With ICEpush you can add Ajax Push collaboration features to any web application. Let's take a look at the technology through question and answer:

How does it work?

ICEpush is purely web-based notification, allowing group members to receive a callback when a push is sent to a group.

As may be familiar to you with ICEfaces, just a few lines of code are needed to use it:

Java code to add the client to the desired group:

org.icepush.PushContext.addGroupMember(myGroup, pushId);

JavaScript code to listen for push notifications to that group:

ice.push.register(pushId, myCallback);

Java code to push to the group:

org.icepush.PushContext.push(myGroup);

Note that these are just the low-level APIs. Framework-specific integrations provide additional easy to use features for each framework.

Just notification? Why not send messages containing data?

There are many reasons for this, some architectural, some practical.

Architecturally, the web is made up of distributed resources, not messaging endpoints (we're using HTTP, not CORBA). Exchanging data messages outside of resource interaction breaks REST. On the other hand, fetching a resource at a certain time (such as in response to a notification or a user event) is perfectly compatible with REST, and this is just what ICEpush provides.

In practical terms, arbitrary messaging on the web raises a number of problems. The most immediate problem lies with browser connection limits: If IE 6 only allows two connections per server host, how can messages be delivered to multiple browser windows? How about by implementing ethernet over URL fragments? If these messages are tunnelling between windows, how are they secured? Will the message channel immediately inherit the existing security in my applications? How large can the messages be? Can the messages carry binary data? How do late joiners catch up with the current application state?

But if we just focus on notification, Ajax Push becomes possible without opening any of those cans of worms.

Ajax applications are already good at transporting data, either by encoding it in the initial page render or transporting it via XMLHttpRequest (or some other Ajax mechanism). Push features can be added via notification alongside your existing Ajax techniques.

Is this the same as comet?

It's deliberately substantially simpler than the typical implementation of comet; see above.

Which frameworks/platforms are supported?

Initial support is available for JSP, Spring MVC, Grails, GWT, Wicket, JQuery, and Prototype.

• JSP: JSP tags for callback registration and page regions associated with push groups
• Spring MVC: based on JSP integration, will include DispatcherServlet automatic registration
• JavaServer Faces (JSF): ICEfaces 2.0 is the JSF integration for ICEpush
• Grails: Grails plugin is available
• GWT: core PushContext as well as a buffered command API
• Wicket: pushPanel Wicket UI component
• jQuery: pushed page updates automatically applied to jQuery selector
• Prototype: AjaxPush.Updater updates page in response to push notification

More integrations will be made available, and community participation is most welcome (for instance, Stéphane Maldini developed the Grails plugin). Let us know on the forums which framework you would like to have ICEpush integration for next.

Is ICEfaces required?

ICEpush is the Ajax Push technology used in ICEfaces 2.0 (it's now a separate icepush.jar file). ICEfaces 2.0 will run without icepush.jar being present (not all rich Ajax applications have push features). ICEpush has no dependency on ICEfaces or JSF.

How does it scale?

It's only an alpha release, so no numbers are available yet, but the technology is designed to scale effectively:

• Server-side state is minimal, comprised only of groups of pushIds, boolean notification status, and active connections (no message buffering).
• Servlet 3.0 AsyncContext is employed to handle thousands of blocking connections with a bounded number of threads.
• The client protocol provides all necessary information at each reconnect to support clustering.

How do I get started?

Download the integration bundle for your favorite framework, and take a look at the basic examples that are included. Also, to take a look at the various chat demos online and included in the integration bundles.

What do you mean "version 2.0", I've never heard of this before; is that some crazy version number marketing stunt like "Java 2"?

ICEfaces 2.0 makes use of ICEpush, so the goal is to have these version numbers in sync (at least initially).

From http://www.jroller.com/tedgoddard/entry/icepush_for_real_time_web