Entwurf und Prototypische Implementierung einer Data Mashup Plattform

Entwurf und Prototypische Implementierung einer Data Mashup Plattform Daniel Del Gaudio, Nikolas Paparoditis, Johannes Bohn Abstract In dieser Projektarbeit werden der Entwurf und die prototypische Implementierung einer serviceorientierten Data Mashup Plattform vorgestellt. Diese dient dazu Daten aus verschiedenen Quellen miteinander kombinieren und manipulieren zu können. Dazu kann der Benutzer einen Workflow auf einer graphischen Oberfläche modellieren und dann durch eine Workflow Engine ausführen lassen. Um die einzelnen Daten zu extrahieren und die gewollten Operationen durchzuführen, werden Webservices verwendet. Nach der Beschreibung eines Anwendungsfalles gehen wir auf ausgewählte, themenbezogene Arbeiten ein. Anschließend wird der Entwurf des Data Mashups vorgestellt, der auf einem Drei-Schichten-Modell basiert. Um die Funktionalität des Entwurfes zu zeigen, haben wir einen Prototypen implementiert, welcher daraufhin erläutert wird. Index Terms Data Mashup, Workflow Engine, Service Oriented Architecture, Webservice, Data Source Adapter, Filter. 1 EINLEITUNG Anwendungen, welche auf der Kombination von bestehenden Inhalten aus verschiedenen Quellen basieren werden Mashups genannt. Konkret entsteht ein Mashup also durch die Kombination von (Web-)Inhalten, Daten und Anwendungen [5]. Mashups so wie wir sie kennen sind fast ausnahmslos Web-Anwendungen. Eine Web-Anwendung wird auf einem Web-Server ausgeführt und interagiert mit dem Nutzer meistens über den Web-Browser. Der Grund für die Erstellung von Mashups ist der Bedarf an einer Anwendung, welche dem Nutzer für eine bestimmte Aufgabe oder ein Aufgabenfeld Unterstützung bietet. Die Erstellung erfolgt also problembezogen. Die Ersteller von Mashups sind meistens Nutzer, die über keine oder nur sehr wenige Programmierkentnisse verfügen. Es ist demnach wichtig, dass die Erstellung von Mashups auch Nutzern ohne Programmierkenntnisse gelingt. Generell gibt es zwei Arten von Mashups [5]: Enterprise Mashups, die für den Unternehmenseinsatz erstellt werden und Mitarbeiter von Unternehmen bei ihrer Arbeit unterstützen sollen, und Web Mashups, bei denen die Ersteller i.d.r. technisch versierte Benutzer sind. Enterprise Mashups lassen sich wiederum in drei Varianten aufteilen: Presentation Layer Mashups zur Vereinigung von UI-Elementen, Logic Layer Mashups zur Vereinigung logischer Operationen und Data Mashups zur Vereinigung von Daten aus unterschiedlichen Quellen. Der Fokus dieser Arbeit liegt ausschließlich auf Data Mashups. Unter einem Data Mashup versteht man das Kombinieren von Daten aus unterschiedlichen, in Struktur und Inhalt verschiedenartigen Quellen. Der Nutzer des Data Mashups kann mehrere Datenquellen einbeziehen und deren Daten miteinander verknüpfen. Die Funktionen eines Data Mashups werden dem Nutzer über eine einheitliche, meist graphische Benutzeroberfläche zur Verfügung gestellt, wobei Implementierungsdetails verborgen bleiben. Im Gegensatz zu anderen Mashup-Varianten ist bei Data Mashups der Integrationsgrad zwischen den unterschiedlichen Elementen etwas höher, weshalb deren Erstellung und Bedienung ein Mindestmaß an technischen Kenntnissen voraussetzt. Die Komplexität eines Data Mashups resultiert aus dem Kompatibilitätsgrad der einbezogenen Datenquellen. Ein Mashup-Tool, das die Erstellung von Data Mashups ermöglicht, ist zum Beispiel Yahoos Pipes [13]. Johannes Bohn Daniel Del Gaudio Nikolas Paparoditis Die vorliegende Arbeit gliedert sich wie folgt. In Kapitel 2 werden ausgewählte themenbezogene Arbeiten, ein konkretes Einsatzgebiet und weitere Aspekte des Einsatzes von Data Mashup-Technologien erläutert. Der Kern der Arbeit liegt in den Kapiteln 3 und 4, welche den Entwurf der resultierenden Data Mashup Plattform behandeln. Das Kapitel 5 gibt einen Überblick über die Implementierung eines Data Mashups und veranschaulicht wie bereits vorhandene Technologien eingesetzt und integriert werden können, um ein Data Mashup zu konstruieren. In Kapitel 6 werden Messungen über die Leistung des implementierten Mashups präsentiert. Abschließend wird ein kurzes Fazit dieser Arbeit mit Ausblick auf zukünftige Erweiterungen gegeben. 2 HINTERGRUND In diesem Abschnitt wird ein Anwendungsfall erläutert. Außerdem wird darauf eingegangen, wie andere themenbezogene Arbeiten geholfen haben, den Entwurf zu realisieren. 2.1 Anwendungsfall Ein möglicher Anwendungsfall, bei dem der Einsatz eines Data Mashups von Nutzen ist, kommt aus der Industrie. Ein Unternehmen, das beispielsweise Produkte verwaltet, entscheidet sich zu den jeweiligen Produkten auch die Meinung der Konsumenten zu berücksichtigen. Die Marketingabteilung der Firma möchte je nach Produkt verschiedene Feedbackquellen nutzen. Jeder Mitarbeiter sollte dabei in der Lage sein, selbstständig das Produkt und die Feedbackquelle auszuwählen. Außerdem soll es möglich sein ohne großen Aufwand neue Feedback- oder Informationsquellen integrieren zu können. Das Unternehmen könnte alle seine Produktdaten in einer oder mehrerer SQL-Datenbanken verwalten. Als eine mögliche Feedback-Quelle könnte Twitter dienen, da es von den Kunden häufig verwendet wird, um positives oder negatives Feedback über Produkte abzugeben. Da die Mitarbeiter des Unternehmens über keine fortgeschrittenen Programmierkentnisse verfügen wird eine grafische Oberfläche benötigt. Vorkenntnisse im Umgang mit Datenbanken und dem Inhalt der jeweiligen Produkt-Tabellen sind dafür aber existent. Ein Data Mashup ist für diesen Anwendungsfall das geeignete Mittel um diese Anforderungen umzusetzen, da es durch eine graphische Oberfläche einfach zu bedienen ist und einen hohen Grad an Flexibilität bei der Erweiterung um zusätzliche Quellen aufweist. 1

