Introducing OpenSocial and how Liferay can benefit from it

Last week Google announced OpenSocial with an impressive set of partners including Orkut (as expected), MySpace, iLike, Flixter, Oracle, .... There were companies that had their own social network, others that offered applications through the Internet and even companies that provide services and infrastructures. There's been a lot of blogging about whether this is Google's checkmate to Facebook platforms or it doesn't make such a difference, among other reasons because Facebook could actually jump in into OpenSocial too.

But I'm not that interested in politics. What I really care about is the technical side of OpenSocial and looking at that side there are a lot of things to be excited about.

Let's start from the beginning, what exactly is OpenSocial?

“OpenSocial is a set of APIs that an application can use to access social network related functionality. Including accessing information about the user and his/her network of friends, modifying this information or generating activities based on what the user does in the application that his/her friends will receive.”


This API is targeted to applications that run in social networks. Those applications do not usually run by themselves but are accessed through a social network container that executes it either locally (as it's done with portlets) or remotely (as happens with Google gadgets). The fact that the application runs in a web page that acts as a container is key to understand OpenSocial.

The key innovation of OpenSocial

OpenSocial provides both a web services API and a JavaScript API, but it's the latter the one that makes a difference. The reason for this is that it allows the paradigm of:

“Develop Once, Run Everywhere”
This is possible because JavaScript is a dynamic language and is executed in the browser. Let's see an example code:
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
req.add(req.newFetchPersonRequest('OWNER'), 'owner');
req.add(req.newFetchPeopleRequest('OWNER_FRIENDS'), 'ownerFriends');
req.send(function(data) {
viewer = dataResponse.get('viewer').getData();
owner = dataResponse.get('owner').getData();
ownerFriends = dataResponse.get('ownerFriends').getData().asArray() || [];


There are several things to note about this example:

  • The access to the API starts through an object called 'opensocial'. That object is not part of the application, it just assums that it's going to exist when it's executed within the social network container.
  • Each opensocial request contains several petitions for functionality. That allows reducing latency and network bandwith, because each application only needs to make one remote request.
  • The request is asynchronous (uses AJAX), so the user can interact with the parts of the site that do not need to wait for the response.

This application can be run in any web page that offers a JavaScript object called 'opensocial' that implements the functionality defined. So any current (social network) platform that already provides that functionality through it's own mechanisms and API can quite easily write a thin JavaScript and web services layer to support OpenSocial.


From an application developer perspective that really means that they can develop their social application once and deploy it in several distinct containers. The application will use the social network of the container where it's deployed.

But what if some social networks have some functionalities that others don't?
Standarization vs Innovation
OpenSocial defines three functional modules:

While those modules cover much of the functionality needed in social networks, it doesn't cover all. Because the truth is no fixed standard will never be able to cover the functionality that is very specific for a given social network. So, faced with this situation what should an OpenSocial application developer do? I see two options:

  1. In some cases it should be possible to leverage the dynamicity of JavaScript to check if a given functionality is available or not. And if not, just avoid using it.
  2. In more complex cases, where using the functionality or not makes a bigger difference or when it has to be decided in the client side, there might be a need to create different versions of the application for each platform.

When the second option is chosen, the sentence “Develop once, run everywhere” is not true anymore. For this reason, some say that Google is not that ambitious and they are in fact promoting an slightly different motto:

“Learn Once, Use Everywhere”

Which is still quite useful. There is still one more technical aspect that may make the developer decide to have different versions per platform: the technology used to develop the OpenSocial application itself.

What technology can be used to build OpenSocial applications?

If you read the OpenSocial website, it clearly says that it's built on top of the Google Gadgets technology. One nice aspect about Gadgets is that the can run in one server (such as Google's servers) but can be shown in any website (for example in Liferay using the Gadget's portlet). Also Gadgets already make heavy use of JavaScript, and even have a mechanism to specify that a certain JavaScript functionality is required by the application. OpenSocial has reused that, so that if an Google Gadget wants to have the 'opensocial' object available it just needs to add the following in its XML definition:

<Require module=”opensocial-0.5”>


So using OpenSocial within Google Gadgets is easy. But Google Gadgets are not the best solution for any type of application. So the question is, would it be possible to use OpenSocial with other technologies such as portlets?

How does Liferay relate to OpenSocial?

Liferay already provides basic functionality that can be used (and has been used) to build social networks. To be fair, that requires some development. For this reason, we had talked lately about developing and adding more functionality tipicaly of social networks in the default distribution (or as an official plugin).


Open Social makes this idea even more attractive. First Liferay would become one of the first products for executing open social applications (right now there are platforms, but you cannot download and use them yourself). Second, Liferay's social features would be exposed through an standard well known API, which is very useful to promote the development of extra applications that leverage it. Third, as Liferay already supports Gadgets, any open social application developed with this technology may even run unmodified in Liferay.

So this is a case where reasonably little effort would yield a great amount of benefit to our users'
The dark side

Although OpenSocial is a very promising technology, and I think it is big step forward in interoperation of applications in different platforms, not everything is good news for it. Most complains come from the lack of documentation and because of some security deficiencies. In fact, very shortly after it was announced someone found a way to hack an OpenSocial application and very shortly after, the same guy hacked another one. There are other people complaining about general security issues regarding the usage of JavaScript and Iframes (specially when cookies are used). And some highlight the lack of user authentication in the standard.


Other complains, that I heard in last week's W-JAX have come from people that don't like the technologies chosen and in particular JavaScript. The good news for those is that other RIA technologies such as Flash or JavaFX can also be used, since they have (or will have) connectors to JavaScript.


To be fair, this is version 0.5 of OpenSocial and the engineers behind it are showing a lot of interest in hearing what the community has to say. I'm pretty sure these problems will be solved for version 1.0. Until then it should probably not be used in live environments, but this is a great time to start development around it. We will most probably do it :)

Some of this stuff is actually very complimentary to JSR-168.
Hi Michael,

Yeah, I fully agree. JSR-168 and JSR-286 just cover the means to execute the application, but the mechanisms in which the application access certain services is out of its scope.

Unfortunately, until now nobody realized that it would be a good idea to start standardizing those communication mechanism. Fortunately, even if they did it for gadgets it can be used for any type of application including portlets.
Hey Jorge!

Yup. It's a good idea. I think that we can start a practice to help facilitate the convergence of some of these standards.
"JSR-168 and JSR-286 just cover the means to execute the application"


So it's a langage dependant standard and, in the future, I think the standard will not be dependant of the standard.
* will not be dependant of the langage.
Hi Laurent,

I partly agree with you. Java is already a multi-language platform. Liferay supports already development of portlets in PHP and Ruby, and more will come.

On the other side, I also expect new standards for integrating remote application inspired by the architectural styles of Google Gadgets and the Facebook Platform. These architectures allow developing applications in the server side platform of choice.
Is there something new about OpenSocial in relation with Liferay?
Hi Brahim,

There is a prototype that integrates Shindig with Liferay in SVN. It's not updated to 5.2 because people haven't shown yet a lot of interest in it. But I think it's just a matter of time until OpenSocial gets more and more popular.

Of course, any help and contributions regarding this would be very appreciated.
Ok Laurent,

Thanks a lot!