Ajax Push for OpenSocial
Ajax Push for OpenSocial
Join the DZone community and get the full member experience.Join For Free
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.
Opinions expressed by DZone contributors are their own.