OpenSocial

Vor drei Jahren, genauer am 01. November 2007, hat Google OpenSocial veröffentlich. Viel Zeit und jede Menge Entwicklungsarbeit ist seitdem vergangen. Ein idealer Zeitpunkt also, um sich wieder etwas mit OpenSocial zu beschäftigen. In diesem Blog erfahren wir, wo OpenSocial heute steht und wie es funktioniert (englischen Artikel lesen).

OpenSocial?

Das Internet ist besser, wenn es sozial ist. Unter diesem Motto hat Google OpenSocial ins Leben gerufen. Doch was ist OpenSocial überhaupt und was soll sozial, also miteinander verbunden werden? OpenSocial ist im Grunde eine Spezifikation für eine standardisierte Schnittstelle für soziale Netzwerke. Diese Schnittstelle stellt die für soziale Netzwerke typischen Daten wie Personendaten, Beziehungsinformationen sowie Aktivitäten zur Verfügung. Der Zugriff auf diese Daten erfolgt lesend als auch schreibend. Ein Entwickler, der nun eine Anwendung für ein oder mehrere soziale Netzwerke schreiben möchte, kann dies mit Hilfe von OpenSocial über eine einzige Schnittstelle tun. Dies setzt allerdings voraus, dass das soziale Netzwerk OpenSocial als Schnittstelle implementiert hat. Aktuell implementieren fast vierzig verschiedene Netzwerke OpenSocial. Die Bekanntesten Plattformen sind MySpace, XING sowie die VZ-Netzwerke. Das Ziel von OpenSocial ist, einen einheitlichen Zugriff auf soziale Netzwerke zu ermöglichen. Die verschiedenen proprietären Schnittstellen sozialer Netzwerke sollen langfristig mit OpenSocial ersetzt werden. So gesehen wird das soziale Internet aus Sicht der Entwickler und Nutzer tatsächlich besser: Die Entwickler müssen sich nur noch in eine Schnittstelle einarbeiten und der Nutzer kann eine Anwendung in verschieden sozialen Netzwerken nutzen.

Wie funktioniert’s?

OpenSocial kann sowohl clientseitig als auch serverseitig eingesetzt werden. Clientseitige OpenSocial-Anwendungen basieren auf der gleichen Technologie wie die von iGoogle bekannten Google Gadgets. Mit Hilfe von XML, HTML, JavaScript, CSS und Flash werden diese sogenannten OpenSocial Gadgets erstellt. XML dient hierbei als eine Art Container und enthält neben Meta-Informationen über das Gadget alle nötigen Daten der Anwendung (Logik und Benutzeroberfläche). Der Zugriff auf die Daten der Nutzer eines soziales Netzwerks erfolgt über die OpenSocial JavaScript API. Ein vereinfachter Zugriff ohne tiefgehende Kenntnisse über JavaScript wird mit OpenSocial Templates ermöglicht. Serverseitig kommt die OpenSocial REST API

zum Einsatz. Mit ihr können nicht nur Clients wie mobile Anwendungen, sondern auch andere Server auf die Daten eines sozialen Netzwerks zugreifen. Somit können beispielsweise soziale Netzwerke untereinander Daten austauschen. Der Austausch der Daten erfolgt dabei keineswegs unkontrolliert, sondern wird mit der API-Autorisierung OAuth abgesichert. Ein großer Vorteil der REST API ist, dass man im Gegensatz zur clientseitigen Nutzung von OpenSocial nicht auf bestimmte Programmier- oder Scriptsprachen wie JavaScript angewiesen ist. Dank der aktiven Entwicklergemeinde gibt es mittlerweile Client Libraries für die verschiedensten Sprachen. Damit die OpenSocial-Anwendung ausgeführt werden kann, ist eine Sandbox nötig. In dieser Laufzeitumgebung wird die Anwendung gerendert und bekommt alle zur Ausführung nötigen Ressourcen zur Verfügung gestellt. OpenSocial bezeichnet diese Laufzeitumgebung als Container, wobei Container auch als Übergriff für die client- und serverseitigen Schnittstellen zu verstehen ist. Somit ist jedes soziale Netzwerk, dass OpenSocial implementiert, ein Container. Natürlich ist es auch möglich, einen eigenen Container zur Verfügung zu stellen. Entweder, man implementiert mit Hilfe der OpenSocial Spezifikation seine eigene Schnittstellen und testet sie gegen die Compliance Tests oder man nutzt Apache Shindig, der die nötigen Schnittstellen zur Installation auf dem eigenen Webserver bereitstellt. Laut Aussage der Entwickler von Apache Shindig soll die Installation innerhalb einer Stunde erledigt sein – also durchaus eine Alternative zur Entwicklung eigener Schnittstellen.

