Deployment Architecture

Overview of Social Networks

What is a social network? For us its about connecting communities, users and applications anywhere in a connected environment. For our Ringside Social Application Server its about providing applications everything they need to become socially aware. We take that one step further and allow applications to bring to their customers a social platform where they can connect community, users and and other applications anywhere in a connected environment. What a social network is not to us is a specific list of applications out of the box.

The Ringside Social Application Server is the first open source platform that enables businesses to weave social capabilities directly into their existing websites while seamlessly integrating with social networks such as Facebook.

Facebook Applications - the beginning of Social Applications

In May, 2007 Facebook took an important step forward in expanding what a Social Network could become by opening up an API that allowed 3rd party applications to run on Facebook. This diagram explains their architecture at a high level:

  1. User has logged in and requests the application. The social network prepares some information for the application and adds that to the request, this is the start of a social network context.
  2. The application can do whatever it wants at this point, but it has access to social information and can now make an application more engaging by using social information (like getting your list of friends) and more viral by taking social actions (such as adding a comment to the user's wall), all available through the APIs provided by the Facebook social network
  3. Finally your application builds a response which is made of a markup language understood by the social network, in this case Facebook Markup Language (FBML)
  4. Facebook then renders your FBML onto the Facebook web page. For example, if your FBML requests to put the profile picture of friends for this user on the page, Facebook will do that in a consistent manner to the rest of Facebook. This is how Facebook keeps a consistent look and feel and makes things simple for application developers

This simple architecture has proven to be incredibly popular and scalable. By March of 2008, there were more than 19,000 applications (browse facebook apps), and 95% of of the 67 Million Facebook users had added at least one application.

So how do we contemplate enabling social applications where they can become a part of the social network of their own choice?

The start of the Social Application Server

Our primary goal is to make sure every application has access to a social context and an extensible (and pluggable) set of social APIs for improving the engagement of applications and enabling them to push through viral information. Middleware application servers are focused on embedding a full application, providing isolation, and a set of apis for writing an application. Social application servers do not have this constraint as applications do not exist inside the server (they might not even exist in the same domain). Just as a social application server does not provide infrastructure for one application it does not limit itself to just one social community. Lets start taking a deeper look.

The simplest view is one external website (or community site) and one application. Lets hook them together and we can begin to see how the Social Application Server starts to integrate. We need an application and a web site, for this example we will use Runlicious(an application that allows runners to keep track of their mileage, races, etc.) as the application and Running Co(a web site for a small chain of running stores) as the sample web site/community. www.runningco.com would like to offer all of it's users the ability to have a running log, for logs to be shared within the community, between friends, coaches and even be able to promote the information within other social networks such as Facebook.

As a user requests content the process consists of four steps.

  1. Browser hits the www.runningco.com web site and the web site makes a request to the Ringside Social Application Server for the Runlicious application. Ringside builds the social context (including User and Application identity and security) and connects to the application
  2. The Runlicious application has enough information to make calls to the Ringside server for social information like get friends list
  3. The Application builds a Social DSL (Domain Specific Language) response, in this case FBML
  4. The Ringside Server processes the FBML, rendering a page (or part of a page or widget) specific to the Application. This is then passed to the web site, which can then return a complete page to the user

Facebook Compatibility

The Ringside Social Application Server is designed to work within a multi-social network and multi-application context. The initial version has been built to have both Compatibility and INTEROPERABILITY with Facebook (future versions will also work with Open Social). This means that any application that runs on Facebook can also run on the Ringside Social Application Server (Compatibility), and that an application can use social information held in Facebook as well as on the Ringside Server together (interoperability).

The Ringside Server accomplishes this by supporting the Facebook API, FQL and FBML - all of the ways that a social application interacts with Facebook. The internal Ringside Server architecture is shown below:

This enables any Facebook application to run on the Ringside Social Application Server with only a few simple changes - unlocking three powerful use cases:

  1. Facebook developers can develop and test their social applications on their own laptop using the Ringside Social Application Server, and then simply upload their applications to Facebook for deployment
  2. Facebook applications can now run on any website using the Ringside Social Application Server and are no longer limited to just running on Facebook
  3. New social applications can be developed and deployed on both your website and on Facebook simultaneously - greatly expanding the reach of a website into a large and vibrant user base

We have implemented the primary facebook API's already and have a strong set of FBML tags implemented, we make progress on this every day. The Ringside Social Application Server is implemented entirely in open source (LGPL license to allow embedding of the server in any software application), and we expect the community to help us implement the full Facebook API and FBML tags and to keep up with the rapid pace of change and wide range of adoption by an extended community. To get involved or see what we have implemented - APIs and Tags.

and More...

The Ringside Social Application Server has more than just Facebook compatibility. The server has an extensible API and Domain Specific Language structure. This allows for a consistent way of extending capabilities. The Ringside Server includes a default API that allows for things like a more extensive security structure than Facebook offers. For example, applications can take advantages of this as well and create API's and tags that are custom to their applications. The Domain Specific Language capability is particularly powerful, allowing applications to open up custom tags just at Facebook has added FBML tags. For example, the Runlicious application could open up a tag to get the mileage of a runner for the past month. This means a web site developer could simply embed a tag in their web page to get the mileage for a web site visitor - something like "Congratulations Bob on running 127 miles last month".

Facebook Interoperability

Social applications can chose two modes to use the Ringside Server to extend beyond Facebook and integrate their applications. In the first mode, the social application keeps track of which server (Facebook or Ringside):

The second mode provides a great deal of simplification for the social application. The Ringside Server provides a proxy for both Facebook as well as any web site. The Ringside Server is able to provide the connection between Facebook User ID's and the web site user ID. For example if Bob had an account on the running store web site as well as Facebook, then he could enter his running information on either Facebook or www.runningco.com. When the Runlicious social application requested a list of friends, it would provide friends of Bob on both Facebook and on the running store web site - a "federated view":

Social Applications can be anything

Social applications are not constrained by language, they exist in Java, Ruby, Python, Perl, PHP or any language. They can be custom applications like the Runlicious example, or they can be blogs, forums, wikis, photo sharing, or even custom business applications like Faceforce. The social context passed in from the Social Application Server is not a complex Corba IIOP stream, its not masked by the details of Java's RMI or obscured by WSDLs and XML RPCS. The power is in the simplicity - here is a user coming from this network. With this and some other information we can ensure that user, application and network are who they say they are. Then the server provides functionality that the application can choose to use.

However social applications today are built for one network. Today, social applications either build their own network for target markets or applications. Being part of other social networks and applications is not easy today, there are no easy ways for a user to be a part of multiple social networks and applications that would ensure security and permissions. So today there are cool social networks such as Ravelry (thanks Jess), Threaded (you guys rock) and a laundry list of others. There are many great websites and even great content pages but they are closed. They continue to create stand-alone social networks and social applications.

Communities are everywhere

On the opposite side of the applications we have communities, and they are everywhere. Communities are not limited to a single site and multiple communities can exist on a single page. For example on the attached page the number of social networks are HUGE. What if this page had a social context - where we could see if the user was a dentist in New Jersey, New Guinea or New Zealand, and what professional social community the user was a part of. We would be able to control not just the language preferences but social preferences. This page becomes a social network on its own, friends could be made on this page, they can continue their relationships in other communities or they can limit it to this page but their social interaction is now possible.

We believe the integration of Communities and Applications define a digital Social Network. This can happen on any page, site or independent destination.

Supporting many applications implies that inside the Ringside Social Application Server we maintain information about all the applications. This is true as each application needs to register. As an application registers it will be provided with some security token information so that each application is a known entity and we can manage the communication. Today we collect enough information about an application to register it within the system. We also collect enough information to help us support applications in both a Facebook environment and Ringside environment simultaneously (more about this later).

Web Pages, Community Sites, Content Sites, Social Networks (Federation)

Our philosophy is that social interactions can happen anywhere. They are not limited to an application, blog, forum, or gadget. We should be able to enable social interactions on a single web page or throughout an entire site. Social interactions should be integrated into content oriented (content management and wikis) sites. And these interactions should be enabled going into and coming out of existing large scale social networks.

Should I be friends with you on this site? Should our friendship continue to a social network? Who should control this behavior? Can applications support a user coming from 10 sites but wants only one set of data for your application? Should my actions be viral? Should they be viral on this site only, and only to those who have participated in the conversation? Should it be viral across social networks? The questions can be broad or narrow, the combination are indeterminate as are the business cases supporting each model.

As a Social Application Server we focus on how can this be done. We continue to look for real world cases for all kinds of networks and keep looking to make sure we are implementing towards those real world examples. The key concepts in dealing with many networks focus around Identity Management, Permission and Privacy, Social Network Federation and configuration of the intersection of user(s), site(s) and application(s).

Now we are trying to balance an immense number of potential social networks and our rules of identity management by which to control how networks, users and applications behave. We continue to investigate the security models which will be important to created trusted relationships with all these social locations.

What about my own network? Sure you can do that.

Bringing it all together we have Pages, Sites, Apps, Social Networks and everything that wants to be social connecting with a specific set of applications or an open repository of applications. What this does not answer is how do I create my own social network based on this technology, how do I create a destination location fully integrated first and foremost with my site and then broaden that out to other communities.

The packaging of the Ringside Social Application Server includes a Community Engine and over time we will provide a set of increasingly rich applications from our repository. Since this will be in open source, we expect contributors will also expand the capabilities that are important to the market. The community engine will serve a few functional points in our architecture

  1. Developer Console (adding your applications)
  2. User Profile application
  3. Registration/User Application
  4. Customizable Menu Application
  5. Side bar Applications
  6. Control Panel (not available yet)

Our community engine is thin, very thin. Why? Because everything is an application, even authentication. Sidebars, Menu, Canvas Page - they are all apps. Do you want to show no sidebars and two apps? OK. The community engine helps serve as an example of how to combine applications and create a social network for one application or one hundred. The community engine will serve as the entrance into the management and maintenance of the Ringside Social Application Server.

Conclusion

Ringside Social Application Server is a complete platform to take your application from stand alone to socially aware. The server enables an application to serve one community or extend its reach across many communities. The work currently being done on Identity Management will provide a mechanism for Social Network federation that concentrates on federation and not consolidation of profiles. By bringing together many communities and many applications we have created the possibility of open networks or closed networks that make sense. As of March, 2008 we are in early beta and continue to push on the platform. Being open source provides you the ability to watch our progress as often as you want and contribute to making social networking ubiquitous with us.