OpenSocial

Three years ago, on the 1st of November 2007, Google released OpenSocial. A lot of time and development work has passed since then. It is a perfect time to deal with it, so in this blog we get to learn where OpenSocial is today and how it actually works (read german version).

OpenSocial?

The web is better when it is social. With this motto, Google has launched OpenSocial. But what is it and what should be socially, meaning connected together? OpenSocial basically is a specification for a standardized interface in social networking. This interface represents the typical social network data such as personal informations, relationship links and activities. The access to this informations is not read-only. A developer who wants to write an application for one or more social networks, does this by using OpenSocial as single interface. This requires that the social network has implemented OpenSocial as an interface. Nearly fourty different networks currently do so. The most popular platforms are MySpace, XING or orkut. The goal of OpenSocial is to enable unified access to social networks. The various proprietary interfaces of social networks should be replaced with OpenSocial. The social web, seen from the perspective of developers and users, will be actually better:
Developers need to learn only in one interface and users can use an application in different social networks.

How does it work?

OpenSocial can be used client- and server-side. Client-side applications are based on the same technology as the iGoogle gadgets: Using XML, HTML, JavaScript, CSS and Flash you create these so-called OpenSocial gadgets. XML serves as a kind of container, which contains meta-information about the gadget and all the necessary data for the application (logic and user interface). You can get access to the data via the OpenSocial JavaScript API. A simplified access without deep knowledge of JavaScript is made possible with OpenSocial Templates.

On server-side, the OpenSocial REST API is used. It enables not only clients such as mobile applications, but also other servers to access data of a social network. Thus, for example, social networks can share data with each other. The sharing of data is in no case out of control, but it is protected by the API-authorization OAuth.

A major advantage of the REST API in contrast to client-side use of OpenSocial, it is not dependent on a specific programming or scripting language like JavaScript. Thanks to the active development community, there are many client libraries for various languages.

In order for the OpenSocial application to run properly, a so called sandbox is needed. This run-time environment will render the application and provide all the necessary resources which are needed by the application. OpenSocial describes this runtime environment as a container, but a container is also to be understood as a term for the client and server-side interfaces. So basically every social network that implements OpenSocial is a container. Of course it is also possible to make your own container. Either you implement your own interfaces using the OpenSocial specification and tests them against the compliance tests, or you use Apache Shindig, which provides the necessary interfaces for installing on your own web server. According to the developers of Apache Shindig, the installation can be done within an hour – that is certainly an alternative to developing your own interfaces.

What does Apache Shindig exactly do?

As already mentioned, a website which implements the functionality of OpenSocial is a container. Apache Shindig is an optional either PHP or Java based web service that provides the required functionalities of OpenSocial. Therefore Apache Shindig is an OpenSocial container that can be installed on your own web server with a few simple steps. This container fully implements the OpenSocial REST API and provides a sandbox with the JavaScript API to run OpenSocial gadgets. The sandbox itself is basically nothing more than an inline frame. This frame references to the previously installed Apache Shindig web service, which in turn is being passed the URL to the XML with all the gadget information as a parameter. This XML is then parsed by the web service and shown as an OpenSocial gadget within the inline frame. You do not need more than providing an URL, Apache Shindig will take care of the rest.

Especially for development and testing of OpenSocial gadgets, Apache Shindig should be used. Although social networks offer appropriate sandboxes for developers, but their use is riddled with all sorts of harassment. For example, only XML files with complete information to the author can be uploaded, the sandboxes are not available or you have to apply to be a developer of a social network in order to create some gadgets. Such restrictions are not shipped with Apache Shindig. Its use is therefore way more comfortable, stress-free and is highly recommended from my side.

Where is our „Hello World“?

OpenSocial offers three types of applications that can be realized with the given interfaces. The simplest application is illustrated by the Social Mashup. This type of application uses only the client-side interfaces of OpenSocial and runs within a container – or more simply within the above mentioned inline frame. It scales extremely well, but is also completely limited to the container, which can lead to limitations in storing and processing data. A Social Application avoids these restrictions. It works just like the Social Mashup, but uses services on external servers. That’s not bad in principle, but can lead to peformance issues once the application is heavily used or there are too many requests to the external servers. The last type of application is the Social Website / Social Mobile Application. This application does not run within a container, but it is an own web service (such as a web page) or an application on a mobile device. It only uses the data of social networks by accessing it via the OpenSocial REST API and OAuth.

You might realize that the first own OpenSocial application wont be developed within five minutes. At first, you have to decide what type of application you would like to create now. Although OpenSocial offers appropriate articles for the creation of Social Mashups, Social Applications and Social Websites/Social Mobile Applications, they are very extensive, rather inappropriate for someone who just wants to know how OpenSocial works or would like to know about how an OpenSocial gadget looks like. So I have created a small Hello World!

Social Mashup that takes on this task:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs title="Hello World!"></ModulePrefs>
  <Content type="html">
    <![CDATA[
      <script type="text/os-data" xmlns:os="http://ns.opensocial.org/2008/markup">
        <os:ViewerRequest key="viewer" fields="displayName" />
      </script>
      <script type="text/os-template">
        Hello World! Your name is ${viewer.displayName}!
      </script>
    ]]>
  </Content>
</Module>

This social mashup does not do very much, but it does its job very well. It just shows the name of the user running it. If you run the XML with Apache Shindig, as described above, within the inline frame Hello World! Your name is Shin Digg! will be displayed. OpenSocial templates are used to read out the user name. If you want to learn more about creating OpenSocial gadget, you really should get into the linked tutorials.

Where is the rub?

A single interface for social networks sounds great in the first moment, but OpenSocial also comes with limitations. OpenSocial is primarily a specification. It does not control how the social networks implement it. Thus, for example, differences arise when it comes to the implementation of the OpenSocial API, or there might be differences in access rights to the data of a social networks user. In the worst case it may be that your application works on the network A, in the network B only partially and maybe not at all in the network C. Sometimes there are approaches to avoid this, but in fact with OpenSocial these dependencies are what you try to avoid. At least this is the basic idea of the project.

The attentive reader will also have recognized that Facebook, with over 500 million users probably the biggest social network, does not appear in the list of platforms that support OpenSocial. The reason is quite banal: Facebook did not jump on then OpenSocial train and instead created OpenGraph, an own interface for social networks. Therefore Facebook’s OpenGraph is a direct competitor to Google’s OpenSocial and therefore latter will probably not offer a container for Facebook in the future.

At least not officially. Theoretically, it should be possible to provide a container as a third party service, which maps the interfaces of OpenGraph to OpenSocial, which is certainly not easy. But the documentation of OpenSocial is good, especially very large and there is a very active developer community. Maybe this blog has inspired the interest of someone who is currently looking for a small private project…