Was genau macht Apache Shindig?

Wie bereits erwähnt ist eine Webseite, die die Funktionalität von OpenSocial implementiert, ein Container. Apache Shindig ist ein wahlweise auf PHP oder Java basierender Webservice, der die von OpenSocial geforderten Funktionalitäten zur Verfügung stellt. Somit ist Apache Shindig ebenfalls ein OpenSocial Container, der mit wenigen Handgriffen auf dem eigenen Webserver installiert werden kann. Dieser Container implementiert vollständig die OpenSocial REST API sowie die zur Ausführung von OpenSocial Gadgets nötige Sandbox inklusive OpenSocial JavaScript API. Die Sandbox selbst ist im Prinzip nichts anderes als ein Inlineframe. Dieses Frame referenziert auf den zuvor installierten Webservice von Apache Shindig, dem wiederum als Parameter die URL zum XML mit den Gadget-Informationen übergeben wird. Dieses XML wird dann vom Webservice geparst und das OpenSocial Gadget letztendlich innerhalb des Inlineframes angezeigt. Man muss also nicht mehr machen, als eine URL anzugeben. Um den Rest kümmert sich Apache Shindig. Gerade zum Entwicklen und Testen von OpenSocial Gadgets sollte Apache Shindig verwendet werden. Zwar werden von den sozialen Netzwerken entsprechende Sandboxes für Entwickler angeboten, doch ist deren Nutzung mit allerlei Schikanen gespickt. Zum Beispiel dürfen nur XML-Dateien mit vollständigen Informationen über den Urheber hochgeladen werden, die Sandboxes sind nicht erreichbar oder man muss sich gar als Entwickler bewerben. Solche Einschränkungen gibt es bei Apache Shindig nicht. Dessen Benutzung ist daher definitiv bequemer, stressfreier und nur zu empfehlen.

Wo ist unser „Hallo Welt“?

OpenSocial unterscheidet drei verschiedene Anwendungstypen, die mit den gegebenen Schnittstellen realisiert werden können. Der einfachste Anwendungsfall stellt das Social Mashup dar. Dieser Anwendungstyp nutzt lediglich die clientseitigen Schnittstellen von OpenSocial und wird innerhalb eines Containers ausgeführt – oder einfach gesagt innerhalb des oben beschriebenen Inlineframes. Dadurch skaliert sie extrem gut, ist aber komplett auf den Container limitiert, was zu Einschränkungen beim Speichern und Verarbeiten von Daten führen kann. Um diese Einschränkungen aufzuheben, kann auch eine Social Application entwickelt werden. Sie funktioniert genau wie das Social Mashup, nutzt aber Dienste externer dritter Server. Das ist prinzipiell nicht schlecht, kann aber zu Peformanceproblemen führen, sobald die Anwendung stark genutzt wird und es somit zu vielen Zugriffen auf den externen Servern kommt. Der letzte Anwendungstyp ist die Social Website/Social Mobile Application. Diese Anwendung läuft nicht innerhalb eines Containers, sondern ist ein eigener Webservice (beispielsweise eine Webseite) oder eine Anwendung auf einem mobilen Endgerät. Sie nutzt mit Hilfe der OpenSocial REST API und OAuth lediglich die Daten sozialer Netzwerke. Man stellt also fest, dass die erste eigene OpenSocial-Anwendung nicht gerade in fünf Minuten entwickelt sein wird, da man sich erst entscheiden muss, welchen Anwendungstyp man nun realisieren möchte. Zwar bietet OpenSocial entsprechende Artikel zur Erstellung von Social Mashup, Social Application und Social Webseite/Social Mobile Application an. Doch diese sind sehr Umfangreich gestaltet und für jemanden, der nur wissen will, wie OpenSocial ungefähr funktioniert beziehungsweise wissen möchte, wie ein OpenSocial Gadget aussieht, eher ungeeignet. Daher habe ich ein kleines Hello World! Social Mashup erstellt, dass diese Aufgabe übernehmen soll:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs title="Hello World!"></ModulePrefs>
  <Content type="html">
    <![CDATA[
      <script type="text/os-data" xmlns:os="http://ns.opensocial.org/2008/markup">
        <os:ViewerRequest key="viewer" fields="displayName" />
      </script>
      <script type="text/os-template">
        Hello World! Your name is ${viewer.displayName}!
      </script>
    ]]>
  </Content>
