Liferay Portal provides an excellent platform for building web applications, websites, and portals, but it can additionally be used for a new category of web applications called "social applications." The definition is simple: a social application is a web application that additionally leverages social identity, data, and features or services. In the left figure, the light blue squares represent a definition of a standard web application while the darker blue squares show the addition of social aspects. First (center), a standard web application consists of a user interface built to access application logic. Second (left), web applications are often influenced by a formal identity policy. Third (bottom), applications will have access to data that they store or is specific to the current user. Lastly (right), web applications are often built to interface with external services and are built using external systems as part of the business logic.
Nearly any web application can also be built as a social application, increasing the productivity of users. Liferay has several key features to implement social applications.
Leveraging Social Identity by Adding it to Formal Identity
Enterprises often implement an enterprise-wide systems architecture that simplifies access management. Applications are defined to access user identity from a central repository, while Identity Management software is used to update this information. This type of architecture simplifies the management of a large and changing number of users that are accessing an equally large and changing number of applications. It also allows auditing and compliance as all accounts are centrally managed and all access can be centrally audited.
The right diagram shows how Bob Smith is identified by both his formal and social identities. He has a formal identity that states his membership in the Engineering Organization, Core Engineering Team, Project X Group; plus, he has the additional role of Manager. This formal identity is defined by policy, implemented by people administrators, and is often regulated by SOX compliance.
Standard web applications can be developed to leverage a formal identity with several methods (e.g., simple access control, node specific access control, role-based content delivery, or even workflow access). However, users can be identified by more than their formal, defined-from-the-top-down identity—they can also be identified by their social identity. "Social identity" is the definition given to an individual's self-identified friends and groups or communities. Social applications also leverage a person's social identity in several methods (e.g., activity streams, subgrouping, grant access control, restrict access control, and delegation). In the left graphic, Bob can access a social collaboration site, which knows he has a friend network that is different from Steve's and Joe's friend networks. Activities and applications would be available to others in Bob's friend network if he grants them access, in which case all would be permitted to use the applications and content. While the community itself is a social application, applications available in the community can also be social applications depending on their data scope (see below).
Leveraging Social Data by Expanding Data Scope
A social application is often designed to have a data scope that is broader or more restricted based on an individual's social identity. In the diagram, the left application is a standard web application while the one on the right represents a social application. The standard web application has application data, but Bob can only see the application data associated with himself. For example, a calendar application would allow Bob to create events that he can see; however, Steve cannot see Bob's events and vice versa. If Bob is accessing a social application, he can see data that is specific to himself as well as information that is specific to all members in Project Y. For instance, a team calendar would allow all members to create events and enable individuals to see events created by all members. Expanding data scope allows a self-defined group of individuals to work on an application either as a team or as individuals .
Leveraging Existing Social Features and Services in Social Applications
Social applications can be developed using existing social features or services available in a social application platform. For example, a social application could include an existing shared document library, RSS subscription service, or wiki. Liferay provides many applications/features with collaborative capabilities and can be combined into the use case for the application in development. These services can be grouped into categories as shown below. More than simply adding links, each can become a service within a social application. A portal's ability to build an application from a set of modules, where features are grouped into one or more web pages, helps to make the application customizable while simplifying the growth of the application's feature set over time.
Liferay as an OpenSocial Container
Social applications can each implement their own social repository or leverage a centralized repository for social identity. Liferay 6.0 implements OpenSocial, which defines both a method to run gadgets and widgets as well as a common method to store and access social identity. This allows enterprises to use Liferay as an authoritative source for social identity information. A single Liferay installation in an enterprise allows users to create a profile page, develop a friend network, create and manage new communities or join other communities. This repository of social data can then be used by other applications installed into the same Liferay portal.
Liferay as a Centralized Social Identity Repository
Additionally, because Liferay leverages the OpenSocial standard, and because Liferay externalizes the definition of the friend network, a single Liferay implementation can be leveraged as the master repository for social networking data as shown in the left image. Applications that also support OpenSocial can point at this Liferay implementation and leverage its master social identity repository. Enterprises that implement this method will be able to develop a single IdM repository for social data, enabling a single source for collaborative definitions (and auditing).