rasant entwickelndes Geschäftsumfeld anzupassen. Daraufhin werden Unterschiede zwischen prozessorientierten Mashups, datenorientierten Mashups, Webservice-Zusammensetzungen und traditionellen Workflow-Systemen erläutert. Wie in den vorher beschriebenen Arbeiten wird Wert darauf gelegt, dass das zu entwerfende System insbesondere auch durch technisch unversierte Anwender nutzbar ist. Im Gegensatz zu diesen wird ein Workflow-basiertes System entworfen, welches durch den Einsatz einer Workflow Engine an Robustheit gewinnt. Dabei wird der Fokus auf die Verbindung zwischen graphischer Benutzeroberfläche und der Ausführung des Arbeitsablaufes gelegt. Eine Transformation zwischen dem Datenmodell für die Modellierung und dem zur Ausführung, soll es ermöglichen verschiedene Ausführungsumgebungen für das selbe Modellierungsmodell zu verwenden. 3 GROBENTWURF Das Data Mashup-System basiert auf einem Drei-Schichten-Modell (siehe Abbildung 1). Die Modellierungs-Schicht, welche die Client-Seite beschreibt, sowie die Transformations-Schicht und die Ausführungs-Schicht, welche zusammen die Server-Seite bilden. Abbildung 1: Schichten der Data Mashup Architektur 2.2 Themenbezogene Arbeiten Hoyer et al. [7] befassen sich mit der Entwicklung eines Kosten- Nutzen-Modells [6] für Enterprise Mashups. Zunächst wird mittels eines Konzeptes zur Dokumentation, Steuerung und Messung der Aktivitäten von Unternehmen unter Berücksichtigung von Unternehmensanforderungen und -strategien ein leistungsorientiertes Modell entworfen. Im Anschluss wird mittels diverser Tests und einer Fallstudie die Anwendbarkeit des Modells demonstriert und von ausgewählten Nutzern bewertet. Ein besonderer Schwerpunkt der Arbeit liegt in der Fragestellung, inwieweit Endnutzer eigenständig Anwendungen erstellen können ohne die IT-Abteilungen der jeweiligen Firmen zu involvieren. Um Enterprise-Systeme und Geschäftsprozesse aufeinander abstimmen zu können, werden Modelle für die Spezifikation und die Kommunikation der Ziele und Aktivitäten des Unternehmens verwendet. Damit befassen sich Tietz et al. [11] genauer. Sie geben an, dass obgleich modellbasierte Systemintegrationen für Daten und Logik bereits erarbeitet wurden, die Realisierung von nutzerbeteiligten Aktivitäten immer noch eine Herausforderung ist. Der größte Teil der Arbeit befasst sich mit der Konzeption einer plattformunabhängigen Implementierung. Zuerst wird die Zuordnung von Prozessmodellen und Arbeitsmodellen anhand einer Business Process Model and Notation (BPMN) spezifiziert und ein sogenannter Empfehlungs-Algorithmus entwickelt. Für die Mashup-Plattform wird eine Infrastruktur genutzt, die ein semantisches Komponentenarchiv und eine Browser-basierte Laufzeitumgebung enthält. De Vrieze et al. [4] befassen sich, im Gegensatz zu den vorigen zwei Arbeiten, insbesondere mit der Unterstützung von Geschäftsprozessen durch Mashups. Sie untersuchen dabei, wie die vorhandene datenorientierte Funktionalität von Web 2.0 für den Einsatz in Unternehmen erweitert werden kann. Gezeigt wird, dass sich Prozess-Zusammensetzung in einem Enterprise Mashup als eine nützliche Technik für serviceorientierte, Architektur-basierende Automatisierungen und die Integration von Unternehmensaktivitäten erweist. Die beschriebene Zusammensetzung von Prozessen ist eine agile Vorgehensweise, die Unternehmen erlaubt, sich an ein 3.1 Modellierungs-Schicht Die Modellierungs-Schicht ist die einzige vom Nutzer zugreifbare Schicht. Hier werden alle Datenquellen ausgewählt und der Arbeitsablauf in einem Workflow modelliert. Dies geschieht anhand einer leicht zu bedienenden, graphischen Oberfläche. Der zu erstellende Workflow wird dabei als gerichteter Graph dargestellt, der einen eindeutigen Endknoten besitzt. 3.2 Transformations-Schicht In der Transformations-Schicht wird der von der Modellierungs- Schicht übergebene Workflow in ein für die Ausführungs-Schicht ausführbares Format übersetzt. 3.3 Ausführungs-Schicht In der Ausführungs-Schicht wird der transformierte Workflow ausgeführt. Sie basiert auf einer serviceorientierten Architektur, was sie gut skalierbar und hochflexibel macht. Um einen hohen Grad an Verteilung zu erreichen und um die einzelnen Schritte des Arbeitsablaufes umzusetzen werden hier Webservices verwendet. Dies stellt einen hohen Grad an Modularisierung und Erweiterbarkeit sicher. Ein Webservice muss nicht in das System integriert sein, sondern kann auch auf einem fremden Server liegen. Um den Ablauf der Webservices zu koordinieren wird eine Workflow Engine verwendet, wodurch das System an Dynamik und Robustheit gewinnt. Eine Teilmenge der Webservices bilden den Data Source Adapter. Hierzu gehören alle Webservices, welche auf externe Datenquellen zugreifen. Die andere Teilmenge bilden die Datenoperationen welche die zuvor extrahierten Daten manipulieren. Durch das Verwenden von Webservices mit einer Workflow Engine lässt sich das System ohne großen Aufwand beliebig erweitern. 4 FEINENTWURF Im Feinentwurf wird auf die clientseitigen und serverseitigen Komponenten des Systems genauer eingegangen. Abbildung 2 veranschaulicht die Architektur des Systems. 4.1 Clientseitige Komponenten Der Client ist eine Anwendung, die in einem Web-Browser läuft. Er stellt über eine grafische Benutzeroberfläche Kontrollelemente zur Verfügung, mit denen der Benutzer den Workflow als Graph modellieren kann. Die verschiedenen Kontrollelemente, die die Daten bearbeiten sind durch unterschiedliche Symbole dargestellt, die verbunden werden können. Diese Verbindungen stellen den Datenfluss dar. Die Elemente unterscheiden sich zwischen Datenquellen und Datenoperationen. 2

