CommunityMashup – Service-Orientierte-Architektur

Alleine durch die auf der Seite zum modellgetriebenen Ansatz des CommunityMashups beschriebenen, 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.

Verteilte Umgebung

Die Verbindung der Daten aus den einzelnen 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 aktualisieren lässt, beispielsweise um auf die Änderung einer entfernten Schnittstelle zu reagieren. Intern überführen die dargestellten Quellkomponenten Daten der externen Dienste in das 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 um den Datenaustausch und verlagern je nach Client rechenintensive Aufgaben auf den Server.

Ansprechpartner für diesen Beitrag

Peter Lachenmaier

Peter Lachenmaier ist seit Mai 2009 als wissenschaftlicher Mitarbeiter in der Forschungsgruppe Kooperationssysteme tätig. Er studierte von Oktober 2003 bis Oktober 2006 Informatik an der Technischen Universität München im Bachelorstudiengang. Anschließend absolvierte er den Elitestudiengang Software Engineering erfolgreich. Dieser wird im Rahmen des Elitenetzwerks Bayern durch die Technische Universität München, die Ludwig Maximilians Universität München und die Universität Augsburg gemeinsam angeboten. Zeige alle Beiträge von Peter Lachenmaier →