universit¨at duisburg-essen fakultät f¨ur

UNIVERSITÄT DUISBURG-ESSEN
FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN
ABTEILUNG INFORMATIK UND ANGEWANDTE KOGNITIONSWISSENSCHAFT
Masterarbeit
Re-Engineering eines Rahmensystems für Multiagentensysteme zur Datenanalyse
Stefan Remberg
Matrikelnummer:
Abteilung Informatik und angewandte Kognitionswissenschaft
Fakultät für Ingenieurwissenschaften
Universität Duisburg-Essen
31. Januar 2016
Betreuer:
Prof. Dr. H. U. Hoppe
Dipl.-Math. Tilman Göhnert
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen
2.1. Multiagentensysteme . . . . . . . . . . .
2.2. Verwandte Arbeiten . . . . . . . . . . .
2.2.1. Network Workbench . . . . . . .
2.2.2. GATE . . . . . . . . . . . . . . .
2.2.3. UIMA . . . . . . . . . . . . . . .
2.3. Architekturen und Entwurfsmuster . . .
2.3.1. Blackboard-Architektur . . . . .
2.3.2. Publisher/Subscriber-Architektur
2.3.3. Pipes and Filters . . . . . . . . .
2.3.4. Abstrakte Fabrik . . . . . . . . .
2.4. SQLSpaces . . . . . . . . . . . . . . . .
2.5. Analytics Workbench . . . . . . . . . . .
2.5.1. Architektur . . . . . . . . . . . .
2.5.2. Ablauf eines Workflows . . . . .
2.5.3. Kommunikation . . . . . . . . .
2.5.4. Framework . . . . . . . . . . . .
2.5.5. Probleme . . . . . . . . . . . . .
2.6. Nachrichtenaustausch und Speicher . . .
2.6.1. MQTT . . . . . . . . . . . . . .
2.6.2. PostgreSQL . . . . . . . . . . . .
2.6.3. FTP . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Ansatz
3.1. Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Aufbau des Frameworks . . . . . . . . . . . . . . . . . . . . .
3.1.4. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Aufbau des Frameworks . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Verbindungen und Kommunikation . . . . . . . . . . . . . . .
3.2.1.1. Anzahl der Verbindungen . . . . . . . . . . . . . . .
3.2.1.2. Nachrichten- und Datenaustausch . . . . . . . . . .
3.2.1.3. Datenaustauschformat und Nachrichtenspezifikation
3.2.2. Struktur des Agenten-Frameworks . . . . . . . . . . . . . . .
3.2.2.1. AgentManager . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
5
6
7
7
8
10
11
12
13
14
14
15
16
17
18
18
19
20
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
23
24
25
27
27
27
29
30
32
33
iii
Inhaltsverzeichnis
3.2.2.2. Agent . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.3. Executor, Verbindungsverwaltung und Konfiguration
3.2.3. Node.js-Serverkomponente . . . . . . . . . . . . . . . . . . . . .
3.2.3.1. Verbindungen und Konfiguration . . . . . . . . . . . .
3.2.3.2. Erkennen von aktiven Analysekomponenten . . . . . .
3.2.3.3. Sammeln von Resultaten . . . . . . . . . . . . . . . .
3.3. Kommunikation innerhalb des Frameworks - konkrete Ansätze . . . .
3.3.1. Nachrichtenaustausch . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1. MQTT . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.2. PostgresSQL . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Datenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.2. PostgreSQL als Speicher für binäre Daten . . . . . . .
3.3.3. Sitzungsübergreifende Persistenz . . . . . . . . . . . . . . . . .
3.3.3.1. SQLSpaces . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.2. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
37
39
39
39
40
41
41
41
43
44
44
46
46
47
47
4. Implementierung
4.1. Verwendete Bibliotheken . . . . . . . . . . . . . . . . . .
4.2. Status und Resultate eines Analyseworkflows . . . . . .
4.2.1. Überführen eines Analyseworkflows in eine Liste
4.2.2. Abarbeiten der Analysemodule und Resultate . .
4.3. PostgreSQL: Datenbank Initialisierung und Trigger . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
51
51
52
53
5. Anwendungsbeispiel
5.1. Analysesystem . . . . . . . . . . . . . . . . . . . . . .
5.2. Beispielanalyse im Rahmen des KOLEGEA Projektes
5.2.1. Analysedaten . . . . . . . . . . . . . . . . . . .
5.2.2. Analyseworkflow . . . . . . . . . . . . . . . . .
5.2.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . .
5.3. Performancetest . . . . . . . . . . . . . . . . . . . . . .
5.3.1. Analyseworkflow und Testdaten . . . . . . . . .
5.3.2. Durchführung . . . . . . . . . . . . . . . . . . .
5.3.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . .
5.4. Auswertung . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
56
57
58
58
59
59
60
.
.
.
.
.
.
.
.
.
.
6. Zusammenfassung und Ausblick
63
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A. Eidesstattliche Erklärung
65
B. Datenträger
67
Literaturverzeichnis
69
iv
Abbildungsverzeichnis
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
7
9
10
11
13
14
21
Verbindungen pro Manager und Agenteninstanzen . . . . . . . . . . . .
Verbindungen pro Analysekomponente . . . . . . . . . . . . . . . . . . .
Verbindungen pro Agenten-Gruppe . . . . . . . . . . . . . . . . . . . . .
Architekturübersicht mit neuem Kommunikationsmodell . . . . . . . . .
Vereinfachte Darstellung des Vererbungsmodells von Agent und AgentManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6. Klassendiagramm des AgentManagers (getter und setter-Methoden nicht
in Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7. Klassendiagramm des Agenten (getter und setter-Methoden sowie Hilfsmethoden nicht in Darstellung) . . . . . . . . . . . . . . . . . . . . . . .
3.8. Verbindungsverwaltung als abstrakte Fabrik . . . . . . . . . . . . . . . .
3.9. Analyseworkflow als Graph . . . . . . . . . . . . . . . . . . . . . . . . .
3.10. MQTTMessageConnection Klassendiagramm . . . . . . . . . . . . . . .
3.11. Listen/Notify-Mechanismus . . . . . . . . . . . . . . . . . . . . . . . . .
3.12. PostgresMessageConnection Klassendiagramm . . . . . . . . . . . . . . .
3.13. FTPDataConnection Klassendiagramm . . . . . . . . . . . . . . . . . .
3.14. PostgresDataConnection Klassendiagramm . . . . . . . . . . . . . . . .
.
.
.
.
27
28
29
30
3.1.
3.2.
3.3.
3.4.
3.5.
Benutzeroberfläche der Network Workbench) . . . . . . . . . . .
Text und Annonation (entnommen aus[Grishman, 1997]) . . . .
Ablauf einer Analyse in UIMA . . . . . . . . . . . . . . . . . . .
Ablauf Publisher/Subscriber Pattern . . . . . . . . . . . . . . . .
Beispiel Pipes and Filters . . . . . . . . . . . . . . . . . . . . . .
Abstrakte Fabrik (entnommen aus [Gamma et al., 1995]) . . . .
Grafische Oberfläche der Analytics Workbench . . . . . . . . . .
Architektur der Analytics Workbench . . . . . . . . . . . . . . .
FTP-Architektur (angelehnt an [Postel und Reynolds, 1985])
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 33
. 34
.
.
.
.
.
.
.
.
36
38
40
42
43
44
45
46
5.1. KOLEGEA Analyseworkflow . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2. Ergebnis der Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3. Ausschnitt des Analyseworkflows zur Performanceanalyse . . . . . . . . . 59
v
1. Einleitung
1.1. Motivation
Multiagentensysteme finden in verschiedenen Szenarien Anwendung, beispielsweise bei
Robotersystemen, Sensornetzwerken, verteilten Systemen oder bei der Gestaltung komplexer Softwaresysteme. Sie bestehen aus einer Menge von autonomen, miteinander agierenden Agenten, von denen jeder eine bestimmte Aufgabe übernehmen kann. Dies bietet
eine Reduktion der Komplexität eines Systems [Jennings, 2001] sowie ein erhöhtes Maß
an Flexibilität und Wiederverwendbarkeit, d.h. einzelne Agenten können hinzugefügt,
wiederverwendet, entfernt oder ausgetauscht werden.
Anwendung findet dieser Ansatz unter anderem in dem Analysesystem Analytics Workbench, einem Werkzeug zur Analyse verschiedener Daten. Hier werden verschiedene Analyseaufgaben von einzelnen Agenten übernommen, ein flexibles Hinzufügen von neuen
Analysekomponenten, sprich Agenten, ist möglich. Ein weiterer Vorteil, den der Multiagentenansatz in diesem Analysesystem bietet, ist die Möglichkeit der Sprachheterogenität. Dies bedeutet, dass nicht alle Analysekomponenten in der selben Programmiersprache realisiert werden müssen, da nicht jede Sprache für jeden Analyseschritt gleich
gut geeignet ist. Beispielsweise eignen sich für Textanalysen besonders die Bibliotheken
der Programmiersprache Python, für allgemeinere Aufgaben eher die Programmiersprache Java.
Durch den Einsatz in Forschungsprojekten haben sich die Anforderungen an die Analytics Workbench verändert. Analysen sollen mit großen Datenmengen durchführbar sein.
Außerdem soll das System skalierbar sein und auch eine Vielzahl von Analysekomponenten unterstützen. Diese beiden Anforderungen sind mit dem bisherigen Framework,
insbesondere mit der bisherigen Kommunikationsinfrastruktur, nicht zu erfüllen. Analysedaten können lediglich bis zu einer Größe von 4 Megabyte verarbeitet werden. Dadurch
sind Analysen auf großen Datensätzen nicht möglich. Auch führt eine erhöhte Belastung
der Kommunikationsinfrastruktur durch eine Vielzahl von Analysekomponenten zu einem fehlerhaften Systemzustand.
1.2. Aufgabenstellung
In dieser Abschlussarbeit soll ein Framework für Analysesysteme auf Multiagentenbasis
entwickelt werden. Dazu soll das bisherige Framework der Analytics Workbench als
Ausgangsbasis genommen werden. Das neu gestaltete Framework soll die ursprünglichen
Anforderungen der losen Kopplung der Agenten sowie der Sprachheterogenität erfüllen.
Des Weiteren sind folgende Anforderungen zu erfüllen:
1
1. Einleitung
• Es muss ein geeignetes Kommunikations- und Datenaustauschmodell gefunden
werden. Besonders der Austausch von größeren Datenmengen soll unterstützt werden. Gleichzeitig soll das System auch bei einer großen Anzahl an Agenten performant und stabil bleiben.
• Es müssen Kommunikationskanäle gefunden werden, die die Anforderungen an das
Kommunikations- bzw. Datenmodell erfüllen.
• Die Kommunikationskanäle sollen austauschbar sein und je nach Anwendungsfall
konfiguriert werden können, um ein höchstes Maß an Flexibilität zu garantieren.
• Um die Funktionalität des entworfenen Konzepts zu belegen, soll ein Beispielsystem
auf Basis der Analytics Workbench erstellt und demonstriert werden.
1.3. Aufbau der Arbeit
Im nachfolgenden Kapitel zwei werden die für diese Arbeit benötigten Grundlagen vorgestellt. Darunter fällt eine Definition von Agenten und Multiagentensystemen, die Vorstellung verwandter Arbeiten sowie eine Übersicht über Architektur- und Entwurfsmuster,
eine genaue Beschreibung der Analytics Workbench und eine Übersicht über Protokolle
bzw. Technologien zur Nachrichtenübertragung und Persistenz. Kapitel drei dokumentiert die Anforderungen an das zu entwickelnde Framework und beschreibt die Entscheidungsfindung bei der Gestaltung des Systems. Das vierte Kapitel enthält in Auszügen die
technische Realisierung des in Kapitel drei beschriebenen Konzepts. Ein Anwendungsbeispiel, das die Tragfähigkeit des Konzeptes belegt, wird in Kapitel fünf vorgestellt.
Das letzte Kapitel bietet eine Zusammenfassung über diese Arbeit und einen Ausblick
über potentielle Weiterentwicklungsmöglichkeiten.
2
2. Grundlagen
In diesem Kapitel werden alle für diese Arbeit benötigten Grundlagen vorgestellt. Hierzu
gehört eine Definition und Charakterisierung von Multiagentensystemen in Abschnitt 2.1
sowie ein Einblick in verwandte Arbeiten in Abschnitt 2.2. Abschnitt 2.3 erläutert die
Architekturmuster Blackboard und Publisher/Subscriber als auch die Entwurfsmuster
Pipes and Filters und Abstrakte Fabrik. Die Abschnitte 2.4 und 2.5 beschäftigen sich
mit den SQLSpaces und einer detaillierten Beschreibung des Analysesystems Analytics
Workbench. Ein Überblick über MQTT, PostgreSQL und FTP schließt diese Kapitel
ab.
2.1. Multiagentensysteme
In dieser Arbeit soll das Rahmensystem für ein Multiagentensystem einem Re-Engineering unterzogen werden. Daher ist es sinnvoll, zunächst den Begriff Multiagentensystem
genauer zu definieren und zu beschreiben. Wie der Name bereits suggeriert, besteht
ein Multiagentensystem aus mehreren Agenten. Die Definition eines Agenten ist in der
Literatur nicht eindeutig. Stattdessen werden Charakteristika verwendet, die die Beschaffenheit eines Agenten beschreiben. [Wooldridge, 1997] verwendet hierzu folgende
Eigenschaften:
• Sozial. Agenten können miteinander kommunizieren und sich an kooperativen Prozessen beteiligen, wie z.B. an Problemlösungsprozessen.
• Pro-Aktiv. Agenten reagieren nicht nur auf ihre Umgebung, sie können auch aktiv
einen Prozess initiieren.
• Autonom. Agenten sind unabhängig von anderen Agenten. Sie haben ihren eigenen
Zustand und können diesen ohne Einwirkung von Außen verändern.
• Reaktiv. Agenten kennen die Umgebung, in der sie sich befinden. Des Weiteren
können sie Änderungen an dieser Umgebung feststellen und entsprechend reagieren.
Setzt man bei der Systemgestaltung auf einen Agenten-basierenden Ansatz, reicht ein
Agent zur Lösung des Gesamtproblems meist nicht aus. Stattdessen verwendet man ein
Multiagentensystem, bestehend aus mehreren, autonomen Agenten [Jennings, 2001].
Diese unterstützen den Entwickler nach [Jennings, 2000] bei der Gestaltung komplexer
Systeme durch Dekomposition, Abstraktion und Organisation, welches wichtige Konzepte zur Vereinfachung und Komplexitätsreduktion sind. Durch die Dekomposition wird
ein Problem durch die Aufteilung in kleinere Unterproblem vereinfacht. Abstraktion
beschränkt ein Problem auf die wesentlichen Punkte und Organisation beschreibt die
Zusammenhänge zwischen verschiedenen Komponenten [Jennings, 2000].
Bei der Gestaltung eines Multiagentensystems stellt sich für den Entwickler vor allem
3
2. Grundlagen
das Problem, wie die Agenten miteinander kommunizieren. [Schumacher, 2001] stellt
dazu vier Kommunikationsparadigma vor: die Broadcast-, die Gruppen-, die Peer-ToPeer- und die Generative-Kommunikation. Im Broadcast-Kommunikationsmodell sendet
ein Agent eine Nachricht, die alle anderen Agenten in der Umgebung des Agenten erhalten. Etwas eingeschränkter ist der Nachrichtenversand bei der Gruppen-Kommunikation.
Hier erhält lediglich eine Gruppe von Agenten die gesendete Nachricht. Fällt die Entscheidung auf das Peer-To-Peer-Kommunikationsmodell, sind die Agenten zum Nachrichtenaustausch direkt miteinander verbunden. Dies ist nur möglich, wenn die Agenten eindeutig identifizierbar sind [Schumacher, 2001]. Eine Besonderheit ist das GenerativeKommunikationsparadigma. Hier verläuft der komplette Nachrichtenaustausch über ein
Blackboard (s. 2.3.1). Agenten können eigene Nachrichten auf dem Blackboard persistieren und Nachrichten von anderen Agenten aus dem Blackboard lesen. Auf diese Art
und Weise sind die Agenten komplett voneinander entkoppelt [Schumacher, 2001].
Neben einem geeigneten Kommunikationsparadigma muss ein Austauschformat bzw. eine ”Agenten-Sprache” festgelegt werden. Bekannte ”Agenten-Sprachen” zum Austausch
von Informationen zwischen Agenten sind FIPA-ACL 1 [Fipa, 2002] und KQML 2 [Finin
et al., 1994].
2.2. Verwandte Arbeiten
In diesem Abschnitt werden verwandte Arbeiten vorgestellt. Hierzu gehört das Analysetool Network Workbench sowie GATE und Apache UIMA.
2.2.1. Network Workbench
Die Network Workbench ist ein Tool zur Analyse von Netzwerken aus verschiedenen
Forschungsgebieten, wie beispielsweise aus der Informatik, der Biologie oder der Sozialwissenschaft [Herr et al., 2006]. Sie bietet zur Analyse von Netzwerken verschiedene Algorithmen, beispielsweise für ein Clustering oder zur Visualisierung eines Netzwerks. Da die Network Workbench auf dem Cyberinfrastructure Shell-Framework [for
Network Science Center, 2011] (welches selbst auf der OSGi-Spezifikation aufsetzt
[OSGi-Alliance, 2015]) basiert, können leicht neue Komponenten, wie z.B. weitere
Algorithmen, hinzugefügt werden [Börner et al., 2010].
Abbildung 2.1 zeigt die Benutzeroberfläche der Network Workbench. In der ’Console’
werden alle Rückmeldungen, wie über das Laden eines Datensatzes oder das Durchführen
eines Algorithmus, für den Benutzer ausgegeben. Der ’Data Manager’ enthält alle geladenen und verfügbaren Datensätze. Standardmäßig unterstützt die Network Workbench verschiedene Datenformate, wie beispielsweise GraphML, Pajek .NET oder CSV
[Team, 2009]. Im ’Scheduler’ kann eine Abfolge von Analyseschritten festgelegt werden.
Dies wird benötigt, da eine komplette Untersuchung eines Netzwerks meist aus mehreren Analyseschritten besteht. Die Reihenfolge der durchgeführten Analyseschritte kann
variiert werden. Durch den Abspielen-Button kann eine Analyse gestartet werden. Der
Status der einzelnen Analyseschritte wird durch Fortschrittsbalken angezeigt.
1
2
4
Foundation for Intelligent Physical Agents-Agent Communication Language
Knowledge Query and Manipulation Language
2.2. Verwandte Arbeiten
Abbildung 2.1.: Benutzeroberfläche der Network Workbench)
2.2.2. GATE
GATE (General Architecture for Text Engineering) bietet Sprachwissenschaftlern eine
Architektur für die Entwicklung von Sprachanalyseanwendungen [Cunningham, 2002]
und bietet diesen zusätzlich Komponenten zur Verarbeitung natürlicher Sprache, wie
Tagger oder Information Retrieval Tools [Cunningham, 2014]. Ähnlich wie das UIMAFramework von Apache (siehe Abschnitt 2.2.3) ist GATE komponentenbasiert. Entsprechend ist der wichtigste Teil in GATE die sogenannte CREOLE, die ’Collection
of REusable Objects for Language Engineering’. CREOLE beschreibt eine Sammlung
von Komponenten, die innerhalb von GATE verwendet werden können und hauptverantwortlich für die Analysevorgänge ist. Es gibt drei Typen von Komponenten: Visual
Resources, Language Resources und Processing Resources. Visual Resources sind darstellende Komponenten, die innerhalb der Benutzeroberfläche Anwendung finden [Cunningham, 2014]. Language Resources sind Datenquellen, wie Lexika oder Ontologien.
Sie beinhalten lediglich Daten, bieten aber keine Algorithmen zur Verarbeitung dieser
Daten. Diese Funktion erfüllen Processing Resources. Im Gegensatz zu den Language
Resources stellen diese nur Algorithmen zur Datenauswertung bereit, wie beispielsweise
Parser.
Zum Austausch von Daten zwischen den einzelnen Komponenten wird ein Dokument
beim Einlesen in eine Datenstruktur überführt, die den Dokumentinhalt und zusätzlich
Annotationen [Cunningham, 2014] enthält. Die Annotationen sind auf einer modifizierten Form des TIPSTER-Formats aufgebaut [Bontcheva et al., 2004]. Abbildung 2.2
zeigt beispielhaft eine Tabelle, die einen Satz mit entsprechenden Annotationen enthält.
Um Annotationen zu bestimmen, wird der Satz in seine einzelnen Glieder unterteilt.
Die Zeilen eins bis fünf geben an, um was für Satzglieder es sich handelt. NP steht für
ein Nomen im Singular, VBD für ein Verb in der Vergangenheitsform, DT für den Artikel und NN für ein Nomen im Singular mit unbestimmter Mengenangabe. Zeile sechs
5
2. Grundlagen
Abbildung 2.2.: Text und Annonation (entnommen aus[Grishman, 1997])
bestimmt das Nomen genauer, nämlich, dass es sich um einen Personennamen handelt.
Dass es sich bei den Wörtern, abgeschlossen durch den Punkt, um einen Satz handelt,
wird in Zeile sieben beschrieben.
Durch den komponentenbasierten Ansatz kann der Benutzer bei der Entwicklung einer
Sprachanalyseanwendung selbst entschieden welche Dokumente und welche Processing
Resources verwendet werden und in welcher Reihenfolge die einzelnen Analyseschritte
durchlaufen werden [Cunningham et al., 2002].
2.2.3. UIMA
Apache UIMA (Unstructured Information Management Architecture) ist ein Framework
zur Analyse von unstrukturierten Daten. Diese folgen, im Gegensatz zu strukturierten
Daten, keinem bestimmten Schema hinsichtlich ihrer Repräsentation. Typische Beispiele
für unstrukturierte Daten sind Text, Audio- oder Videodateien [Ferrucci und Lally,
2004].
Zur Analyse dieser Daten verwendet UIMA eine komponentenbasierte Architektur, hierbei werden alle Analyseschritte auf verschiedene Komponenten verteilt [Hahn et al.,
2008]. Innerhalb dieser wird zwischen Collection Readern, Analysis Engines und CAS
Consumers unterschieden. Collection Reader sind verantwortlich für das Einlesen von
zu analysierenden Dokumenten aus sogenannten Document Collections. Diese sind, wie
der Name bereits beschreibt, Ansammlungen von Dokumenten, die für eine Analyse relevant sind. Die Analyse eines Dokuments erfolgt durch Analysis Engines, die verschiedene Aufgaben übernehmen können, wie Textübersetzung oder Grammatiküberprüfung
[Ferrucci und Lally, 2004]. Hat eine Analysis Engine eine Analyse durchgeführt,
wird das Resultat in einer Common Analysis Structure (im Folgenden CAS genannt)
repräsentiert. In dieser befinden sich das Originaldokument (auch Subject of Analysis
genannt) und zusätzlich Annotationen, die Metadaten über das Originaldokument beinhalten und in Folge der Analyse entstanden sind [Götz und Suhre, 2004].
Üblicherweise besteht eine komplette Analyse aus mehreren Analyseschritten, die von
mehreren Analyse Engines, die Pipeline-artig miteinander verbunden sind, übernommen
werden (s. Abbildung 2.3). In jedem Analyseschritt wird die CAS zwischen den einzelnen
Engines ausgetauscht und von diesen erweitert, sodass am Ende eine CAS entsteht, die
das Originaldokument und alle Metainformationen aus den einzelnen Analyseschritten
enthält. Am Ende einer Analysekette stehen die CAS Consumer, die das komplette CAS
6
2.3. Architekturen und Entwurfsmuster
empfangen und Aufgaben erfüllen, wie beispielsweise eine Konvertierung in verschiedene Dateiformate [Ferrucci und Lally, 2004] und die letztendliche Überführung des
Dokuments in eine strukturierte Information.
Abbildung 2.3.: Ablauf einer Analyse in UIMA
2.3. Architekturen und Entwurfsmuster
In der Softwaretechnik wird zur Entwicklung von Software und komplexer Systeme auf
Architektur- und Entwurfsmuster zurückgegriffen. Sie erleichtern den Entwicklungsvorgang, bieten dem Entwickler Abstraktionsschichten und Schemata für den Aufbau des
zu entwickelnden Systems. Ein Entwurfsmuster ist nach Christopher Alexander wie folgt
definiert: ”Each pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem, in such a way
that you can use this solution a million times over, without ever doing it the same way
twice” [Alexander et al., 1977, s. x]. Es beschreibt also eine Lösung zu einem in verschiedenem Kontext wiederholt auftretenden Problem, die sich immer wieder auf dieses
Problem anwenden lässt.
Im Folgenden werden die Architekturmuster Blackboard, als Muster für eine Problemlösungsstrategie, Publisher/Subscriber, als Muster für Kommunikation zwischen lose gekoppelten Komponenten, Pipes and Filters, als Muster für die Transformation von Datenströmen sowie das Entwurfsmuster Abstract Factory, als Muster zur Kapselung der
Objekterzeugung, vorgestellt.
2.3.1. Blackboard-Architektur
Die Blackboard-Architektur ist ein Architekturmuster zur Problemlösung und hat ihren
Ursprung in dem in [Erman et al., 1980] vorgestellten ”Hearsay-II speech-understanding
system”. Hierbei handelt es sich um ein Spracherkennungssystem, bei dem gesprochene
Worte nach einer Reihe von Transformationen durch das System erkannt werden. Dieser
Prozess der Worterkennung ist mittels Blackboard-Architektur realisiert worden.
Um die Idee hinter diesem Architekturmuster zu verstehen, verwendet [Corkill, 1991]
folgende Metapher: Vor einer Tafel sitzen Experten, die zu einem bestimmten Thema
eine bestimmte Kompetenz besitzen. Die Experten arbeiten zusammen an der Lösung
7
2. Grundlagen
eines Problems. Die Tafel dient als Oberfläche, um die Lösung zusammenzutragen. Findet ein Experte auf der Tafel ein Teilproblem zu dem er etwas beitragen kann, fügt der
Experte sein Wissen dem bisherigen Wissen hinzu. Dieser Prozess beginnt, wenn das
Problem und die initialen Daten auf der Tafel stehen und wiederholt sich so lange, bis
das Problem gelöst ist.
Es ergeben sich also folgende Komponenten innerhalb einer Blackboard-Architektur: die
Wissensquellen, die Tafel oder auch das Blackboard und der Blackboard-Monitor sowie
Scheduler als Kontrollkomponenten.
Wissensquellen tragen mit ihrem Wissen zur Lösung eines Problems bei. Sie zeichnen
sich dadurch aus, dass sie unabhängig von allen anderen Wissensquellen existieren und
auch keine Kenntnis über alle anderen Wissensquellen besitzen. Ihren Beitrag zur Problemlösung tragen sie durch das Eintreten einer bestimmten Bedingung bei. [Erman
et al., 1980] bezeichnet Wissensquellen aus diesem Grund als ”condition-action pair”
[Erman et al., 1980, S. 218]. Condition bezeichnet hier die Bedingung, unter der eine Wissensquelle ausgelöst wird. Action bestimmt welcher Beitrag zur Problemlösung
geleistet wird. Da Wissensquellen voneinander unabhängig sind und daher nicht direkt
miteinander kommunizieren, erfolgt die Kommunikation über ein Blackboard.
Das Blackboard repräsentiert eine globale Datenbank zu der Zwischenlösungen beitragen, bereits vorhandene Zwischenlösungen modifiziert und finale Lösungen gespeichert
werden können [Erman et al., 1980]. Gleichzeitig dient das Blackboard auch als Auslöser
für die einzelnen Wissensquellen. Befinden sich in dem Blackboard für eine Wissensquelle
relevante Daten, wird die Wissensquelle aktiviert und sie trägt ihr Wissen zu der bereits
vorhandenen Zwischenlösung bei.
Der Blackboard-Monitor überwacht Änderungen am Blackboard und erhält so einen
globalen Zustand, womit eine Prioritätenreihenfolge festgelegt werden kann. Auf diese
Weise kann die Ausführung der einzelnen Wissensquellen durch den Scheduler koordiniert werden.
Passende Einsatzgebiete für eine Blackboard-Architektur sind Systeme, deren Komponenten Heterogenität bezüglich ihrer Lösungsexpertise bieten sollen oder solche, die von
verschiedenen Entwicklern implementiert werden. In letzterem Fall bietet der BlackboardAnsatz den Vorteil, dass die Komponenten einzeln entwickelt, getestet und gewartet
werden können. Trotz der Vorteile, ist der Architekturansatz im Rahmen der Systemgestaltung nicht weit verbreitet. Dies liegt daran, dass sich die Vorteile nicht auf einfache
Systeme übertragen lassen und nur für komplexe Systeme relevant sind [Corkill, 1991].
Zudem bietet die Blackboard-Architektur zwar ein gutes Verständnis über den Aufbau
eines Systems und hilft bei der Entwicklung eines Prototyps, dass Endprodukt lässt sich
aber auch ohne Blackboard-Architektur realisieren [Corkill, 1991].
2.3.2. Publisher/Subscriber-Architektur
Moderne, verteilte Systeme bestehen häufig aus einer Vielzahl an Komponenten und erfordern ein geeignetes Kommunikationsmodell. Punkt-zu-Punkt- und synchrone Verbindungen zwischen den Komponenten führen zu unflexiblen Systemen und sind somit nicht
geeignet [Eugster et al., 2003]. Einen anderen Ansatz verfolgt das Publisher/SubscriberPattern. Hier läuft die Kommunikation über eine zentrale Kommunikationseinheit, einem
Bus oder Message Broker, sodass alle Komponenten sind mit der zentralen Kommunikationseinheit verbunden sind. Dieses Kommunikationsparadigma wird als Many-to-many
8
2.3. Architekturen und Entwurfsmuster
bezeichnet [Baldoni et al., 2003].
Der Kommunikationsablauf wird im Folgenden beschrieben. Die einzelnen Komponenten
können zwei Rollen einnehmen: Zum einen die Rolle des Subscribers, in der sie Nachrichten erhalten und zum anderen die Rolle des Publishers, in der sie diese veröffentlichen.
Um zu verhindern, dass alle Kommunikationsteilnehmer in Subscriber-Rolle jegliche
Nachrichten erhalten, können bei der zentralen Kommunikationseinheit Nachrichtentypen angegeben werden, zu denen Nachrichten erhalten werden sollen. Anhand dieser angegebenen Nachrichtentypen wird selektiert, welcher Subscriber welche Nachricht
erhält. In Abbildung 2.4 wird der Kommunikationsablauf verdeutlicht. Die Komponen-
Abbildung 2.4.: Ablauf Publisher/Subscriber Pattern
ten 1 und 2 sind Subscriber und lediglich interessiert an temperature-, beziehungsweise
speed-Nachrichten. Die Komponenten 3 und 4 sind Publisher. Sie senden temperatureund speed-Nachrichten an die zentrale Kommunikationskomponente. Diese wiederum
sendet die Nachrichten an die jeweils relevante Komponente. In einem Anwendungsfall
könnten Komponenten 1 und 2 Kontrolleinheiten darstellen und Komponenten 3 und 4
Sensoren, die in bestimmten Zeitintervallen die Kontrolleinheiten benachrichtigen.
Die Vorteile dieses Kommunikationsmodells sind die komplette Entkopplung auf Zeit-,
Raum- und Synchronisationsebene [Eugster et al., 2003]. Dies bedeutet, dass die Kommunikationspartner nicht zeitgleich existieren müssen, dass sie sich nicht kennen und
dass sie sich nicht beim Senden beziehungsweise Empfangen einer Nachricht blockieren
[Baldoni et al., 2003].
Zur Kategorisierung von Publisher/Subscriber-Systemen verwendet man die Begriffe
Content-based und Topic-based. Diese charakterisieren die Art und Weise, wie an der
zentralen Kommunikationskomponente Nachrichten zu Subscribern zugeordnet werden.
In einem Content-based System können sich Subscriber auf den tatsächlichen Inhalt
einer Nachricht registrieren [Rosenblum und Wolf, 1997]. Hierzu kann eine spezielle Subscription-Language verwendet werden [Eugster et al., 2003], mit Hilfe dieser
Eigenschaften der Nachrichten spezifiziert werden. Anhand dieser wird bestimmt, ob
ein Subscriber eine Nachricht erhält oder nicht. Auf diese Art und Weise lässt sich die
Beschaffenheit der Nachricht, die der Subscriber erhalten soll, wesentlich detaillierter
spezifizieren als bei einem Topic-based System.
Bei einem Topic-based System hingegen werden Nachrichten nur anhand von Topics
gefiltert. Topics sind dabei logische Kanäle. Alle Kommunikationspartner die sich auf
ein bestimmtes Topic registriert haben, erhalten alle Nachrichten, die in diesem Topic
veröffentlicht werden. Die Topic-based Systeme haben den Vorteil, dass sie auf Grund
der einfachen Logik eine effiziente Implementierung ermöglichen und gleichzeitig dem
Benutzer leicht zugänglich sind [Milo et al., 2007].
9
2. Grundlagen
2.3.3. Pipes and Filters
In manchen Systemen müssen Datenströme eine Reihe von Verarbeitungsschritten durchlaufen. Dies könnte in einer einzigen Filterkomponente des Systems stattfinden. Einen
anderen Ansatz stellt das Pipes and Filters Entwurfsmuster dar. Hier werden alle benötigten Verarbeitungsschritte in einzelne Module, auch als Filter bezeichnet, aufgeteilt. So
ist jeweils ein Modul für einen Verarbeitungsschritt verantwortlich [Buschmann, 1998].
Diese Module werden durch Pipes miteinander verbunden. Sie haben die Aufgabe, Daten von einem Modul zum Nächsten zu transportieren. Die Datenströme durchlaufen
auf diese Weise die einzelnen Module und werden so in den gewünschten Endzustand gebracht (Abbildung 2.5). Die zu erfüllenden Aufgaben der Filter können variieren. Filter
können [Buschmann, 1998]:
• Zu den bisherigen Daten weitere Informationen hinzufügen. So könnte beispielsweise ein Text mit Metainformation angereichert werden und die Satzglieder der
im Text vorkommenden Sätze bestimmt werden.
• Die bereits vorhandenen Daten verfeinern. Hier könnten aus Analyse-Logs die Ereignisse auf bestimmte Tage oder Stunden fixiert werden.
• Die bereits vorhandenen Daten umwandeln. So können Sie einen Text von einer
Repräsentation in eine Andere bringen.
Abbildung 2.5.: Beispiel Pipes and Filters
Angewendet wird dieses Entwurfsmuster im Betriebssystem UNIX [Buschmann, 1998].
So können durch die Verwendung des |-Symbols, Daten von einer Komponente zur
Nächsten weitergereicht werden. So liest der Kommandozeilenbefehl ’cat names.txt |
wc’ zunächst den Inhalt der Textdatei ’names.txt’ aus und leitet die gelesenen Daten
weiter. Der Filter ’wc’ zählt dann die in dem Text vorkommenden Zeichen, Wörter und
10
2.3. Architekturen und Entwurfsmuster
Zeilen.
Durch die strikte Trennung der Filter können diese innerhalb der Anwendung wiederverwendet, ausgetauscht, entfernt oder hinzugefügt werden [Buschmann, 1998]. Außerdem
lässt sich auf diese Weise eine parallele Verarbeitung ermöglichen. Ob das Muster angewendet werden kann, hängt in erster Linie davon ab, ob die Verarbeitungsschritte
voneinander getrennt werden können. Hängen die Verarbeitungsschritte zusammen, ist
eine Aufteilung und somit auch die Anwendung des Musters nicht möglich.
2.3.4. Abstrakte Fabrik
Das Entwurfsmuster Abstrakte Fabrik, auch als Kit bezeichnet, gehört zu der Kategorie
der Erzeugungsmuster. Es dient dazu miteinander verwandte Objekte zu erstellen, ohne
konkrete Klassen anzugeben [Gamma et al., 1995]. Dies ist besonders hilfreich, wenn
ein System mit einer bestimmten Objektfamilie konfiguriert werden soll oder der Objekterzeugungsprozess unabhängig von dem Systemkontext geschehen soll [Gamma et al.,
1995]. Das Erstellen einer solchen Objektfamilie erfolgt über eine abstrakte Schnittstelle,
die Abstrakte Fabrik (Abstract Factory).
Die gesamte Struktur des Musters inklusive aller Komponenten zeigt Abbildung 2.6.
Die Klasse AbstractFactory repräsentiert das Interface für die Erstellung der abstrakten Produkt-Objekte. ConcreteFactory1 und ConcreteFactory2 erweitern die Klasse AbstractFactory und implementieren die Methoden CreateProductA() beziehungsweise CreateProductB(), um die konkreten Objekte ProductA1, ProductA2, ProductB1 und ProductB2 zu erstellen. Die beiden Produktfamilien ProductA1, ProductA2 und ProductB1,
ProductB2 werden definiert durch das Interface der Klassen AbstractProductA bzw. AbstractProductB. Die Vorteile bei der Verwendung des Patterns sind nach [Gamma et al.,
Abbildung 2.6.: Abstrakte Fabrik (entnommen aus [Gamma et al., 1995])
11
2. Grundlagen
1995] das Kapseln des Objekterzeugungsprozesses durch die einzelnen Fabriken. Auch
können konkreten Fabriken leicht angepasst werden, falls eine Änderung an den konkreten Objekten erwünscht ist. Ebenfalls gewährleistet das Erstellen von Objektfamilien
durch eine Abstrakte Fabrik Konsistenz innerhalb dieser Objektfamilien.
2.4. SQLSpaces
SQLSpaces ist ein Framework zur Gestaltung verteilter Systeme [Weinbrenner, 2012]
und eine Implementierung des TupleSpace Konzepts, welches auf [Gelernter, 1985]
zurück geht.
Die Idee hinter dem TupleSpace-Konzept basiert auf dem in Kapitel 2.3.1 beschriebenen
Blackboard-Ansatz. Clients sind hierbei nicht direkt miteinander verbunden, sondern
über einen zentralen Server. Dieser beinhaltet alle Nachrichten der Clients [Giemza
et al., 2007]. Die Nachrichten basieren dabei auf Tupel, d.h. eine Liste (x1 , .., xn ) von
n Objekten. Um dem Server Nachrichten hinzuzufügen, diese vom Server zu entfernen
oder zu lesen, bieten sich drei Operationen: out(), in() und read() [Gelernter, 1985].
Out() fügt ein Tupel dem Server hinzu, in() nimmt ein Tupel aus dem Server und gibt
es an den Client zurück, read() gibt ein Tupel an den Client zurück. Im Unterschied zu
in() wird das Tupel aber nicht vom Server entfernt. Um Suchanfragen zu stellen, können
zum einen konkrete Werte verwendet werden, z.B. (Stefan, true). Zusätzlich werden auch
Wildcard-Felder unterstützt, wie beispielsweise read(i:integer, j:string). Eine Suchanfrage in dieser Form liest alle Tupel, die aus einer Integerzahl und einem String in beliebiger
Form bestehen.
Die SQLSpaces bieten, neben den für TupleSpaces typischen Basisfunktionalitäten, weitere Features. So können dank Schnittstellen für verschieden Programmiersprachen sprachheterogene, verteilte Systeme entwickelt werden, da die einzelnen Komponenten nicht
in der selben Programmiersprache entwickelt werden müssen. Auch können außer den
Operationen out(), in() und read() blockende Operationen verwendet werden, beispielsweise waitToTake(). Das Besondere an dieser Operation ist, dass als Parameter für die
waitToTake()-Funktion ein Tupel oder eine Signatur von einem Tupel angegeben werden
kann, welches noch nicht existiert. Sobald ein Tupel von der Form den SQLSpaces hinzugefügt wird, wird es dem Client, der diese Funktion aufgerufen hat, zurückgegeben und
aus den SQLSpaces entfernt. Ein weiteres Feature, nämlich der Callback-Mechanismus,
ist besonders hinsichtlich der Blackboard-Architektur von Bedeutung. Clients können
sich bei den SQLSpaces auf Tupel und Operationen bestimmter Form für Callbacks
registrieren, beispielsweise (Stefan, 5, 2, 1990) mit der Operation Löschen. Sobald auf
diesem Tupel-Typ die angegebene Operation durchgeführt wird, wird der registrierte Client benachrichtigt. Auf diese Weise können die Komponenten eines Blackboard-Systems
indirekt miteinander Kommunizieren.
Auf technischer Ebene liegt auf unterster Schicht der SQLSpaces eine relationale Datenbank [Weinbrenner, 2012]. Unterstützt werden verschiedene relationale Datenbanken,
z.B. MySQL und HSQL [COLLIDE, 2012].
12
2.5. Analytics Workbench
2.5. Analytics Workbench
Die Analytics Workbench ist ein Werkzeug zur Analyse verschiedener Daten. Es wurde unter der Prämisse entwickelt, leicht benutzbar und flexibel erweiterbar zu sein
[Göhnert et al., 2014]. Um einem Benutzer das Erstellen einer Analyse zu vereinfachen,
bietet die Workbench eine Weboberfläche, die gleichzeitig der visuellen Darstellung des
Analyseprozesses dient. Die Abbildung 2.7 stellt den Aufbau dieser Nutzerschnittstelle
dar.
Auf der linken Seite befinden sich die zur Verfügung stehenden Analysemodule, die
per Drag-and-Drop im Zentrum der Oberfläche angeordnet werden können. Die Verknüpfungen der einzelnen Module ermöglichen Pfeile, wodurch eine Pipes and Filtersähnliche Struktur entsteht (s. 2.3.3). Hierbei repräsentieren die einzelnen Analysemodule
die Filter, in denen Daten weiterverarbeitet werden und die Pfeile die Pipes, die dazu dienen, Datenströme weiterzuleiten. Neben der Visualisierung gibt der zentrale Bereich der
Oberfläche während der Durchführung einer Analyse Aufschluss über den aktuellen Analyseschritt. Je nach aktuellem Zustand werden die Analysekomponenten gefärbt. So sind
bereits abgearbeitete Analysekomponenten grün gefärbt, laufende Analysekomponenten
sind gelb gefärbt. Die Analyse in der Abbildung beinhaltet vier Module, bestehend aus
dem Data Repository (einer Datenquelle), der Format Transformation (einem Modul
zur Umwandlung verschiedener Dateiformate), dem Biclique Communities Modul (zur
Analyse der Daten) und dem Super Graph Modul, das für die Visualisierung der Analyseergebnisse verantwortlich ist.
Auf der rechten Seite bietet die Weboberfläche Informationen über den Status sowie die
Ergebnisse der Analyse. Um neue Workflows zu erstellen, Gespeicherte zu laden, Eigene
zu speichern und auszuführen und um Ergebnisse von bereits durchgeführten Analysen
einzusehen, steht eine Menüleiste am oberen Rand der Oberfläche zur Verfügung.
Initial stellt die Workbench Komponenten für verschiedene Operationen bereit. So gibt
es Komponenten für die Eingabe und Transformation von Daten sowie Komponenten
zur Analyse und Repräsentation analysierter Daten, wie beispielsweise ”Main Path Analysis” und ”Bar Chart” [Göhnert et al., 2014]. Bei der Konzeption des Systems wurde
Wert auf Erweiterbarkeit gelegt, sodass es möglich ist, eigene Agenten zu entwickeln.
Abbildung 2.7.: Grafische Oberfläche der Analytics Workbench
13
2. Grundlagen
2.5.1. Architektur
Im Wesentlichen besteht die Architektur der Workbench (Abbildung 2.8) aus fünf Komponenten, den Agenten, dem SQLSpaces-Server, der Node.js Serverkomponente, der Weboberfläche und dem Result-Repository. Die Durchführung einer Analyse wird durch ein
Multiagentensystem (s. 2.1), das heißt eine Vielzahl von unabhängigen Agenten (s. 2.1)
realisiert. Hier entspricht ein auswählbares Analysemodul in der Weboberfläche einem
Agenten [Göhnert et al., 2014]. Die Kommunikation zwischen den Agenten erfolgt über
einen SQLSpaces-Server (s. 2.4). Dieser bietet Schnittstellen für verschiedene Programmiersprachen, wodurch Agenten in unterschiedlichen Programmiersprachen entwickelt
werden können. Ebenfalls mit dem SQLSpaces-Server verbunden, ist die Node.js Serverkomponente. Sie stellt die Weboberfläche bereit und fungiert als Schnittstelle zwischen
der Weboberfläche und dem Multiagentensystem [Göhnert et al., 2013] als auch als
Kontrollkomponente über die Durchführung eines Workflows. Die Weboberfläche dient
zur Interaktion mit dem Benutzer. Mittels dieser kann er Analysen gestalten, modifizieren und durchführen. Komplettiert wird die Architektur durch das Result-Repository. In
diesem werden Analyseergebnisse gespeichert und können bei Bedarf abgerufen werden.
Abbildung 2.8.: Architektur der Analytics Workbench
2.5.2. Ablauf eines Workflows
Um einen Analyseworkflow zu starten, werden sogenannte Command-Tupel in den SQLSpaces gespeichert. Sie werden typischerweise aus dem Workflow erzeugt, den ein Benutzer in der Weboberfläche konfiguriert hat. Dabei wird pro Analyseschritt ein CommandTupel generiert, in dem Informationen über die ein- und ausgehenden Pipes des Moduls gespeichert sind [Göhnert et al., 2013]. Verantwortlich für diesen Vorgang ist die
14
2.5. Analytics Workbench
Node.js-Serverkomponente. Es ist aber auch möglich, dass eine andere Komponente diese Tupel generiert, in die SQLSpaces schreibt und so den Analysevorgang auslöst. Um
der Weboberfläche eine Rückmeldung über den aktuellen Status eines Moduls zu geben,
beinhalten Command-Tuple noch ein weiteres Feld. Der Status eines Moduls kann entweder wartend, durchführend, fehlerhaft oder abgeschlossen sein.
Empfängt ein Analysemodul ein Command-Tupel, liest es anhand der eingehenden Pipes die relevanten Daten, führt den Analyseprozess durch und speichert die modifizierten
Daten in den ausgehenden Pipes. Dies bedeutet, dass neben der Darstellung des Analyseworkflows auf der Weboberfläche in Pipes and Filters-Struktur, auch die interne
Verarbeitung über den Pipes and Filters-Ansatz erfolgt. Die Daten, die zwischen den
Modulen ausgetauscht werden, werden durch Data-Tupel repräsentiert. Diese beinhalten eine Zuordnung zu den entsprechenden Pipes sowie die tatsächlichen Nutzdaten
und Informationen über deren Beschaffenheit. Wird innerhalb des Workflows ein Modul
erreicht, dass keine ausgehenden Pipes besitzt, wird ein Result-Tupel erzeugt. Dieses
enthält einen Link auf das Analyseergebnis des korrespondierenden Analysezweigs sowie
einen Namen und eine Beschreibung des Resultats. Werden alle Module ohne ausgehende
Pipes erreicht, ist der Workflow abgeschlossen. Falls der Workflow aus der Benutzeroberfläche gestartet wurde, erhält diese Rückmeldung über die erfolgreiche Durchführung
der Analyse.
2.5.3. Kommunikation
Wie bereits beschrieben, verwendet die Analytics Workbench zum Nachrichten- und Datenaustausch zwischen den Komponenten verschiedene Tupel-Typen. Diese Tupel-Typen
lassen sich in zwei Kategorien einteilen. Zum einen sind dies Tupel, die nur für die Koordination des Analyseworkflows zuständig sind und zum anderen Tupel, die über einen
Workflow hinaus bestehen müssen.
Command-, Data- und Error-Tupel gehören in die erste Kategorie. Sie koordinieren
und starten einen Workflow, dienen zum Datenaustausch zwischen den Agenten und
indizieren einen fehlerhaften Agentenzustand. Nach dem Abschluss des Analyseworkflows werden sie nicht weiter benötigt. Command-Tupel haben die folgendene Signatur:
{Run-Id, Agent-State, Instance-Id, Agent-Id, Pipes, Parameters}. Die Felder Run-Id,
Agent-State, Instance-Id und Agent-Id beschreiben zu welchem Analysedurchlauf und
zu welchem Agenten dieses Tupel gehört, das Feld Pipes beinhaltet alle ausgehenden
Pipes des Agenten [Göhnert et al., 2013] und Parameters umfasst alle für den Agenten verantwortlichen Parameter. Data-Tupel beinhalten die Felder Run-Id, Pipe-Id und
Data. Run-Id und Pipe-Id beschreiben für welche Analyse und für welche Pipe die im
Feld Data hinterlegten Nutzdaten sind [Göhnert et al., 2013].
Im Gegensatz dazu stehen Workflow Save-, Run-, Result-, User-, Group-, Role-, User
Group Link-, User Role Link-, Workflow Group Link- und Run Group Link-Tupel. Diese
beinhalten Informationen, die auch außerhalb einer Analyse relevant sind. Um die Menge
der Analyse-übergreifenden Tupel weiter zu verfeinern, können diese wiederum in zwei
Kategorien eingeteilt werden: in Tupel, die Daten über Workflows speichern und Tupel
zur Benutzerverwaltung. Zu den Tupeln, die Daten über Workflows speichern, gehören
Workflow Save-, Run- und Result-Tupel. Workflow Save-Tupel repräsentieren einen vom
Benutzer erstellten und gespeicherten Analyseworkflow. Run-Tupel speichern den Status eines Workflows (fehlerhaft oder abgeschlossen) sowie das Ausführungsdatum, den
15
2. Grundlagen
Workflow-Name und die Beschreibung. Result-Tupel beinhalten einen Verweis auf ein
Analyseresultat sowie Name und Beschreibung des Resultats.
Für die Benutzerverwaltung innerhalb der Workbench werden User-, Group-, Role-, User
Group Link-, User Role Link-, Workflow Group Link- und Run Group Link-Tupel verwendet. Benutzer, Benutzergruppen und Benutzerrollen werden auf User-, Group- und
Role-Tupel abgebildet. Verknüpft werden Benutzer, Gruppen und Rollen durch User
Group Link-, User Role Link-Tupel. Für Workflows kann ein Benutzer entscheiden, ob
er diese für alle anderen Benutzern zur Verfügung stellen möchte oder nur einer bestimmten Gruppe. Hierzu dienen Workflow Group Link- und Run Group Link-Tupel.
Sie ordnen erstellten Workflows und durchgeführten Analysen bestimmte Gruppen zu.
Eine Besonderheit sind Auto Execution Tupel und Agent Description Tupel. Erstere
dienen dazu einen automatischen Workflow-Ablauf zu konfigurieren, sodass ein Workflow (wiederholt) durchgeführt werden kann, ohne das er durch den Benutzer gestartet
wird. Letztere sind Beschreibungs-Tupel. Sie repräsentieren einen Analyseagenten und
existieren so lange, wie die Analysekomponente läuft. Ihren Verwendungszweck finden
sie in der Weboberfläche. Anhand der Beschreibungs-Tupel kann diese alle laufenden
Analyseagenten bestimmen.
2.5.4. Framework
Bis jetzt war im Zusammenhang der Analytics Workbench immer von Agenten oder Analysekomponenten die Rede. Im Framework der Analytics Workbench sind diese Teil des
Agenten-Frameworks, welches in Java entwickelt ist. Prinzipiell können Agenten aber in
jeder Programmiersprache entwickelt werden, die das Tupel-Protokoll unterstützen und
so mit einem SQLSpaces-Server kommunizieren können [Göhnert et al., 2013].
Die Basis einer Analysekomponente sind der Agent-Manager und zugehörige Agenten.
Der Agent-Manager eines Analysemoduls dient zum Verwalten mehrere Agenteninstanzen. Wird er gestartet, fügt er den SQLSpaces sein Beschreibungs-Tupel hinzu. Des
Weiteren registriert sich der Agent-Manager bei dem SQLSpaces-Server auf ein für ihn
spezifisches Command-Tupel (s. 2.5.2 und 2.4), nämlich auf ein Command-Tupel, welches als Feld Agent-Id die eigene Bezeichnung enthält. Wenn dieses Command-Tupel
dem SQLSpaces-Server hinzugefügt wird, startet der Agent-Manager eine Agenteninstanz [Göhnert et al., 2013].
Die Agenteninstanz ist das Herzstück des Analysemoduls. Sie registriert sich beim
SQLSpaces-Server auf ein Data-Tupel, welches die Id der aktuellen Analyse und die
eingehende Pipe des Analysemoduls beinhaltet (s. 2.5.2). Erreicht sie ein solches DataTupel, beginnt die eigentliche Analyse oder Aufgabe des Analysemoduls. Auf diese Art
und Weise ist eine Agenteninstanz an einen Analysedurchlauf gebunden. Ist die Analyse oder die Aufgabe abgeschlossen, schreibt die Agenteninstanz ihre Resultate mittels
eines Data-Tupels in den SQLSpaces-Server und beendet sich daraufhin. Während der
einzelnen Schritte, das heißt Beginn und Ende der Analyse beziehungsweise Aufgabe,
benachrichtigt die Agenteninstanz den zugehörigen Agent-Manager über ihren Status.
Dieser gibt Rückmeldung an die Weboberfläche, wodurch die Analysemodule auf der
Weboberfläche entsprechend ihres Status gefärbt werden.
Neben den Analysekomponenten gibt es noch Infrastruktur-Komponenten. Sie erfüllen
keine Analysezwecke, sondern haben Aufgaben, die die Umgebung betreffen, wie zum
Beispiel das Sammeln von Ergebnissen einer Analyse. Diese Aufgabe erfüllt der Result
16
2.5. Analytics Workbench
Collector. Er wartet bis alle Analysekomponenten, die keine ausgehenden Pipes haben,
ein Ergebnis produziert haben und schreibt dann Result-Tupel. Diese werden verwendet,
um die Ergebnisse abrufen und anzeigen zu können.
Um Agenten beziehungsweise Agent-Manager starten zu können, wird eine ExecutorKomponente verwendet. Anhand einer Konfigurationsdatei, die angibt, welche Analysekomponenten gestartet werden sollen, werden die Agent-Manager zu den Analysekomponenten gestartet. Zudem bietet die Executor-Komponente ein Menü auf Konsolenbasis,
womit unter anderem einzelne Analysekomponenten gestartet werden können oder eine
Übersicht aller laufenden Analysekomponenten ausgeben werden kann.
Außer der Konfigurationsdatei, die die zu startenden Agenten angibt, gibt es eine weitere Konfigurationsdatei für Umgebungsvariablen, zum Beispiel Adresse und Port des
SQLSpaces-Servers. Beim Starten des Executors wird die Konfigurationsdatei eingelesen
und den einzelnen Komponenten die benötigten Umgebungsvariablen übergeben.
Um neue Agenten zu entwickeln, müssen, wie bereits beschrieben, ein Agent-Manager
und ein Agent implementiert werden. Zur Vereinfachung des Entwicklungsprozesses bietet das Framework die Klassen AgentManager und Agent an. Diese beinhalten die Basisfunktionalitäten, die jeder Agent-Manager bzw. Agent beherrschen muss. Für die eigene Implementierung leitet der Entwickler von den Klassen ab und muss lediglich die
für den Agent-Manager bzw. Agent spezifische Funktionalität hinzufügen. Soll die neu
entwickelte Analysekomponente verwendet werden, muss sie in die Konfigurationsdatei
eingetragen werden.
Eine Besonderheit unter den Agenten bilden R-Agenten, welche dazu dienen, Analysen
auch in R durchführen zu können [Göhnert et al., 2013]. R ist eine Programmiersprache für Datenanalysen [Ihaka und Gentleman, 1996]. Die Entwicklung von RAgenten erfolgt durch Erweitern der R-Wrapper-Analysekomponente. Diese dient dazu,
in den R-Agenten spezifizierte R-Skripte auszuführen. Das Ausführen des Skripts erfolgt
über eine Bibliothek, die es erlaubt R aus Java aufzurufen. Dieses wird benötigt, da die
R-Wrapper-Analysekomponente in Java entwickelt wurde.
2.5.5. Probleme
Kleine Analysen können mit der Analytics Workbench schnell und performant durchgeführt werden. Bei der Analyse von Daten innerhalb komplexer Workflows mit einer
Vielzahl von Agenten oder bei großen Analysedaten, offenbart das System Schwachstellen. Diese sollen im Folgenden beschrieben werden.
1. Wie in Abschnitt 2.5.3 beschrieben, läuft die Kommunikation der Agenten über
einen SQLSpaces-Server. Bei der Durchführung eines komplexen Workflows registriert sich eine große Zahl von Agenten bei diesem Server auf Callbacks bestimmter
Tupel-Typen (s. 2.4). Dadurch wird dieser bei der Durchführung der Analyse stark
belastet, was bedingt, dass er nicht mehr erreichbar ist. Dies zieht den Abbruch der
Analyse nach sich. Die Weboberfläche ist für den Benutzer nur noch eingeschränkt
nutzbar. Alle Aktionen, die Datenbankzugriff benötigen (beispielsweise die Benutzeranmeldung), sind nicht mehr durchführbar. Für den Benutzer hat dies zur Folge,
dass er das System als solches nicht mehr verwenden kann. Das Problem lässt sich
nur durch einen Neustart des SQLSpaces-Servers beheben.
17
2. Grundlagen
2. Die Behandlung größerer Datenmengen ist in einem Analysesystem erforderlich. In
der Analytics Workbench ist es nicht möglich, Daten mit einer Größe von über 4
Megabyte als Ausgangspunkt für eine Analyse zu verwenden. Dies ist auf technische
Limitierungen seitens des SQLSpaces-Servers zurückzuführen. Tupel, die Daten
über 4 Megabyte enthalten, können nicht verarbeitet werden.
3. Durch sich ändernde Anforderungen, muss ein System flexibel gestaltet sein. Treten
Probleme auf, wie beispielsweise die Limitierungen durch den SQLSpaces-Server,
muss es möglich sein zu reagieren und Teile des Systems leicht austauschen zu
können. Das Auswechseln des SQLSpaces-Server stellt sich aufgrund der Datenverarbeitung innerhalb des Frameworks als schwierig dar. Sämtliche Nachrichten
und Daten werden über das Tupel-Format ausgetauscht und müssten bei einer
anderen Kommunikationslösung in ein anderes Datenformat überführt werden.
2.6. Nachrichtenaustausch und Speicher
Innerhalb eines verteilten Systems spielen Persistenz und Nachrichtenaustausch eine
bedeutende Rolle, diese sollten besonders während der Konzeptionsphase des Systems
berücksichtigt werden. In diesem Kapitel werden MQTT, PostgreSQL und FTP vorgestellt. MQTT ist ein leichtgewichtiges Nachrichtenaustauschprotokoll, welches in
Publisher/Subscriber-Systemen (s. 2.3.2) Anwendung findet. PostgreSQL, welches Daten in relationalen Schemata ablegt und FTP, welches Daten auf Dateisystemebene
speichert, sind für Persistenz verantwortlich.
2.6.1. MQTT
Durch die Entstehung der Internet der Dinge-Bewegung haben sich die Anforderungen an die Netzwerkverbindungen verändert. Internet der Dinge meint eine Verbindung
zwischen alltäglichen Dingen, ausgestattet mit einem eingebetteten System, dass den
Menschen den Alltag erleichtern soll [Xia et al., 2012]. Ein Beispiel ist das Smart Home
Konzept, bei dem sämtliche Elemente des Hauses vernetzt sind und gesteuert werden
können. Solche eingebetteten Systeme sind oft durch Netzwerke verbunden, die instabil
sind oder eine geringe Bandbreite zur Verfügung stellen. Das Message Queue Telemetry
Transport (MQTT) Protokoll trägt diesen Problemen Rechnung. Es ist leichtgewichtig, orientiert sich am Publisher/Subscriber-Architekturmuster (siehe 2.3.2) und legt die
Hauptkomplexität auf die Seite des Message-Brokers [Hunkeler et al., 2008].
MQTT ist ein topic-based Publisher/Subscriber-System (siehe 2.3.2). Clients registrieren
sich hier bei dem MQTT-Broker (dem Message-Broker) auf bestimmte Topics, zu denen
sie Nachrichten erhalten wollen. Dabei werden bei der Angabe von Topics auch hierarchische Strukturen erlaubt. Konkret bedeutet dies, dass ein Topic den Namen ”/wohnung”,
aber auch ”/wohnung/schlafzimmer” tragen kann. Bei der Registrierung auf Topics
kann auf Wildcards zurück gegriffen werden. Gibt der Client als Topic ”/wohnung/#”
an, erhält er Nachrichten aus allen Topics, die mit ”/wohnung” beginnen, z.B. ”/wohnung/schlafzimmer/” oder ”wohnung/schlafzimmer/temperatur” [Standard., 2014].
Um sich mit dem MQTT-Broker zu verbinden, senden Clients CONNECT-Nachrichten.
Diese enthalten eine Client-Id, die der Broker zur eindeutigen Identifizierung des Clients
verwendet. Neben der Client-Id wird angegeben, ob die Sitzung eine ”clean session” sein
18
2.6. Nachrichtenaustausch und Speicher
soll und weitere optionale Attribute, wie Benutzername und Passwort festgelegt. ”Clean
session” gibt an, ob (falls existent) Informationen über eine bereits gespeicherte Sitzung
beim Verbinden eines Clients mit dem Broker verworfen werden oder nicht. Wird ”clean
session” auf true gesetzt, verwirft der Broker alle Informationen über vorherige Sitzungen.
Wie bereits erwähnt, sind die Netzwerke, die die eingebetteten Systeme verbinden, geprägt von Instabilität und geringer Bandbreite. Daher bietet das MQTT-Protokoll drei
verschiedene Quality of Service (im Nachfolgenden QoS genannt)-Stufen an, um sicher
zu gehen, dass Nachrichten ihre Empfänger erreichen [Hunkeler et al., 2008]. Die geringste Stufe ist QoS 0: At most once delivery 3 und bedeutet, dass Nachrichten den
Empfänger gar nicht oder wenn, dann nur einmal erreichen. Eine Verbesserung ist QoS
1: At least once 4 . Im Gegensatz zu QoS 0 wird hier sicher gestellt, dass eine Nachricht
den Empfänger erreicht. Es wird aber nicht ausgeschlossen, dass dieselbe Nachricht den
Empfänger zwei oder mehrmals erreicht. Dazu ist QoS 3: Exactly once delivery 5 nötig.
Dieser versichert, dass eine Nachricht nur genau einmal zugestellt wird, verursacht aber
auch den größten Verwaltungsaufwand. QoS 0 sollte in Systemen verwendet werden, bei
denen die Verbindung stabil ist oder es irrelevant ist, wenn Nachrichten verloren gehen.
QoS 1 sollte verwendet werden, wenn Nachrichten ihren Empfänger erreichen müssen,
aber keine Rücksicht darauf genommen werden muss, ob Duplikate den Empfänger erreichen. Die Anwendung von QoS 2, der höchsten Stufe, sollte stattfinden, wenn es wichtig
ist das Clients Nachrichten nur genau einmal erhalten und es zu Fehlern führen würde,
dieselbe Nachricht mehr als einmal zu empfangen.
Neben den Quality of Service-Einstellungen, unterstützt MQTT ein Last Will and Testament-Feature [Standard., 2014]. So kann der Client eine Nachricht spezifizieren, die im
Falle eines ungewollten Verbindungsabbruchs an alle Clients, in einem bestimmten Topic,
publiziert wird.
2.6.2. PostgreSQL
PostgresSQL ist ein open-source relationales Datenbanksystem mit einer längeren Entwicklungsgeschichte [Douglas und Douglas, 2003]. Ursprünglich stammt das System
aus akademischen Kontext, konnte sich aber dank wachsender Popularität, über diesen
hinaus, auf dem Markt neben kommerziellen Datenbanklösungen wie DB2 oder Oracle,
etablieren. Da PostgreSQL ein relationales Datenbanksystem ist, werden Daten wie bei
allen relationalen Datenbanken wie folgt organisiert: eine Datenbank enthält mehrere Schemata. Ein Schema beinhaltet eine Menge von Relationen. Relationen wiederum
enthalten Datensätze. Diese sind charakterisiert durch verschiedene Attribute.
Um Datensätze anzulegen oder bereits vorhandene auszulesen, können Anfragen gegen
die Datenbank gestellt werden. Diese sind in der Datenbanksprache SQL 6 formuliert.
PostgreSQL ist größtenteils Kompatibel zu dem SQL-Standard [PostgreSQL, 2015a],
bietet aber zusätzlich eigene Funktionen.
So ist es möglich, Daten auch in Form des Dateiaustauschformats Json 7 in der Datenbank abzulegen und abzurufen [PostgreSQL, 2015c]. Mittels der Anfrage ”INSERT
3
Höchstens einmal zugestellt
Mindestens einmal zugestellt
5
Genau einmal zugestellt
6
Structured Query Language
7
JavaScript Object Notation
4
19
2. Grundlagen
INTO jsonexample (id, studenten) VALUES (1, {”name”:”Stefan”, ”alter”: 25})” wird
in der Relation ”jsonexample” ein Eintrag erzeugt, der das Json-Objekt {”name”: ”Stefan”, ”alter”: 25} enthält. Will man die Daten als Json-Format auslesen bzw. abgleichen,
ob ein gegebener Wert einem Feld innerhalb des Json-Objektes entspricht, so verwendet
man innerhalb einer SQL-Anfrage die von PostgreSQL vorgegebenen Json-Operatoren.
Die Anfrage, um das zuvor beispielhaft eingefügte Json-Objekt wieder abzurufen, würde
wie folgt aussehen: ”SELECT studenten FROM jsonexample WHERE studenten ->>
’name’ = ’Stefan”’. Als Besonderheit fällt hier der ->>Operator auf. Dieser dient dazu,
ein Attribut aus dem Json-Objekt zu selektieren (in unserem Falle das Attribut name)
und als Text zurück zu geben. Eng verwandt mit dem ->> - Operator ist der -> - Operator. Dieser selektiert ein Attribut und gibt es nicht als Text, sondern im Json-Format
zurück. Nützlich ist dies, wenn Objekte eine tiefere Hierarchie besitzen, zum Beispiel,
wenn sich innerhalb eines Json-Objektes ein weiteres Json-Objekt befindet.
Neben dem Json-Feature bietet PostgreSQL noch einen Interprozesskommunikationsmechanismus. Clients können sich bei der Datenbank mittels des ”LISTEN kanalname”Befehls auf einen Kanal registrieren und erhalten so alle Benachrichtigungen, die über
diesen Kanal versendet werden. Über den Befehl ”NOTIFY kanalname, nachricht” kann
eine neue Benachrichtigung erstellt werden, wobei der Kanalname und der Inhalt der
Benachrichtigung spezifiziert werden können. Anwendung findet diese Funktion innerhalb von Echtzeitanwendungen oder wenn die verschiedenen Komponenten eines System
über Änderungen in der Datenbank benachrichtigt werden müssen.
Limitierungen bei der Verwendung des Datenbanksystems gibt es hinsichtlich der maximalen Tabellengröße (32 Terrabyte), der maximalen Zeilengröße (1.6 Terrabyte) und
der maximalen Feldgröße (1 Gigabyte) [PostgreSQL, 2015b].
2.6.3. FTP
Das File Transfer Protocol (FTP) ist ein Netzwerkprotokoll zur Übertragung von Daten
in einem Netzwerk zwischen zwei Rechnersystemen. Neben dem reinen Austausch von
Dateien, hat das FTP-Protokoll außerdem die zuverlässige Übertragung von Daten und
die Ermöglichung eines Dateizugriffs unabhängig eines bestimmten Betriebssystems zum
Ziel [Postel und Reynolds, 1985]).
Die Kommunikation zwischen zwei Rechnernetzen über das FTP-Protokoll verläuft nach
dem Client-Server-Modell: Dieses besteht aus einem Client, der Anfragen an den Server
stellt und einem Server, der die Anfragen des Clients beantwortet. Grundsätzlich ergeben
sich zwei Anwendungsfälle für das FTP:
• Der Client lädt von dem FTP-Server Dateien herunter.
• Der Client lädt Dateien auf den FTP-Server.
Bei jeder FTP-Sitzung werden zwei Verbindungen aufgebaut, eine Verbindung zur Übertragung von FTP-Kommandos inklusive deren Antworten, die sog. Kontrollverbindung.
Die zweite Verbindung dient der Übertragung von Daten, die sog. Datenverbindung. Die
Datenverbindung muss aber nicht während der gesamten Sitzung aktiv sein.
Der Verbindungsaufbau geschieht nach folgendem Schema:
Der Client Protocol Interpreter baut die Kontrollverbindung auf. Über das User-Interface
kann der Benutzer nun FTP-Kommandos eingeben, diese sendet der Client Protocol Interpreter an den Server Protocol Interpreter. Sobald dieser ein FTP-Kommando empfängt,
20
2.6. Nachrichtenaustausch und Speicher
sendet er entsprechende Antworten zurück an den Client Protol Interpreter [Postel und
Reynolds, 1985].
Das Speichern und Laden von Dateien auf beziehungsweise vom Server wird über die
Datenverbindung abgewickelt. Dabei werden zwei Modi unterschieden: das aktive FTP
und das passive FTP. Passives FTP wird verwendet, wenn keine Verbindung zum Client
aufgebaut werden kann, beispielsweise weil das Netzwerk des Clients durch eine Firewall
geschützt wird.
Beim aktiven FTP einigen sich Client und Server auf einen Port zum Datenaustausch.
Der Client wartet dann über den zuvor ausgetauschten Port auf das Eingehen einer Datenverbindung. Der Server initiiert daraufhin den Datentransfer zum Client mittels der
vereinbarten Parameter und der Datenaustausch beginnt.
Beim passiven FTP sendet der FTP-Server seine IP-Addresse und einen Port an den
Client und wartet dann auf das Eingehen einer Datenverbindung. Der Client beginnt
daraufhin die Datenverbindung zu dem ausgetauschten Port, woraufhin der Datenaustausch stattfinden kann. Abbildung 2.9 zeigt noch einmal die beschriebenen Komponenten. Neben der typischen Client-Server Verbindung ist es auch möglich, das zwei FTP-
Abbildung 2.9.: FTP-Architektur (angelehnt an [Postel und Reynolds, 1985])
Server Dateien untereinander austauschen. Das Austauschen der Konfigurationsparameter und das steuern der Dateiübertragung erfolgt hierbei durch einen Client [Postel
und Reynolds, 1985].
21
3. Ansatz
In diesem Kapitel wird das Konzept des Re-Engineering des Frameworks der Analytics Workbench vorgestellt sowie konzeptionelle Entscheidungen diskutiert. Dazu werden
zunächst anhand der in Abschnitt 2.5 vorgestellten Analyse der Analytics Workbench,
Anforderungen an das neue Framework aufgestellt. Im darauf folgenden Abschnitt wird
die Struktur des Frameworks vorgestellt. Dazu gehört der Aufbau der einzelnen Komponenten sowie der Kommunikationsinfrastruktur. Der letzte Abschnitt beschreibt konkrete
Ansätze zur Umsetzung der zuvor beschriebenen Kommunikationsinfrastruktur.
3.1. Anforderungsanalyse
Der erste Schritt innerhalb des Softwareentwicklungszyklus ist das Bestimmen von Anforderungen an die zu entwickelnde Anwendung bzw. an das zu entwickelnde System.
Dazu wird zunächst eine Problemstellung definiert und daraus die konkreten Anforderungen abgeleitet.
3.1.1. Problemstellung
Die in Abschnitt 2.5.5 vorgestellten Probleme innerhalb des Systems erfordern ein ReEngineering des Frameworks. Re-Engineering bedeutet die Erhaltung der Funktionalität,
bei gleichzeitiger Steigerung der Softwarequalität [Ebert, 2003]. Verwendet ein Benutzer
also die Weboberfläche der Analytics Workbench, um einen Analyseworkflow zu konfigurieren und durchzuführen, bemerkt er das erfolgte Re-Engineering lediglich durch ein
stabileres und performanteres System. Auch sollen alle weiteren Besonderheiten, die die
Analytics Workbench bietet, wie beispielsweise die Verarbeitung der Daten nach Pipes
and Filters-Schema, erhalten bleiben. Dies gilt auch für lose Kopplung zwischen den
einzelnen Analysekomponenten.
Um die Qualität des Systems zu verbessern, müssen alle Bestandteile betrachtet und
teilweise neu konzipiert werden. Herausforderungen sind hierbei die Kommunikation
und Synchronisierung zwischen den Elementen sowie der Datenaustausch, die Datenrepräsentation und interne Verarbeitung der Daten. Um die Komplexität bei der Betrachtung des kompletten Systems zu reduzieren, wird eine Unterteilung in Subprobleme
vorgenommen.
3.1.2. Kommunikation
In Abschnitt 2.5.3 und 2.5.4 wird die Kommunikation innerhalb des bisherigen Frameworks beschrieben. Sämtliche Funktionen, die die bisherige Kommunikationsinfrastruktur bietet, müssen durch die neue Kommunikationsinfrastruktur abgedeckt sein.
23
3. Ansatz
Zur Steuerung eines Workflows werden Nachrichten zwischen Node.js-Serverkomponente
und den Agenten ausgetauscht. So erfolgt das Starten einer Agenteninstanz durch Nachrichten, die an die Agent-Manager gesendet werden. Sie enthalten zum Zwecke der Zuordnung die Id des Analysemoduls. Während einer Analyse werden Datennachrichten
zwischen den einzelnen Agenten ausgetauscht. Diese beinhalten die Id des aktuellen
Analysedurchlaufs und die Pipe, in der sich die Daten befinden. Um den aktuellen Status einer Analyse auszulesen oder zu aktualisieren, werden Nachrichten übermittelt, die
Informationen über die aktuelle Analyse beinhalten. Resultate werden bisher in einem
Result-Repository gespeichert und Informationen über gespeicherte Resultate mittels
einer Nachricht mitgeteilt.
Für die neue Kommunikationsinfrastruktur müssen Nachrichten spezifiziert werden, die
die vorgestellten Funktionen übernehmen können. So muss es Nachrichten geben, die
einen Analyseworkflow steuern, wie beispielsweise das Starten einer Agenten-Instanz.
Diese Nachrichten sollten eine Zuordnung zu der zugehörigen Analysekomponente beinhalten. Ebenfalls muss ein Austausch von Daten zwischen den einzelnen Agenten realisiert werden. Neben der Übertragung der Nutzlast ist es notwendig, dass Meta-Informationen zu dieser übertragen werden, die die Nutzlast zu einer Analyse und zu einer Pipe zuordnen. Auf diese Weise kann ein Agent filtern, welche Daten für ihn bestimmt
sind. Für Informationen bezüglich einer Analyse und der Verarbeitung der Resultate,
müssen ebenfalls Lösungen gefunden werden. Um den Status einer Analyse zu bestimmen, müssen Nachrichten ausgetauscht werden, die den aktuellen Status der Analyse
beinhalten und sich eindeutig auf diese Analyse beziehen. Resultate müssen gespeichert
werden und Informationen über diese Resultate auch zu einem späteren Zeitpunkt abrufbar sein. Für die Benutzerverwaltung, welche in der Weboberfläche Anwendung findet,
müssen Repräsentationen gefunden werden. Dies umfasst die Repräsentation von Benutzern, Rollen und Gruppen als auch eine Verbindung zwischen Benutzern und Rollen
sowie Benutzern und Gruppen. Ebenfalls müssen von einem Benutzer erstellte Analyseworkflows repräsentiert werden.
Für den Austausch von Nachrichten muss ein Nachrichtenaustauschformat festgelegt
werden. Dieses muss von allen Bestandteilen des Frameworks interpretiert werden können.
Zusätzlich sollte es leichtgewichtig sein und wenig Overhead erzeugen.
Zur Kommunikation zwischen den einzelnen Agenten sowie den Agenten und der Node.jsServerkomponente muss eine Kommunikationskomponente verwendet werden, die ein
Publisher/Subscriber-Verfahren unterstützt. Diese wird benötigt, da Agenten selbst keine Kenntnis darüber besitzen welche anderen Agenten aktiv sind und somit keine direkte
Verbindung aufgebaut werden kann. Weiterhin muss es eine Möglichkeit geben, Daten
dauerhaft zu persistieren. Dies ist relevant für die Benutzeroberfläche. Gespeicherte Analyseworkflows sollten zu jedem Zeitpunkt abrufbar sein. Alle Probleme, die innerhalb der
bisherigen Kommunikationsinfrastruktur bestehen (s. Abschnitt 2.5.5), sollten behoben
werden. Dies betrifft den Austausch von Daten über 4 Megabyte als auch das Verbinden
von vielen Analysekomponenten.
3.1.3. Aufbau des Frameworks
Für die Problemstellung sind alle Bestandteile des kompletten Frameworks, das heißt
das Agenten-Framework, die Node.js-Serverkomponente sowie die zentrale Kommunikationskomponente, zu berücksichtigen.
24
3.1. Anforderungsanalyse
Auf Basis der Funktionalitäten des bisherigen Agenten-Frameworks, beschrieben in Abschnitt 2.5.4 und 2.5.3, müssen folgende Eigenschaften erfüllt sein:
Ein Agent-Manager muss mit der zentralen Kommunikationskomponente verbunden sein
und auf eingehende Nachrichten warten, die das Starten einer Agenteninstanz bedingen.
Gleichzeitig muss der Agent-Manager in der Lage sein, gestartete Agenteninstanzen wieder zu beenden, sei es, weil dieser seine Aufgabe erfüllt hat oder erzwungen beendet
werden soll.
Gestartete Agenteninstanzen müssen mit der zentralen Kommunikationskomponente
verbunden sein und auf eingehende Daten warten. Erreichen sie Daten, müssen diese
verarbeitet werden und das Ergebnis wieder der zentralen Kommunikationskomponente
mitgeteilt werden.
Ist eine Analyse abgeschlossen, müssen die Resultate gespeichert werden. Dies geschieht
bisher durch eine Infrastruktur-Komponente, dem ’Result Collector’. Dieser erkennt, ob
alle Agenten, die am Ende eines Analyseworkflows stehen, eine Ausgabe produziert haben und schreibt diese in das Result-Repository. Hier sollte eine neue Lösung entwickelt
werden, die performanter ist und ohne zusätzliche Infrastruktur-Komponente realisiert
werden kann. Die Steuerung eines Workflows erfolgt über die Node.js-Serverkomponente,
daher ist es sinnvoll, auch das Sammeln von Resultaten in den Aufgabenbereich der
Node.js-Serverkomponente zu legen. Ebenfalls sollten von Agenten produzierte Zwischenergebnisse nach Abschluss einer Analyse gelöscht werden, da diese nicht mehr
benötigt werden. Ausgeführt werden die einzelnen Analysekomponenten durch einen
Executor. Dieser muss gegebenenfalls an das neue Framework angepasst werden.
Die Node.js-Serverkomponente muss der neuen Kommunikationsinfrastruktur angepasst
werden. Auch müssen Funktionalitäten zur Kontrolle über eine Analyse umgesetzt werden. Hierzu gehört das Übersetzen eines Analyseworkflows in eine für die Agenten
verständliche Repräsentation sowie den Zustand eines Analysedurchlaufs zu erkennen
und Resultate zu verarbeiten.
Durch den Einsatz in verschiedenen Forschungsprojekten, wie z.B. KOLEGEA und GoLab, haben sich auch die Anforderungen an die Analytics Workbench verändert. Dort,
wo das System ursprünglich ausreichend war hinsichtlich seiner Skalierbarkeit, stellen
es andere Einsatzgebiete vor Herausforderungen, die es nicht bewältigen kann. Entsprechend ist es wünschenswert bei dem Re-Engineering des Frameworks darauf Wert zu
legen, auch auf sich verändernde Anforderungen reagieren zu können. Dies betrifft vor
allem den Nachrichten- und Datenaustausch. Das Framework sollte so gestaltet sein,
dass ein Entwickler zwischen verschiedenen Nachrichten- und Datenaustauschverfahren
wählen und gegebenenfalls sein Eigenes hinzufügen kann.
3.1.4. Anforderungen
Aus der beschriebenen Problemstellung leiten sich die nachfolgenden Anforderungen an
das Framework ab.
1. Alle für die Analytics Workbench typischen Merkmale sollen erhalten bleiben. Dies
betrifft die lose Kopplung zwischen den Analysekomponenten als auch die Datenverarbeitung nach dem Pipes and Filters-Prinzip.
25
3. Ansatz
2. Alle Funktionen, die die Benutzeroberfläche bietet, müssen erhalten bleiben. Darunter sind Benutzerverwaltung und Funktionen, wie das Speichern und Laden von
erstellten Analyseworkflows.
3. Die Unabhängigkeit bzw. lose Kopplung zwischen den einzelnen Agenten impliziert eine indirekte Kommunikation. Dies bedeutet, dass die Kommunikation über
eine Zwischeneinheit erfolgen muss, die alle Agenten kennt und Nachrichten an
entsprechende Agenten weiterleitet.
4. Dadurch, dass mehrere Agenten vom selben Typ innerhalb eines Workflows existieren können, ist es notwendig, die Agenten zu verwalten. Relevante Analysedaten
müssen an den korrekten Agenten weitergeleitet werden.
5. Für die Kommunikation zwischen den Agenten und der Kommunikation zwischen
den Agenten und der Node.js-Serverkomponente, welche beide indirekt erfolgen,
wird eine Kommunikationskomponente benötigt, die ein Publisher/Subscriber-Verfahren unterstützt. Dies ist nötig, da sich die einzelnen Komponenten nicht kennen
und somit kein direkter Kommunikationsweg möglich ist.
6. Zur Kommunikation zwischen den Agenten als auch mit allen anderen Komponenten, muss ein Dateiaustauschformat gefunden werden. Dieses muss leichtgewichtig
sein und von allen Kommunikationsteilnehmern verarbeitet werden können.
7. Die Art und Weise wie Zwischenergebnisse verarbeitet werden, muss definiert werden.
8. Das Framework sollte in der Lage sein auch Analysedaten über 4 Megabyte behandeln zu können.
9. Auch bei großen, komplexen Analysen mit vielen Agenten soll das System skalieren
und stabil bleiben.
10. Das Framework muss abstrakt genug sein, um die Kommunikationskomponente
leicht austauschen zu können.
11. Die Node.js-Serverkomponente muss einen durch den Benutzer erstellten Workflow für die Agenten verständlich umwandeln. Sie muss dazu mit den Agenten in
Verbindung stehen.
12. Nach Abschluss einer Analyse müssen die Ergebnisse gespeichert werden und sollten zu jedem Zeitpunkt abrufbar sein.
13. Analysekomponenten müssen gestartet werden können. Dazu muss es eine ausführende Komponente geben, die gleichzeitig globale, für das System relevante Parameter an die Agenten übergeben kann. Weiterhin sollte diese Komponente initial
alle vorbereitenden Maßnahmen treffen, wie beispielsweise das Konfigurieren der
Kommunikationskomponente.
14. Die Kommunikationskomponente muss über Sicherheitsmechanismen verfügen, die
einen ungewollten Eingriff von außerhalb des Systems verhindern.
26
3.2. Aufbau des Frameworks
3.2. Aufbau des Frameworks
Der konzeptuelle Aufbau des Frameworks beginnt mit den Konzepten zur Verbindung
und Kommunikation zwischen den einzelnen Agenten. Hier wird eine neue Kommunikationsinfrastruktur beschrieben, insbesondere mit Hinblick auf die Probleme der bisherigen Kommunikationsinfrastruktur. Danach folgt die Struktur des Agenten-Frameworks,
welches für die Analyseaufgaben verantwortlich ist. Zuletzt werden Konzepte für die
Node.js-Serverkomponente betrachtet.
3.2.1. Verbindungen und Kommunikation
Bevor der Aufbau des Frameworks genauer vorgestellt wird, sollen an dieser Stelle allgemeine Konzepte hinsichtlich Verbindungen zwischen den Komponenten und das der
Verbindungsverwaltung vorgestellt werden. Die konkrete Umsetzung der allgemeinen
Ansätze wird im weiteren Verlauf beschrieben.
3.2.1.1. Anzahl der Verbindungen
Bisher stellt sich die Situation wie folgt dar (siehe Abbildung 3.1): Jeder Agent-Manager
hält eine Verbindung zu der zentralen Kommunikationskomponente. Gleiches gilt für die
zu einem Agent-Manager gehörigen Agenteninstanzen. Dies ist notwendig, um Nachrichten zu empfangen, die bestimmte Ereignisse auslösen. Dies kann beispielsweise der Start
eines Agenten sein oder der Beginn einer Analyse. Pro Analysekomponente existieren
also eine plus n weitere Verbindungen, je nach Anzahl der Agenteninstanzen. Dies bietet zwar eine hohes Maß an Unabhängigkeit zwischen dem Agent-Manager und seinen
Agenteninstanzen, sorgt aber gleichzeitig für eine höhere Belastung der Kommunikationskomponente. Werden m Analysekomponenten gestartet, die wiederum n Agenteninstanzen starten, ergeben sich m · (1 + n) = m + m · n aufgebaute Verbindungen.
Abbildung 3.1.: Verbindungen pro Manager und Agenteninstanzen
27
3. Ansatz
Da der Agent-Manager und seine Agenteninstanzen eng miteinander verbunden sind,
ist eine weitere Verbindungskonfiguration denkbar. Anstatt einer neuen Verbindung für
jedes Element, kann der Agent-Manager eine Verbindung aufbauen und diese mit seinen
Agenteninstanzen teilen. Dadurch wird die Kommunikationskomponente entlastet. Pro
Analysekomponente existiert nur noch eine Verbindung, d.h. bei n Analysekomponenten
werden nur n Verbindungen aufgebaut (siehe Abbildung 3.2). Durch das Verwenden der
Verbindung des Agent-Managers, sind die Agenten-Instanzen abhängiger von diesem.
Ebenfalls ist der Aufwand, die Nachricht dem korrekten Empfänger zuzuordnen, höher.
Erreicht eine Nachricht eine Analysekomponente, muss diese intern entscheiden, ob die
empfangene Nachricht an den Agent-Manager oder an eine seiner zugehörigen Agenteninstanzen weitergeleitet wird. Wenn die Nachricht zu einer Agenteninstanz gehört, muss
diese zusätzlich bestimmt werden.
Abbildung 3.2.: Verbindungen pro Analysekomponente
Um die Verbindungsanzahl weiter zu reduzieren, können Agenten als zusammengehörige
Gruppe definiert werden (im Folgenden auch Agenten-Bundle genannt) (siehe Abbildung
3.3). Eine solche Gruppe beinhaltet Analysekomponenten, die innerhalb der selben Java
Virtual Machine laufen. Dies können Analysekomponenten sein, die besonders häufig
in einzelnen Workflows Anwendung finden oder einen ähnlichen Aufgabenbereich haben. Das Besondere hierbei ist, dass sich alle Analysekomponenten eine Verbindung
zur Kommunikationskomponente teilen. Das heißt trotz einer beliebigen Anzahl von
Analysekomponenten, bleibt nur eine Verbindung offen. Dadurch wird die Kommunikationskomponente stark entlastet, die Hauptkomplexität liegt bei den Analysekomponenten. Die Performanz dieser Verbindungskonfiguration hängt von der Anzahl der
Analysekomponenten und der Agenteninstanzen innerhalb der Gruppe ab. Verwenden
viele Analysekomponenten die gleiche Verbindung, wird diese stark beansprucht, was
zur Überlastung oder zu einem Flaschenhalseffekt führen kann. Die Konfiguration eines
solchen Agenten-Bundles kann zu Problemen führen, für den Fall, eine Analysekomponente in zwei Agenten-Bundles vorkommt. Dies führt zu einem fehlerhaften Zustand der
betroffenen Analysekomponente.
Die Wahl, der geeigneten Verbindungskonfiguration, hängt von der Kommunikationskomponente und dem gegebenen Anwendungsszenario ab. Bei einer gut skalierenden
28
3.2. Aufbau des Frameworks
Abbildung 3.3.: Verbindungen pro Agenten-Gruppe
Kommunikationskomponente kann die erste Konfiguration gewählt werden. Hat die
Kommunikationskomponente Schwierigkeiten mit einer großen Menge an Verbindungen, bietet sich die zweite Konfiguration an. Die letzte Konfiguration ist ein Spezialfall.
Anwendung findet dieser, wenn es gewünscht ist, das einzelne Analysekomponenten zusammengefasst werden. Welcher Anwendungsfall vorliegt, muss ein Benutzer mit administrativen Aufgaben entscheiden. Zu dem Zwecke bietet das neu gestaltete Framework
eine Option mit der die Verbindungskonfiguration festgelegt werden kann 1 .
3.2.1.2. Nachrichten- und Datenaustausch
Bisher findet innerhalb der Analytics Workbench keine Trennung zwischen Nachrichten statt. So werden Nachrichten mit Nutzlast auf dieselbe Art und Weise übertragen
wie Nachrichten, die lediglich zur Koordination dienen. Wie in Abschnitt 2.5.3 beschrieben, gibt es drei verschiedene Nachrichtentypen, die für das System relevant sind. Zwischen den einzelnen Agenten und der Node.js-Serverkomponente werden Koordinationsnachrichten ausgetauscht. Zwischen den Agenten selbst werden Datennachrichten ausgetauscht. Letztendlich gibt es noch Informationsnachrichten, die nur für die Node.jsServerkomponente relevant sind. Diese umfassen beispielsweise gespeicherte Analysen
oder von einem Benutzer erstellte Analyseworkflows.
Zum Zwecke der Optimierung des Kommunikationsflusses, bietet sich eine Unterteilung
an. Koordinationsnachrichten sollten über ein Kommunikationsmedium ausgetauscht
werden, das seine Vorzüge in einem effizienten Nachrichtenaustausch hat, Datennachrichten über ein Kommunikationsmedium, das spezialisiert ist auf das Speichern und Abrufen von Dateien. Für die Informationsnachrichten wird eine Kommunikationskomponente
benötigt, welche Informationen persistieren kann und auf Abruf zur Verfügung stellen
kann. Gespeicherte Analysen und Analyseworkflows sollen auch zu einem späteren Zeitpunkt abrufbar sein können. Am stärksten frequentiert ist der Austausch von Koordinations- und Datennachrichten. Dementsprechend müssen die Kommunikationskomponenten
1
Näheres dazu in Abschnitt 3.2.2.3
29
3. Ansatz
für diese Nachrichtentypen skalierbar sein.
Gänzlich trennen lassen sich Koordination- und Datennachrichten nicht. Datennachrichten enthalten neben ihrer Nutzlast noch Informationen über den relevanten Empfänger
und Informationen über die Nutzdaten. Um dies auch weiterhin zu gewährleisten, werden
Datennachrichten aufgeteilt. Zunächst wird die Nutzlast bei der Kommunikationskomponente, die für das Speichern und Abrufen von Daten verantwortlich ist, hinterlegt.
Danach wird eine Koordinationsnachricht an die Nachrichtenaustauschkomponente gesendet, die alle relevanten Informationen über die Nutzlast enthält. Diese Informationen
beinhalten eine Zuordnung zu der aktuellen Analyse sowie einem Empfänger und einem
Verweis auf die Nutzlast. Der Verweis innerhalb der Nachricht ermöglicht den Abruf
der Nutzlast. Abbildung 3.4 zeigt die Architektur des gesamten Systems mit dem neu-
Abbildung 3.4.: Architekturübersicht mit neuem Kommunikationsmodell
en Kommunikationsmodell. Im Vergleich zu der bisherigen Architektur aus Abbildung
2.8 gibt es keine zentrale Kommunikationskomponente mehr. Stattdessen beinhaltet sie
drei Kommunikationskomponenten, jeweils für verschiedene Aufgaben. Alle Analysekomponenten sowie die Node.js-Serverkomponente sind mit der Nachrichtenaustauschund Datenaustauschkomponente verbunden. Über diese Komponenten läuft, wie beschrieben, sämtliche Kommunikation hinsichtlich der Koordination und des Datenaustausches während einer Analyseaufgabe. Mit der Informationsspeicher-Komponente ist
lediglich die Node.js-Serverkomponente verbunden. Hier werden Daten (Nachrichten)
gespeichert, die für die Funktionalität der Weboberfläche und der Benutzerverwaltung
relevant sind.
3.2.1.3. Datenaustauschformat und Nachrichtenspezifikation
Wie in Abschnitt 2.1 beschrieben, ist innerhalb eines Multiagentensystems ein Datenaustauschformat erforderlich, welches alle Kommunikationsteilnehmer verarbeiten können.
Dieses sollte leichtgewichtig sein und von allen für das System relevanten Programmiersprachen unterstützt werden. Hier ist die Wahl auf das Json-Format gefallen. Zum einen,
weil es leichtgewichtig ist und zum anderen, weil es bereits innerhalb der auf JavaScript
30
3.2. Aufbau des Frameworks
basierenden Node.js-Serverkomponente verwendet wird und gleichzeitig auch von der
Programmiersprache Java unterstützt wird, auf der das Agenten-Framework basiert.
Hinsichtlich der genauen Spezifikation der Nachrichten ist es sinnvoll, diese entsprechend
der im vorherigen Abschnitt beschriebenen Kommunikation aufzuteilen. Dies bedeutet
eine Aufteilung in Koordinationsnachrichten, Datennachrichten und Informationsnachrichten, welche für die Benutzeroberfläche relevant sind. Diese sollen im Folgenden weiter
spezifiziert werden. Die Nachrichten werden nach dem Muster Name der Nachricht →
Nachrichteninhalt beschrieben.
Koordinationsnachrichten umfassen die Nachrichten CoordinationMessage, ErrorMessage, RunMessage und ResultMessage:
• CoordinationMessage → {runid, agentstate, instanceid, agentid, pipes,
parameters}. Sie dient dazu, den Status der Agenten zu repräsentieren. Die Felder
runid, instanceid und agentid geben an, zu welchem Agent in welchem Workflow
die Nachricht gehört. Das Feld agentstate repräsentiert den aktuellen Zustand des
Agenten und das Feld parameters enthält Parameter, die für den Agenten relevant
sind. Für die Zuordnung der ausgehenden Pipes ist das Feld pipes verantwortlich.
• ErrorMessage → {runid, agentid, instanceid, message}. Die Felder runid,
agentid und instanceid dienen der genauen Bestimmung des fehlerhaften Agenten.
Im Feld message wird die Ursache des Fehlers angegeben.
Datennachrichten:
• DataMessage → {runid, pipe, payload}. Das Feld runid ordnet die Nachricht
dem entsprechenden Analyseworkflow zu, Pipe spezifiziert hierbei die relevante
Pipe eines Agenten (s. CoordinationMessage). Payload beinhaltet Informationen
über die Nutzlast und einen Pfad, auf dem diese hinterlegt ist.
Zu den Informationsnachrichten gehören WorkflowSaveMessage sowie Nachrichten für
das Benutzermanagement:
• WorkflowSaveMessage → {workflowid, name, description, workflow, userid, savedate}. Die WorkflowSaveMessage wird generiert, wenn der Benutzer innerhalb der Benutzeroberfläche seinen erstellten Analyseworkflow speichert, um
ihn später wieder abrufen zu können. Für den Analyseworkflow wird eine Id generiert und im Feld workflowid gespeichert. Des Weiteren kann der Benutzer noch
einen Namen angeben und eine Beschreibung. Die Zuordnung des Workflows zum
Benutzer erfolgt über das Feld userid. Der Aufbau des Workflows wird im Feld
workflow gespeichert. Das Erstellungsdatum wird im Feld savedate hinterlegt.
• UserMessage → {userid, username, password, email}. Eine User-Message
repräsentiert einen Benutzer. Für diesen wird eine Id generiert. Des Weiteren werden der Benutzername, Password und E-Mail des Benutzers gespeichert.
• RoleMessage → {roleid, rolename}. Um innerhalb der Benutzerverwaltung
verschiedenen Benutzern verschiedene Rechte zuweisen zu können, werden RoleMessages verwendet. Diese beinhalten eine ID und den Namen der Rolle.
• GroupMessage → {groupid, groupname}. Benutzer können Gruppen zugeordnet werden. Hierzu werden Group-Messages verwendet. Diese beinhalten eine
ID und den Gruppennamen.
31
3. Ansatz
Eine Besonderheit stellen RunMessage- und ResultMessage-Nachrichten dar. Diese gehören sowohl zur Kategorie Koordinationsnachrichten als auch zur Kategorie der Informationsnachrichten. Zu den Koordinationsnachrichten werden sie gezählt, da sie während
einer Analyse Rückmeldung über den aktuellen Status einer Analyse geben als auch signalisieren, wenn ein Resultat erstellt ist. Zu den Informationsnachrichten gehören sie,
da sie für die Benutzeroberfläche benötigt werden, um durchgeführte Analysen inklusive
Resultate abrufen zu können.
• RunMessage → {runid, workflowid, userid, date, status, name, description}. RunMessage-Nachrichten beinhalten Informationen über den Status eines
Analysedurchlaufs. Sie enthalten über die Felder runid und workflowid eine Zuordnung zu dem aktuellen Analyseworkflow und über das Feld userid eine Zuordnung
zu dem Benutzer, der die Analyse durchführt. Die Felder date, status, name und
description sind Eigenschaften des Durchlaufs, zu denen beispielsweise Datum und
Uhrzeit, Name und Beschreibung sowie Angaben über den Erfolg oder Misserfolg
der Durchführung.
• ResultMessage → {runid, agentid, link, name, description}. Resultate
von Analyseabläufen werden in ResultMessages abgebildet. Dazu erfolgt mittels
runid und agentid eine Zuordnung zu dem Agenten, der das Resultat innerhalb
eines Durchlaufs produziert hat. Um auf das Resultat zuzugreifen, wird der Link
zu dem Resultat in dem Feld link gespeichert. Die Felder name und description
beinhalten Name und Beschreibung des Resultats.
Für die Benutzerzuordnung gibt es noch weitere Nachrichtentypen, die dem Benutzer eine Gruppe und eine Rolle zuordnen sowie Workflows und Analysedurchläufe zu
Gruppen. Diese beinhalten jeweils die Ids der zuzuordnenden Elemente, beispielsweise
{userid, groupid}. Um alle für die Weboberfläche verfügbaren Analysekomponenten zu
repräsentieren, dienen AgentDescriptionMessages. Sie beinhalten eine Beschreibung der
Komponente.
3.2.2. Struktur des Agenten-Frameworks
Das Agenten-Framework dient als grundlegende Struktur für die Entwicklung von Analysekomponenten und soll in der Programmiersprache Java entwickelt werden. Dennoch
ist es möglich, Agenten in anderen Programmiersprachen zu entwickeln. Diese müssen
lediglich in die neue Kommunikationsinfrastruktur eingebunden werden.
Wie in Abschnitt 2.5.4 beschrieben, bestehen Analysekomponenten immer aus einem
Agent-Manager und einem Agenten, von dem zur Laufzeit mehrere Instanzen existieren
können. Abbildung 3.5 verdeutlicht den Sachverhalt. Um die Entwicklung von Analysekomponenten zu vereinfachen und zu vereinheitlichen, werden bei der Entwicklung
von Agent-Manager und Agent die Klassen AgentManager und Agent erweitert. Im Folgenden sollen der Aufbau und die Aufgaben der Klassen AgentMananger und Agent
sowie des Executors, der für das Ausführen von Analysekomponenten verantwortlich ist,
vorgestellt werden. Des Weiteren wird die Umsetzung der im vorherigen Abschnitt beschriebenen Konzepte der Verbindungen und der Verbindungsverwaltung beschrieben.
Zur Nomenklatur: Im Nachfolgenden wird die Kommunikationskomponente für den Austausch von Koordinationsnachrichten als Nachrichtenaustauschkomponente, die Kommunikationskomponente für den Austausch von binären Daten als Datenaustauschkom-
32
3.2. Aufbau des Frameworks
ponente und die Kommunikationskomponente für den Austausch von Nachrichten, welche lediglich relevant sind für die Node.js-Serverkomponente, als InformationsspeicherKomponente bezeichnet.
Abbildung 3.5.: Vereinfachte Darstellung des Vererbungsmodells von Agent und
AgentManager
3.2.2.1. AgentManager
Das Klassendiagramm in Abbildung 3.6 zeigt die Klasse AgentManager mit allen Attributen und Methoden. Sie ist die Basis für alle Agent-Manager der Analysekomponenten und stellt Möglichkeiten zur Verwaltung der Agenteninstanzen bereit. Diese kann
beispielsweise Agenten starten und beenden oder den Status eines Agenten aktualisieren. Wird eine Instanz eines AgentManagers erzeugt, verbindet dieser sich zunächst
mit der Nachrichtenaustauschkomponente (Methode initialize()). Je nach Konfiguration
verwendet der AgentManager eine Verbindung, die zuvor bereits erstellt wurde (wenn
als Verbindungsoption ’Agent-Bundle’ gewählt wird) oder bekommt eine Neue von der
Verbindungsverwaltung zugewiesen. Ist die Verbindung aufgebaut, registriert sich der
AgentManager auf CoordinationMessages (s. 3.2.1.3). Erreicht ihn eine CoordinationMessage (Methode notifyManager()), die für ihn relevant ist, also die Id der zu dem
Manager gehörigen Analysekomponente beinhaltet, ruft er die Methode createAgent()
auf. Diese ist im AgentManager nur abstrakt definiert, da die Umsetzung dieser Methode innerhalb des konkreten Agent-Managers geschieht. Nach der Registrierung sendet
der AgentManager eine für ihn spezifische AgentDescription-Nachricht an die Nachrichtenaustauschkomponente und signalisiert damit, dass die zu dem Manager zugehörige
Analysekomponente für Analyseaufgaben verfügbar ist (Methode createAndSendDescription()). Während seiner Laufzeit, die über das boolesche Attribut isAlive charakterisiert wird, sendet er alle 60 Sekunden seine AgentDescription-Nachricht um anzuzeigen,
dass er weiterhin existiert. Hat sich der Status eines Agenten verändert, wird der Manager benachrichtigt (Methode notifyManager()). Der Status eines Agenten kann unter
normalen Umständen RUNNING 2 , DONE3 und ERROR4 sein. In all diesen Fällen wird
2
laufend
abgeschlossen
4
fehlerhaft
3
33
3. Ansatz
eine CoordinationMessage mit dem aktuellen Status an die Nachrichtenaustauschkomponente gesendet (Methode updateAgentState()). Im Falle von DONE oder ERROR wird
der entsprechende Agent beendet und aus der Liste der verwalteten Agenten entfernt.
Eine Besonderheit ist der Status FINISH 5 . Dieser wird verwendet, wenn eine Analysekomponente gezwungenermaßen gestoppt werden soll. In diesem Fall wird keine Nachricht an die Kommunikationskomponente gesendet. Stattdessen der Agent beendet und
aus der Liste aller verwalteten Agenten entfernt. Um den Agent-Manager zu stoppen,
wird die Methode shutdown() verwendet. Sie beendet alle Agenten, meldet sich von der
Nachrichtenaustauschkomponente ab und schließt je nach Verbindungstyp die Verbindung. Im Falle des Verbindungstyps ’Agent-Bundle’ darf die Verbindung nicht geschlossen werden, da dies Auswirkungen auf alle anderen Analysekomponenten hat.
Die Liste selfDescriptionMessages beinhaltet alle AgentDescription-Nachrichten, die an
die Kommunikationskomponente gesendet wurden. Das Attribut coordinationMessageTemplate ist ein Json-Objekt und beinhaltet den Namen der Analysekomponente, wie
dieser in der Weboberfläche dargestellt ist. Es wird verwendet für den Registrierungsvorgang bei der Nachrichtenaustauschkomponente. ManagerName beschreibt den Namen des Agent-Managers. Das Attribut dataConnection repräsentiert eine Verbindung
zur Datenaustauschkomponente. Dieses findet keine direkte Verwendung innerhalb des
Managers und ist außer im Falle des Verbindungstyps ’Agent-Bundle’ auch nicht initialisiert. Um zu bestimmen, um welchen Verbindungstyp es sich handelt, wird das Attribut
connectionType verwendet. Diese erhält der Manager bei seiner initialen Ausführung.
Problematisch ist die strikte Trennung zwischen Verwaltungs- und Analyseeinheit nur
Abbildung 3.6.: Klassendiagramm des AgentManagers (getter und setter-Methoden
nicht in Darstellung)
in dem seltenen Fall, dass vor dem Erstellen eines Agenten bereits Daten für diesen
5
beendet
34
3.2. Aufbau des Frameworks
vorhanden sind. Diese würden den Agenten niemals erreichen. Um dies zu verhindern,
müsste ein Agent-Manager zusätzlich noch auf eingehende Datennachrichten warten und
diese sammeln. Vor dem Starten eines Agenten müsste er dann überprüfen, ob für diesen Agenten bereits eine Datennachricht verfügbar ist. Ist dies der Fall, muss er diese
dem Agenten übergeben. Dies bedeutet einen höheren Verwaltungsaufwand für ein sehr
unwahrscheinliches Ereignis und soll deshalb an dieser Stelle vernachlässigt werden.
3.2.2.2. Agent
Als Ergänzung zu der Klasse AgentManager dient die Abstrakte Klasse Agent als Basis
für alle Agenten der Analysekomponenten. Abbildung 3.7 zeigt das zugehörige Klassendiagramm. Eine Instanz der Agenten-Klasse einer Analysekomponente wird durch den
zugehörigen Agent-Manager erstellt und existiert so lange, bis der Agent Analysedaten
erhalten und verarbeitet hat. Um Analysedaten zu erhalten, registriert sich der Agent
bei der Nachrichtenaustauschkomponente auf DataMessages (initializeAgent()). Dazu
wird je nach konfiguriertem Verbindungstyp eine neue Verbindung erstellt (im Falle von
einzelnen Verbindungen pro Agent bzw. Agent-Manager) oder die Verbindung von dem
Agent-Manager übernommen. Ähnliches gilt für die Datenverbindung. Diese wird auch
neu erstellt, wenn die Nachrichtenverbindung von dem Agent-Manager übergeben wird.
Lediglich im Falle der Verbindungsoption ’Agent-Bundle’ verwendet der Agent eine zuvor erstellte Datenverbindung.
Welche DataMessages für den Agenten relevant sind, wird durch die eingehenden Pipes der Analysekomponente bestimmt, welche in der Weboberfläche festgelegt werden
können (s. Abschnitt 2.5). Die Pipes werden in dem Json-Objekt dataStructure gespeichert. Neben der Registrierung bei der Kommunikationskomponente wird entschieden,
ob der Agent ein Ausgabeagent ist. Ausgabeagenten sind diejenigen Agenten, die sich am
Ende der Analyse befinden und eine Ausgabe produzieren, sei es in Form von abrufbaren
Daten oder einer Visualisierung der Analyseergebnisse. Falls ein Agent ein Ausgabeagent
ist, erstellt er bevor er beendet wird, eine ResultMessage-Nachricht und schreibt das Resultat in das Result-Repository. Diese Nachricht wird verwendet, um dem Benutzer nach
dem Abschluss der Analyse die Ergebnisse anzeigen zu können oder Ergebnisse von bereits durchgeführten Analysen abrufen zu können.
Erreicht den Agenten eine für ihn relevante DataMessage (notifyMessage()), fängt der
Agent mit der eigentlichen Analysearbeit an (handleDataMessage()). Dazu extrahiert er
sich aus der DataMessage den Pfad zu den Nutzdaten, die zu der DataMessage gehören
(s. 3.2.1.3) und lädt diese mittels seiner Datenverbindung herunter. Um keine Überreste
zu hinterlassen, werden die heruntergeladen Daten von der Datenaustauschkomponente
gelöscht. Haben den Agenten alle zur Analyse benötigten Daten erreicht, wird die Methode executeAgent() aufgerufen. Diese ist in der Klasse Agent nur abstrakt definiert,
da jeder Agent eine andere Analyse durchführt und die Klasse Agent nur die Basis für
alle Agenten darstellt. Ist die Analyse durchgeführt, werden die Daten, auf denen die
Analyse durchgeführt wurde, bei der Datenaustauschkomponente hinterlegt. Nach dem
Vorgang wird eine DateMessage erstellt, die neben den Informationen über die Nutzlast
einen Pfad zu den hinterlegten Daten enthält. Diese DataMessage wird an die Nachrichtenaustauschkomponente gesendet. Danach ändert der Agent seinen Status auf DONE
und benachrichtigt seinen zugehörigen Agent-Manager. Dieser beendet den Agenten.
35
3. Ansatz
Abbildung 3.7.: Klassendiagramm des Agenten (getter und setter-Methoden sowie Hilfsmethoden nicht in Darstellung)
36
3.2. Aufbau des Frameworks
3.2.2.3. Executor, Verbindungsverwaltung und Konfiguration
Der Executor dient, wie in der Ursprungsversion des Frameworks, zur Ausführung von
Analysekomponenten. Diese zu startenden Komponenten werden in einer XML-Datei
konfiguriert. Beim Ausführen des Executors wird diese eingelesen und die entsprechenden Komponenten gestartet. Eng verbunden mit dem Executor ist die Verbindungsverwaltung.
Für die Umsetzung der in Abschnitt 3.2.1 beschriebenen Konzepte, gehört zu dem Framework eine Verbindungsverwaltung. Diese ist Verantwortlich für das Erstellen der Verbindungen zu den jeweiligen Kommunikationskomponenten. Da das Erstellen der Verbindungen nicht innerhalb der einzelnen Analysekomponenten geschieht, werden so Inkonsistenzen verhindert. Weiterhin wird die Kommunikationsschicht abstrahiert, sodass
neue Verbindungswege leicht hinzugefügt werden können.
Das Festlegen der Verbindungskonfigurationen für das Agenten-Framework erfolgt über
eine Konfigurationsdatei, die beim Starten des Executors geladen wird. Innerhalb dieser
kann über Attribute festlegt werden, welcher Verbindungstyp sowie welche Kommunikationskanäle Verwendung finden sollen. Diese Verbindungskonfiguration ist gültig für
alle Komponenten, die mittels eines Executors gestartet werden. Auf diese Weise ist es
möglich, verschiedene Analysekomponenten mit unterschiedlichen Verbindungskonfigurationen zu starten.
Die Verwaltung der Verbindungen erfolgt über einen Connection-Client. Dieser dient
als Schnittstelle zur Erstellung von Nachrichten- und Datenverbindungen, gleichzeitig
hält er im Falle des Verbindungstyps ’Agenten-Bundle’ eine globale Nachrichten- und
Datenverbindung. Um zu verhindern, dass an mehreren Stellen innerhalb des Systems
ein neuer Connection-Client instanziiert wird, ist der Connection-Client als Singleton
realisiert. Dies garantiert, dass nur eine Instanz des Connection-Clients existiert.
Das Erstellen neuer Nachrichten- bzw. Datenverbindungen erfolgt über das Abstrakte
Farbik-Entwurfsmuster (s. 2.3.4), zu sehen in Abbildung 3.8.
Für jede Nachrichten- bzw. Datenverbindung gibt es eine konkrete Fabrik, die das Interface AbstractConnectionFactory realisiert. Eine konkrete Fabrik ist dafür verantwortlich
eine zugehörige, konkrete Nachrichten- beziehungsweise Datenverbindung zu erstellen.
Die konkreten Nachrichten- bzw. Datenverbindungen implementieren die Interfaces MessageConnection bzw. DataConnection. Deren kompletter Aufbau ist in den Abbildungen
3.10, 3.12, 3.13 und 3.14 zu sehen.
Ob eine neue Nachrichten- bzw. Datenverbindung aufgebaut wird oder auf die Globalen des Connection-Clients zurückgegriffen wird, hängt je von gewählter Verbindungsart
ab. Bei der Option ’Einzelne Verbindungen’ erstellen Agent-Manager und Agent mittels
Connection-Client jeweils eigene Verbindungen. Anders verhält es sich im Falle der Option ’Manager-basiert’. Hier erstellt lediglich der Manager neue Verbindungen und gibt
diese beim Erstellen des Agenten an diesen weiter. Im Falle der Option ’Agenten-Bundle’
greifen Agent-Manager und Agenten aus dem ’Agenten-Bundle’ auf die globalen Verbindungen des Connection-Clients zu. Diese werden zuvor durch den Executor erstellt.
37
3. Ansatz
Abbildung 3.8.: Verbindungsverwaltung als abstrakte Fabrik
38
3.2. Aufbau des Frameworks
3.2.3. Node.js-Serverkomponente
Die Node.js-Serverkomponente ist für die Benutzeroberfläche und die Koordination der
einzelnen Analysekomponenten während einer Analyse verantwortlich. Im Zuge des ReEngineering und den damit einhergehenden Veränderungen, sind auch Anpassungen an
der Node.js-Serverkomponente vorzunehmen. Die Veränderungen betreffen vor allem die
Kommunikation mit allen anderen Framework-Komponenten aus ihrer direkten Umgebung.
3.2.3.1. Verbindungen und Konfiguration
Die Node.js-Serverkomponente benötigt Verbindungen zu allen Kommunikationskomponenten; zur Nachrichtenaustauschkomponente, um die Analyse zu steuern, zur Datenaustauschkomponente, für den ’Direct Uploader’ und zur Informationsspeicherkomponente, um Daten hinsichtlich der Weboberfläche zu speichern. Um auch hier den Ansatz
so flexibel wie möglich zu halten, gibt es für jeden Kommunikationstyp eine implementierte Verbindung. Eine Umsetzung mit Interfaces ist hier nicht möglich, da die
Node.js-Serverkomponente auf der Programmiersprache JavaScript basiert, in welcher
kein Interface-Konzept vorgesehen ist. Daher müssen die Namen der Methoden in allen
verwendeten Verbindungsansätzen gleich lauten, zur Laufzeit werden dann die korrekten
Methoden aufgerufen. Dieser Ansatz wird als ’Duck-typing’ bezeichnet.
Welche Verbindung konkret verwendet wird, entscheidet sich anhand eines Attributs in
einer Konfigurationsdatei. Diese ist eine JavaScript-Datei, die eine direkt Verarbeitung
innerhalb der Node.js-Serverkomponente ermöglicht. Durch die drei Attribute messageConnection, dataConnection und workbenchConnection wird festgelegt, welche konkrete Kommunikationskomponente verwendet wird. Dazu gibt es drei weitere Attribute,
die messageConnectionConfig, die dataConnectionConfig und die workbenchConnectionConfig, in denen Verbindungsparameter, wie Adresse zur Komponente und Port, gespeichert sind.
3.2.3.2. Erkennen von aktiven Analysekomponenten
Beim Aufbau der Benutzeroberfläche muss die Node.js-Serverkomponente in der Lage
sein, alle verfügbaren Analysekomponenten zu erkennen und entsprechend dem Benutzer anzuzeigen. Realisiert wird dies durch AgentDescriptionMessage-Nachrichten, die
von den Agent-Managern versendet werden. Um eine solche AgentDescriptionMessageNachricht auch zu einem beliebigen Zeitpunkt zu erhalten, verwendet die Node.js-Serverkomponente einen Broadcast-Ansatz. Hierzu sendet sie eine Nachricht mit dem Inhalt
{broadcast:true} an alle Analysekomponenten und wartet dann auf eingehende Nachrichten. Die Analysekomponenten senden bei Erhalten der Broadcast-Nachricht ihre
AgentDescriptionMessage-Nachricht. Diese werden von der Node.js-Serverkomponente
gesammelt und dem Benutzer angezeigt.
39
3. Ansatz
3.2.3.3. Sammeln von Resultaten
Die Resultate einer Analyse sollen dem Benutzer nach erfolgreichem Durchlaufen angezeigt werden. Der Ablauf ist also Folgender: Ausgabe-Analyseagenten schreiben Resultate in das Result-Repository und benachrichtigen mit einer ResultMessage-Nachricht
die Node.js-Serverkomponente darüber. Diese ResultMessage-Nachrichten werden verwendet, um die Ergebnisse zu laden, sobald die Analyse abgeschlossen ist. Dazu muss
entschieden werden können, zu welchem Zeitpunkt eine Analyse abgeschlossen ist. Dies
ist der Fall, wenn alle Analysekomponenten erfolgreich ihre Arbeit abgeschlossen haben
oder, falls ein Agent fehlerhaft, ist, alle anderen möglichen Agenten abgearbeitet wurden.
Der Status eines Agenten ist innerhalb der CoordinationMessage-Nachrichten enthalten.
Um abzugleichen, wie viele Agenten noch besucht werden müssen bzw. besucht werden
können, kann ein Analyseworkflow als gerichteter, azyklischer Graph gesehen werden.
Vor dem Beginn einer Analyse wird eine Liste aufgebaut, die alle möglichen Knoten, also Analysekomponenten, enthält. Ist eine Analysekomponente abgeschlossen, wird diese
aus der Liste der Knoten entfernt. Abgeschlossen ist eine Analyse, wenn die Liste aller
Knote leer ist. Problematisch ist der Fall einer fehlerhaften Analysekomponente. Alle
nachfolgenden Komponenten können in diesem Fall nicht mehr besucht werden. In Abbildung 3.9 fällt Analysekomponente 2 aus, die Analysekomponenten 4 und 5 können
infolgedessen nicht mehr erreicht werden. Entsprechend müssten die Komponenten aus
der Liste der zu erreichenden Knoten entfernt werden. Um dies zu realisieren, kennt
jeder Knoten jeden seiner Nachfolger. Diese werden zu Beginn einer Analyse bestimmt.
Tritt ein Fehler auf, wird aus der Liste der zu besuchenden Knoten der Knoten entfernt,
bei dem der Fehler aufgetreten ist sowie alle Nachfolger dieses Knotens.
Abbildung 3.9.: Analyseworkflow als Graph
40
3.3. Kommunikation innerhalb des Frameworks - konkrete Ansätze
3.3. Kommunikation innerhalb des Frameworks - konkrete
Ansätze
Nach den bereits vorgestellten abstrakten Ansätzen zur Kommunikationsinfrastruktur
des Frameworks, sollen in diesem Kapitel konkrete Ansätze zur Realisierung der einzelnen Kommunikationskanäle beschrieben werden. Nach Abbildung 3.4 läuft die Verbindung über drei Kanäle, zu denen Verbindungen umzusetzen sind. Für das AgentenFramework sind diese hauptsächlich die Kommunikationskanäle zum reinen Nachrichtenaustausch und zum Speichern von Zwischenresultaten. Für die Node.js-Serverkomponente
kommt weiterhin ein Kommunikationskanal hinzu zum Speichern von sitzungsübergreifenden Daten hinzu.
3.3.1. Nachrichtenaustausch
Die konkrete Umsetzung der Nachrichtenkanäle soll hier gezeigt werden. Die eingesetzte Kommunikationskomponente sollte die lose Kopplung zwischen den Agenten unterstützen, das heißt es wird eine Art Publisher/Subscriber-Mechanismus benötigt. Des
Weiteren sollte sie auch bei einer hohen Zahl an Klienten gut skalieren und zuverlässig arbeiten. Die Wahl fällt hier auf einen Nachrichtenaustausch über das MQTT-Protokoll mit
einem Message-Broker als zentraler Nachrichtenaustauschkanal sowie das Austauschen
von Nachrichten über eine PostgreSQL-Datenbank, die über einen Interprozesskommunikationsmechanismus verfügt, wodurch ein Publisher/Subscriber-ähnliches Verfahren
realisiert werden kann.
3.3.1.1. MQTT
MQTT hat seine stärken vor allem im schnellen Austausch von Nachrichten (s. Abschnitt 2.6.1). Daher eignet es sich in dem Framework der Analytics Workbench als
Mittel für den Nachrichtenaustausch. Wie für alle Publisher/Subscriber-basierten Systeme, benötigt MQTT dazu einen Message-Broker. Dieser ist verantwortlich für das
korrekte Koordinieren von Nachrichten und Verwalten von Klienten.
Übertragen auf das Framework bedeutet dies, dass alle Analysekomponenten sowie die
Node.js-Serverkomponente mit dem Message-Broker verbunden sind. Die einzelnen Systembestandteil müssen entsprechende Verbindungen realisieren.
Innerhalb des Agenten-Framework wird dazu eine eine MQTTMessageConnection realisiert. Diese ist eine konkrete Implementierung des Interfaces MessageConnection (s.
Abschnitt 3.2.2.3 und Abbildung 3.10). Sie baut über setupConnection() eine Verbindung zum Message-Broker auf. Die Kommunikation über den Message-Broker läuft
über Topics. Entsprechend werden die einzelnen Nachrichtentypen zu Topics zugeordnet. AgentDescription-Nachrichten laufen über die Topics ’/agentdescription/new’ sowie
’/agentdescription/delete’; Topics für neue AgentDescriptionMessage-Nachrichten sowie
für selbige, falls eine Analysekomponente entfernt werden soll. DataMessage-Nachrichten
laufen über das Topic ’/data’ ab, CoordinationMessage-Nachrichten über die Topics
’/coordination/new’ und ’/coordination/update’, ErrorMessage-Nachrichten über das
Topic ’/error’. Für Nachrichten die Resultate betreffen, wird das Topic ’/result’ verwendet.
41
3. Ansatz
Je nach konfiguriertem Verbindungstyp erfolgt das Registrieren auf Topics direkt nach
Verbindungsaufbau oder dann, wenn es von Agent beziehungsweise Agent-Manager gewollt ist. Bei dem auf den Agent-Manager basierenden Verbindungstyp sowie ’AgentBundle’ ist es notwendig, sich bereits nach Verbindungsaufbau auf alle relevanten Topics zu registrieren. Andernfalls müsste bei jedem Registrierungswunsch die Verbindung
zu dem Message-Broker unterbrochen und wieder neu aufgebaut werden. Dies könnte
dazu führen, dass Nachrichten verloren gehen. Die Agent-Manager und Agent relevanten Topics zum Erhalten von Nachrichten sind ’/agentdescription/delete’, ’/coordination/update’ und ’/data’. Die Zuordnung, welche Nachricht für welchen Agent beziehungsweise Agent-Manager relevant ist, erfolgt über zwei Map-Datenstrukturen, die für
Agenten und die für Agent-Manager. Sie ordnen ein bestimmtes Nachrichtenmuster einem Agent bzw. einem Agent-Manager zu. Wird eine Nachricht empfangen, wird mittels
dieser beiden Map-Datenstrukturen abgeglichen, welcher Agent bzw. Agent-Manager
der korrekte Empfänger der Nachricht ist. Über writeDescription() werden lediglich
AgentDescriptionMessage-Nachrichten versendet.
Neben der Möglichkeit Nachrichten zu empfangen, muss auch die Möglichkeit gegeben
sein Nachrichten zu senden. Hierzu wird in den Methoden write(), update() zunächst
bestimmt, um welche Art von Nachricht es sich handelt. Ist der Nachrichtentyp zugeordnet, erfolgt ein ’publish’ auf das zu dem Nachrichtentyp gehörige Topic an den
Message-Broker.
Ähnliches gilt auch für die Node.js-Serverkomponente. Sie muss ebenfalls eine Verbindung zum Message-Broker besitzen. Wie in Abschnitt 3.2.2.3 beschrieben, existiert für
JavaScript kein Interface-Konzept. Daher muss darauf geachtet werden, dass alle Umgesetzten Verbindungen dieselben Methoden anbieten. Relevante Topics für das Erhalten
von Nachrichten sind hier ’coordination/update’, ’run/update’, ’agentdescription/new’
und ’result’. Diese werden für das Aktualisieren der Benutzeroberfläche und zum Verarbeiten der Analyseresultate verwendet.
Abbildung 3.10.: MQTTMessageConnection Klassendiagramm
42
3.3. Kommunikation innerhalb des Frameworks - konkrete Ansätze
3.3.1.2. PostgresSQL
PostgreSQL eignet sich für den Einsatz innerhalb der Analytics Workbench aufgrund
seines Interprozesskommunikationsmechanismus und der Möglichkeit Daten im JsonFormat zu verarbeiten.
Da PostgreSQL ein relationales Datenbanksystem ist (s. Abschnitt 2.6.2), werden Daten auch in Relationen (oder auch Tabellen) gespeichert. Entsprechend müssen Relationen erstellt werden, die die in 3.2.1.3 vorgestellten Nachrichten speichern können.
Diese Relationen haben alle das gleiche Schema: {id, Json-Objekt}. Die Id wird durch
das Datenbanksystem generiert und das Json-Objekt enthält die Nachricht. Folgende
Relationen sind für den reinen Nachrichtenaustausch relevant: AGENTDESCRIPTION,
COMMANDMESSAGE, DATAMESSAGE, ERRORMESSAGE. Auf diesen Relationen
müssen Trigger implementiert werden, die bei einer Operation auf der Relation (sei es
schreiben oder updaten) eine Nachricht über einen bestimmten Kanal senden. Abbildung 3.11 veranschaulicht den Vorgang. Ein Agent setzt einen ’LISTEN COORDINATION NEW’-Befehl ab (1). Danach schreibt die Node.js-Serverkomponente eine neue
CoordinationMessage-Nachricht in die Datenbank (2). Infolgedessen wird der Agent benachrichtigt (3).
Abbildung 3.11.: Listen/Notify-Mechanismus
Ebenfalls wie bei der Verwendung von MQTT, muss für PostgreSQL eine Nachrichtenverbindung sowohl für das Agenten-Framework als auch für die Node.js-Serverkomponente
realisiert werden. Diese implementiert ebenso wie die MQTTMessageConnection das Interface MessageConnection. Anstelle des Registrierens auf Topics, wird eine Verbindung
zur Datenbank aufgebaut und auf entsprechenden Kanäle gehorcht. Das Empfangen
von Nachrichten erfolgt über einen separaten Notifier. Dieser hält im Hintergrund eine
Datenbankverbindung aufrecht, empfängt Nachrichten und leitet diese an die PostgresMessageConnection weiter. Die Zuordnung der Nachrichten erfolgt auch hier über zwei
Map-Datenstrukturen, eine für die Agenten, eine für Agent-Manager.
Beim Schreiben bzw. Veröffentlichen einer Nachricht, wird zunächst bestimmt, um welche Art von Nachricht es sich handelt. Danach wird eine Verbindung zur Datenbank aufgebaut, die Nachricht gespeichert und die Verbindung zur Datenbank wieder geschlossen.
43
3. Ansatz
Abbildung 3.12.: PostgresMessageConnection Klassendiagramm
3.3.2. Datenspeicher
Neben reinen Nachrichten werden während einer Analyse auch Daten zwischen den einzelnen Analysekomponenten ausgetauscht. Diese werden nicht über den Nachrichtenkanal transportiert, sondern separat gespeichert. Dabei müssen Kommunikationskomponenten gewählt werden, die besonders für den Datentransfer geeignet sind. Hier fällt die
Wahl sowohl auf das File Transfer-Protokoll (FTP), ein bewährtes Protokoll zum Austausch von Dateien zwischen zwei Parteien, als auch auf eine PostgreSQL-Datenbank,
welche auch das Speichern von binären Daten unterstützt. Innerhalb einer PostgreSQLDatenbank können Daten bis zu einem Gigabyte gespeichert werden 2.6.2. Für FTP gibt
es keine Limitierungen hinsichtlich der Datengröße.
3.3.2.1. FTP
Das File Transfer Protocol dient zum Austausch von Dateien zwischen Client und
Server (s. 2.6.3). Entsprechend eignet es sich zum Austausch von Zwischenergebnissen zwischen verschieden Analysekomponenten. Ähnlich wie bei den Verbindungen zu
einem MQTT-Broker oder zur PostgreSQL-Datenbank, müssen entsprechende FTPVerbindungsschichten realisiert werden.
44
3.3. Kommunikation innerhalb des Frameworks - konkrete Ansätze
Innerhalb des Agenten-Frameworks ist dies die FTPDataConnection. Diese konkretisiert die Methoden des Interfaces DataConnection. Zum Verbindungsaufbau zu einem
FTP-Server wird, neben Url und Port, ein Benutzername und ein Passwort benötigt
(setupConnection()). Diese Eigenschaften werden aus der Konfigurationsdatei, die für
Umgebungsvariablen verantwortlich ist, extrahiert (s. 3.2.2.3). Da die meisten Netzwerke durch eine Firewall geschützt sind, ist es sinnvoll, passives FTP zu verwenden (s.
2.6.3).
Ist die Verbindung aufgebaut, können über writeData() Daten auf den FTP-Server geladen werden. Dazu muss ein Pfad angegeben werden. Dieser setzt sich aus einer generierten Id und einer Dateiendung zusammen. Die Dateiendung ist in den Metadaten über die
zu speichernden Daten hinterlegt. Neben dem Pfad muss zusätzlich eine Beschreibung
über den Dateiinhalt erfolgen. Dies sind im Falle der ausgetauschten Zwischenergebnisse Binärdateien. Nach der erfolgreichen Dateiübertragung wird die Verbindung wieder
getrennt.
Zum Dateidownload vom Server muss zunächst eine Verbindung aufgebaut werden. Um
eine konkrete Datei zu laden, wird der Pfad zu der Datei angegeben. Daraufhin wird die
Datei heruntergeladen und kann von den einzelnen Agenten weiter verarbeitet werden.
Um den Server frei von nicht benötigten Dateien zu halten, werden nach erfolgreichem
Laden der Daten durch einen Agenten, diese auf dem FTP-Server gelöscht (removeData()).
Die Node.js-Serverkomponente benötigt eine FTP-Verbindung lediglich für den ’Direct
Uploader’.
Abbildung 3.13.: FTPDataConnection Klassendiagramm
45
3. Ansatz
3.3.2.2. PostgreSQL als Speicher für binäre Daten
Alternativ zu FTP kann auch PostgreSQL zum Speichern von Zwischenergebnissen verwendet werden. Anstatt die Daten Dateisystemebene zu speichern, werden hier die Daten
als BLOB 6 in einer Relation gespeichert. Dazu wird Seitens der PostgreSQL eine neue
Relation erstellt, die den Namen ’Data’ trägt. Sie besteht aus den Attributen ’id’ und
’data’. ’id’ besteht aus einer generierten Id und einer Dateiendung. ’data’ beinhaltet die
binären Daten. Das Lesen und Speichern von Daten aus bzw. in diese Relation erfolgt
durch SQL-Anfragen. Speichern erfolgt über eine ’INSERT INTO ..’-Anfrage und Lesen
über eine ’SELECT data FROM data WHERE id = ..’-Anfrage.
Zuständig für den Aufbau der Verbindung zur PostgreSQL-Datenbank und zum Speichern der binären Daten ist die PostgresDataConnection. Diese realisiert, wie die FTPDataConnection, das Interface DataConnection. Entsprechend wird bei writeData() eine
Verbindung aufgebaut und innerhalb eine Transaktion die Daten in die Relation der Datenbank persistiert. Selbiges Verfahren erfolgt beim Löschen von Daten aus der Relation.
Innerhalb einer Transaktion wird die Anfrage ’DELETE FROM data WHERE id = ..’
ausgeführt, wobei ’id’ der für die Datei generierten Id entspricht.
Abbildung 3.14.: PostgresDataConnection Klassendiagramm
3.3.3. Sitzungsübergreifende Persistenz
Für die Node.js-Serverkomponente ist auch ein Kommunikationskanal von Bedeutung,
der es ermöglicht Daten zu speichern, die auch nach Ablauf einer Analyse erhalten bleiben müssen. Dies betrifft Daten zur Benutzerverwaltung, zu durchgeführten Analysen
6
Binary Large Object
46
3.3. Kommunikation innerhalb des Frameworks - konkrete Ansätze
und Ergebnissen sowie gespeicherten Analyseworkflows. Entsprechend muss das System,
bei dem diese Daten hinterlegt werden sollen einen permanenten Speicher anbieten. Besonders geeignet sind dazu Datenbanksysteme. Weiterhin sollte der Zugriff auf das Speichersystem Daten im Json-Format unterstützen oder es nur einen geringen Aufwand
darstellen, die Daten in das für das Speichersystem relevante Format umzuwandeln.
Um die Verbindungen zu abstrahieren, werden für jedes gewählte Speichersystem Verbindungen umgesetzt. Diese haben alle dieselben Methoden, wobei die Umsetzung innerhalb
der Methoden je nach Kommunikationskanal variiert. Die Logik zum Verbindungsaufbau
und die Anfrage werden in die entsprechenden Verbindungsumsetzungen ausgelagert.
3.3.3.1. SQLSpaces
SQLSpaces basiert zwar auf einer SQL-Datenbank (s. 2.4), bietet aber durch eine einfache
Schnittstelle Zugriff auf das Datenbanksystem und erfordert somit kein Formulieren komplexer Anfragen. Ebenfalls ist das Starten und Konfigurieren eines SQLSpaces-Servers
schnell erfolgt. Aus diesen Gründen eignet er sich für den Einsatz als Datenspeicher für
die sitzungsübergreifenden Daten, wie zum Beispiel in Kombination mit MQTT-Message
Broker als Nachrichtenaustauschkanal und FTP als Datenaustauschkanal.
Für den Zugang zu dem SQLSpaces-Server wird, wie bereits erwähnt, eine Verbindung
realisiert. Je nach zu speichernden Daten, wird der ’Space’ gewählt, in dem die Daten abgespeichert werden sollen. Der ’Space’ gibt innerhalb eines SQLSpaces-Servers
zusammengehörige Tupel an. Alle benutzerrelevanten Tupel werden in dem ’userSpace’
gespeichert, alle anderen im ’defaultSpace’. Da innerhalb der Node.js-Serverkomponente
Daten im Json-Format ausgetauscht werden, muss eine Konvertierung in das TupelFormat erfolgen und umgekehrt. Beim Schreiben eines Tupels werden alle Werte der
Schlüssel/Werte-Paare eines Json-Objekts in Tupel-Felder überführt. Das so entstandene Tupel wird dann dem SQLSpaces-Server hinzugefügt. Entsprechend werden beim
Lesen von Tupeln diese wieder in Json-Objekte überführt.
3.3.3.2. PostgreSQL
PostgreSQL kann auch als Komponente für alle sitzungsübergreifende Daten verwendet
werden, besonders wenn es bereits als Technologie für den Nachrichten- oder Datenaustausch verwendet wurde. Dazu müssen der Datenbank weitere Relationen hinzugefügt
werden. Diese werden zum einen für Benutzer, Rollen und Gruppen verwendet sowie für
Relationen, die Benutzer zu Rollen und Gruppen zuordnen. Da PostgreSQL zur Abfrage
der Daten die Abfragesprache SQL benutzt, sind Relationen, die lediglich zur Zuordnung
dienen nicht notwendig. Über JOINS lassen sich auch Daten über mehrere Relationen
abfragen. Da der Ansatz aber so abstrakt wie möglich sein soll und beispielsweise die
SQLSpaces keine JOINS unterstützen, werden die Zuordnungen separat gespeichert. Neben den Relationen für die Benutzerverwaltung, muss eine weitere Relation existieren,
die erstellte Workflows speichert und eine, die diese den Workflow-Gruppen zuordnet.
Weiterhin müssen durchgeführte Analysen sowie Informationen über Resultate in zwei
weiteren Relationen gespeichert werden.
Ebenfalls muss, wie bei allen anderen Kommunikationskanälen, für die Verwendung innerhalb der Node.js-Serverkomponente eine Verbindung umgesetzt werden. Da PostgreS-
47
3. Ansatz
QL das Json-Format unterstützt, müssen die aus der Datenbank gelesene Ergebnisse
nicht konvertiert werden, sondern können direkt weiterverarbeitet werden.
48
4. Implementierung
In diesem Kapitel sollen Auszüge aus der Implementierung des in Kapitel 3 beschriebenen Konzepts vorgestellt werden. Hierzu werden zunächst verwendete Bibliotheken aufgelistet und kurz skizziert. Darauffolgend wird der Algorithmus des in Abschnitt 3.2.3.3
erläuterten Konzepts zur Bestimmung des Status einer Analyse und des Sammelns von
Resultaten vorgestellt. Abgeschlossen wird diese Kapitel durch die Beschreibung des
Einsatzes von Triggern auf Relationen der PostgreSQL-Datenbank, die nötig sind, um
den Interprozesskommunikationsmechanismus verwenden zu können.
4.1. Verwendete Bibliotheken
In diesem Abschnitt sollen alle wichtigen Bibliotheken, die während der Implementierung
verwendet worden sind, vorgestellt werden. Diese werden unterteilt in Java-Bibliotheken,
die relevant sind für das Agenten-Framework und die JavaScript-Bibliotheken für die
Node.js-Serverkomponente. Verwendete Java-Bibliotheken sind Eclipse Paho, PostgresJDBC und Apache Commons.
• Eclipse Paho. Eclipse Paho [Foundation, 2015b] bietet Clients zur Kommunikation mit MQTT-Message Brokern in verschiedenen Programmiersprachen, darunter auch Java. Das Aufbauen einer neuen Verbindung erfolgt über eine Url, eine
eindeutige Client-Id sowie eine Angabe, wie Nachrichten persistiert werden sollen, solange sie sich im Zustellungsprozess befinden [Foundation, 2014]. Durch
MqttConnectionOptions können Optionen festgelegt werden, die die Verbindung
betreffen, wie beispielsweise eine clean-session (s. 2.6.1).
M q t t C l i e n t c l i e n t = new M q t t C l i e n t ( c o n n e c t i o n U r l , c l i e n t I d ,
persistence ) ;
MqttConnectOptions connOpts = new MqttConnectOptions ( ) ;
connOpts . s e t C l e a n S e s s i o n ( true ) ;
c l i e n t . c o n n e c t ( connOpts ) ;
Ist die Verbindung aufgebaut, kann der MqttClient verwendet werden, um ein
Topic zu abonnieren als auch eine Nachricht zu veröffentlichen.
// s u b s c r i b e t o t o p i c d a t a
c l i e n t . s u b s c r i b e ( ” data ” ) ;
// p u b l i s h message t o t o p i c d a t a
String content = ” Hello ! ” ;
MqttMessage message = new MqttMessage ( c o n t e n t . g e t B y t e s ( ) ) ;
c l i e n t . p u b l i s h ( ” data ” , message ) ;
49
4. Implementierung
• Postgres-JDBC. Zum Verbindungsaufbau zur PostgreSQL-Datenbank wird die Postgres-JDBC-Bibliothek verwendet [Group, 2013]. Dies ist der JDBC-Treiber für
die Postgresql-Datenbank. Seine Verwendung erfolgt ähnlich wie die des Standard
JDBC-Treibers. Die Verbindung wird wie folgt aufgebaut:
try {
C l a s s . forName ( ” o r g . p o s t g r e s q l . D r i v e r ” ) ;
} catch ( ClassNotFoundException e ) {}
// s e t u p c o n n e c t i o n
Connection c o n n e c t i o n = null ;
try {
c o n n e c t i o n = DriverManager . g e t C o n n e c t i o n ( ” j d b c : p o s t g r e s q l
: / / 1 2 7 . 0 . 0 . 1 : 5 4 3 2 / t e s t d b ” , ” t e s t ” , ” 123 ” ) ;
} catch ( SQLException e ) {}
Ist die Verbindung aufgebaut, können Anfragen durchgeführt werden. Bei datenmanipulierenden Operationen werden Transaktionen verwendet. Ein Beispiel für
diese, ist das Folgende:
try {
c o n n e c t i o n . setAutoCommit ( f a l s e ) ;
Statement stmt = c o n n e c t i o n . c r e a t e S t a t e m e n t ( ) ;
S t r i n g SQL = ”UPDATE m a h l z e i t e n SET p i z z a a n z a h l = 3
WHERE p i z z a a n z a h l = 1 ” ;
stmt . executeUpdate (SQL) ;
c o n n e c t i o n . commit ( ) ;
} catch ( SQLException e ) {
connection . rollback () ;
}
• Apache Commons. Apache Commons ist eine Sammlung von Bibliotheken für die
Programmiersprache Java, entwickelt von der Apache Software Foundation [Foundation, 2015a]. Diese unterstützen den Entwickler bei Aufgaben wie dem versenden von E-Mails, dem Hochladen von Dateien, der Durchführung einer Konvertierung oder Input/Ouput-Operationen. Unter der großen Anzahl an Komponenten
befindet sich Apache Commons Net. Sie bietet Implementierungen von Netzwerkprotokollen unter anderem auch für FTP. Im folgenden Beispiel wird das Aufbauen
einer Verbindung, das Herunterladen einer Datei vom Server und das Speichern
einer Datei auf dem Server gezeigt.
FTPClient c l i e n t = new FTPClient ( ) ;
// c o n n e c t t o f t p s e r v e r w i t h g i v e n u r l and p o r t
c l i e n t . connect ( url , port ) ;
// l o g i n w i t h username and password
c l i e n t . l o g i n ( username , password ) ;
// download f i l e
50
4.2. Status und Resultate eines Analyseworkflows
client . retrieveFileStream ( path to file ) ;
// u p l o a d f i l e
c l i e n t . s e t F i l e T y p e (FTP. BINARY FILE TYPE) ;
c l i e n t . s t o r e F i l e ( p a t h f o r f i l e , inputstream with data ) ;
// d i s c o n n e c t
c l i e n t . disconnect () ;
Innerhalb Node.js-Serverkomponente werden Bibliotheken verwendet, um eine Verbindung zu einer PostgreSQL-Datenbank, zu einem MQTT-Message Broker und zu einem
FTP-Server herzustellen.
• node-postgres. Für die Verbindung zur PostgreSQL-Datenbank wird die Bibliothek node-postgres verwendet, welche in JavaScript entwickelt ist. Sie unterstützt
Connection-Pooling, parametrisierte Anfragen sowie asynchrone Benachrichtigungen durch den Interprozesskommunikationsmechanismus von PostgreSQL [C, 2010].
• mqtt.js. Als Client für die Verbindung zum MQTT-Message Broker wird die Bibliothek mqtt.js verwendet. Sie bietet alle Features, wie beispielsweise das Veröffentlichen von Nachrichten, das Abonnieren von Topics und Empfangen von asynchronen
Benachrichtigungen bei eintreffenden Nachrichten. Bei der Verbindung können weitere Optionen angegeben werden, wie die Client-Id, die clean-session oder der Benutzername und das Password [Collina und Rudd, 2011].
• node-ftp. Zum Herunterladen und Hochladen von Dateien von/zu einem FTPServer wird für die Node.js-Serverkomponente die Bibliothek node-ftp verwendet.
Sie bietet eine Implementierung aller in RFC 959 spezifizierten FTP-Befehle, darunter auch das Speichern und Herunterladen von Dateien [White, 2011].
4.2. Status und Resultate eines Analyseworkflows
Um zu bestimmen, zu welchem Zeitpunkt eine Analyse abgeschlossen ist, wird ein Analyseworkflow in Liste aller Analysemodule überführt. Der zugehörige Algorithmus soll
in dem nachfolgenden Abschnitt vorgestellt werden. Im darauffolgenden Abschnitt wird
erläutert, wie die Liste der Analysemodule während einer Analyse verwendet wird.
4.2.1. Überführen eines Analyseworkflows in eine Liste
Wenn ein Benutzer eine Analyse startet, wird der zu der Analyse gehörige Workflow
in eine Liste von Analysemodulen, die alle ihre Nachfolger kennen, überführt. Dies ist
notwendig, um während der Analyse festzustellen, welche Analysekomponenten bereits
abgearbeitet wurden. Die Kenntnis über sämtliche Nachfolger wird benötigt, um im Falle
einer fehlerhaften Komponente alle nachfolgenden Komponenten bestimmen zu können.
Diese können aufgrund des Fehlers nicht mehr erreicht werden und dürfen nicht in der
Liste der noch abzuarbeitenden Komponenten erhalten bleiben.
Gespeichert ist ein Analyseworkflow als eine Menge von Modulen und Relationen zwischen den Modulen und kann als gerichteter, azyklischer Graph betrachtet werden. Die
51
4. Implementierung
einzelnen Analysemodule repräsentieren hierbei Knoten des Graphen. Um alle Nachfolger eines Moduls zu finden, wird für jedes Modul eine Tiefensuche zur Traversierung
des Graphen durchgeführt. Der komplette Algorithmus hierzu, findAllSuccessors, wird in
Listing 1 beschrieben. Beim Aufruf des Algorithmus ist die Liste ’result’ leer, danach wird
initial das Ausgangsmodul hinzugefügt. In einem nächsten Schritt werden alle direkten
Nachfolger dieses Moduls bestimmt. Dies geschieht über den Algorithmus, findDirectSuccesors (Listing 2). Dieser nimmt ein Modul entgegen und durchläuft alle Relationen
(wires). Ist das übergebene Modul der Ausgangspunkt einer Relation, wird der Liste der
direkten Nachfolger des Moduls das Modul übergeben, welches als Endpunkt der Relation angegeben ist. Die auf diese Weise gefundenen direkten Nachfolger eines Moduls
werden durchlaufen und für jeden Nachfolger rekursiv erneut der Algorithmus findAllSuccessors aufgerufen. Das Resultat ist eine Liste aller Module. Jedes Modul innerhalb
dieser Liste, enthält eine weitere Liste, die alle Nachfolger dieses Moduls beinhaltet.
Algorithm 1 Finden aller Nachfolger eines Moduls
function findAllSuccessors(module, result)
result ← result ∪ module
children ← findDirectSuccesors(module)
for child in children do
findAllSuccessors(child, result)
end for
end function
Algorithm 2 Finden der direkten Nachfolger eines Moduls
function findDirectSuccesors(module)
children ← empty
for wire in wires do
if wire.source == module then
children ← children ∪ wire.target
end if
end for
return children
end function
4.2.2. Abarbeiten der Analysemodule und Resultate
Das Resultat der beiden zuvor beschriebenen Algorithmen, eine Liste aller Module
mit deren Nachfolgern, wird während einer Analyse benötigt und dementsprechend
Zwischengespeichert. Trifft während einer Analyse eine CoordinationMessage ein, wird
überprüft, welchen Status das durch die CoordinationMessage beschriebene Analysemodul hat. Ist der Status 3, also die Analyse des Moduls erfolgreich abgeschlossen, wird aus
der Liste aller Module das abgeschlossene Analysemodul entfernt. Komplizierter ist der
Sachverhalt im Falle eines fehlerhaften Analysemoduls. Hier wird aus der gespeicherten
Liste das betroffene Modul sowie dessen Nachfolger gesucht. Diese werden geschlossen
aus der gesamten Liste aller Module entfernt. Auf diese Weise werden nicht mehr erreichbare Module entfernt. Im nächsten Schritt wird überprüft, ob die Liste leer ist.
52
4.3. PostgreSQL: Datenbank Initialisierung und Trigger
Eine leere Liste bedeutet eine abgeschlossene Analyse.
Während einer Analyse erreichen die Node.js-Serverkomponente ResultMessage-Nachrichten von Analysemodulen, die Resultate in das Result-Repository geschrieben haben. Diese empfangenen Informationen über ein geschriebenes Resultat werden in der Informationsspeicher-Komponente hinterlegt. Ist die Analyse abgeschlossen, werden diese Informationen abgerufen und dem Benutzer angezeigt.
4.3. PostgreSQL: Datenbank Initialisierung und Trigger
Wird PostgreSQL als Nachrichtenaustausch-, Datenaustauschkomponente oder zur Speicherung von Informationen für die Benutzeroberfläche verwendet, müssen bei der ersten
Benutzung Relationen erstellt werden. Dies geschieht zum einen innerhalb des AgentenFrameworks durch den Executor und zum anderen innerhalb der Node.js-Serverkomponente beim Startvorgang. Innerhalb des Agenten-Frameworks gibt es zusätzlich die Unterscheidung hinsichtlich der Verwendung der PostgreSQL-Datenbank als Nachrichten- oder
Datenaustauschkomponente oder beider Komponenten gleichzeitig. Dies erfolgt über
Boolesche Attribute, die anhand der festgelegten Konfiguration gesetzt werden.
Um zunächst zu überprüfen, ob eine Tabelle angelegt werden muss oder ob sie bereits
existiert, wird die Anfrage ’SELECT relname FROM pg class WHERE relname = ’relation relation’; ausgeführt. Ist das Ergebnis dieser Anfrage leer, wird über ’CREATE
TABLE table name ..’ die neue Tabelle erstellt.
Um den Interprozesskommunikationsmechanismus, dessen Verwendung innerhalb des
Frameworks in Abschnitt 3.3.1.2 beschrieben wird, nutzen zu können, müssen Datenbanktrigger umgesetzt werden. Diese finden Anwendung auf Relationen, die für Benachrichtigungen bei Veränderungen relevant sind, so z.B. für die Relation CoordinationMessage, die alle CoordinationMessage-Nachrichten beinhaltet. Ein Datenbanktrigger
ist eine Funktion, die ausgelöst wird, sobald bestimmte, festgelegte Bedingungen bei einer Operation auf einer Relation eintreten.
Listing 4.1 zeigt den Code, der einen Trigger auf der Relation CoordinationMessage
definiert. Dieser wird ausgeführt vor dem Einfügen einer neuen Zeile in die Relation.
Die Hauptfunktionalität, nämlich das Auslösen der Benachrichtigung, findet in Zeile
3 statt. Hier wird die Funktion pg notify aufgerufen, eine Funktion der PostgreSQLDatenbank, die als ersten Parameter den Kanal erwartet und als zweiten Parameter die
Nachricht, die über den angegeben Kanal verschickt werden soll. In diesem Fall soll über
den Kanal ’coordination new’, die neu eingefügte Zeile als Json-Objekt versendet werden. Die Überführung der neuen Zeile in ein Json-Objekt geschieht über die Funktion
row to json().
Listing 4.1: Trigger auf der Relation coordinationmessage
1
2
3
4
5
6
7
CREATE FUNCTION c o o r d i n a t i o n n e w ( ) RETURNS t r i g g e r AS $$
BEGIN
PERFORM p g n o t i f y ( ’ c o o r d i n a t i o n n e w ’ , r o w t o j s o n (NEW) : : t e x t ) ;
RETURN NEW;
END;
CREATE TRIGGER c o o r d i n a t i o n n e w BEFORE i n s e r t ON c o o r d i n a t i o n m e s s a g e
FOR EACH ROW EXECUTE PROCEDURE c o o r d i n a t i o n n e w ( ) ;
53
5. Anwendungsbeispiel
In diesem Kapitel soll die Tragfähigkeit des neuen Frameworks gezeigt werden. Dazu
wird zunächst ein Analyseworkflow, der im Rahmen des KOLEGEA-Projekts relevant
ist, verwendet. Dieser wird mit einer großen Menge Analysedaten durchgeführt. Dies ist
mit dem ursprünglichen Framework nicht möglich. Danach erfolgt ein Performancetest
des neuen Frameworks. Hier wird ein Analyseworkflow verwendet, der eine große Zahl
von Agenten beinhaltet und in verschiedenen Konfigurationen durchgeführt wird.
5.1. Analysesystem
Alle im Folgenden durchgeführten Analysen und Tests werden auf einem System mit
diesen Spezifikationen durchgeführt:
Name
Reihe
Prozessor
Arbeitsspeicher
Festplatte
Betriebssystem
Browser
MacBook Pro
Ende 2011
2,4 GHz Intel Core i5
8 GB 1333 MHz DDR3
256 GB SSD (M4-CT256M4SSD2)
OS X Yosemite (10.10.5)
Google Chrome v. 45.0.2454.85 (64 Bit)
Sämtliche Nachrichten- als auch Datenaustauschkomponenten laufen lokal auf dem angegebenen System.
Als MQTT-Message Broker wird Apache ActiveMQ (Version 5.12.0) verwendet. PostgreSQL findet in der Version 9.4.1.1 Anwendung. Als FTP-Server wird der Betriebssystemeigene FTP-Server verwendet.
5.2. Beispielanalyse im Rahmen des KOLEGEA Projektes
Das Verwenden von Analysedaten über 4 Megabyte ist innerhalb des bisherigen Frameworks der Analytics Workbench nicht möglich. Anhand einer Analyse aus dem KOLEGEAProjekt soll gezeigt werden, dass das neue Framework auch große Datenmengen behandeln kann.
55
5. Anwendungsbeispiel
5.2.1. Analysedaten
Bei den Analysedaten handelt es sich um Daten im Json-Activity Stream-Format [Snell
et al., 2011], welches verwendet wird, um Aktivitäten innerhalb sozialer Webapplikationen aufzuzeichnen. Ein Beispiel für einen Eintrag im Activity Stream- Format zeigt
Listing 5.1.
Listing 5.1: Beispiel eines Json-ActivityStreams
{
1
" published " : " 2 0 1 5 -0 2 -0 5 T 1 5 : 0 4 : 5 5 Z " ,
" actor " : {
" objectType " : " person " ,
" id " : " stefan " ,
},
" verb " : " add " ,
" object " : {
" objectType " : " video " ,
" video " : {
" link " : " www . somelink . de "
}
},
" target " : {
" objectType " : " blog " ,
" id " : " Stefans Blog " ,
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
}
18
Die Einträge sind Event-Logs aus der KOLEGEA-Plattform. Dies kann beispielsweise
das Login eines Benutzers sein. Insgesamt befinden sich in der Datei 38528 Event-Logs,
bei einer Dateigröße von 22,4 Megabyte.
5.2.2. Analyseworkflow
Abbildung 5.1 zeigt den Analyseworkflow. Das Modul ’Data Repository’ liest Daten im
Json-Format vom Webserver. Die Daten werden in den ’Stream Filter’ weitergeleitet.
Hier werden sie im Activity Stream-Format nach bestimmten Kriterien gefiltert. In diesem Beispiel werden Einträge ausgeschlossen, deren ’actor’ die ’role’ ’admin’ hat, also alle
Aktivitäten, die ein Administrator des Portals durchgeführt hat. Die gefilterten Einträge
werden im Modul ’Sequencial Pattern Mining’ einer Sequenzmuster-Erkennung unterzogen. Die Ergebnisse der Sequenzmuster-Erkennung werden durch das ’Table Viewer’Modul in eine Tabelle überführt. Ein Ausschnitt des Analyseergebnisses wird in Abbildung 5.2 dargestellt.
56
5.2. Beispielanalyse im Rahmen des KOLEGEA Projektes
Abbildung 5.1.: KOLEGEA Analyseworkflow
Abbildung 5.2.: Ergebnis der Analyse
5.2.3. Ergebnisse
Der beschriebene Workflow wird in verschiedenen Konfigurationen jeweils fünf mal durchgeführt. Dabei wird die Zeit gestoppt. Das Messen der Zeit erfolgt programmatisch. Beginn der Zeitmessung ist das Laden der Datei durch das Modul ’Data Repository’. Die
Zeitmessung endet nach dem Schreiben der Resultate durch das Modul ’Table Viewer’.
Die Zeiten werden in Sekunden angegeben. Die Darstellung der Ergebnisse erfolgt in
Form einer Tabelle, in der der Mittelwert der benötigten Zeit für verschiedene Konfigurationen abgetragen ist. In der ersten Spalte sind alle möglichen Verbindungsarten
aufgelistet, d.h. einzelne Verbindung pro Agent und Manager, eine Verbindung pro Manager und eine Verbindung pro ’Agenten-Bundle’. In der ersten Zeile sind alle Kombinationen möglicher Technologien dargestellt, beispielsweise MQTT zum Nachrichtenaustausch und FTP als Datenspeicher. Nach diesem Schema sind auch alle weiteren
Kombinationen dargestellt, wie zunächst die Komponenten zum Nachrichtenaustausch,
danach die Komponenten zum Datenaustausch.
57
5. Anwendungsbeispiel
Einzelne Verbindungen
Manager-basierte Verbindungen
Agenten-Bundle
MQTT
+ FTP
28,996
26,184
24,587
MQTT
+ PSQL
17,925
20,082
18,872
PSQL +
FTP
27,823
28,082
26,657
PSQL +
PSQL
21,778
22,493
21,591
5.3. Performancetest
Eine Anforderung an das System ist, seine Stabilität und Performanz auch bei einer
großen Anzahl an Agenten. Um das neue Framework hinsichtlich seiner Tragfähigkeit zu
überprüfen, wird ein Performancetest durchgeführt. Dazu wird ein Analyseworkflow erstellt, der durch viele Analysemodule künstlich vergrößert wird. Dieser Analyseworkflow
führt bei Verwendung innerhalb des alten Frameworks zu einem fehlerhaften Systemzustand und letztendlich dazu, dass das gesamte System nicht mehr nutzbar ist.
5.3.1. Analyseworkflow und Testdaten
Abbildung 5.3 zeigt einen Auschnitt des für den Performancetest verwendeten Analyseworkflows (der gesamte Workflow befindet sich auf dem Datenträger in Anhang B).
Dieser beinhaltet 54 Analysemodule. Darunter befinden sich auch Analysemodule, die
mehr als einmal verwendet wurden. Die Berechnung der Anzahl aufgebauter Verbindungen funktioniert wie folgt: Pro Agent-Manager einer Analysekomponente wird eine
Verbindung aufgebaut, außer im Fall der Verbindungsoption ’Agenten-Bundle’. Ist die
gewählte Verbindungsoption einzelne Verbindungen pro Agent-Manager und Agenten
herzustellen, wird für jede erstellte Agenten-Instanz eine weitere Verbindung erstellt.
Die einfachste Rechnung ist die für die Verbindungsoption ’Agenten-Bundle’. Hier ist die
Verbindungszahl pro gestarteter Analysekomponenten-Gruppe konstant eins. Im Falle
der Verbindungsoption, dass pro Agent-Manager eine Verbindung aufgebaut wird, ist
die Verbindungszahl gleich den gestarteten Analysekomponenten. So gibt es im Falle
des Beispiel-Workflows 11 Verbindungen. Bei der Verbindungsoption, dass pro AgentManager und Agenten eine Verbindung hergestellt wird, werden 11 Verbindungen für die
Agent-Manager und zusätzlich Weitere für die Agenteninstanzen aufgebaut. Da sich in
dem Analyseworkflow 54 Analysemodule befinden, werden 53 Agenteninstanzen erstellt
(für den ’Direct Uploader’ wird keine Agenteninstanz erstellt, da er Teil der Node.jsServerkomponente ist). Dies bedeutet, dass insgesamt 64 Verbindungen aufgebaut werden.
Als Testdaten dient der Inhalt einer gml-Datei mit einer Größe von 201 Kilobyte. Die
Datei beinhaltet einen in Textform überführten Graphen, repräsentiert durch einzelne
Knoten und Kanten, die Knoten zueinander zuordnen.
58
5.3. Performancetest
Abbildung 5.3.: Ausschnitt des Analyseworkflows zur Performanceanalyse
5.3.2. Durchführung
Der zuvor vorgestellte Analyseworkflow wird in verschiedenen Kombinationen zwischen
Kommunikationskanälen und Verbindungskonfigurationen jeweils fünf mal ausgeführt.
Die erste Kombination bildet MQTT als Medium für den Nachrichtenaustausch mit FTP
für den Datenaustausch. Weitere bestehen in der Verbindung von MQTT mit PostgreSQL für den Datenaustausch sowie PostgreSQL als Nachrichtenaustauschkomponente mit
FTP. Eine weitere Möglichkeit bildet PostgreSQL für beide Kommunikationswege.
Für jeden Durchlauf wird die benötigte Zeit bestimmt. Dies erfolgt innerhalb der Node.jsServerkomponente. Die Messung beginnt, sobald der Analyseworkflow gestartet wird
(der Benutzer klickt auf ’Execute’ innerhalb der Weboberfläche) und endet, sobald die
Analyse abgeschlossen ist (s. 3.2.3.3 und 4.2). Die Zeitangabe erfolgt in Sekunden.
5.3.3. Ergebnisse
Die Ergebnisse der Performancetests werden nachfolgend in drei Tabellen dargestellt, jeweils für die entsprechende Verbindungskonfiguration. Die einzelnen Spalten repräsentieren die Kombinationen der verschiedenen Kommunikationskanäle.
Durchlauf
1.
2.
3.
4.
5.
Mittelwert
MQTT +
FTP
42,488
41,25
41,454
44,541
38,599
41,6664
MQTT +
PSQL
26,824
24,193
23,443
23,927
23,277
24,3328
PSQL
+
FTP
40,188
43,365
42,514
42,42
39,317
41,5608
PSQL
+
PSQL
26,27
26,757
27,109
26,406
27,18
26,7444
Tabelle 5.1.: Ergebnisse für einzelne Verbindungen für Agent-Manager und Agenten
59
5. Anwendungsbeispiel
Durchlauf
1.
2.
3.
4.
5.
Mittelwert
MQTT +
FTP
44,417
41,47
40,514
42,697
41,15
42,0496
MQTT +
PSQL
25,624
25,136
24,13
24,637
24,685
24,8424
PSQL
+
FTP
58,950
58,464
49,658
50,542
51,000
53,7228
PSQL
+
PSQL
34,643
29,726
28,319
32,276
30,365
31,0658
Tabelle 5.2.: Ergebnisse für eine Verbindung pro Manager
Durchlauf
1.
2.
3.
4.
5.
Mittelwert
MQTT
FTP
74,394
81,207
77,346
62,654
62,654
71,651
+
MQTT
PSQL
37,569
31,926
31,957
32,016
33,897
33,473
+
PSQL
+
FTP
77,877
76,381
77,795
72,079
70,939
75,0142
PSQL
+
PSQL
42,599
43,891
38,58
51,843
45,503
44,4832
Tabelle 5.3.: Ergebnisse für ein Agenten-Bundle
5.4. Auswertung
Für die Beispielanalyse aus dem KOLEGEA-Projekt 5.2 liefern die Kombinationen
MQTT mit PostgreSQL und PostgreSQL für alle Kommunikationswege die schnellsten Ergebnisse (Mittelwerten 18,96 und 21,95 Sekunden). Das lässt den Rückschluss
zu, dass FTP als Datenaustauschkanal für dieses Anwendungsbeispiel langsamer ist als
PostgreSQL. Auch erkennt man, dass die Zeiten zwischen den einzelnen Konfigurationsvarianten nicht stark variieren. Dies liegt daran, dass Dank der wenigen verwendeten
Analysemodule die Verbindungsanzahl nicht drastisch steigt. Die verwendeten Analysemodule könnten auch zu einem ’Agenten-Bundle’ gruppiert werden.
Auch im Performancetest schneidet die Kombination aus MQTT und PostgreSQL, mit
Mittelwerten von 24,3228 Sekunden, 24,8424 Sekunden und 33,473 Sekunden am besten
ab. Betrachtet man im Vergleich die Zeiten zwischen den Konfigurationen in Tabelle
5.3.3 und in Tabelle 5.3.3, lässt sich erkennen, dass die Zeiten nahe beieinander liegen,
außer im Falle von PostgreSQL und FTP. Dies zeigt, dass die gewählten Nachrichtenaustauschkomponenten gut skalieren, aber auch, dass die Konfiguration ’Agent-Manager’
trotz der reduzierten Zahl an Verbindungen und der höheren Komplexität auf Seiten der
Analysekomponenten nahezu die gleiche Leistung bringen kann.
Bei der Verwendung der Verbindungskonfiguration ’Agenten-Bundle’ steigen die benötigten Zeiten zum Abarbeiten des Workflows stark an. Sind es bei einzelnen Verbindungen
die Mittelwerte 41,6664 Sekunden, 24,3328 Sekunden, 41,5608 Sekunden und 26,7444
Sekunden, steigt diese bei der Verbindungskonfiguration ’Agenten-Bundle’ auf 62,654
Sekunden, 33,897 Sekunden, 70,939 Sekunden und 45,503 Sekunden. Dieses Ergebnis ist
zu erwarten, da durch die einzelne Verbindung, die sich alle Agent-Manager und Agenten
60
5.4. Auswertung
teilen, ein Flaschenhals-Effekt erzeugt wird. Ein solcher Analyseworkflow ist daher kein
Anwendungsbeispiel für die Verbindungskonfiguration ’Agenten-Bundle’.
Insgesamt zeigt sich, dass das neue Framework sowohl große Datenmengen verarbeiten
kann als auch unter Last und bei einer Vielzahl von Analysekomponenten stabil bleibt.
Als Speicher für binäre Daten schneidet in den Anwendungsbeispielen PostgreSQL besser ab als FTP. Für den Nachrichtenaustausch liegen MQTT und PostgreSQL gleich
auf.
61
6. Zusammenfassung und Ausblick
6.1. Zusammenfassung
Im Rahmen dieser Masterarbeit wurde ein Re-Engineering des Frameworks der Analytics
Workbench durchgeführt. Hierzu wurde die Struktur aller im Framework befindlichen
Komponenten überarbeitet und zusätzlich eine neue Kommunikationsinfrastruktur konzipiert und realisiert.
Statt wie bisher über eine zentrale Kommunikationskomponente, verläuft der Kommunikationsfluss über verschiedene Kommunikationskanäle, die jeweils für unterschiedliche Aufgaben verantwortlich sind. So gibt es einen Kommunikationskanal für den reinen Nachrichtenaustausch, einen für das Speichern von Resultaten als auch einen, der
für das Speichern von binären Daten verantwortlich ist. Daten, die auch nach einer
Analyse verfügbar sein müssen, wie beispielsweise die durch einen Benutzer gespeicherten Analyseworkflows, werden über einen vierten Kommunikationskanal gespeichert.
Dadurch kann für jeden dieser Aufgabenbereiche eine Technologie eingesetzt werden,
die für die jeweilige Aufgabe geeignet ist. Im Rahmen dieser Arbeit wurde hierzu das
Nachrichtenaustauschprotokoll MQTT und PostgreSQL für den reinen Nachrichtenaustausch verwendet so wie FTP und PostgreSQL zum Speichern von binären Daten. Analyseübergreifende Daten können auf einem SQLSpaces-Server oder ebenfalls in einer
PostgreSQL-Datenbank hinterlegt werden. Die Wahl des Kommunikationsmediums, erfolgt durch einen administrativen Benutzer. Da sich in Zukunft die Anforderungen an
die Analytics Workbench ändern können und mit diesen auch die Anforderungen an die
verwendeten Technologien, wurde das Framework so flexibel und abstrakt wie möglich
gestaltet, sodass leicht neue Technologien eingesetzt werden können.
Um die Belastung, die auf den Kommunikationskomponenten liegt zu verringern, wurden neue Verbindungsmodelle gestaltet. Bisher hielten innerhalb einer Analysekomponente der Agent-Manager und seine Agenten jeweils eine Verbindung aufrecht. Dies
hatte mehrere Verbindungen pro Analysekomponente zur Folge. Da Agent-Manager und
zugehörige Agenten auch als logische Einheit betrachtet werden können, wurde eine Verbindungskonfiguration hinzugefügt, sodass sich Agent-Manager und zugehörige Agenten
eine Verbindung teilen. Weiterhin wurde eine zusätzliche Verbindungskonfiguration vorgestellt, die es ermöglicht, mehrere Analysekomponenten zu einer Einheit zusammenzufassen. Diese zusammengefassten Analysekomponenten teilen sich eine Verbindung.
Welches Verbindungsmodell zum Einsatz kommt, entscheidet der Benutzer über einen
Eintrag in einer Konfigurationsdatei.
Neben der Gestaltung einer neuen Kommunikationsinfrastruktur wurde auch die Struktur der Analysekomponenten und der Node.js-Serverkomponente verändert. Insbesondere wurden diese an die neue Kommunikationsinfrastruktur angepasst. Des Weiteren
wurden neue Lösungsansätze gestaltet, wie beispielsweise ein Mechanismus zur Erkennung abgeschlossener Analysen und die Bereitstellung der Ergebnisse dieser für den
Benutzer.
63
6. Zusammenfassung und Ausblick
Um die Tragfähigkeit des neuen Frameworks zu demonstrieren, wurde zum einen eine
Analyse aus dem KOLEGEA-Projekt verwendet. Diese wurde mit Analysedaten durchgeführt, die das vorherige Framework nicht behandeln konnte. Zum anderen wurde ein
Performancetest für unterschiedliche Kommunikationskanäle und Verbindungskonfigurationen durchgeführt. Hierzu wurde eine Analyse entworfen, die durch das Hinzufügen
mehrerer Analysekomponenten künstlich vergrößert wurde.
6.2. Ausblick
Das Verwalten von Analysekomponenten und Festlegen von Konfigurationen kann benutzerfreundlicher gestaltet werden. Bisher ist es möglich, mittels Executor Analysekomponenten zu starten, die dann zu einer Gruppe zusammengefasst werden können. Dies
ist unter Umständen problematisch. Fügt ein Benutzer in zwei verschiedenen Gruppen
dieselbe Analysekomponente ein, führt dies zu einem fehlerhaften Zustand des Systems.
Sinnvoll wäre daher eine Verwaltungskomponente einzusetzen, die es ermöglicht, Analysekomponenten zu starten und zu beenden als auch Verbindungskonfigurationen festzulegen und Analysekomponenten zu gruppieren. Dies kann beispielsweise über eine Weboberfläche erfolgen, die gleichzeitig dafür sorgt, dass ein Benutzer bei der Konfiguration
der Analysekomponenten keinen Fehler begehen kann. So kann die Verwaltungskomponente dafür sorgen, dass eine zu einer Gruppe hinzugefügte Analysekomponente nicht
zu einer weiteren Gruppe hinzugefügt werden kann.
Neben dem neu gestalteten Framework ist es sinnvoll, die Benutzeroberfläche der Analytics Workbench ebenfalls zu überarbeiten. Dies betrifft zum einen die Darstellung von
Ergebnissen, zum anderen die Benutzerfreundlichkeit. Dem Benutzer sollte die Fehlermeldung eines Moduls auch dann angezeigt werden, wenn es weitere Ergebnisse gibt.
Bisher erhält der Nutzer nur Rückmeldung über Fehler, wenn die komplette Analyse
nach Auftreten des Fehlers nicht mehr durchführbar ist. Um die Benutzerfreundlichkeit
zu steigern, sollten Analysekomponenten dynamisch funktionieren. Beispielsweise muss
bei dem Modul ’Data Repository’, falls eine neue Datei hinzugefügt wurde, erst das Modul neu gestartet werden, damit diese Datei verfügbar ist. Auch kann man dem Benutzer
die Option geben, eine Analyse vorzeitig zu beenden.
Da die Kommunikationskanäle flexibel konfigurierbar sind bietet es sich an, neben den
bereits umgesetzten Verbindungen Weitere zu realisieren. So könnte man einen Datenaustausch über das Dateisystem realisieren, vorausgesetzt entsprechende Analysekomponenten laufen auf demselben System.
64
Anhang A.
Eidesstattliche Erklärung
Ich erkläre, dass ich die vorliegende Masterarbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe und dass ich alle Stellen, die ich
wörtlich oder sinngemäß aus Veröffentlichungen entnommen habe, als solche kenntlich
gemacht habe. Die Arbeit hat bisher in gleicher oder ähnlicher Form oder auszugsweise
noch keiner Prüfungsbehörde vorgelegen.
Hünxe, den 16.11.2015
Stefan Remberg
65
Anhang B.
Datenträger
Der beiliegende Datenträger hat folgenden Inhalt:
Ordner
Sources
Präsentation
Dokumentation
Anwendung
Inhalt
1. Quellcode des Frameworks sowie der angepassten
Komponenten
2. Quellcode der Node.js-Serverkomponente
1. Folien der ersten Präsentation
2. Folien der zweiten Präsentation
1. Masterarbeit in PDF-Format
2. Installationsanleitung und Anleitung für die Entwicklung von Agenten
3. Analyseworkflows
1. Analysekomponenten
2. Node.js-Serverkomponente und Weboberfläche
67
Literaturverzeichnis
[Alexander et al., 1977] Alexander, Christopher, S. Ishikawa und M. Silverstein (1977). A pattern language: towns, buildings, construction, Bd. 2. Oxford
University Press.
[Baldoni et al., 2003] Baldoni, Roberto, M. Contenti und A. Virgillito (2003).
The evolution of publish/subscribe communication systems. In: Future directions in
distributed computing, S. 137–141. Springer.
[Bontcheva et al., 2004] Bontcheva, Kalina, V. Tablan, D. Maynard und
H. Cunningham (2004). Evolving GATE to Meet New Challenges in Language Engineering. Nat. Lang. Eng., 10(3-4):349–373.
[Börner et al., 2010] Börner, Katy, W. Huang, M. Linnemeier, R. J. Duhon,
P. Phillips, N. Ma, A. M. Zoss, H. Guo und M. A. Price (2010). Rete-netzwerkred: analyzing and visualizing scholarly networks using the Network Workbench Tool .
Scientometrics, 83(3):863–876.
[Buschmann, 1998] Buschmann, F. (1998). Pattern-orientierte Software-Architektur:
ein Pattern-System. Professionelle Softwareentwicklung. Addison-Wesley.
[C, 2010] C, Brain (2010). node-postgres - PostgreSQL client for node.js.. https:
//github.com/brianc/node-postgres. letzter Stand: 30.10.2015.
[COLLIDE, 2012] COLLIDE (2012). Configuration - SQLSpaces - COLLIDE projects.
http://projects.collide.info/projects/sqlspaces/wiki/Configuration. letzter Stand: 18.09.2015.
[Collina und Rudd, 2011] Collina, Matteo und A. Rudd (2011).
https://github.com/mqttjs/MQTT.js. letzter Stand: 30.10.2015.
MQTT.js.
[Corkill, 1991] Corkill, Daniel D (1991). Blackboard systems. AI expert, 6(9):40–
47.
[Cunningham, 2014] Cunningham, et al (2014). Developing Language Processing
Components with GATE Version 8 . University of Sheffield Department of Computer
Science.
[Cunningham, 2002] Cunningham, Hamish (2002). GATE, a general architecture for
text engineering. Computers and the Humanities, 36(2):223–254.
[Cunningham et al., 2002] Cunningham, Hamish, D. Maynard, K. Bontcheva
und V. Tablan (2002). GATE: an architecture for development of robust HLT applications. In: Proceedings of the 40th annual meeting on association for computational
linguistics, S. 168–175. Association for Computational Linguistics.
69
Literaturverzeichnis
[Douglas und Douglas, 2003] Douglas, Korry und S. Douglas (2003). PostgreSQL: a comprehensive guide to building, programming, and administering PostgreSQL
databases. SAMS publishing.
[Ebert, 2003] Ebert, Jürgen (2003). Software-Reengineering Umgang mit SoftwareAltlasten. Konradin-Verlag. Grasbrunn. Informatiktage, S. 224–31.
[Erman et al., 1980] Erman, Lee D, F. Hayes-Roth, V. R. Lesser und D. R.
Reddy (1980). The Hearsay-II speech-understanding system: Integrating knowledge
to resolve uncertainty. ACM Computing Surveys (CSUR), 12(2):213–253.
[Eugster et al., 2003] Eugster, Patrick Th, P. A. Felber, R. Guerraoui und
A.-M. Kermarrec (2003). The many faces of publish/subscribe. ACM Computing
Surveys (CSUR), 35(2):114–131.
[Ferrucci und Lally, 2004] Ferrucci, David und A. Lally (2004). UIMA: an architectural approach to unstructured information processing in the corporate research
environment. Natural Language Engineering, 10(3-4):327–348.
[Finin et al., 1994] Finin, Tim, R. Fritzson, D. McKay und R. McEntire (1994).
KQML As an Agent Communication Language. In: Proceedings of the Third International Conference on Information and Knowledge Management, CIKM ’94, S.
456–463, New York, NY, USA. ACM.
[Fipa, 2002] Fipa, ACL (2002). Message structure specification.
[Foundation, 2015a] Foundation, Apache Software (2015a). Apache Commons.
https://commons.apache.org/. letzter Stand: 30.10.2015.
[Foundation, 2014] Foundation, The Eclipse (2014). org.eclipse.paho.client.mqttv3
1.0.0 API . http://www.eclipse.org/paho/files/javadoc/index.html. letzter
Stand: 30.10.2015.
[Foundation, 2015b] Foundation, The Eclipse (2015b). Paho - Open Source messaging for M2M . http://www.eclipse.org/paho/clients/java/. letzter Stand:
30.10.2015.
[Gamma et al., 1995] Gamma, Erich, R. Helm, R. Johnson und J. Vlissides
(1995). Design Patterns: Elements of Reusable Object-oriented Software. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA.
[Gelernter, 1985] Gelernter, David (1985). Generative communication in Linda.
ACM Transactions on Programming Languages and Systems (TOPLAS), 7(1):80–112.
[Giemza et al., 2007] Giemza, Adam, S. Weinbrenner, J. Engler und H. U. Hoppe (2007). Tuple spaces as a flexible integration platform for distributed learning environments. FRONTIERS IN ARTIFICIAL INTELLIGENCE AND APPLICATIONS,
162:313.
[Göhnert et al., 2013] Göhnert, Tilman, A. Harrer, T. Hecking und H. U. Hoppe (2013). A Workbench to Construct and Re-use Network Analysis Workflows Concept, Implementation, and Example Case. Niagara Falls, Canada.
70
Literaturverzeichnis
[Göhnert et al., 2014] Göhnert, Tilman, S. Ziebarth, N. Malzahn und H. U.
Hoppe (2014). Einbettung von Learning Analytics in Lernplattformen durch Integration mit einer Analyseworkbench. Bd. 1227, S. 96–103, Freiburg, Deutschland.
CEUR-WS.
[Götz und Suhre, 2004] Götz, Thilo und O. Suhre (2004). Design and implementation of the UIMA Common Analysis System. IBM Systems Journal, 43(3):476–489.
[Grishman, 1997] Grishman, R (1997). TIPSTER Architecture Design Document
Version 2.3 . Technischer Bericht, DARPA.
[Group, 2013] Group, The PostgreSQL Global Development (2013). PostgreSQL JDBC Driver . https://jdbc.postgresql.org/. letzter Stand: 30.10.2015.
[Hahn et al., 2008] Hahn, Udo, E. Buyko, R. Landefeld, M. Mühlhausen,
M. Poprat, K. Tomanek und J. Wermter (2008). An overview of JCoRe, the
JULIE lab UIMA component repository. In: Proceedings of the LREC , Bd. 8, S. 1–7.
[Herr et al., 2006] Herr, Bruce W, W. Huang, S. Penumarthy und K. Börner
(2006). Designing highly flexible and usable cyberinfrastructures for convergence. Annals of the New York Academy of Sciences, 1093(1):161–179.
[Hunkeler et al., 2008] Hunkeler, U., H. L. Truong und A. Stanford-Clark
(2008). MQTT-S A publish/subscribe protocol for Wireless Sensor Networks. In:
Communication Systems Software and Middleware and Workshops, 2008. COMSWARE 2008. 3rd International Conference on, S. 791–798.
[Ihaka und Gentleman, 1996] Ihaka, Ross und R. Gentleman (1996). R: a language for data analysis and graphics. Journal of computational and graphical statistics, 5(3):299–314.
[Jennings, 2000] Jennings, Nicholas R. (2000). On agent-based software engineering. Artificial Intelligence, 117(2):277 – 296.
[Jennings, 2001] Jennings, Nicholas R (2001). An agent-based approach for building
complex software systems. Communications of the ACM, 44(4):35–41.
[Milo et al., 2007] Milo, Tova, T. Zur und E. Verbin (2007). Boosting topic-based
publish-subscribe systems with dynamic clustering. In: Proceedings of the 2007 ACM
SIGMOD international conference on Management of data, S. 749–760. ACM.
[for Network Science Center, 2011] Network Science Center, Cyberinfrastructure for (2011). Cyberinfrastructure Shell . http://cishell.org/home.
html. letzter Stand: 14.11.2015.
[OSGi-Alliance, 2015] OSGi-Alliance (2015). OSGi Alliance — The Dynamic Module System for Java. https://www.osgi.org/. letzter Stand: 14.11.2015.
[Postel und Reynolds, 1985] Postel, J. und J. Reynolds (1985). File Transfer
Protocol . RFC 959 (INTERNET STANDARD). Updated by RFCs 2228, 2640, 2773,
3659, 5797, 7151.
[PostgreSQL, 2015a] PostgreSQL (2015a).
Appendix D. SQL Conformance.
http://www.postgresql.org/docs/9.5/static/features.html.
letzter Stand:
01.09.2015.
71
Literaturverzeichnis
[PostgreSQL, 2015b] PostgreSQL (2015b). PostgreSQL: About.
postgresql.org/about/. letzter Stand: 01.09.2015.
http://www.
[PostgreSQL, 2015c] PostgreSQL (2015c).
PostgreSQL: Documentation: 9.4:
JSON Functions and Operators. http://www.postgresql.org/docs/9.4/static/
functions-json.html. letzter Stand: 01.09.2015.
[Rosenblum und Wolf, 1997] Rosenblum, David S. und A. L. Wolf (1997). A
Design Framework for Internet-scale Event Observation and Notification. In: Proceedings of the 6th European SOFTWARE ENGINEERING Conference Held Jointly
with the 5th ACM SIGSOFT International Symposium on Foundations of Software
Engineering, ESEC ’97/FSE-5, S. 344–360, New York, NY, USA. Springer-Verlag New
York, Inc.
[Schumacher, 2001] Schumacher, Michael (2001). Multi-agent systems. Objective
Coordination in Multi-Agent System Engineering: Design and Implementation, S. 9–
32.
[Snell et al., 2011] Snell, James M, M. Atkins, W. Norris, C. Messina, M. Wilkinson und R. Dolin (2011). Activity Streams Working Group: JSON Activity Streams 1.0 . http://activitystrea.ms/specs/json/1.0/#toc. letzter Stand:
30.10.2015.
[Standard., 2014] Standard., OASIS (2014). MQTT Version 3.1.1 . http://docs.
oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. letzter Stand: 13.09.2015.
[Team, 2009] Team, NWB (2009). Network Workbench Tool User Manual 1.0.0 . http:
//nwb.cns.iu.edu/Docs/NWBTool-Manual.pdf. letzter Stand: 14.11.2015.
[Weinbrenner, 2012] Weinbrenner, Stefan (2012). SQLSpaces-A Platform for Flexible Language-Heterogeneous Multi-Agent Systems. Verlag Dr. Hut.
[White, 2011] White, Brian (2011).
node-ftp. letzter Stand: 30.10.2015.
node-ftp.
https://github.com/mscdex/
[Wooldridge, 1997] Wooldridge, Michael (1997). Agent-based software engineering. IEE Proceedings-software, 144(1):26–37.
[Xia et al., 2012] Xia, Feng, L. T. Yang, L. Wang und A. Vinel (2012). Internet
of things. International Journal of Communication Systems, 25(9):1101.
72