Abbildung 2: Komponentendiagramm. Nach Fertigstellung der Modellierung des Workflows wird dieser in dem Datenformat, das vom Clienten zur Modellierung verwendet wird, an die Kommunikations-Komponente der Server-Seite geschickt. 4.2 Serverseitige Komponenten Die Server-Seite lässt sich in eine Kommunikations-Komponente, eine Transformations-Komponente, einen Engine-Handler, die Webservices und einen Cache unterteilen. Dabei befinden sich die ersten drei in der Transformations-Schicht und die anderen beiden in der Ausführungs-Schicht. 4.2.1 Kommunikations-Komponente Die Kommunikations-Komponente hat die Aufgabe, Meta-Daten der Datenquellen an die Client-Seite zu übermitteln, welche die Auswahl von Datenquellen erleichtern sollen. Ein Beispiel hierfür wären die Tabellennamen einer SQL-Datenbank. Durch ein HTTP Request wird am Ende der Modellierung die Kommunikations-Komponente aufgerufen. Diese konvertiert daraufhin die Daten, die von der Client-Seite übermittelt wurden, in eine für die Workflow Engine verständliche Sprache. Nachdem der Code für die Workflow Engine generiert wurde, erteilt die Kommunikations- Komponente den Befehl zur Ausführung des Workflows. Sobald die Workflow Engine die Ausführung abgeschlossen hat, werden die resultierenden Daten durch die Kommunikations- Komponente an die Client-Seite zurückgeschickt. 4.2.2 Transformation Die von gängigen Workflow Engines verwendeten Ausführungs- Sprachen eignen sich nicht für die Modellierung auf Seite des Benutzers, da sie syntaktisch komplex ist. Die Transformations- Komponente dient somit dazu, das vereinfachte Datenmodell der Client-Seite in die Ausführungs-Sprache der verwendeten Workflow Engine zu konvertieren. 4.2.3 Engine-Handler Um den Workflow mit der Workflow Engine auszuführen, müssen die notwendigen Daten an diese übermittelt und der Workflow- Prozess initiiert werden. Hierfür dient die Komponente Engine- Handler. Sie bildet die Schnittstelle zwischen Kommunikations- Komponente und Workflow Engine. 4.2.4 Webservices Die Webservices werden in zwei unterschiedliche Kategorien unterteilt: Data Source Adapter und Daten-Operationen. Data Source Adapter sind in der Lage, Daten von verschiedenen Datenquellen zu extrahieren. Die Daten-Operationen können diese Daten dann bearbeiten. Für die Daten-Operationen werden beispielhaft eine Filter- Operation und eine Join-Operation beschrieben. Data Source Adapter Für jede Datenquelle muss ein eigener Data Source Adapter existieren. Diese entnehmen die gewünschten Daten aus den gewählten Datenquellen und bringen sie in ein einheitliches Format. Als Data Source Adapter können zum Beispiel SQL- und Twitter- Adapter dienen. Der SQL-Adapter ist für die Extraktion der Daten aus der gewünschten Tabelle einer SQL-Datenbank zuständig. In gleicher Weise greift der Twitter-Adapter über eine Twitter-API auf die Suchmaschine von Twitter zu um alle gewünschten Tweets zu entnehmen. Daraufhin werden diese nach Stimmung klassifiziert und mit ihrer Klassifizierung abgespeichert. 3

