Shinding Architecture Overview

Social Networking has taken the internet from read only mode to a real collaborative mode intertwined with human networks. This has opened up unlimited ways in which the information can be stored, retrieved and used. OpenSocial attempts to reduce the pain for application developers to write applications from scratch for various Social networking sites.

This is a specification which envisions a write once, run anywhere mantra in the Social Networking space. Shindig is a reference implementation of OpenSocial specifications for developers to develop against container providers to use as a reference. The Shindig code base can be used as a starting point and modified for Social networking sites which want to join the OpenSocial revolution.

Shindig Components

The Goal of the Open source project is to be language neutral and cover multiple languages. Currently Java and PHP implementations are availabe.We will be focusing on the Java based implementation as it is the most mature one. Shindig's Java version is a Java Servlet based application which can sit on top of any servlet container which complies with Servlet 2.3 specifications. By default it is shipped with an embedded jetty servlet container.

Figure 1 describes in more detail these components.All the three components are accessed using HTTP / HTTPs through a servlet. OpenSocial Server side components and Persistent Data Access Layer share a common Servlet ( GadgetDataServlet ) , while Gadget Rendering components have a separate Servlet entry point ( GadgetRenderingServlet).

The container consists of 5 different servlets. We describe how each of these map to server side components listed above

All the servlets are subclasses of HttpServlet and serve as independent entry points at runtime. This architecture adoption has to do with the evolutionary way in which shindig has evolved.

Persistent Data Loading Mechanism

This layer is responsible for loading the persistent social data which includes- Person details, friends list, activities associated with a Person. In the default implementation this is stored in a XML file.

The GadgetDataServlet provides the entry point for this. This layer is pretty much pluggable and can be easily replaced with a more robust persistent mechanisms.

The GadgetDataServlet uses StateFileHandler to load the data for the container into memory. OpenSocialData Handler is used to populate the Open Social objects and query them. StateFileHandler happens to be one of the mechanisms used here as a sample implementation for XML based state persistence. Actual implementation will replace this depending on the data store chosen to store social data.

Figure 3 : Class diagram of the GadgetDataServlet and its related classes used to reset and access the Open Social state

Figure 4 : Sequence diagram explaining how the state data is reloaded by the Sample container before the Gadget is rendered.

Gadget Rendering Infrastructure

Gadget Rendering infrastructure has client side and server side components. It is responsible for generation of Gadget HTML from the Gadget Xml.

Client Side Components

Server Side Components :

GadgetReenderingServlet
GadgetRenderer
GadgetSpec
Gadget

Diagram below explains the sequence in more detail on how HTML is generated from the Gadget Xml and sent back to the browser.

Figure 5 : Collaboration flow on how the Gadget XML gets converted into HTML and by the GadgetRenderingServlet and its downstream components

OpenSocial Server Side Implementation

We will be covering this scenario in more detail using the collaboration diagram.This diagram will show the call flow from the client side to the Server Side.

Client Side Components:

Server Side Components

All the OpenSocial calls are received by GadgetDataServlet and passed on to the OpenSocialDataHandler._This datahandler is called depending on the type of the request which should be one of the following :

We will take FETCH_PEOPLE as an example and go through the flow in the figure below. Default People service is a wrapper on XML file based Persistent store which is used in Shindig out of the box.( XML file based implementation is just for demonstration, needs to be replaced by a more robust persistent mechanism)

This service loads, parses and stores the data of Person, Friends, Activities in Memory in Maps. Depending on the nature of the call data is rerieved in memory (6 to 14 )and converted into JSON object(14) and sent back (15 ) to the client side for presentation

Figure 6 : Collaboration diagram tracing call to view friends from client side javascript to server side components and back

Replacing the default Sample Container persistent store with a Custom Store.

The diagram below expands the discussion so far into one figure. The OpenSocial Sample Container piece is the actual runtime by default. It consists of 3 services, BasicPeopleService, BasicActivitiesService and BasicDataService.

For Custom Persistent implementation the following classes need to be replaced and implemented according to the storage mechanism being put in place.

Summary

Shindig's basic implementation is a good starting point for somebody interested in getting started quickly on OpenSocial in their networking web sites. We explained how the container has multiple entry points and our discussion is based on servlet technology. The rendering and social data access are independent compoents and can be replaced depending on the needs for it has to be used. Towards end of the article we talk about the plug gable nature of the data persistent layer. The pluggability in the architecture is a big help in adapting it quickly to the exact storage model required to be plugged in.

Shindig itself is a moving target with an active community and OpenSocial's evolving spec,but is a very good starting point for container providers looking for a head start.

Architectural Overview of Shindig , an OpenSocial Reference Implementation

Introduction