Open Social
OpenSocial definiert eine Menge von Programmierschnittstellen für Anwendungen von Drittanbietern im Kontext sozialer Netzwerke. Unter der Verwendung von Standardtechnologien wie HTML und JavaScript können Entwickler interoperable Anwendungen erstellen, die auf den sozialen Graphen des jeweiligen Netzwerks zugreifen.
Soziale Netzwerke wie Facebook oder XING stellen eine Form von Netzgemeinschaften dar, welche technisch durch eine den sozialen Graphen abbildende Netzwerk-Software realisiert werden [2]. Dem einzelnen Mitglied ermöglicht diese primär die Pflege eines persönlichen Profils mit Sichtbarkeitseinstellungen für die übrigen Nutzer sowie die Verwaltung von Beziehungen zu anderen Mitgliedern der Netzgemeinschaft (z. B. zu Freunden, Kollegen oder Geschäftskontakten). Darüber hinaus bietet die Netzwerk-Software in der Regel Funktionen für den Empfang und Versand von Plattform-Nachrichten sowie sogenannte Update- Feeds, welche den Nutzer über Aktivitäten seiner Kontakte innerhalb des Netzwerks informieren. Social Networking und offene Schnittstellen stellen zwei für das Web 2.0 charakteristische Trends dar [8], welche sich in den vergangenen Jahren weitgehend unabhängig voneinander entwickelt haben. Mit OpenSocial liegt ein Standard vor, der beide Bereiche zusammenbringt, indem er eine API zur Entwicklung sogenannter Social Applications definiert, die über verschiedene Networking-Plattformen hinweg interoperabel sind. Die Netzwerk-Software, in deren Kontext eine solche Anwendung ausgeführt wird, wird entsprechend des Standards als Container bezeichnet. Über die OpenSocial-API ermöglicht der Container seinen Anwendungen den Zugriff auf Profil- und Kontaktdaten sowie eventuelle Nachrichtensysteme und Update-Feeds.
Im Gegensatz zu Anwendungen, die für proprietäre Umgebungen wie z. B. die Facebook-Platform [5] geschrieben wurden, sind OpenSocial- Anwendungen im Kontext unterschiedlicher Netzwerke interoperabel. Aus Perspektive des Anwendungsentwicklers ermöglicht der Standard somit eine Erhöhung der Reichweite, da Anwendungen einmalig entwickelt und dann innerhalb eines beliebigen Containers positioniert werden können, der den Standard unterstützt. Für die Betreiber von Social-Networking-Plattformen wiederum ergibt sich die Chance, die eigene Funktionalität durch eine Vielzahl von Drittanbieter-Anwendungen zu erweitern, ohne dabei die Hoheit über die eigenen Nutzerdaten aus der Hand zu geben.
Der Standard wurde zu Beginn insbesondere von Google vorangetrieben. Zum Zeitpunkt seiner Veröffentlichung im November 2007 war er allerdings noch nicht für den Produktiveinsatz geeignet, da insbesondere hinsichtlich Benutzerschnittstelle und Sicherheit noch gravierende Mängel vorhanden waren [10]. Mittlerweile wird die Spezifikation von der gemeinnützigen OpenSocial Foundation [9] weiterentwickelt und hat einen weitgehend stabilen und für den kommerziellen Einsatz hinreichenden Stand erreicht. Im Februar 2009 nutzten etwa 20 große Social-Networking-Plattformen (u. a. MySpace, hi5 und orkut) den OpenSocial-Standard, um ihren Nutzern Social Applications zur Verfügung zu stellen [4].
Social Applications
Social Applications basieren auf der von Google entwickelten Gadget-Architektur, welche um Schnittstellen erweitert wurde, die den Zugriff auf die sozialen Daten des Containers ermöglichen. Gadgets sind XML-Dokumente, die neben einer Reihe von Metadaten vor allem HTML- und JavaScript-Code enthalten. Die XML-Spezifikation eines Gadgets wird vom Container gerendert und in das eigene Webangebot integriert. Die Kommunikation zwischen Gadget und Container erfolgt hierbei über standardisierte Ajax-Requests [6], welche in den OpenSocial Javascript-API-Namensräumen opensocial.* und gadgets.* definiert sind.
Aus Perspektive des Nutzers geht mit der erstmaligen Nutzung einer Social Application meist eine Art Installationsprozess einher, in welchem der Nutzer der Anwendung explizit erlaubt, auf das eigene Nutzerprofil zuzugreifen. Nachdem das Gadget dem Nutzerkonto hinzugefügt wurde, kann der Nutzer mit dieseminteragieren. Container können mehrere Orte unterstützen, an denen dies der Fall ist. Formal werden diese Orte als Views bezeichnet und sind in der Klasse gadgets.views.ViewType spezifiziert. Ein Gadget kann über die API ermitteln, welche Views vom Container unterstützt werden und in welcher View es selbst gerade gerendert wird.
Profile View: Das Gadget wird mit weiteren Gadgets als Teil des Nutzerprofils gerendert. Dies ergibt insbesondere dann Sinn, wenn der Nutzer innerhalb der Anwendung Inhalte generiert hat, die er anderen Nutzern in seinem eigenen Profil präsentieren möchte.
Canvas View: Hier wird das Gadget in einer Vollansicht alleine angezeigt. Die Canvas View ist dementsprechend der zentrale Ort, an dem der Nutzer mit der Anwendung interagiert und Inhalte erzeugt.
Home View: Das Gadget wird auf der Startseite des Containers gerendert. Auch in dieser Ansicht werden meist mehrere Gadgets nebeneinander gerendert, welche dem Nutzer einen Überblick über Neuigkeiten imeigenen Informationsraum geben.
Oft entstehen im Rahmen der Nutzerinteraktion Daten, die persistent gespeichert werden müssen. OpenSocial spezifiziert daher eine Persistenzschicht, die es dem Entwickler erlaubt, pro Anwendung bzw. pro Anwendung und Nutzer einfache Schlüssel/Wert-Paare abzuspeichern. Die tatsächliche Implementierung dieser Persistenzschicht ist Aufgabe des Containers und bleibt dem Entwickler verborgen. Anfragen an den Container werden mittels der Klasse opensocial.DataRequest gestellt, die nebenMethoden zur Bereitstellung der Persistenzschicht auch Methoden für den Zugriff auf Personen und Beziehungen sowie Aktivitäten und Nachrichten bereitstellt.
Personen und Beziehungen
Die OpenSocial-API ermöglicht einen direkten Zugriff auf den sozialen Graphen des Containers, wobei einzelne Knoten des Graphen durch die Klasse opensocial.Person repräsentiert werden. Die Klasse unterstützt mehr als Felder, die innerhalb der Nutzerprofile sozialer Netzwerke Verwendung finden. Die Mehrzahl dieser Felder ist optional, sodass der Container letztendlich entscheidet, welche Profildaten er seinen Anwendungen anbietet. Mit dem VIEWER und dem OWNER sind zwei Instanzen der Klasse opensocial.Person direkt verfügbar. Bei Ersterem handelt es sich um den aktuellen Nutzer bzw. Betrachter der Anwendung, Letzterer ist derjenige Nutzer, in dessen Kontext die Anwendung ausgeführt wird. So handelt es sich bei VIEWER und OWNER um die gleiche Person, wenn ein Gadget in der Home oder Canvas View gerendert wird. Für den Fall der Profile View kann es sich jedoch um verschiedene Personen handeln, wenn der VIEWER die Anwendung im Kontext des Nutzerprofils des OWNER betrachtet.
Das zentrale Merkmal von Netzwerk-Software ist die Unterstützung des Aufbaus zielgerichteter Beziehungen [2]. Social Applications müssen auf ebendiese zugreifen, um den Informationsaustausch und die Interaktion zwischen Personen zu unterstützen. OpenSocial gewährleistet dies durch die Konzepte VIEWER_FRIENDS und OWNER_FRIENDS. Diese Mengen unterscheiden sich voneinander, wenn eine Person das Profil einer anderen Person betrachtet, sind häufig jedoch nicht-disjunkt, sodass der VIEWER in den Kontakten des OWNER auch eigene Kontakte wiederfindet.
Aktivitäten und Nachrichten
Aktuelle Networking-Plattformen bieten in der Regel Update-Feeds, die den Nutzer über Aktivitäten seiner Kontakte informieren (z. B. „Neues aus meinem Netzwerk“ bei XING). So erfährt der Nutzer beispielsweise,wer seine Firma oder Position gewechselt hat, wer mit wem in Kontakt getreten oder einer Gruppe beigetreten ist. OpenSocial bildet Aktivitäten mit der Klasse opensocial.Activity ab und bietet Social Applications die Möglichkeit, im Update-Feed des Containers auf sich aufmerksam zu machen, um auf dieseWeise organisch zu wachsen. Eine Aktivität kann dabei einerseits eine Interaktion des Nutzersmit dem Container abbilden (z. B. Installation eines Gadgets oder Hinzufügen des Gadgets zur eigenen Profilseite). Anderseits kann eine Aktivität aber auch die Interaktion des Nutzersmit dem Gadget selbst repräsentieren (z. B. Upload einer Datei in einem Kollaborationstool oder Erzielen eines neuen Highscores in einem Spiel). Container implementieren das Aktivitätskonzept dabei in der Regel so, dass der Nutzer jederzeit selbst entscheiden kann, ob er einem Gadget das Senden von Aktivitäten an sein Kontaktnetzwerk erlaubt. Um zu vermeiden, dass Nutzer in ihren Update-Feeds eine große Anzahl von gleichen oder ähnlichen Aktivitäten zu sehen bekommen, lassen sich Aktivitäten entsprechend des OpenSocial- Standards mithilfe von Activity Templates aggregieren, in denen der Entwickler allgemeine Ereignisse mit Platzhaltern für anwendungs- und nutzerspezifische Daten definiert. Diese Trennung von Inhalt und Präsentation erlaubt es dem Container, konsolidierte Bündel von Aktivitäten anzuzeigen und so die Übersichtlichkeit des Update- Feeds zu garantieren. Die letztendliche Darstellung und Auslieferung einer jeden Aktivität bleibt dabei dem Container vorbehalten.
Eine über das Aktivitätskonzept hinausgehende Möglichkeit, andere Nutzer der Networking-Plattform mit anwendungsspezifischen Informationen zu versorgen, ist das Versenden von Nachrichten. Abgebildet durch die Klasse opensocial.Message können Social Applications dem Container verschiedene Arten von Nachrichten zuspielen. Auch hier entscheidet allein der Container, ob und wie diese dem Empfänger präsentiert werden (z. B. als E-Mail oder Plattform-Nachricht). Um die Privatsphäre des Nutzers zu schützen, legen Container die Entscheidung, ob ein Gadget überhaupt Nachrichten an andere Nutzer versenden darf, meist ebenfalls in die Hand des Nutzers.
Internationalisierung
Social Applications können in ihrer XML-Spezifikation Sprachmodule (sogenannte Message Bundles) definieren und so beliebig viele Sprachen unterstützen. Hierzu wird das Gadget so strukturiert, dass alle Textressourcen für Benutzeroberfläche, Nachrichten und Aktivitäten für verschiedene Sprachen in verschiedenen Message Bundles ausgelagert sind. Festgelegt wird dabei auch, welche Sprache verwendet werden soll, wenn für die vom Container angeforderte Sprache kein Sprachmodul vorhanden ist. Sprachmodule sind separate XML-Dokumente, deren Namen sowohl die Benutzeroberflächensprache als auch einen Zielmarkt spezifizieren (z. B. en_UK.xml, en_US.xml, de_ALL.xml).
Backend-Server
Social Applications kommunizieren häufig mit Backend-Servern, welche z. B. externen Content bereitstellen, komplexere Berechnungen durchführen oder eine über die Persistenzschicht des Containers hinausgehende Datenhaltung realisieren. Diese können unter Zuhilfenahme gängiger Web- Frameworks [3] implementiertwerden und heben so etwaige Limitationen auf, die aus der Beschränkung des Gadgets auf JavaScript und HTML resultieren. Um HTML-, JSON-, XML- und ATOM-Daten von entfernten Servern abzurufen, greift der Entwickler auf gadgets.io.makeRequest() zurück. Der Container fungiert dabei stets als Proxy, welcher laut Spezifikation zunächst eine Validierung der übergebenen Parameter vornehmen sollte und anschließend auf sichere Art und Weise den Backend-Server kontaktiert.
Um Servern, mobilen Endgeräten und Desktop- Computern einen Datenzugriff zu ermöglichen, der unabhängig von Ajax und einer direkten Nutzerinteraktion ist, enthält die OpenSocial-Spezifikation neben der JavaScript-API eine RESTful-API, die die Formate AtomPub, XML und JSON unterstützt. Anwendungen können diese analog zur JavaScript-API nutzen, um auf Personen, Beziehungen, Aktivitäten und Nachrichten des Containers zuzugreifen. Mittels standardisierter Authentifizierungsverfahren kann hierbei garantiert werden, dass nur autorisierte Nutzer auf die jeweiligen Daten zugreifen.
Eine Referenzimplementierung
Um den OpenSocial-Standard zu unterstützen, muss ein Container alle Methoden der OpenSocial JavaScript-API implementieren sowie der Gadgets- Spezifikation genügen. Mit Apache Shindig [1] liegt eine Referenzimplementierung des gesamten OpenSocial-Stacks vor, auf die die Betreiber von Social Networking-Plattformen zurückgreifen können. Shindig ist quelloffen und wird parallel in Java und PHP entwickelt. Der Datenaustausch zwischen Shindig und Netzwerk-Software erfolgt über das sogenannte OpenSocial Service Provider Interface (SPI), dessen Klassen so erweitert werden, dass sie auf das Backend der Netzwerk-Software zugreifen. Dabei muss das Backend nicht zwangsweise in Java oder PHP implementiert sein, sofern es eine geeignete API zur Verfügung stellt, die z. B. per HTTP angesprochen werden kann. Neben der Implementierung des Gadget Container JavaScript (für Sicherheit, Kommunikation und Benutzerschnittstelle) und des OpenSocial Container JavaScript (für Persistenz, Personen, Beziehungen, Aktivitäten und Nachrichten) umfasst Shindig einen Gadget-Server, der die XMLSpezifikation einer Social Application in JavaScriptund HTML-Code transformiert und per HTTP zur Verfügung stellt. Der entstehende Code wird in der Regel als in die Seitenbeschreibungen des Containers integriert. Eine weitere Komponente von Shindig ist der OpenSocial Gateway Server, welcher u. a. die RESTful-API implementiert. Die entstehende Architektur ist in der folgenden Abbildung visualisiert:
Fazit
OpenSocial kann als Wegbereiter eines Paradigmenwechsels betrachtet werden, an dessen Ende Social-Networking-Plattformen nicht länger in sich geschlossene Softwaresysteme sind, sondern vielmehr eine Laufzeitumgebung für SocialApplications darstellen, welche die Networking-Grundfunktionalität und die für den Anwendungsbetrieb notwendige standardisierte Infrastruktur zur Verfügung stellt. Mit der für Mitte 2009 geplanten Versionsnummer 0.9 bewegen sich die Spezifikation sowie ihre Referenzimplementierung Shindig auf einen stabilen Stand zu, an dem sich eine weiter zunehmende Anzahl von Containern orientieren wird [4]. DieMöglichkeit, Social Software zu entwickeln, welche nicht auf den Aufbau eines eigenen sozialen Graphen angewiesen ist, bietet eine Reihe von ökonomischen Chancen. So können beispielsweise Internetunternehmen ihre Reichweite immens erhöhen, indem sie ihr bereits bestehendes Produkt in Formeiner Social Application auf verschiedenen Networking-Plattformen positionieren. Relevant ist dies insbesondere für Gründungsunternehmen, die bei gleichzeitiger Ressourcenknappheit darauf angewiesen sind, mit einem flexiblen Produkt möglichst schnell eine breite Nutzerbasis zu erreichen [7]. Für Social-Networking-Plattformen wie XING bedeutet OpenSocial insbesondere, eine sichere Infrastruktur bereitzustellen, die ausschließlich autorisierten Parteien einen Zugriff auf zuvor sorgfältig ausgewählte Teile der OpenSocial-API ermöglicht. Dabei sollte es stets in den Händen des Nutzers liegen, welchen Parteien der Zugriff auf personenbezogene Daten gestattet ist.
Literatur
1. Apache Shindig. incubator.apache.org/shindig/ (Zugriff 19.02.2009)
2. Bächle M (2006) Social Software. Informatik-Spektrum 29:121–124
3. Bächle M, Kirchberg P (2007) Frameworks für das Web 2.0. Informatik-Spektrum 30:79–83
4. Containers – OpenSocial. wiki.opensocial.org/index.php (Zugriff 19.02.2009)
5. Facebook Developers. developers.facebook.com (Zugriff 19.02.2009)
6. Gebhardt M (2007) Ajax als Schlüsseltechnologie des Web 2.0 – Asynchrone Browser-Server-Kommunikation in der Net Economy. In: Kollmann T, Häsel M (Hrsg) Web 2.0 – Trends und Technologien im Kontext der Net Economy. DUV, Wiesbaden, S 121–141
7. Häsel M (2007) Softwareentwicklung in internetbasierten Gründungsunternehmen – Anforderungen an Produkte, Prozesse und Personal. Informatik-Spektrum 30:327–335
8. Kollmann T, Häsel M (2007) Trends und Technologien des Web 2.0 – Neue Chancen für die Net Economy. In: Kollmann T, Häsel M (Hrsg) Web 2.0 – Trends und Technologien im Kontext der Net Economy. DUV, Wiesbaden, S 1–14
9. OpenSocial Foundation. www.opensocial.org (Zugriff 19.02.2009)
10. OpenSocial Still „Not Open for Business“. www.techcrunch.com/2007/12/06/ opensocial-still-not-open-for-business/ (Zugriff 19.02.2009)