JavaOne 2008 – Making your website social – on OpenSocial API and project SocialSite

3

The Web is better when it is social – is the tagline for the OpenSocial (API) initiative. This initiative, from Google and many partners in the Social  Networking arena such as LinkedIn, Ning, Hi5, MySpace, orkut, Plaxo and companies such as Oracle, aims at defining a common API for social applications across multiple websites. With standard JavaScript and HTML,
developers can create apps that access a social network’s friends and update feeds.


The OpenSocial API is somewhat ironically the next step after an earlier initiative of Facebook that opened up some of its platform with an API and the FBML (FaceBook Markup Language) (see http://wiki.developers.facebook.com/index.php/FBML ), with Face Book not yet part of the OpenSocial movement. The OpenSocial API is expected to be implemented/provided by many of the leading social networks. And it is expected to be soon controlled by the OpenSocial foundation – instead of being hosted by the rather closed Google corporation.

The presentation at CommunityOne by Dave Johnson and Jamey Wood provided a good overview of the developments in terms of social software in the past – starting in 1996 with the first blogs and wikis and propelled in recent years by initiatives such as Friendster (an early one), LinkedIn, Twitter, Dopplr, Facebook, MySpace, Plaxo – and the expected future. The unstoppable march of social aspects of software into the Enterprise is clear to all. If you do not want your company’s website and web-applications to be the static HTML dinosaur but want to explore and exploit new ways of engaging visitors, you have to open up and socialize.

The OpenSocial API certainly helps. However, it has its limitations. Well, what is it to begin with? OpenSocial describes to mechanisms to interact with Social Networking platforms such as Twitter and LinkedIn:

 

  • The OpenSocial JavaScript API
  • The OpenSocial REST API

The JavaScript API is targeted for use in client side widgets based on the Google Gadgets architecture, that plug into the UI of Social Networking sites. At their core, social gadgets are XML files, sometimes known as gadget specifications. These gadgets provide interaction with a Social Networking service. (see http://code.google.com/apis/opensocial/articles/tutorial/tutorial-0.7.html for a tutorial on getting started with creating Social Gadgets). Developers can create applications, using standard JavaScript and HTML,
that run on social websites that have implemented the OpenSocial APIs.
These websites, known as OpenSocial containers, allow developers to
access their social information; in return they receive a large suite
of applications for their users. Note that these containers – such as orkut and the other major social networking services – implement the Google Gadget container specification for hosting these social gadgets.

The REST API provides programmatic access based on ATOM (or JSON) for communication from your own server side applications. These APIs allow social applications to run on desktops, mobile devices, and other channels that don’t support JavaScript.

The API supports three areas:

  • access to people profiles – support for over 50 characteristics found in many of the social networks, (The People and Friends data API allows client applications to
    view and update users’ profiles and relationships. Your client
    application can request a list of a user’s Friends and query the
    content in an existing Profile) Note: Google’s website states view and update, while the presenters stressed the fact that the people and friends api only allowed read only access.
  • read/write access for activities – entries with a timestamp, title, a body, associated media content (he Activities data API allows client applications to view and publish “actions”
    in the OpenSocial platform. Your client application can use the API to create new
    entries, edit or delete existing entries, and view lists of entries.)
  • The Persistence data API allows client applications to view and
    update key/value content for their applications. Your client
    application can edit or delete content for an existing application,
    user, or gadget instance, and query the content in an existing feed.

Dave and Jamey stated that the OpenSocial API is fuzzy on support for groups and how to do authentication. They were a bit vague about support for Friends/Links and said that the People API was read-only. This latter statement seems to contrast wtih the specification on the OpenSocial website, so I am somewhat at a loss here. Note that the API is currently at release 0.7 and is still very much work in progress.

Apache Shindig

The Apache Shindig project – currently in Incubator at http://incubator.apache.org/shindig/ – will provide us with a few interesting things, including an open source implementation of the Google Gadgets server:

  • Gadget Container JavaScript – core JavaScript foundation for general gadget functionality. This JavaScript manages security,
    communication, UI layout, and feature extensions, such as the OpenSocial API.
  • Gadget Server -an open source version of Google’s gmodules.com, which is used to render the gadget XML into JavaScript and HTML for
    the container to expose via the container JavaScript.
  • OpenSocial Container JavaScript — JavaScript environment that sits on top of the Gadget Container JavaScript and provides OpenSocial
    specific functionality (profiles, friends, activities, datastore).
  • OpenSocial Data Server — an implementation of the server interface to container-specific
    information, including the OpenSocial REST APIs, with clear extension points so others can connect it to their own backends.

Note that Shindig will have both Java and PHP implementations of the server.

Dave and Jamey indicated that Shindig will not have the ability to create the social graph (data). I have not looked into this closely enough – you would think that the Data Server component listed on the Shindig website would allow us to at least implement that functionality if it is not already there. However, I need to find out more about this. Since this missing link is a primary motive for the SocialSite project, it is hard to imagine how this point could be misunderstood by Dave & Jamey. What is very clear is that Shindig is in its very early stages.

Making your Web Site a Social Site

Dave and Jamey continued with discussing how to turn your web site into a social one.

Step one seems to be to leverage the OpenSocial API. However, the JavaScript API will only have you add gadgets to the Social Networking sites – which is not what you want. The RESTFul API allows you to add functionality to your own site, but all data – the social graphs of your site’s friends – is in one or more of the Social Networking services – not typically what you would want.

One step beyond this could be the use of white label (hosted) social networking services like Ning, Apppod and KickApps, but that still has your data with someone else.

If you find that a problem, you could leverage Apache Shindig, if and when available, to build your own Social Site server infrastructure.

However, Dave and Jamey suggested that this probably will still leave some things to be desired and proposed an alternative approach: Project SocialSite (see https://socialsite.dev.java.net/ ).  ” The SocialSite project is delivering social networking functionality by
adding social networking platform support based on the OpenSocialTM
standard to any community site. Any social application written for the
OpenSocial based social network can be seamlessly and easily hosted on
a transformed community site that is powered by the SocialSite project.”

SocialSite provides the server infrastructure to host a Social Site, implementing the OpenSocial APIs. SocialSite comes with a bunch of jMaki widgets that can be used to very quickly – mutually coordinated – gadgets exposing ‘social features’ to your website.  SocialSite comes with a database for storing the Social graph data.

The demo was pretty smooth. In September we may expect a beta release with a ‘production’  release expected for October. What exactly the status of Project SocialSite is or will be, was unclear to me. It is part of the GlassFish area of dev.java.net – but what exactly it is part of, I do not yet know. And why it could not build on top of Shindig did also not become entirely clear. But it most certainly looks interesting.

 

 

 

 

Resources

See the blog article http://rollerweblogger.org/roller/entry/project_socialsite by one of the presenters, Dave Johnson, on this presentation.

Here is the project website at Java.Net: https://socialsite.dev.java.net/

The homepage for the OpenSocial (API): http://code.google.com/apis/opensocial/

 

Some very interesting examples  of sites and gadgets created using the OpenSocial API: http://opensocial-examples.googlemashups.com/

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

3 Comments

  1. The author of technology.amis.nl has written an excellent article. You have made your point and there is not much to argue about. It is like the following universal truth that you can not argue with: If God hadn’t meant us to eat, he’d have made us photosynthesise. Thanks for the info.

  2. Thanks for blogging about our SocialSite talk. Glad you enjoyed it. Regarding the paragraph that starts with “Dave and Jamey indicated that Shindig will not have the ability to create the social graph (data)” I’d like to comment that since Shindig is an open source project, somebody may well contribute a Social Graph repository to the mix in the future. But right now and for the foreseeable, I believe the major focus of the Apache Shindig (incubating) project will be to make it really easy for sites with social data to act as OpenSocial containers. Currently, Shindig provides a set of stub interfaces that you can implement to hook in your social data and I’m not aware of any plans for a back-end social data repository and definitely not the kind of comprehensive, flexible and scalable we are working to build in Project SocialSite. We think we can add significant value beyond what Shindig offers and we hope to contribute to Shindig as well, where it makes sense.