Filter Als Beispiel dafür, wie die extrahierten Daten nun weiterverarbeitet werden können, werden zwei Filter beschrieben: Der SQL-Filter selektiert die Daten nach eingegebenen Kriterien. Der Twitter-Filter selektiert Tweets nach der vom Twitter-Adapter klassifizierten Stimmung. Da alle extrahierten Daten das selbe Format besitzen, kann der Twitter-Filter als eine Spezialisierung des SQL-Filters angesehen werden. Join Der Join Webservice ermöglicht es zwei Datensätze zu kombinieren. Hierfür durchsucht er die beiden Datensätze nach Übereinstimmungen, und konkateniert sie entsprechend. 4.2.5 Data Cache Da nicht alle Workflow Engines dazu geeignet sind, große Datenmengen zu verarbeiten, wurde im Entwurf ein Data Cache hinzugefügt. Dieser wird dazu verwendet, die Daten zwischen den Aufrufen der einzelnen Webservices zwischenzuspeichern. Die Data Source Adapter speichern die Datensätze in einem einheitlichen Format im Cache ab. Die Operationen entnehmen die Daten aus dem Cache und legen sie nach der Verarbeitung wieder dort ab. Nach Ausführung des Arbeitsablaufes kann die Kommunikations-Komponente die Ergebnis-Daten dem Data Cache entnehmen. 5 IMPLEMENTIERUNG Im vorangegangenen Kapitel wurde ein generischer Entwurf für einen Workflow-basierten Data Mashup beschrieben. Dieser wurde beispielhaft in eine prototypische Implementierung umgesetzt, wobei der Anwendungsfall aus Kapitel 2.2 herangezogen wurde. Die Server-Seite des Prototypen wurde in Java implementiert. Als Container wurde daher ein Apache Tomcat Server [3] verwendet. Als Workflow Engine dient die Apache ODE [2]. 5.1 Client Für die graphische Benutzeroberfläche wurde das Framework AlloyUI [1] verwendet, das auf JavaScript, HTML und CSS basiert. Die Benutzeroberfläche ist in zwei Komponenten unterteilt. Die erste Komponente ist eine Seitenleiste, auf der mögliche Knotenelemente aufgelistet sind. Diese kann der Benutzer auf die andere Komponente, die Modellierfläche ziehen, um sie in das Modell des Mashups aufzunehmen. Des Weiteren dient die Seitenleiste dazu die Parameter der einzelnen Knotenelemente zu initialisieren. Einen Spezialfall stellt das Modellieren eines SQL-Adapters dar. Dieser ermöglicht dem Benutzer das Schema einer SQL-Datenbank auszulesen, indem ein HTTP-POST Request an das Servlet gesendet wird, welches die eingegebene URI, den logischen Datenbanknamen und die Authentifizierungsdaten (Benutzername, Passwort) als Parameter zurückgibt. Das Servlet liefert über eine entsprechende HTTP Response das Datenbankschema in Form von Tabellennamen zurück, woraus der Benutzer auswählen kann. Auf der Modellierfläche wird der Workflow für das aktuelle Mashup dargestellt. Dort können Knotenelemente in der gewünschte Reihenfolge verknüpft werden. Abbildung 3 zeigt die graphische Benutzeroberfläche mit einem modellierten Anwendungsfall. Der Workflow wird als JSON-Array gespeichert. Sobald ein Knotenelement auf der Modellierfläche erstellt wird, wird ein JSON- Objekt dafür in diesem Array angelegt. In jedem JSON-Objekt werden nun diverse Attribute des zugehörigen Knotenelementes gespeichert, unter anderem der Typ, ein eindeutiger Name und alle Nachfolger dieses Elementes. Dieses JSON-Array wird anschließend mittels eines HTTP-POST Requests an die Kommunikations-Komponente gesendet. Abbildung 4: Aktivitätsdiagramm des Data Mashups. 4

