JavaOne. How to Implement Your Own OpenSocial Container on the Java™ Platform

This was session TS-6574 at JavaOne.

A talk around implementing the OpenSocial APIs for your site.  OpencSocial defines a dingle API for social applications that covers the majority of interactions with social web tools.

There are two basic parts.  The Server side contains a Gadget Server (think Google gadgets), and an OpenSocial JavaScript library. The client side uses XML and JavaScript, similar to that by Google gadgets to make requests to the server using JSON requests.

The JavaScript API has 3 constituent parts:

• People and Friends API
• Activities Data API
• Persistence Data API

So what are your options? Well, you can either roll your own API to the spec. or utilise the existing open source implementation – e.g. Shindig.

An opensource implementation, as part of the Apache Incubator.  Currently only for PHP and Java, and very easy to use.

The Gadget server renders XML, and the server-side components are covered by an OpenSocial Servlet, and now there is a REST based API on it’s way.  Note: It needs JDK 1.5.

It comes bundled with Jetty so you don’t have to have another Application server to run it in. When you download it, there is an infrastructure dir with some useful plugins.  A maven plugin for Eclipse that allows you to great a project for a gadget etc.

When it comes to integrating it with your data e.g. a Database, you just need to implement your own brand of the sample implementations included of People Services, Activity and Data.  These are bound using a provided module, using Guice.

Security is obviously important, so you can either use the built in OAuth mechanism, or again roll your own.

Social site Hi5 have built their own, based on the RI, more detail on their developer site.

They shared a few lessons learned:

1. Prepare for viral growth.  They experienced a sudden 50% increase in days.
2. Think carefully about the policies – what you will allow
3. Build tools to for publishing and managing this data.
4. Think about the request model – they had a friends list on every page, which each time the page gets refreshed, makes a very expensive call to getListFriends.  They added a TTL style cache.
5. Tuning – on their dev site, there’s a tuning guide for 6.10
6. There is a need for lots of synchronization and encryption (cases that worked in the guide)