</Module>

Dieses Social Mashup macht zwar nicht viel, aber das dafür richtig gut. Es zeigt lediglich den Namen des Benutzers an, der es gerade ausführt. Übergibt man das XML wie oben beschrieben Apache Shindig, wird innerhalb des Inlineframes Hello World! Your name is Shin Digg! angezeigt. Zum Auslesen des Benutzernamens wird OpenSocial Templates verwendet. Wer mehr über die Erstellung von OpenSocial Gadgets erfahren möchte, sollte sich in die oben verlinkten Tutoriale einarbeiten.

Wo ist der Haken? Eine einheitliche Schnittstelle für soziale Netzwerke hört sich im ersten Moment toll an. Aber auch mit OpenSocial gibt es Einschränkungen. OpenSocial ist in erster Linie eine Spezifikation. Wie diese von den sozialen Netzwerken umgesetzt wird, wird nicht direkt kontrolliert. Somit ergeben sich beispielsweise Unterschiede in der Implementierung der OpenSocial API. Oder es gibt Unterschiede bei den Zugriffsrechten auf die Daten der Nutzer eines sozialen Netzwerks. Im schlimmsten Fall kann es also sein, dass die eigene Anwendung im Netzwerk A funktioniert, im Netzwerk B nur teilweise und im Netzwerk C gar nicht. Teilweise gibt es Lösungsansätze zu den Einschränkungen, aber eigentlich möchte man mit OpenSocial solchen Abhängigkeiten aus dem Weg gehen. Zumindest ist dies der Grundgedanke dieses Projekts. Dem aufmerksamen Leser dürfte auch nicht entgangen sein, dass Facebook, das mit über 500 Millionen Benutzern vermutlich größte soziale Netzwerk, bei den oben genannten Plattformen, die OpenSocial unterstützen, nicht auftaucht. Der Grund hierfür ist recht banal:

Facebook ist nicht auf den OpenSocial-Zug mit aufgesprungen und hat stattdessen mit OpenGraph eine eigene offene Schnittstelle für soziale Netzwerke ins Leben gerufen. Somit steht Facebooks OpenGraph in direkter Konkurenz zu Googles OpenSocial und vermutlich wird es zukünftig keinen Container für Facebook geben. Zumindest nicht offiziell. Denn es sollte theoretisch möglich sein, als Drittanbieter einen Container zur Verfügung zu stellen, der die Schnittstellen von OpenGraph anbindet. Das ist sicherlich nicht ganz einfach. Doch die Dokumentation von OpenSocial ist gut, vor allem sehr  umfangreich und es gibt eine sehr aktive Entwicklergemeinde. Vielleicht hat ja dieser Blog bei jemanden das Interesse geweckt, der zurzeit auf der Suche nach einem kleinen Privatprojekt ist…