Abbildung 3: Benutzeroberfläche mit modelliertem Anwendungsfall. 5.2 Kommunikations-Komponente Die Kommunikations-Komponente besteht aus einem Java Servlet und einer Klasse für die Kommunikation mit den Datenquellen. Dies veranschaulicht Abbildung 5. Sobald das Servlet den HTTP-POST Request vom Client empfängt, wird eine Fallunterscheidung vorgenommen, um entweder den Arbeitsablauf auszuführen, oder um die Schemata (Tabellennamen) der SQL-Datenbank abzufragen und an den Client zurückzuliefern. Im Fall einer Schema-Abfrage, werden zunächst mit Hilfe der Klasse Wrapper die Tabellennamen aus einer MySQL-Datenbank entnommen. Wenn das Modellieren des Workflows abgeschlossen ist erhält das Servlet diesen vom Client als JSON-Array und übergibt ihn an die Transformations-Komponente, welche den Arbeitsablauf dann in einen BPEL-String konvertiert und zurückliefert. Anschließend wird dieser zur Ausführung an den Engine-Handler übergeben der ihm einen Schlüssel für den Data Cache zurückgibt. Dieser wird per HTTP Response an den Clienten zurückgeschickt. 5.3 Transformation Die Klasse Converter dient dazu den Arbeitsablauf im JSON- Format in ein ausführbares BPEL-Format zu übersetzen. Für jeden Knoten des Workflows wird deshalb der entsprechende BPEL-Code generiert und zu einem BPEL-String zusammengefügt. Dafür muss der JSON-String zuerst in ein JSON-Objekt umgewandelt werden. Die Methode convert wandelt daraufhin das JSON-Objekt in den ausführbaren BPEL-Code um. Dafür werden zuerst sequentiell alle Elemente des JSON-Objekts gelesen, da jedes Element einen Knoten des Mashups darstellt. Für jeden Knoten wird nun ein Objekt der Klasse WorkflowNode angelegt, und die entsprechenden Attribute initialisiert. Zu diesen Attributen gehört unter anderem eine Liste, in welcher alle Nachfolger des Knotens gespeichert werden. Jedes angelegte Objekt wird dann in einer selbstreferenzierenden Hashmap gespeichert. Dadurch bildet diese auch einen Graph, auf dem eine Breitensuche durchgeführt werden kann. Dies ist notwendig, damit der BPEL-Code für jeden Knoten an der richtigen Stelle des BPEL-Strings eingefügt wird. Dies gewährleistet, dass parallel modellierte Komponenten des Workflows in der korrekten Sequenz ausgeführt werden können, was den BPEL-Code erheblich vereinfacht. 5.4 Engine Handler Der Engine Handler übernimmt die Kommunikation zwischen dem Servlet und der Apache ODE. Er ist in zwei Teile aufgeteilt. Zuerst wird der BPEL-Prozess durch den EngineProcessStarter auf der Apache ODE deployt und dann durch den EngineCommunicator aufgerufen. 5.4.1 Engine Process Starter In der Klasse EngineProcessStarter wird zuerst der generierte BPEL-Code in eine Datei geschrieben. Diese Datei wird in das Verzeichnis geschrieben, in dem bereits die für die Ausführung nötigen.wsdl - und deploy.xml -Dateien, sowie die.wsdl -Dateien aller potenziell benutzten Webservices liegen müssen. Dann werden alle Dateien in diesem Verzeichnis in einer Zip- Datei komprimiert. Zuletzt wird eine SOAP-Nachricht an den Deployment-Service der Apache ODE zusammengebaut. In den Hauptteil der Nachricht wird die Zip-Datei eingefügt. Dazu wird diese in einen String encodiert. 5.4.2 Engine Communicator Die Klasse EngineCommunicator dient dazu, den BPEL-Prozess zu starten. Hierzu wird eine SOAP-Nachricht mit den Eingangsvariablen des Prozesses an die Apache ODE gesendet. Am Ende der Ausführung des BPEL-Prozesses wird per SOAP-Nachricht die Adresse der Daten an diese Klasse zurückgegeben. Diese wird aus der Nachricht extrahiert und an das Servlet zurückgegeben. 5.5 Webservices Der Rückgabewert eines Webservices ist immer der Schlüssel, anhand dessen die Ergebnis-Daten aus dem Cache gelesen werden 5

