Application Architecture
Overview
In this section we dive deeper into the plumbing of the Ringside Social Application Server and explain how things are connected and how they are expected to behave based on interactions. From the picture just below we break apart the internal workings of the Ringside Social Application Server.
- Web - The community engine providing an interface into your application and eventually a management console for network providers, developers, affiliates and users.
- Social - The Social Engine is responsible for the requests for social applications. It handles the requests creating the social context. In this layer, identity management and trust between users and networks is established. It processes the response from applications and applies the appropriate handling of tags on the response before being sent back out.
- API - This layer represents the end points (REST-ish) for Social Application to ask questions and also developers to add capabilities to the platform specific to the network you are creating.
- Social Graph - The data store for social data, tagging data and local application data.
- System Apps - These are applications which are needed for the Web tier (Community Engine) to work. They are written as normal Social Applications (i.e. we can add <fb> tags to them); however, they circumvent being called remotely and therefore have some special properties available to them. Normal social applications should not be written this way.
- Extension Applications - Applications written to take advantage of the Ringside Social Application Server or apps that add their own APIs and Tags to the system.
- Facebook Applications - Standard applications written for Facebook can be pointed at a Ringside Social Application Server (learn more about how they integrate and the advantages available).
- Third Party Integration - The components that allow your social application and social network to expand to any page, site, or system.
How is an application connected in?
Prior to uncovering applications we need to talk about Clients and Endpoints. In the Ringside Social Application Server we are building the notion that the API Containers, Social Engine and Community engine can each run remotely. We know that social applications and third party sites are all remote from the perspective of the Ringside Social Application Server. We need to uncover how all these end points communicate and what types of clients are available for them.
We refer to things internally as Social Client and API Client. Social client is how external networks (pages, sites, social networks ) communicate with the social engine. The information here is typical user X on network Y requests a flavor (widget, canvas, mobile, ... ) of application Z. Social engine turns that request into a social context and calls the end point in the application. Application end points are registered in the list of known applications and are typically referred to as Callback URLs. The API client allows applications to make calls back to the API container requesting Facebook API calls, Ringside API calls or any call you like. The API client creates a context which represents that Application X would like to know "something" about the current user Y, where "something" is method X (i.e. facebook.user.get). The API container endpoint receives the request and determines if the request is legitimate, the user has the appropriate permissions, and other permission/metering rules are passed and then makes the method call.
Trusting the connections
How do we trust the connections between the clients and the end points? There are three connections to understand:
- External Network to Social Engine
- Social Engine to the Application
- Application to the API Container
External networks are, by nature, not a secure mechanism as most of their code is exposed on web pages. These mechanisms are not secure be default; however, we do provide the concept of trusted authorities. Each user must authenticate with one of these trusted authorities to establish a point in time trusted relationship. Our plans are to further extend the model of trusted network to social engine communication by providing minimal technology third party sites could use.
Social Engine, Application Engine and API engine share the application's public and private key. Messages from Social to Application and Application to API engine support creating a hash of the request and signing it with the application's private key. This mechanism ensures every application uniquely interacts with the platform.
We continue to design and move forward on these concepts, as security in a social and federated environment continues to evolve we continue to implement. Read more about identity management here
Ringside or Facebook generic application architecture
In using a social application server your application architecture can be Ruby On Rails, J2EE, JBoss SEAM, Php On Trax, Symphony, Velocity, Smarty Templates and on and on and on. Integrating with a social engine retains the properties of a normal http request but includes social context. That context is seamlessly managed by a client class. This client class allows you to communicate back to the API engine or have access to information passed through in the social request.
If the request comes from a Ringside Server or Facebook server the request handling process is identical.
Step 0. Your server receives a request.
Step 1. Create an instance of the Ringside Client (we provide pass through support for Facebook calls)
Step 2. Call back to the social engine for information you require
Step 3. Return your markup response
With this information, it's pretty easy for us to create a Hello World type application, though maybe not a very social application it would demonstrate integration.
As an application developer, the first challenge is to understand how user ids would work. A request from a Ringside Social Application Server could have the same user id as one coming from Facebook but represent different users, be careful to not generically use userid as the key.
In this model we can support standard Facebook applications as well as applications that take advantage of extensions of the Ringside Social Application Server.
Ringside Enabled Applications
To truly extend the power of social networking, you have to add to its core. If your application is about gifting friends, how can you make that fundamental to the social network so gifting is not isolated to your application but EVERY application can gift. If we examine an application and break it down into its normal architecture, we typically see that there are three layers:
- Model (the data)
- View (presentation layer)
- Controller ( business layer )
In a social architecture, your application can serve all of those layers or it can just become the controller leaving model to the API and view to the TAG layer. Thus, by exposing functionality via API and Tags, your application can focus on the aggregation of information across not just the user of the social network, but the applications of the social network.
Unlocking the power of applications
The gift app today in Facebook is an application. You can gift me and I can gift you - we interact in the context of that application. Why can't I gift you solely in the context of my Running Application? The answer today is that external applications are not capable of becoming part of the social network in any meaningful way.
An application fully integrated with the Ringside Social Application Server offers their services to other applications. Applications can call the gift API as they would call the users. The tags and api's are executed with the context of the calling application, user and network.
If your social network was based on health, you could offer core APIs and TAGS such as:
or an API like
The power is that any application plugged into your network can take advantage of this API or TAG.
 | QUESTION
If a user accesses your TAG enabled app from Facebook, will those tags display? I would assume not since Ringside would not be rendering those tags, only Facebook would, and they would probably throw an error for an unknown tag? |
A new class of applications could be born just dedicated to these social networks which are an off take of the 19K plus applications already available at Facebook.
