Ted received his PhD in mathematics in 1996, answering open problems in complexity theory and infinite colorings for ordered sets, and proceeded with post-doctoral research in component and Web-based collaborative technologies. Following work at Java Software, Sun Microsystems, he was a device management and XML architect at Wind River, participating in the IETF NETCONF design team. Ted currently participates in the JavaServer Faces and Servlet expert groups and is a senior software architect at ICEsoft Technologies developing ICEfaces, an Ajax framework for JavaServer Faces. Ted is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

Ajax Push for OpenSocial

  • submit to reddit

At CommunityOne, Chris Schalk and I presented our ideas on how to integrate Ajax Push with OpenSocial: Developing Sleek and Collaborative Applications with OpenSocial and AJAX Push. For the dramatic conclusion to our talk, we showed a demo that used ICEfaces Ajax Push to push OpenSocial Activity updates to connected users.

The demo is a good way to learn about both the OpenSocial and ICEfaces APIs, but you'll need a few things to get started:

Download the Java version of Shindig and copy shindig-server-1.1-SNAPSHOT.war to Tomcat 6 webapps/shindig.war (this gives the Shindig application the expected URL).

You can download the icefaces-opensocial application source code from subversion:


Download ICEfaces 1.8.1 and unpack it.

Edit icefaces-opensocial/build.properties so that icefaces.home points to your "icefaces" directory from ICEfaces 1.8.1. Invoke "ant" and copy the .war file in icefaces-opensocial/dist to webapps/ in Tomcat 6.

Then, launch separate browser instances for the URL http://localhost:8080/icefaces-opensocial . As the different users create Activities (with a specified title and body), the updates will be pushed to the other users. It would be easy to customize the code to accept more interesting Activity objects with application-specific properties; for instance, with image or hyperlink payloads.

How does it work?

When the ActivityBean starts up, we use SessionRenderer.addCurrentSession(personName) to register the current session for all updates for the logged in user (the demo is single user from a login perspective; you will likely wish to expand on that capability). We also prepare a stub for our connection to the local Shindig server. Note the TOKEN initialization; this is necessary to encourage the Shindig server to allow us to change (rather than just read) Activities.

When the user clicks on the submit button activate() is called. We create a new Activity in the Shindig server with the provided input and cause the new Activity to be pushed out to all connected browsers with SessionRenderer.render(personName)

The final main part of the application is the display of the Activities themselves; it's simply a dataTable that displays a list of Activities fetched via socialClient.fetchActivitiesForPerson(personName).

As you can see, the push capability is entirely driven by the web application front-end. An interesting extension to the OpenSocial RESTful protocol would be to incorporate push capabilities there directly, so that HTTP clients could listen for server-side changes.

Chris has posted the full set of slides on slideshare.

From http://blog.icefaces.org

Published at DZone with permission of Ted Goddard, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)