Abbildung 5: Klassendiagramm der Kommunikations- und Transformations-Komponente. 6

Abbildung 6: Klassendiagramm der Webservices, des Data Caches und deren Utilities. können. Außer den Data Source Adaptern benötigen alle Services auch einen Schlüssel als Parameter, um die Daten, die sie bearbeiten sollen, aus dem Cache zu lesen. Die Data Source Adapter benötigen als Parameter alle nötigen Daten für die jeweilige Datenquelle. Abbildung 6 zeigt das Klassendiagram der Webservices. 5.5.1 Data Source Adapter Die Data Source Adapter greifen auf die entsprechenden Datenquellen zu und wandeln die Daten in ein JSON-Array um. Dieses speichern sie dann in den Cache. Dieser liefert einen Schlüssel zurück, welcher dann der Apache ODE weitergegeben wird. Für den Prototyp wurden zwei Data Adapter implementiert: Einen für Twitter-Daten und einen für MySQL-Datenbanken. Twitter Adapter Der Twitter Adapter verwendet die Bibliothek Twitter4J [12], um auf die Twitter API zuzugreifen, und die Bibliothek LingPipe [8], um alle Tweets in eine positive, negative oder neutrale Stimmung zu kategorisieren. Er durchsucht alle Tweets nach dem übergebenen Parameter und speichert die neuesten davon im Data Cache als ein JSON-Objekt pro Tweet. Diese haben die Attribute text, user und sentiment. SQL Adapter Der SQL Adapter stellt eine Verbindung mit einer SQL-Datenbank her. Dafür verwendet er die Bibliothek JDBC [10]. Mit einer SQL- Abfrage wird die gesamte Tabelle ausgelesen, die der Benutzer vorher ausgewählt hat. Diese Tabelle wird dann in ein JSON-Array umgewandelt, wobei für jede Zeile ein JSON-Objekt und darin für jede Spalte ein Attribut angelegt wird. 5.5.2 Filter Die Filter lesen zuerst die zu filternden Daten aus dem Cache aus. Nach Anwenden der Filterregel wird der neue Datensatz dann wieder in den Cache geschrieben. Es wurde für jede der beiden Datenquellen ein Filter-Service implementiert. Der Filter benötigt außerdem einen Parameter der festlegt nach welcher Regel die Daten gefiltert werden sollen. Twitter Filter Die Twitter-Daten können nach der zuvor kategorisierten Stimmung gefiltert werden. Nachdem die Daten aus dem Cache gelesen wurden, wird jeder Tweet nach dem Attribut sentiment durchsucht. Alle Tweets, bei denen dieses mit dem Kriterium übereinstimmt, werden an ein neues JSON-Array angefügt. Dieses wird dann wieder in den Cache abgelegt und der Schlüssel wird an die Apache ODE zurückgegeben. SQL Filter Im Gegensatz zum Twitter-Filter benötigt der SQL-Filter ein Kriterium der Form [Spalte]=[Wert], wobei [Spalte] mit einer Spalte aus der gewählten Tabelle in der ursprünglichen MySQL- Datenbanken übereinstimmen muss. Alle JSON-Objekte des JSON- Arrays, welches gefiltert werden soll, werden dann nach dem Attribut Spalte durchsucht. Die Einträge, bei welchen der Wert in der Spalte [Spalte] mit dem Filterwert übereinstimmt, werden dann an ein neues JSON-Array angehängt, und dieses im Cache abgelegt. 5.5.3 Join Der Join-Service dient dazu zwei Datensätze zusammenzufügen. Er benötigt dazu einen String-Parameter der Form [Attribut 1]=[Attribut 2]. Er durchsucht alle Elemente der beiden Datensätze nach beiden Attributen, und fügt alle Paare, bei denen diese 7

