[toc] Das CommuntiyMashup ist eine Integrationslösung für Daten aus sozialen Diensten. Es vereinheitlicht und verbindet Daten aus den unterschiedlichsten Quellen. Hierbei steht im Sinne des “Social Web” die Person im Vordergrund. Eine definierte Schnittstelle mit vorgefertigen Anwendungskompenten lässt eine einfache Verwendung der Daten in verschiedensten Anwendungsszenarien zu. Diese Seite gibt einen Überblick über die dem CommunityMashup zugrundeliegenden Konzepte und vermittelt einen Einblick in seine vielfältigen Verwendungsmöglichkeiten.
Ausgangssituation
Mit dem Erfolg von Web 2.0 im privaten und Enterprise 2.0 im unternehmensweiten Bereich veränderte sich die Art und Weise wie Informationen strukturiert und kosumiert werden.
[singlepic id=220 w=618 float=center]
Auswirkungen des Erfolg von Social Software
Im Zuge des immer verbreiteteren Einsatzes von Social Software auch im Unternehmenskontext vollzieht sich eine Entwicklung von einer datenzentrischen Systemsicht hin zu einer personzentrischen Perspektive. Soziale Netzwerke wie Facebook oder Microblogging Dienste wie Twitter sind nur zwei Arten von Diensten die Einzug in unser tägliches Leben gefunden haben. Insgesamt lässt sich beoachten, dass fast jeder Nutzer inzwischen mehr als einen Dienst benutzt, sei es wegen spezieller Funktionalitäten, den Personen die über den jeweiligen Dienst erreichbar sind oder schlichtweg um private und berufliche Nutzung zu trennen. So sind wir unter anderem gezwungen den richtigen Kanal zu wählen um Informationen zu konsumieren bzw. zu verteilen. Dies nährt den Wunsch nach einer Integrationslösung, die unsere Daten aus unterschiedlichen Diensten vereint ohne dabei ein neues zentralisiertes System zu schaffen. Insbesondere muss uns die Wahl der Dienste und die Art und Weise, wie wir diese nutzen wollen offen bleiben.
Mobile und ubiquitäre Nutzung
Eine weitere Veränderung der letzten Jahre lässt sich in der Nutzung verschiedenster Geräte, mit denen wir Informationen konsumieren, festhalten. Sei es mit dem Tablet zuhause im Wohnzimmer, unterwegs per Smartphone oder klassisch im Büro mit dem Desktoprechner. Hinzukommen ubiquitäre Systeme wie interaktive Wandbildschirme, welche die letzten Lücken unserer Informationsversorgung schließen. Eine zukunftsfähige Integrationslösung muss daher dem Nutzer die Möglichkeiten der freien Geräte- und Plattformwahl offen lassen.
Nutzerzentrische Aggregation verschiedener Quellen
Der Grundgedanke des Web 2.0 beinhaltet die starke Einbeziehung aller Nutzer bei der Erstellung von Inhalten und die Möglichkeit diese mit anderen Personen zu teilen. Mit der Integration von Daten aus uterschiedlichen Diensten entsteht der Wunsch diese untereinander mit zusätzlichen Informationen zu Verknüpfen und diese wiederum mit anderen zu teilen. Hierin liegt auch ein Kritikpunkt an aktuellen Integrationssystemen, die meist nur aus einer Single-User Perspektive getrieben sind. Beispielsweise ist die Verteilung der Information innerhalb einer Gruppe, wer welche Artikel zu einem gemeinsamen Interessensgebiet gelesen hat, aus dieser Perspektive unmöglich. Wobei die Artikel natürlich aus verschiedensten Quellen stammen können. Zusammen mit der personenzentrischen Sicht auf Daten, der Vielzahl verschiedenster genutzer Dienste und der Verwendung unterschiedlichster Geräte führt dies zum Wunsch einer neuen Integrationslösung für die wir im folgenden die Konzepte und Lösungsansätze vorstellen.
Grundidee
Das CommunityMashup verbindet die Inhalte aus verschiedensten sozialen Diensten. Dazu zählen beispielsweise Soziale Netzwerke wie facebook, Microblogging Dienste wie twitter oder Bild-Dienste wie flickr, aber auch spezielere wie beispielsweise der Referenzmanagement-Dienst Mendeley für wissenschaftliche Veröffentlichungen. Die Daten aus diesen Diensten werden über die Schnittstellen der Services abgerufen und über spezielle Adapter vereinheitlicht, so dass sie miteinander vermischt und verbunden werden können (“mashup”). Die vereinheitlichten Daten werden anschließen wieder über spezielle Schnittstellen bereitgestellt. Hierbei wird auf unterschiedliche Anwendungsszenarien und deren spezielle Anforderung eingegangen, die insbesondere durch verschiedene Geräte und Plattformen beeinflusst sind. Wir unterscheiden ganz allgemein zwischen Web-Anwendungen, Desktop-Anwendungen und Anwendungen für mobile Geräte. Die folgende Grafik visualisiert diese Zusammenhänge noch einmal grafisch. Hierbei ist vorallem zu beachten, dass Daten nicht nur von den angebunden Diensten zu den Endbenutzer Anwendungen fließen, sondern auch in umgekehrter Richtung.
[singlepic id=603 w=618 float=center]
Model Driven Approach
Ausgehend von der Grundidee einer Integrationslösung für soziale Dienste, die Daten vereinheitlicht und über spezielle Schnittstellen wieder bereitstellt, stellt sich die Frage nach dem passenden Entwicklungsansatz. Erfahrungen haben gezeigt, dass Internetdienste sowie ihre ggf. vorhandenen Schnittstellen einer permanenten Änderung und Weiterentwicklung unterworfen sind. Dienste kommen und gehen bzw. sind populären oder unpopulärer ebenso verhält es sich mit ihren Funktionen und Schnittstellen. Um flexibel auf diesen kontinuierlichen Wandel reagieren zu können und dabei eine stetige Evolution der Integrationslösung zu ermöglichen, schlagen wir einen modellgetriebenen Ansatz vor. Dieser basiert auf einem dafür konzipierten personenzentrischen Datenmodell, das die Zusammenhänge in sozialen Diensten wiedergibt. Dieses Datenmodell und die darauf aufbauenden Anwendungskomponenten stellen wir im weiteren Verlauf näher vor.
Datenmodell
Untenstehende Abbildung zeigt die Kernelemente des personenzentrischen CommunityMashup-Datenmodells. Es enthält die drei Kernelmente Person, Organisation und Inhalt (Content). Organisationen wie auch Inhalte können hierarchisch strukturiert werden. Inhalte werden über eine Autor-Beziehung mit Personen verknüpft, diese wiederum können über Organisationen gruppiert werden. Personen-Objekte spiegeln jeweils reale Menschen wieder, d. h. für eine Person wird nicht ein eigenes Element für je benutzten Dienst erzeugt werden, vielmehr bilden alle verteilten Profile zusammen eine digitale Identität ab. Das Selbe gilt auch für die Profile von Organisationen. Jeder weitere Dienst trägt seine zusätzlichen Profilinformationen über Erweiterungs-Objekte (Extensions) bei. So bleibt auch der Bezug zur ursprünglichen Quelle erhalten.
[singlepic id=600 w=618 float=center]
Ein Kernkonzept des Datenmodells ist die bewusst offene Verwendung von Tags für Metainformationen, um ein Minimum von zusätzlichen Attributen für die einzelnen Daten-Objekte fix speichern zu müssen. Beispielsweise erhält eine Person nicht mehr zwei Attribute für die private und die berufliche E-Mail-Adresse, sondern Referenzen zu zwei E-Mail Objekten getaggt mit privat bzw. beruflich. Ein E-Mail Objekt lässt sich dann beispielsweise noch facebook taggen um so deren Verwendung auszuzeichnen. Dieses Verfahren wird auf alle Objekte des Datenmodells angewandt und erlaubt sehr flexible Such- und Filtermethoden und ermöglicht dadurch letztlich eine nutzungsoffene Verwendung der Integrationslösung.
Anwendungskomponenten
Mit der aus dem Datenmodell hervorgehend Abbildungsvorschrift, die es erlaubt Daten aus sozialen Diensten zu vereinheitlichen und miteinander zu verbinden, stellt sich die Frage, welche Teile einer konkreten Anwendung direkt vom vorliegenden Datenmodell abängen und somit ebenfalls automatisch aus dem Modell generiert werden können. Um eine nachhaltige und erweiterbare Lösung zu ermöglichen, ist es quasi ein Muss, dass alle diese direkt ableitbaren Teile automatisch bzw. zumindest semi-automatisch generiert werden. Die folgende Grafik gibt einen Überblick über die für das CommunityMashup relevanten, automatisch generierbaren Anwendungskomponenten:
[singlepic id=604 w=618 float=center]
Viele UML-Werkzeuge unterstützen mittlerweile die automatische Erzeugung einer (Java) Schnittstelle mit zugehörigen leeren Klassen und Methoden. Für eine durchgängige Lösung wird allerdings ausführbare Code mit einer Laufzeitumgebung (RunTime) benötigt. Diese kümmert sich beispielsweise um die Erzeugung von Objekten bzw. um die Bereitstellung von Methoden zur Manipulation solcher Instanzen. Ein zusätzlicher Event-Mechanismus erlaubt das Verfolgen dieser Änderungen. Eine weitere wichtige Anwendungskomponente stellt die Persistierung dar. Diese wird beispielsweise für Caching benötigt. Für die Persistierung von Daten ist eine Serialisierung und Deserialisierung der Objekte notwendig. Diese wird ebenfalls für den Datenaustaustausch über Web-Schnittstellen im XML-Format benötigt. Im Rahmen des CommunityMashup-Projektes wird aktuell eine durchgängige Werkzeugkette aufgebaut, die die automatische Erstellung dieser Komponenten ermöglicht. Wir wenden den gleichen modellgetrieben Ansatz auch auf ein Meta-Modell an, das die möglichen Konfigurationen des CommunityMashup beschreibt. Hierfür werden viele identische Komponenten benötigt, allerdings jeweils bezogen auf ein anderes Modell. Die Verwendung des Meta-Modells erlaubt es, Konfigurationen speichern und laden zu lassen (Persitierung) und beispielsweise aus Gründen der Fernwartung auch über eine Web-Schnittstelle abfragen und verändern zu lassen.
Service-Orientierte-Architektur
Alleine durch die oben beschrieben, aus einem Modell erzeugbaren Komponenten lässt sich noch keine gesamte Integrationslösung erstellen. Ziel des CommunityMashups ist nicht nur ein flexibles Entwicklungskonzept das durch den modellgetriebenen Ansatz erreicht wird, sondern auch eine flexible Systemarchitektur die aufgrund von Anforderungen wie Skalierbarkeit, Performance und Ausfallsicherheit eine Verteilung von Systemkomponenten zulässt. Diese Service-Orientierte-Architektur, muss sich dadurch auszeichnen, dass definierte Systemkomponenten als eigenständige Services mit definierten Schnittstellen realisiert werden. So lassen sich selbst zur Laufzeit einzelne Komponenten aktualisieren bzw. austauschen ohne die Verfügbarkeit des Gesamtsystems zu beeinflussen. Nachfolgende Abbildung zeigt ein exemplarisches verteiltes Szenario mit Client- und Server Komponenten.
[singlepic id=601 w=618 float=center]
Die Verbindung der Daten aus den eizelnen Quelldiensten (Source 1 bis Source n) wird auf einem Server durchgeführt und durch eine Konfiguration gesteuert. Jede dieser Quellkomponenten wird als eigener Service realisiert, der sich sich einzeln aktualiseren lässt, beispielsweise um auf die Änderung einer entfernten Schnittstelle zu reagieren.Java Intern überführen die dargestellten Quellkomponenten Daten der externen Dienste in das dem personenzentrische CommunityMashup-Datenmodell und tragen diese hierdurch sukzessive zu einem gemeinsamen Datensatz zusammen. Die zentrale CommunityMashup-Komponente stellt diesen Datensatz (ggf. je nach Bedarf gefiltert) wieder über eine Java Schnittstelle bereit. Darauf aufbauend lässt sich eine REST Schnittstelle hinzufügen, die die aggregierten und gefilterten Daten (zugriffsbeschränkt) über das Web verfügbar macht. Spezielle Anwendungskomponenten lassen nun eine Verwendung der Daten auf Client-Seite über eine identische Java API zu. Die je nach Client-Typ (im oben abgebildeten Beispiel eine klassische Desktop Anwendung in Kombination mit einem Android Mobile Device) speziell ausgeprägten Anwendungskomponenten kümmern sich im Hintergrund transparent um den Datenaustausch und verlagern je nach Client rechenintensive Aufgaben auf den Server.
