Chapter 11
Standards for Social Networking and Integration
In This Chapter
Surviving shifting standards
Leveraging common web standards
Exploring the OpenSocial enterprise standard for app embedding
Calculating the odds for social software standards
There is a lot to love about the idea that an organization should have one integrated social platform for all its communication and collaboration needs. At the same time, one software product, or software vendor, or cloud service, probably cannot fulfill every business need, now and forever.
So, using multiple products implies the need for standards — or at least commonly accepted specifications, data formats, and protocols — for plugging applications into each other and sharing context. Otherwise, you will tend to wind up with not one collaboration network but dozens of them. In this chapter, I help you think through the difficulties of dealing with shifting standards, enumerate the different types of standards, and consider the viability of one in particular, OpenSocial.
Surviving Shifting Standards
The social software industry is still in the process of figuring out the best way to do social application integration. There are standard data formats, standard authentication security methods, and standard mechanisms for embedding one application inside another. The challenge with these standards is there are so many to choose from.
And because social collaboration overlaps with the public social web, which is rapidly changing and morphing to accomplish other trends (such as the rise of mobile apps), setting standards that will last is extremely challenging. The very nature of standards-setting organizations has also changed under the influence of open source software, which emphasizes the creation of working software over stacks of specifications. Meanwhile, de facto standards including those from public social platforms like Facebook are often as influential as any defined by a formal committee.
Standards organizations like the Internet Engineering Task force (the custodian of the most fundamental Internet protocols) are often in the position of formalizing the definition of technologies that are already being treated like standards by agreement among major Internet companies. In the process, they try to improve the quality of these technologies — for example, of the OAuth social authentication protocol discussed in this chapter.
As a buyer and manager of social collaboration platforms, you will have to bet on which vendors seem to be making the right choices and forming the right partnerships. You also have to judge how important social application integration is to your organization now and in the near future. For example, is close integration with another web application essential, or is it enough for users to be able to click a link that takes them to it?
Bottom line: Do you insist on compliance with certain standards, or can you afford to relax and let these things sort themselves out?
Coping with immature technologies
No social collaboration platform exhibits the maturity that we expect from, say, a relational database management system (RDBMS). For that matter, the level of standardization between RDBMS products shouldn’t be exaggerated. The general pattern of using linked tables of related data to organize a database became commonplace in business applications decades ago. But SQL, the Structured Query Language used to add, retrieve, and manipulate relational database data, is a standard with many vendor-specific variations.
The social authorization standard OAuth (explained in more detail here) is probably the most widely accepted of all social application integration standards, but implementations in software products and cloud services vary in the extensions that they implement.
The current OAuth 2.0 specification is more “official” than some of the others mentioned here, having been defined through a standards track process of the Internet Engineering Task Force (IETF), the body behind basic Internet standards like TCP/IP and HTTP.
Yet the section on Interoperability in the OAuth 2.0 specification begins with a disclaimer:
OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.
In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
In other words, adhering to the specification may be a good starting point, but when the developers of two applications want to integrate with each other, they still have to agree on a specific approach to applying OAuth. Nailing down those details is to be the subject of future work by the specification’s authors.
Recognizing de facto standards
A de facto standard is one that exists in practice, because it is commonly treated as a standard regardless of what any committee may say.
The Facebook platform for developers is not a standard the way OAuth is (although it actually incorporates OAuth). Instead, the platform — also known as Facebook’s Open Graph — is simply the way Facebook does things and defines some of the things developers will have to do, too, if they want to give their apps access to the social network’s more than 1 billion active users.
Because Facebook has done so much to influence expectations about what a social network should be, enterprise social networking players, including Yammer and VMware’s Socialcast unit, have chosen to model their application integration frameworks more on Facebook than on standards more influenced by enterprise architects, such as OpenSocial.
The Open Graph Protocol is a component of the Facebook platform that looks a little more like an open source or web standards project, with its specifications available on a freestanding website (http://ogp.me). However, if you want to participate in discussions about the future of the specification, you have to do so in a Facebook Group rather than an IETF mailing list.
The Open Graph Protocol defines a series of metadata specifications for web pages and applications defining how they should be displayed on Facebook. Other social software can parse the same data to achieve a Facebook-like look.
Adobe created the PDF file format in 1993 without participation from any standards body, but because the associated Adobe Reader was freely available, PDFs became a standard for printable web documents and e-books. Eventually it became so pervasive that in 2005, PDF/A got the blessing of the International Standards Organization as a de jure standard.
HTML started out as a de facto standard, as did many browser-specific extensions of HTML that eventually became standardized. However, for many years, creating web applications that would display and function properly in multiple browsers was extremely painful. Only recently did web standards advocates make their voices heard loudly enough to get the browser makers to play nice.
The same could prove to be true of social networking standards.
Leveraging Common Social Web Standards
The road to standards nirvana may be rocky, but it’s not impassible. Social applications can take advantage of all the web and web services technologies that have evolved over the last couple of decades.
The following are all basic web development technologies that aren’t specific to social collaboration but are important elements of social application development and integration:
REST: Representational State Transfer (REST) is not so much a standard as it is a style of interaction between web-based applications, using a short list of standard HTTP request methods — GET, POST, PUT, and DELETE — to interact with any remote resource. The virtue of this is loose coupling, as opposed to the kind of integration that requires applications to have intimate knowledge of each other. That makes REST a good match for building and integrating web and cloud applications.
JavaScript: This rich scripting language for manipulating data and the display of data in the browser has evolved over time to include methods for asynchronously sending and retrieving data in the background, without requiring the user to download a new web page.
XML and JSON: These data exchange formats were derived from HTML and JavaScript, respectively. XML (eXtensible Markup Language) is a method of encoding data wrapped in HTML–like tags that specify meaning and context, rather than formatting. JSON (JavaScript Object Notation) is a method of serializing all the data associated with a JavaScript object into a text format that can be transmitted over the network. When a browser-based application written in JavaScript downloads data in JSON format, serialized objects can be reconstituted instantly without the parsing that would be required for the same data transmitted in XML.
These things can be used together. A web application may include an interactive JavaScript application that runs in the user’s browser, uses REST-style communication with a server-side web application, downloads data in JSON format, and uses that data to update what the user sees onscreen. This would be one way to build a web-based interactive chat application, for example.
In addition, there are several web technologies that are particularly relevant to social networks — OAuth, Activity Stream, HTML iframes, JavaScript APIs, and Open Graph — and I cover them in the following sections.
Authorizing social app access with OAuth
If you ever accessed a Facebook application that asked you to review a list of permissions that the application is requesting and then click OK, you have seen OAuth in action.
OAuth outlines a method for giving one application access to another, with the user’s permission. In particular, the user is giving access to something private, such as an e-mail address, affinities reflected in a social profile (things Liked, groups joined), or a collection of photos.
Say you want to provide a printing company access to your photos on Facebook or another photo-sharing site to print a custom calendar with your kid’s pictures.
The process goes like this:
1. Authorization is requested.
The client application requests access to a protected resource. In my example, the client application is the printing service, and the protected resource is the photos on Facebook.
2. The authorization grant is returned to the client for approval.
The user (you) grants access. This process is mediated by the social networking platform, which you presumably trust, in the form of a user interface that makes clear what rights you are granting. If you say no, the process stops.
3. The authorization grant is relayed to the authorization server.
The client application presents the authorization grant as proof that it should be provided with an access token, which is a key that it will be able to use to access the protected resource.
4. The access token is returned to the client.
The social networking server in charge of protecting your identity verifies that the digital credential presented as proof of authorization is legitimate and then returns an access token.
5. The access token is sent to the resource server.
The server in charge of the protected resource (your photos) receives an access token (the key) along with a specific access request.
6. The resource is returned to the client application.
First, the resource server validates the access key. If it checks out, the print shop app gets access to your photos.
After going through the process once, the client application can continue to use the key you have given it to unlock the server containing your protected resource. By granting access, you’re saying that you trust this application to act on your behalf and not against your interests.
Here’s another simple example: If you give an online magazine access to your social profile so it can show you more of the articles that you tend to like, it will be able to continue to access the most current version of your profile on subsequent visits.
Access tokens can be set to expire and can be revoked, however. When you remove an application from your profile, you’re telling the social platform that access token should no longer be honored.
Much debate remains as to whether OAuth strikes the right balance between security and ease of use. When representatives of enterprise IT organizations and their vendors got involved in defining OAuth 2.0, some web purists complained that the specification was becoming unnecessarily complex. On the other hand, OAuth 2.0 was designed to be easier to implement than the previous version, and some security advocates worried it may become too easy to hack in the process.
OAuth may not be perfect, but it has been widely adopted as a way of sharing profile data and other protected resources between applications.
Standardizing feeds with ActivityStrea.ms
Just as the RSS and Atom data formats make it possible to syndicate and aggregate blog posts and news stories, the Activity Streams format is intended to enable the syndication and aggregation of social posts, comments, and related data.
Although the term "activity stream" is also used much more generically to refer to the user interface style of social news feeds, I'm specifically referring here to an open web specification (http://activitystrea.ms). In conversation, software developers and architects sometimes pronounce the "dot-ms" part to make the distinction clear (like saying "Amazon.com" to make it clear you mean the online retailer, not the river).
Unlike a feed of headlines, an Activity Streams feed is meant to be much richer, with room to specify that one item was in reply to another, or to include references to embedded applications that should be displayed within the stream. The core specification includes a base schema plus two alternative data format specifications: one based on JSON and the other on Atom.
The most common use I have seen so far is in specialized collaboration applications that integrate with a broader social platform such as Jive, IBM Connections, or Atlassian Confluence. The embedded app can provide its own social commenting function but also provide a feed that appears in the parent platform’s activity stream (by which, in this case, I mean the social news feed).
Embedding apps in HTML iframes
The easiest way of embedding one web application inside another, without needing to do much to wire them together, is with an HTML iframe. This is a way of inserting an entire application into a new context. You may use an iframe to embed a business application such as expense approval into a social platform, or, alternatively, to embed social commenting functionality into an expense record.
Before exploring more complicated scenarios, I explain how an iframe works on an ordinary HTML web page. Embedding an iframe in a web page is just about as easy as embedding an image.
Just look at the similarity between an image tag
<img src="http://mysite.com/myimage.jpg" height="600" width="600">
and an iframe tag
<iframe src="http://mysite.com/myapp.php" height="600" width="600">
Either one gives you a 600 x 600 pixel region in the middle of the page filled by content from the specified source web address. In the first example, the embedded content is an image, but in the second example, the iframe can contain a complete web application with its own styling and scripts.
If you stop here, you have a convenient way of displaying embedded content. However, the embedded application knows nothing about the context in which it’s running. And that’s where JavaScript APIs come in.
Setting social context with JavaScript APIs
To function like an integrated part of the social network, an embedded application needs to know who is accessing it and in what context.
An application embedded in an iframe is said to be running within a container, where the container is the master application containing the iframe pointing to the embedded app. For a Facebook app, the container would be Facebook. For an app from the Jive Apps Market, the container would be your organization’s instance of Jive.
The embedded app needs to talk to the container to access the user’s social profile. This is usually accomplished through JavaScript APIs (application programming interfaces) that request resources from the container, which in turn kicks off the OAuth workflow.
Charting Facebook’s Open Graph
While the Facebook platform is limited to Facebook, enterprise social network players such as Yammer have modeled their own approaches to embedding and connecting applications on Facebook’s approach. For example, Yammer defined its own version of Open Graph for functions like using an embedded app for document management, provided by an external cloud service, and publishing “stories” about those interactions to the Yammer stream.
The Facebook platform is constantly evolving. As of this writing, it includes the elements discussed here and more:
The Open Graph Protocol: A metadata standard for documenting how you would like a web resource to be displayed on Facebook. For example, if a product page on your website includes the correct Open Graph tagging, when a Facebook user shares a link to that page it will be displayed with the product image, title, and other data you specified. You can include a reference to a video demonstrating the use of your product, allowing Facebook to display it in an inline video player.
A set of APIs: A documented series of mechanisms for requesting services from the platform, particularly on behalf of the user. This includes the Facebook implementation of OAuth and protocols for registering Likes and other actions.
The Facebook JavaScript library: A standard starting point for developers to access Facebook platform services and display standard widgets.
Facebook plug-ins: Simplified access to common Facebook widgets, such as the Like button or a Facebook comments feed, using code snippets that can be copied and pasted into any HTML page.
App embedding with iframes: Using the tool available at https://developers.facebook.com/apps, any web developer can register a Facebook app or Facebook tab (an app associated with a Facebook page) by giving it a name and filling out the form provided. After you plug in the web addresses of the external program that will render the user interface, Facebook displays that resource within an iframe. It's then up to the developer to use JavaScript and OAuth to get the user's social context and do something interesting with it. For example, a music app may provide a way to share favorite songs with friends, or a news reading app (like the Washington Post Social Reader) may make it easy to share articles with friends.
The Facebook platform supports both application embedding within Facebook and the ability for external websites and applications to embed Facebook functionality.
Yammer and Socialcast mimic the Facebook style of application integration, but with an emphasis on business content and applications rather than social entertainment apps.
OpenSocial: Providing an Enterprise Standard for App Embedding
OpenSocial is "the industry's leading and most mature standards-based component model for cloud based social apps," according to the website of the OpenSocial Foundation (http://opensocial.org). While support for OpenSocial isn't universal (Yammer is a notable holdout), it has the backing of Jive, IBM, Atlassian, and others.
This is the enterprise-friendly version of something like the Facebook platform, providing a framework for embedding social applications inside each other and allowing them to communicate with each other. OpenSocial aims to make it easier for developers to make social software applications work together, or to bring business application functionality into a social context. OpenSocial can be used to embed application user interface widgets into the activity stream, a sidebar, or a separate tab of the collaboration software’s user interface. The goal is to let users perform a greater variety of tasks without leaving the social collaboration platform.
With the release of OpenSocial 2.0 in August 2011, enterprise computing interests like IBM and Jive Software revived what was originally intended to be a social computing standard for public websites. OpenSocial strives to incorporate other popular web standards, such as OAuth and Activity Streams, while adding its own framework for how those standards should be combined and how a social container should behave. To keep the specification from becoming too abstract, OpenSocial is supported by a parallel open source software effort: namely, the Apache Shindig project (http://shindig.apache.org).
Compared with some other concepts for web application integration, such as Java portlets, OpenSocial also has the advantage of being relatively lightweight. Applications don’t have to be written in the same language or run on the same operating system. A PHP application can plug itself into a Java-based container just by serving up the right HTML and JavaScript code.
OpenSocial has also been enhanced to support embedded experiences, which allow users to access applications right from within the social stream. IBM sponsored the creation of an OpenSocial MIME type as part of the embedded experiences for the standard, making it possible to also embed OpenSocial apps in e-mail messages.
MIME — Multipurpose Internet Mail Extensions — is the protocol used by both e-mail clients and web browsers to render embedded multimedia content and file attachments for e-mail.
The most recent version of the Notes mail client takes advantage of this capability when used in combination with the IBM Connections enterprise social network.
An example of a business application delivered as an embedded experience is a vacation approval request that arrives in the activity stream of an employee’s manager. Rather than clicking a link and being redirected to another web application, the manager can immediately approve or reject the request by using an embedded widget displayed within the stream or within a sidebar. When the request is approved, the employee gets confirmation in his own social stream and can reply with a quick Thank You!
As implemented on the Jive Software platform, adding an application widget to a stream is as easy as typing an exclamation point. Just like how most social platforms display a pop-up list of potential matches when you type @ followed by the first few characters of the name or username of a person you want to reference, Jive does the same thing when you type ! followed by the name of an application.
As a Jive user creating a discussion post or document, I can use this technique with a sample app that helps me give recognition to another employee. As soon as I type the exclamation point, I get the prompt shown in Figure 11-1 with the available options.
After I select the app I want to use, a compact rendition of its user interface is overlaid on the blog editor screen, as shown in Figure 11-2.
Figure 11-1: Jive’s exclamation point access to apps.
Figure 11-2: An embedded app in Jive.
In this case, I chose the Props app, which allows me to choose a virtual trophy to award to another employee. Working with the embedded app, I can add a message about why my colleague is so wonderful. The output of the app gets embedded in my blog post, where I can write about his contributions, but the Props item also gets posted separately to the company activity stream and added to this employee’s profile.
Using the same approach, I can access a flowchart or other diagram created in Lucidchart, or create a new one, and insert it into my document. The Jive Apps Market features a variety of embeddable apps for applications like task management and customer relationship management. IBM is promoting similar apps partnerships. SugarCRM co-founder and CTO Clint Oram recently joined the OpenSocial board to represent the interests of app creators. In some scenarios, the SugarCRM platform also can function as an OpenSocial container.
Atlassian, maker of the Confluence social software platform and JIRA issue-tracking tool, also has a representative on the board. Other social software vendors support OpenSocial, but with varying degrees of enthusiasm.
Calculating the Odds for the Future of Social Software Standards
OpenSocial shows great potential as an application integration framework for social collaboration. However, I keep watching and waiting for the day when it catches fire in the software market. Some of the smaller vendors support OpenSocial just to get access to a channel like the Jive Apps Market, but it’s not clear that they can win a lot of business that way.
Meanwhile, Yammer’s view is that the best Web 2.0 applications provide rich user experiences that don’t fit neatly into an iframe. The Yammer software architects argue it’s better to provide integration that reaches out from Yammer to connect with those other websites and applications and embeds inside them, while allowing them to pump updates into the Yammer news feed.
The biggest sign that OpenSocial may matter in the long run is that some enterprise buyers are starting to add it to their lists of requirements. For example, Ford Motor Company has some success stories to tell about its use of Yammer, but Ford IT architect Ed Krebs told me he has his doubts about it as a long-term solution. As a member of an advanced technologies group at Ford, he has been running experiments on Shindig and sees the potential of the technology that Yammer is snubbing. He is also working with a W3C (World Wide Web Consortium) business community group on social software and sees OpenSocial as more aligned with that standards-setting process.
Here are a few things to look at when weighting these factors:
Are you concerned with embedding applications in your collaboration network? Or do you see it as a tool for communication and collaborative work that stands alone?
Do you see the potential for the integration requirement to increase as the collaboration network becomes more widely used?
Do you have legacy enterprise applications that could be revitalized by being wrapped in a social container? That’s something that can favor the OpenSocial approach.
Do you make significant use of applications that support either of these approaches, or some other web application framework?