Komponente Messung 1 Messung 2 Messung 3 Messung 4 Messung 5 Durchschnitt Kommunikations-Komponente 4.008,4 2.473,5 2.730,7 6.007,1 2.527,9 3.549,5 Transformation 0,2 0,3 0,3 2,6 0,1 0,7 SQL Adapter 88,8 18,3 317,3 317,5 25,8 153,6 Twitter Adapter 4.182,7 2.911,4 4.117,2 5.882,7 3.160,6 4.050,9 SQL Filter 22,8 25,3 27,0 15,5 12,2 20,6 Twitter Filter 84,9 46,4 133,0 121,4 106,2 98,4 Join 41,2 45,7 75,9 77,8 37.0 55,5 Workflow Engine 763,0 728,1 3.335,6 3.239,5 970,2 1.807,3 Gesamt 9.192,1 6.249,0 10.737,4 15.664,2 6.840,0 9.736,4 Tabelle 1: Messdaten in Millisekunden übereinstimmen aneinander an. Diese fügt er dann in ein neues JSON-Array ein, welches er im Cache ablegt. 5.6 Data Cache Als Cache wird eine MongoDB [9] verwendet. Die Klasse DataCache bildet eine Schnittstelle zu dieser, wofür auch dessen Treiber, gfmongo-java-driver-2.13.0 verwendet wird. Wenn ein neuer Datensatz in den Cache gespeichert werden soll, wird das als Parameter übergebene JSON-Array in eine Collection umgewandelt und diese mit einem zufallsgenerierten Schlüssel abgespeichert. Dieser Schlüssel wird dann zurückgegeben, damit anhand diesem wieder auf die Daten zugegriffen werden kann. Um einen Datensatz aus dem Cache auszulesen, wird die gesamte Collection aus der Datenbank ausgelesen, die unter dem als Parameter erhaltenen Schlüssel gespeichert ist. Diese wird in ein JSON-Array umgewandelt und zurückgegeben. 6 LAUFZEITMESSUNGEN Um die Leistung der Implementierung zu messen, wurde die Laufzeiten der einzelnen Komponenten gemessen. Die Ergebnisse wurden in Tabelle 1 zusammengetragen. Unsere Annahme war, dass die Workflow Engine einen erheblich Anteil der Laufzeit ausmacht. Jedoch hat sich das Gegenteil bestätigt. Den größten Teil der Laufzeit nimmt die Kommunikations-Komponente in Anspruch. [6] B. Farbey, F. Land, and D. Targett. A Taxonomy of Information Systems Applications: The Benefits Ladder. [7] V. Hoyer, K. Stanoevska-Slabeva, S. Kramer, and A. Giessmann. What are the Business Benefits of Enterprise Mashups? 2011. [8] LingPipe. LingPipe Home. http://alias-i.com/lingpipe, 2015. [Online; abgerufen am 15.01.2015]. [9] MongoDB. Scalable, Adaptable, Fast: Database for Modern Applications MongoDB. http://www.mongodb.com/, 2015. [Online; abgerufen am 27.03.2015]. [10] Oracle. Java Platform Standard Edition 8 Documentation. http: //docs.oracle.com/javase/8/docs/, 2015. [Online; abgerufen am 27.03.2015]. [11] V. Tietz, S. Pietschmann, G. Blichmann, K. Meißner, A. Casall, and B. Grams. Towards Task-Based Development of Enterprise Mashups. pages 325 328, 2011. [12] Twitter4J. Twitter4J. http://twitter4j.org/, 2015. [Online; abgerufen am 27.03.2015]. [13] Yahoo. Pipes: Rewire the web. https://pipes.yahoo.com/ pipes/, 2015. [Online; abgerufen am 03.10.2014]. 7 FAZIT UND ZUKÜNFTIGE ARBEITEN Für unseren Anwendungsfall wäre die Verwendung einer Workflow Engine nicht notwendig, da wir die Webservices auch direkt aufrufen könnten. Jedoch haben wir unser System als Grundlage für Erweiterungen entworfen. Dank der Workflow Engine ist es wesentlich leichter, das System um weitere Webservices zu erweitern. Bei einem komplexeren System, welches aus weitaus mehr Webservices besteht, die auch parallel ausgeführt werden sollen, werden die Fähigkeiten der Workflow Engine vollständig ausgeschöpft. Hierfür ist unsere Transformation jedoch nicht ausreichend. Schon bei unserem Prototyp war die Übersetzung des Workflows in BPEL der aufwändigste Teil. Alle möglichen Fälle der Modellierung in BPEL zu konvertieren erfordert eine wesentlich komplexere Transformation. Als zukünftige Arbeit möchten wir eine flexiblere und generische Übersetzung des Arbeitsablaufes in eine Workflow-Sprache entwerfen. LITERATUR [1] AlloyUI. AlloyUI. http://alloyui.com/, 2015. [Online; abgerufen am 27.03.2015]. [2] Apache. Apache ODE Apache ODE TM. https://ode.apache. org/, 2015. [Online; abgerufen am 27.03.2015]. [3] Apache. Apache Tomcat - Welcome! https://tomcat.apache. org/, 2015. [Online; abgerufen am 27.03.2015]. [4] P. de Vrieze, L. Xu, A. Bouguettaya, J. Yang, and J. Chen. Building enterprise mashups. pages 637 642. Elsevier, 2011. [5] N. C. Engard and J. Levine. Library Mashups, Exploring New Ways to Deliver Library Data. Facet Publishing, 2009. 8