Monitoring verteilter Dienste für Datenextraktion

Größe: px
Ab Seite anzeigen:

Download "Monitoring verteilter Dienste für Datenextraktion"

Transkript

1 Monitoring verteilter Dienste für Datenextraktion Diplomarbeit zur Erlangung des akademischen Grades eines Diplom-Informatikers 30. Juli 2013 Steffen Jasper Matrikel-Nr Betreuender wissenschaftlicher Mitarbeiter: Dr. Daniel Schuster Betreuender Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze

2

3 Aufgabenstellung Diese Seite wird beim Druck durch die originale Aufgabenstellung ersetzt. Monitoring verteilter Dienste für Datenextraktion III

4

5 Erklärung Hiermit erkläre ich, Steffen Jasper, die vorliegende Diplomarbeit zur Erlangung des akademischen Grades eines Diplom-Informatikers zum Thema Monitoring verteilter Dienste für Datenextraktion selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literaturund sonstigen Informationsquellen verfasst zu haben. Dresden, 30. Juli 2013 Unterschrift Monitoring verteilter Dienste für Datenextraktion V

6

7 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Motivation Problemstellung und Zielsetzung Aufbau der Arbeit Grundlagen Monitoring verteilter Systeme Geeignete Protokolle und Ansätze XMPP AMQP SOAP REST Verwandte Arbeiten Kestrel Intelligent Server Management Framework over Extensible Messaging and Presence Protocol Django Web-Framework Anforderungen Datensammlung Web-Oberfläche Konzeption Überblick Logger und XMPP-Komponente des Monitors finden sich Push versus Pull Flusssteuerung Pull-Ansatz Push-Ansatz mit Message-Stanzas Push-Ansatz mit IQ-Stanzas Prioritäten Auswahl und Begründung Datensammlung XML-Struktur Monitor als XMPP-Komponente Persistente Datenspeicherung Logger des Cluster-Knoten als XMPP-Client Nutzung von Service Discovery Ablauf der Flusssteuerung Web-Oberfläche Ansicht Modellraum-Hierarchie Entwicklungen bei Modellräumen vergleichen Monitoring verteilter Dienste für Datenextraktion VII

8 Inhaltsverzeichnis Inhaltsverzeichnis Ansicht für einen einzelnen Modellraum Ansicht für einzelnes Dokument Darstellung des Systemzustandes der Cluster-Knoten Implementation Datensammlung XMPP-Komponente nach XEP SQL-Datenbank XMPP-Client als Logging Komponente des Indexierungsservers Web-Oberfläche Django-Anwendung monitor Implementation der JavaScript-Funktionalität am Beispiel der Hierarchie- Darstellung Evaluation Vergleich der unterschiedlichen XML-Strukturen Vergleich der Zugriffsstrategien auf die Datenbank Extraktion der Logging-Einträge Performance-Kosten des Datenbank-Zugriffs Performance bei praxisnahem Setup Prüfung des Verhaltens bei überfüllter Queue des Monitors Zusammenfassung und Ausblick Ergebnisse Ausblick A Abbildungen i B Listings iii Literaturverzeichnis vii VIII Monitoring verteilter Dienste für Datenextraktion

9 Abbildungsverzeichnis Abbildungsverzeichnis Abbildungsverzeichnis 2.1 Struktur eines XMPP-Netzwerkes [Sto11] Intellix Indexing-Prozess [Sch+12] Gesamtüberblick Struktur Interface ILogger XMPP-Kommunikation: Logging Ablauf des Pufferns im Logger XMPP-Kommunikation: Service Discovery Ablauf des Sendens im Logger Ablauf der Vearbeitung im Monitor Struktur der Web-Oberfläche Grid-Layout-Algorithmus: Bearbeitung Blattknoten Grid-Layout-Algorithmus: Knoten mit Kindern und Verschiebung der Nachfolger Layout der Flussansicht Gesamtstruktur modelspace und Abhängigkeiten Klassendiagramm Monitor Klassendiagramm Logger Ablauf Logging mit den implementierten Klassen Vergleich der XML-Repräsentationen Vergleich der Komponenten-Klassen Einfluss der Größe des Worker-Pools Optimale Nachrichten-Größe bei einem sendenden Logger Optimale Nachrichten-Größe bei zehn sendenden Loggern A.1 Vergleich aller Komponenten-Klassen und XML-Strukturen i Monitoring verteilter Dienste für Datenextraktion IX

10

11 Listingverzeichnis Listingverzeichnis Listingverzeichnis 2.1 Service Discovery-Abfrage nach Identität und Features [Hil+08] Service Discovery-Antwort zu Identität und Features [Hil+08] Service Discovery-Anfrage nach verknüpften XMPP-Instanzen [Hil+08] Service Discovery-Antwort zu verknüpften XMPP-Instanzen [MSM10] Veröffentlichung von Daten zu einem Node [MSM10] Publish-Subscribe-Service informiert Abonnenten [MSM10] Generierung des IQ-Result Service Discovery durch Logger Implementation der Methode run der Klasse LoggerSender Start des Sender-Thread Auf IQ-Result warten Die Klasse RawLogEntry als Abbildung des gewählten SQL-Schemas in Django Queryset-API von Django SQL-Anweisung die aus Listing 5.7 durch Django generiert wird Template für Container-HTML-Seite mit Einbindung und Initialisierung eines jquery-plugins B.1 XML-Schema für Inhalt der XMPP-Nachrichten zur Übermittlung der Logging- Einträge iii B.2 SQL-Schema für die persistente Datenspeicherung iv B.3 XML-Schema für Setup-Dateien des Evaluation-Tools iv Monitoring verteilter Dienste für Datenextraktion XI

12

13 Abkürzungsverzeichnis Abkürzungsverzeichnis Abkürzungsverzeichnis AMQP CSS HTML HTTP IETF JID JSON MOM MTV MVC ORM REST SASL SNMP SQL SSD SVG TCP TLS W3C WLAN WSDL XEP XML XMPP XSD XSF Advanced Message Queuing Protocol Cascading Stylesheets Hypertext Markup Language Hypertext Transfer Protocol Internet Engineering Task Force Jabber Identifier JavaScript Object Notation Message Oriented Middleware Model-Template-View Model-View-Controller Object-Relational-Mapping Representational State Transfer Simple Authentication and Security Layer Simple Network Management Protocol Structured Query Language Solid-State-Drive Scalable Vector Graphics Transmission Control Protocol Transport Layer Security World Wide Web Consortium Wireless Local Area Network Web Service Definition Language XMPP Extension Protocols Extensible Markup Language Extensible Messaging and Presence Protocol XML Schema Definition Language XMPP Standards Foundation Monitoring verteilter Dienste für Datenextraktion XIII

14

15 1 Einleitung 1 Einleitung 1.1 Motivation Das Modelspace-Projekt entwickelt ein System zur automatischen Extraktion von Indexdaten aus Dokumenten. Dieses System stellt bisher für Nutzer, die Dokumente indizieren lassen und für die Administratoren des Indizierungsclusters keine Möglichkeit zur Verfügung, den Zustand des Clusters und der Indizierungsleistung während des Betriebes einzuschätzen. 1.2 Problemstellung und Zielsetzung Durch Umsetzung eines Live-Monitorings für den Modelspace-Cluster soll das bestehende Defizit behoben werden. Das Live-Monitoring erfolgt durch eine zentrale Monitor-Instanz. Sie aggregiert Informationen zur Systemleistung im Allgemeinen und zur Extraktion von Indexdaten von jedem Knoten im Cluster und stellt diese geeignet dar. Die Darstellung der Monitoring-Daten erfolgt mittels einer Web-Oberfläche. 1.3 Aufbau der Arbeit Kapitel 2 stellt ausgewählte, für die vorliegende Arbeit relevante Konzepte, Techniken und verwandte Arbeiten vor. In Kapitel 3 werden die an das zu konzeptionierende System gestellten Anforderungen vorgestellt und erläutert. Die Konzeption in Kapitel 4 greift die Anforderungen auf und stellt die gewählten Lösungsansätze für die Datensammlung und die Web-Oberfläche vor. Die prototypische Implementation wird in Kapitel 5 dokumentiert. Anhand ausgewählter Quellcodeartefakte wird erläutert, wie die konzeptionierten Lösungsansätze mit den gewählten Programmiersprachen, Bibliotheken und Frameworks umgesetzt werden. Die Evaluation in Kapitel 6 untersucht das Verhalten des implementierten Prototypen unter verschiedenen Laufzeitbedingungen. Kapitel 7 gibt eine zusammenfassende Betrachtung der erarbeiteten Ziele und stellt mit Bezug auf die in Kapitel 6 gewonnenen Evaluationsresultate ein Fazit und einen Ausblick auf zukünftige Entwicklungen fest. Monitoring verteilter Dienste für Datenextraktion 1

16

17 2 Grundlagen 2 Grundlagen In diesem Kapitel werden für die vorliegende Arbeit relevante Konzepte, Techniken und verwandte Arbeiten vorgestellt. Insbesondere wird auf mögliche Transportmechanismen zur Umsetzung der Datensammlung eingegangen. 2.1 Monitoring verteilter Systeme Monitoring ist die Sammlung von Informationen über ein Netzwerk, seiner Teilnehmer und deren Status und ist ein fundamentaler Bestandteil des Betriebs von Netzwerk-Systemen [Sta+08]. Beim traditionellen Netzwerk-Management wird Monitoring auf Geräte-Basis betrieben und pro Netzwerk-Entität werden periodisch durch ein Monitoring-System Informationen und Parameter des Netzwerk-Knotens abgefragt. Das Simple Network Management Protocol (SNMP) 1 ist wohl das bekannteste Protokoll, dass diesen klassischen Ansatz umsetzt. Für Netzwerke moderater Größe hat sich dieser Ansatz in der Vergangenheit bewährt. Die Anforderungen an ein modernes System zum Monitoring verteilter Systeme mit vielen Knoten und schnellen Änderungen ihrer Konfiguration sind jedoch höher und ergeben sich zum Beispiel aus Problemen der Skalierbarkeit des Pull-Ansatzes für das Sammeln relevanter Daten. 2.2 Geeignete Protokolle und Ansätze Im Folgenden werden geeignete Protokolle und Ansätze für den Austausch von Daten innerhalb von verteilten Systemen vorgestellt XMPP Das Extensible Messaging and Presence Protocol (XMPP) ist ein von der Internet Engineering Task Force (IETF) verwalteter Standard und basiert auf der Verwendung der Extensible Markup Language (XML). Es spezifiziert einen Mechanismus für den XML-basierten Austausch von strukturierten und erweiterbaren Daten in (Fast)-Echtzeit zwischen mehreren Netzwerk- Teilnehmern [Sai11b]. Ein Überblick über den grundlegenden Aufbau wird im Abschnitt Kurzbeschreibung gegeben. XMPP ist sehr flexibel und einfach erweiterbar und für verschiedenste Applikationen und Anforderungen wurden Erweiterungen zu XMPP konzipiert. Die XMPP Standards Foundation (XSF) 2 verwaltet und standardisiert derartige Erweiterungen in Form von XMPP Extension Protocols (XEP) 3. Die Abschnitte XEP-0030: Service Discovery, XEP-0060: Publish-Subscribe, XEP-0114: Jabber Component Protocol und XEP-0163: Personal Eventing Protocol stellen die für diese Arbeit relevanten Erweiterungen vor. Monitoring verteilter Dienste für Datenextraktion 3

18 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze Abbildung 2.1: Struktur eines XMPP-Netzwerkes [Sto11] Kurzbeschreibung Clients verbinden sich nicht direkt miteinander, sondern immer mit einem Server, von denen es mehrere geben kann. XMPP nutzt eine dezentrale Client-Server Architektur, bei der Clients Daten mit Hilfe der Server austauschen und Server miteinander kommunizieren, wenn diese Daten an einen Client weiterleiten, der bei einem anderen Server angemeldet ist. Es ergibt sich eine Netzwerk-Struktur, die sehr ähnlich zur Struktur für die -Kommunikation ist und in Abbildung 2.1 gezeigt wird. Der Datenaustausch zwischen Client und Server erfolgt über unidirektionale XML-Streams (einer für jede Richtung), die bei der Anmeldung des Clients am Server über das Transmission Control Protocol (TCP) aufgebaut werden und für den gesamten Zeitraum der Kommunikation bestehen bleiben. Ein Stream wird mit einem öffnenden Tag <stream> eingeleitet, enthält als Kind-Elemente die Kommunikation zwischen Client und Server in Form von weiteren XML-Tags und wird bei Beendigung der Kommunikation mit </stream> abgeschlossen. Die weiteren XML- Elemente, welche enthalten sein können, werden als XML-Stanzas bezeichnet. XMPP unterstützt die Verschlüsselung der Kommunikation zum Server per Transport Layer Security (TLS) 4 und nutzt für die Authentifizierung Simple Authentication and Security Layer (SASL) 5. Die Kommunikation zwischen Servern verläuft analog, auch sie tauschen XML-Stanzas mit Hilfe von zwei XML-Streams aus, die über eine optional verschlüsselte TCP-Verbindung aufgebaut werden. Der Standard definiert drei Stanza-Typen: IQ, Presence und Message [Sai11b, Abschnitt 8.2]. Jede XMPP-Instanz (Teilnehmer im XMPP-Netzwerk) muss eindeutig identifizierbar sein und besitzt deswegen einen Jabber Identifier (JID) [Sai11a]. Die JIDs sind Grundlage des Routings innerhalb des Servers. Dazu wird bei jedem, von einem Client generierten, Stanza die Quelle und das Ziel in Form der Attribute from und to hinterlegt, indem in den Attributen die entsprechenden JIDs gespeichert werden. Der Server erkennt dann anhand des Ziels, ob dieses Stanza an einen bei ihm angemeldeten Client gerichtet ist und direkt an diesen übermittelt werden Monitoring verteilter Dienste für Datenextraktion

19 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze kann oder ob die Weiterleitung des Stanzas zu einem weiteren Server nötig ist. XMPP-Server erfüllen im XMPP-Netzwerk damit hauptsächlich die Rolle eines Routers, die dafür sorgen dass die Nachrichten die richtigen Endpunkte der Kommunikation erreichen [WL09]. Ursprünglich wurde das Protokoll für das Instant-Messaging entwickelt. Die dafür notwendigen XML-Stanzas, ihre Verarbeitung und die Abläufe werden in Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence 6 näher beschrieben. Es stellt das Konzept der Roster vor und beschreibt wie Presence-Informationen zwischen XMPP-Instanzen ausgetauscht werden. Presence-Informationen sind Angaben über die Verfügbarkeit einer XMPP-Instanz für die Kommunikation [Sai11b, Abschnitt 2.2]. Die Informationen werden über das Presence-Stanza verschickt. Ein Roster ist der XMPP-Begriff für die Kontaktliste einer XMPP-Instanz [Sai11c, Abschnitt 1.3]. Der Roster zu einem XMPP-Client wird serverseitig gespeichert und verwaltet. Er enthält JIDs und den Status des Austauschs von Presence-Informationen zu diesen JIDs. Zwischen zwei XMPP-Instanzen können drei mögliche Zustände des Austauschs bestehen: kein, einseitiger oder gegenseitiger Austausch. Presence-Abonnements müssen immer durch die XMPP- Instanz, deren Presence-Updates abonniert werden sollen, bestätigt werden. Presence-Updates werden vom XMPP-Server anhand der Informationen in den Rostern verbreitet. Wenn sich eine XMPP-Instanz neu beim Server anmeldet und seinen initialen Presence-Status mitteilt, dann bestimmt der XMPP-Server, anhand des Rosters dieser XMPP-Instanz, welche anderen XMPP-Instanzen dieses Update empfangen dürfen und wollen und verteilt das Presence-Stanza an diese. XEP-0030: Service Discovery Mit der Unterstützung von Service Discovery sind XMPP-Instanzen in der Lage Informationen über sich bereitzustellen und von anderen XMPP-Instanzen Informationen über diese anzufordern [Hil+08]. Diese Informationen können unterstützte Features und Protokolle beschreiben, detaillierte Angaben zu Typ und Identität der XMPP-Instanz machen oder eine Auflistung von weiteren XMPP-Instanzenen sein, die mit der angefragten XMPP-Instanz verbunden sind. Zur Abfrage von Informationen werden IQ-Stanzas vom Typ Get verwendet, die ein spezielles Kind- Element enthalten. Abfragen zur Identität und zu Features enthalten ein <query>-element mit dem Namensraum Listing 2.1: Service Discovery-Abfrage nach Identität und Features [Hil+08] 1 <iq type = get 2 from = net / orchard 3 to= plays. shakespeare. lit 4 id= info1 > 5 <query xmlns = http: // jabber. org / protocol / disco # info /> 6 </iq > Die Antwort wird per IQ-Result übermittelt und enthält die Identitäten und die unterstützten Features des angefragten JID: Listing 2.2: Service Discovery-Antwort zu Identität und Features [Hil+08] 1 <iq type = result 2 from = plays. shakespeare. lit 3 to= net / orchard 4 id= info1 > 5 <query xmlns = http: // jabber. org / protocol / disco # info > 6 < identity 7 category = conference 6 Sai11c. Monitoring verteilter Dienste für Datenextraktion 5

20 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze 8 type = text 9 name = Play-Specific Chatrooms / > 10 < identity 11 category = directory 12 type = chatroom 13 name = Play-Specific Chatrooms / > 14 < feature var = http: // jabber. org / protocol / disco # info /> 15 < feature var = http: // jabber. org / protocol / disco # items /> 16 < feature var = http: // jabber. org / protocol / muc /> 17 < feature var = jabber:iq:register / > 18 < feature var = jabber:iq:search / > 19 < feature var = jabber:iq:time / > 20 < feature var = jabber:iq:version / > 21 </ query > 22 </iq > Um die Informationen zu verknüpften XMPP-Instanzen, als Items bei Service Discovery bezeichnet, abzufragen, wird der Namensraum verwendet: Listing 2.3: Service Discovery-Anfrage nach verknüpften XMPP-Instanzen [Hil+08] 1 <iq type = get 2 from = net / orchard 3 to= shakespeare. lit 4 id= items1 > 5 <query xmlns = http: // jabber. org / protocol / disco # items /> 6 </iq > In der Antwort werden die Items mit ihrem JID aufgelistet: Listing 2.4: Service Discovery-Antwort zu verknüpften XMPP-Instanzen [MSM10] 1 <iq type = result 2 from = shakespeare. lit 3 to= net / orchard 4 id= items1 > 5 <query xmlns = http: // jabber. org / protocol / disco # items > 6 <item jid = people. shakespeare. lit 7 name = Directory of Characters / > 8 <item jid = plays. shakespeare. lit 9 name = Play-Specific Chatrooms / > 10 <item jid = mim. shakespeare. lit 11 name = Gateway to Marlowe IM / > 12 <item jid = words. shakespeare. lit 13 name = Shakespearean Lexicon / > 14 <item jid = globe. shakespeare. lit 15 name = Calendar of Performances / > 16 <item jid = headlines. shakespeare. lit 17 name = Latest Shakespearean News / > 18 <item jid = catalog. shakespeare. lit 19 name = Buy Shakespeare Stuff! / > 20 <item jid = en2fr. shakespeare. lit 21 name = French Translation Service / > 22 </ query > 23 </iq > Bei Bedarf können zu jedem Item mit einer Anfrage wie im Listing 2.1 Details zur Identität und zu den unterstützten Features gewonnen werden. XEP-0060: Publish-Subscribe Die Erweiterung beschreibt ein Framework zur Erzeugung und Verteilung von Event-Notifikationen, umgesetzt mit dem Observer-Design-Pattern [MSM10]. Die Beziehung zwischen den Erzeugern und Empfängern von Event-Notifikationen wird durch einen zentralen Publish-Subscribe- Service vermittelt. Bei diesem Service registrieren Clients, die Events verbreiten möchten, einen 6 Monitoring verteilter Dienste für Datenextraktion

21 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze Node und andere Clients können diesen Node abonnieren, um die zu diesem Node erzeugten Events zu empfangen. Die wichtigsten Nachrichtenarten die bei Publish-Subscribe versendet werden, sind die Veröffentlichung neuer Daten zu einem Node und die Verteilung dieser zu allen Abonnenten des Nodes. Die Veröffentlichung über den Publish-Subscribe-Service wird mit einem IQ-Stanza vom Typ Set, adressiert an den JID des Publish-Subscribe-Service, realisiert: Listing 2.5: Veröffentlichung von Daten zu einem Node [MSM10] 1 <iq type = set 2 from = lit / blogbot 3 to= pubsub. shakespeare. lit 4 id= pub1 > 5 < pubsub xmlns = http: // jabber. org / protocol / pubsub > 6 < publish node = princely_musings > 7 <item > 8 <entry xmlns = http: // /2005/ Atom > 9 <title > Soliloquy </ title > 10 <summary >[... SUMMARY... ] </ summary > 11 <link rel = alternate type = text / html 12 href = http: // denmark. lit /2003/12/13/ atom03 /> 13 <id > tag:denmark. lit,2003: entry </ id > 14 <published > T18:30:02Z </ published > 15 <updated > T18:30:02Z </ updated > 16 </ entry > 17 </item > 18 </ publish > 19 </ pubsub > 20 </iq > Das IQ enthält das Kind-Element <pubsub> und dieses das Kind-Element <publish>. Bei diesem wird im Attribut node gespeichert, für welchen Node Daten veröffentlicht werden. Das Element <publish> enthält eine Liste von <item>-elementen, in der jedes Item für ein zu dem Node veröffentlichtes Datenpaket steht. Die XML-Struktur unterhalb von <item> beschreibt das veröffentlichte Datenpaket und ist abhängig von der umgesetzten Funktionalität und Applikation. Listing 2.5 zeigt zum Beispiel die Übergabe des Inhaltes eines Atom-kodierten Blog-Eintrages. Der Publish-Subscribe-Service empfängt das IQ-Set, ermittelt aus dem Attribut node des <publish>-elementes den Node zu dem veröffentlicht wird und stellt die Liste der Abonnenten zu diesem Node auf. Jeder Abonnent wird mit einem Message-Stanza über die neuen Daten informiert: Listing 2.6: Publish-Subscribe-Service informiert Abonnenten [MSM10] 1 < message from = pubsub. shakespeare. lit to= lit id= foo > 2 <event xmlns = http: // jabber. org / protocol / pubsub # event > 3 <items node = princely_musings > 4 <item id= ae890ac52d0df67ed7cfdf51b644e901 > 5 [... ENTRY... ] 6 </item > 7 </ items > 8 </ event > 9 </ message > < message from = pubsub. shakespeare. lit to= lit id= bar > 12 <event xmlns = http: // jabber. org / protocol / pubsub # event > 13 <items node = princely_musings > 14 <item id= ae890ac52d0df67ed7cfdf51b644e901 > 15 [... ENTRY... ] 16 </item > 17 </ items > 18 </ event > 19 </ message > < message from = pubsub. shakespeare. lit to= lit id= baz > 22 <event xmlns = http: // jabber. org / protocol / pubsub # event > 23 <items node = princely_musings > Monitoring verteilter Dienste für Datenextraktion 7

22 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze 24 <item id= ae890ac52d0df67ed7cfdf51b644e901 > 25 [... ENTRY... ] 26 </item > 27 </ items > 28 </ event > 29 </ message > < message from = pubsub. shakespeare. lit to= lit id= fez > 32 <event xmlns = http: // jabber. org / protocol / pubsub # event > 33 <items node = princely_musings > 34 <item id= ae890ac52d0df67ed7cfdf51b644e901 > 35 [... ENTRY... ] 36 </item > 37 </ items > 38 </ event > 39 </ message > Im Beispiel aus Listing 2.6 haben vier XMPP-Instanzen den Node, zu dem Daten veröffentlicht wurden, abonniert. Das Message-Stanza enthält das Element <event> als Zeichen, dass es sich um ein Publish-Subscribe-Message-Stanza handelt. Es enthält die zuvor dem Publish-Subscribe- Service übermittelten Items (<item>-elemente als Kinder des <items>-element). Im Attribut node des <items>-element wird angezeigt, zu welchem Node neue Daten übermittelt werden. Zusätzlich zum beschriebenen, grundsätzlichen Austausch von Daten über Event-Notifikationen definiert die Erweiterung ein Rechte- und Rollen-Modell. Das Modell beschreibt wie eine bestimmte XMPP-Instanz zum Node in Beziehung steht (zum Beispiel die Rolle owner, wenn der Node durch die XMPP-Instanz beim Publish-Subscribe-Service angelegt wurde) und welche Rechte sich aus der aktuellen Beziehung zum Node ergeben (eine owner-xmpp-instanz hat zum Beispiel das Recht neue Daten zum Node zu veröffentlichen) [MSM10, Abschnitt 4.1]. Ob ein Node durch eine XMPP-Instanz abonnierbar ist, hängt von seiner aktuellen Beziehung zum Node und vom gewählten Zugriffsmodell ab. Die Erweiterung definiert verschiedene Zugriffsmodelle mit absteigender Offenheit. Zum Beispiel open für Nodes, die von allen XMPP-Instanzen abonnierbar sind oder whitelist für Nodes, die nur von XMPP-Instanzen, die auf einer von der owner-xmpp-instanz gepflegten Whitelist stehen, abonnierbar sind [MSM10, Abschnitt 4.5]. Die Erweiterung definiert eine Teilmenge des Modells als notwendiges, vom Publish-Subscribe- Service zu unterstützendes, Minimum [MSM10, Kapitel 3]. Werden die erweiterten Fähigkeiten ebenfalls unterstützt, so muss der Service auch die notwendigen Kommandos zur Verwaltung implementieren, damit eine owner-xmpp-instanz zum Beispiel eine andere XMPP-Instanz zum publisher eines von ihm erzeugten Nodes machen kann. Publish-Subscribe unterstützt somit auch, dass mehrere XMPP-Instanzen Daten zu einem Node veröffentlichen können. Die Erweiterung definiert Kommandos, mit denen XMPP-Instanzen beim Publish-Subscribe- Service Informationen zu Nodes einholen [MSM10, Kapitel 5], ihre Abonnements verwalten [MSM10, Kapitel 6], die veröffentlichten Items zu einem Node bearbeiten (erstellen und löschen) [MSM10, Kapitel 7] und Nodes anlegen und deren Konfiguration ändern können (in der Rolle des owner) [MSM10, Kapitel 8]. Der Publish-Subscribe-Service verwaltet die angelegten Nodes in einer Hierarchie [MSM10, Abschnitt 5.2], Nodes können gruppiert und als Kind-Elemente anderer Nodes angelegt werden. Es gibt somit zwei Arten von Nodes, leaf und collection [MSM10, Abschnitt 4.4]. Nodes vom Typ leaf enthalten nur veröffentlichte Items, Nodes vom Typ collection enthalten nur andere Nodes und keine veröffentlichten Items. Eine XMPP-Instanz nutzt Service Discovery-Anfragen, um die Hierarchie der veröffentlichten Nodes zu durchsuchen [MSM10, Abschnitt 5.2]. Mittels Service Discovery können auch die von einem Node unterstützten Features ermittelt werden, damit der Abonnent erkennen kann, welche Art von Daten unter einem bestimmten Node veröffentlicht werden. Das Suchen eines Nodes mit bestimmten unterstützten Features kann somit eine komplizierte Suche in der Node-Hierarchie nach sich ziehen. 8 Monitoring verteilter Dienste für Datenextraktion

23 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze XEP-0114: Jabber Component Protocol Diese Erweiterung definiert ein Protokoll, anhand dessen sich eine XMPP-Instanz als Komponente eines Servers bei diesem anmelden kann [Sai12]. Server stellen verschiedene Dienste bereit, wie zum Beispiel Multi-User-Chat 7 oder Publish-Subscribe aus Abschnitt Im Normalfall werden diese Dienste durch die Software des Servers selbst implementiert und sind unter einer Subdomain erreichbar. Wenn der Server also die Domain modelspace.org verwaltet, dann würde Publish-Subscribe im Beispiel unter dem JID pubsub.modelspace.org erreichbar sein. Unterstützt der Server das Jabber Component Protocol, dann können sich externe Komponenten für eine auf dem Server konfigurierte Dienst-Subdomain anmelden. Der Administrator legt die Dienst-Subdomain an und gibt die notwendigen Zugangsdaten an. Eine externe Komponente, die unter der konfigurierten Subdomain ihren Dienst bereitstellen will, meldet sich unter Beachtung des in durch das Jabber Component Protocol definierten Ablaufs an und übermittelt dabei insbesondere die gewünschte Subdomain und deren Zugangsdaten. Diese Art der Verbindung ist die in der Erweiterung aufgeführte Methode accept [Kapitel 2][Sai12]. Der Hauptunterschied zu normalen XMPP-Clients liegt in der Authentifizierung gegenüber dem XMPP-Server. Es wird kein SASL benutzt, sondern ein geteiltes Geheimnis. Die Komponente übermittelt dem Server ein <handshake>-element, dessen Inhalt ein Hash ist. Bei der Erzeugung des Hashs wird das Passwort mit einbezogen [Sai12, Kapitel 3]. Kann der Server den Handshake verifizieren, so ist die Komponente erfolgreich angemeldet. In Zukunft leitet der Server XML-Stanzas, die an die Subdomain adressiert sind, zur Verarbeitung an die externe Komponente weiter. Unterstützt ein Server das Jabber Component Protocol und Service Discovery (siehe Abschnitt 2.2.1), wird jede aktive und angemeldete externe Komponente bei den mit dem Server verknüpften XMPP- Instanzen aufgeführt (siehe Items aus Abschnitt 2.2.1). Da die externe Komponente den Server durch ihren Dienst in seiner Funktionalität aus der Sicht anderer Clients erweitert, macht es Sinn, dass der Server beim Service Discovery auch die externe Komponente bei den mit ihm verknüpften Items aufführt. Die Verwendung des Jabber Component Protocol erhöht auch die Flexibilität und Wiederverwendbarkeit, da eine einmal implementierte Komponente mit jedem Server verwendet werden kann, der diese Erweiterung unterstützt. Die Unterstützung ist beim Großteil der XMPP-Server-Software vorhanden, wie zum Beispiel bei Openfire 8, ejabberd 9 oder Tigase 10. XEP-0163: Personal Eventing Protocol Die Erweiterung Publish-Subscribe ist sehr kompliziert und umfangreich, deswegen wurde mit Personal Eventing Protocol eine vereinfachte Anwendungsmöglichkeit geschaffen [SS10]. Das Personal Eventing Protocol basiert auf Publish-Subscribe und nutzt dessen definierte Strukturen und Abläufe, verwendet allerdings nur einen Teil der Features in bestimmter, vorgegebener Art und Weise. Die Vereinfachung bezieht sich auf die Implementation in den XMPP-Clients. Der beteiligte XMPP-Server muss einen Großteil der Erweiterung Publish-Subscribe unterstützen. Beim Personal Eventing Protocol ist jeder XMPP-Account ein virtueller Publish-Subscribe- Service [SS10, Abschnitt 2.1]. Es gibt nur eine publisher-xmpp-instanz pro Node und zwar die XMPP-Instanz die den Node anlegt [SS10, Kapitel 2]. Presence-Daten werden genutzt, um die Abläufe zu vereinfachen. Beim Prüfen der Abonnierbarkeit wird das Zugriffsmodell presence [MSM10, Abschnitt 4.5] genutzt und ein Automatismus umgesetzt: XMPP-Instanzen die sich gegenseitig im Roster hinzugefügt haben, werden automatisch Abonnenten der veröffent Monitoring verteilter Dienste für Datenextraktion 9

24 2 Grundlagen 2.2 Geeignete Protokolle und Ansätze lichten Nodes der jeweils anderen XMPP-Instanz [SS10, Abschnitt 2.3]. Um die für eine XMPP- Instanz generierten Event-Notifikationen zu bestimmen, nutzt der XMPP-Server das Feature Filtered Notifications aus Publish-Subscribe [MSM10, Abschnitt 9.2] und die XMPP-Instanz teilt in seinen Presence-Nachrichten mittels XEP-0115: Entity Capabilities 11 mit, für welche Art von Events sich die XMPP-Instanz interessiert [SS10, Abschnitt 2.4]. Da jeder XMPP-Account ein eigener virtueller Publish-Subscribe-Service ist, gibt es nicht eine Hierarchie von Nodes wie bei Publish-Subscribe, sondern jeder virtuelle Publish-Subscribe-Service besitzt seine eigene Hierarchie. Dies vereinfacht es sehr, die von einer XMPP-Instanz veröffentlichten Nodes zu finden. Indem die, bei Publish-Subscribe definierten, Service Discovery-Anfragen zur Durchsuchung der Node-Hierarchie nicht an den JID des Publish-Subscribe-Service gerichtet werden, sondern an den JID der XMPP-Instanz für dessen Nodes sich der Anfrager interessiert. Dadurch erhält die anfragende XMPP-Instanz die Nodes aus der Hierarchie des virtuellen Publish-Subscribe-Service dieser XMPP-Instanz. Dabei handelt es sich um die veröffentlichten Nodes dieser XMPP-Instanz. Dafür muss der JID der angefragten XMPP-Instanz bekannt sein AMQP Das Advanced Message Queuing Protocol (AMQP) 12 ist ein offener Standard und beschreibt ein binäres Netzwerkprotokoll, mit dem Nachrichten ausgetauscht werden können [ASB10]. Es ist kein Transportmechanismus wie XMPP, sondern wird von Anbietern verschiedener Lösungen für eine Message Oriented Middleware (MOM) als Kommunikationsprotokoll zwischen Clients und der Middleware genutzt. Lösungen die AMQP unterstützen sind zum Beispiel RabbitMQ 13 oder Apache Qpid 14. Dies stellt Interoperabilität sicher, da Anwendungen die AMQP nutzen, nicht auf eine bestimmte MOM festgelegt sind und zum Beispiel Anwendungen, die mit unterschiedlichen Programmiersprachen implementiert wurden, durch Nachrichtenaustausch über AMQP interagieren können. Da AMQP ein binäres Netzwerkprotokoll ist, ist auch die Kommunikation über das Netzwerk und damit die Nutzung in verteilten Systemen möglich. Das Protokoll definiert verschiedene Modelle für den Nachrichtenversand, die von der MOM implementiert werden müssen. Dies umfasst Peer-to-Peer-Kommunikation, einen Publish-Subscribe-Mechanismus und den klassischen Request-Response-Ansatz [ASB10] SOAP SOAP 15 ist ein XML-basiertes Kommunikationsprotokoll, mit dem Daten zwischen Systemen ausgetauscht und Remote Procedure Calls ausgeführt werden können und das als Grundlage zur Implementation von Web-Services dient [Gov+04]. Es definiert keinen Transport-Mechanismus, sondern beschreibt nur die übertragenden Inhalte. Der Zugriff erfolgt im allgemeinen über gängige Internet-Protokolle, wie das Hypertext Transfer Protocol (HTTP) und TCP, auch wenn SOAP nicht auf diese Transportprotokolle beschränkt ist [Ull12, Abschnitt 13.3]. Die Dienste die ein SOAP-basiertes System anbietet, werden in Form von Web Service Definition Language (WSDL) 16 -Dateien beschrieben [MG09]. Andere Systeme können auf diese Dienste zugreifen und so Daten abfragen oder übergeben. Der Zugriff und Ablauf, einschließlich der Kodierung von übergebenden Daten und Parametern, ist in SOAP spezifiziert OAS Monitoring verteilter Dienste für Datenextraktion

25 2 Grundlagen 2.3 Verwandte Arbeiten REST Representational State Transfer (REST) ist ein HTTP-basierter Ansatz zur Implementation von Web-Services [MG09] und beschreibt eine Architektur mit folgenden Eigenschaften dar [Min05]: Client-Server-Modell Zustandslose Kommunikation Einheitliche Schnittstelle um den Informationsaustausch zwischen den Komponenten eines REST-Systems in standardisierter Weise umzusetzen Systeme können über die implementierten Web-Services interagieren und Daten austauschen. 2.3 Verwandte Arbeiten In diesem Abschnitt werden Arbeiten vorgestellt, die Systeme und Konzepte, die auf der Grundlage von XMPP basieren, beschreiben. Die Auswahl soll die Eignung von XMPP als Mechanismus zur Kommunikation von Servern in einem verteilten Netzwerk verdeutlichen Kestrel Kestrel ist ein XMPP-basiertes Framework für verteiltes Rechnen. Es dient als Grundlage für den Aufbau von Applikationen für Many-Task Computing [RFY08] und implementiert Virtual Organization Clusters [MFG09]. Das Framework nutzt eine klassische Master-Worker Architektur, bei der die Kommunikation der beteiligten Instanzen über XMPP umgesetzt wird. Ein Kestrel-Pool setzt sich aus Managern, Workern, Clients und XMPP-Servern zusammen. Logisch formen die beteiligten Instanzen ein Stern-basiertes Netzwerk, mit dem Manager als zentrale Instanz. Der Manager ist eine XMPP- Komponente und Worker und Kestrel-Clients sind XMPP-Clients. Deren Kommunikation untereinander wird über die XMPP-Server geroutet und macht den Kestrel-Pool resistent gegen Probleme, wie sie zum Beispiel durch NAT-Traversal entstehen, wenn die Kestrel-Entitäten direkt miteinander kommunizieren würden. Durch Nutzung von XMPP entsteht ein Overlay- Netzwerk, das den Kestrel-Entitäten die freie Kommunikation untereinander erlaubt, unabhängig vom physischen Netzwerk-Layout. Die Nutzung von Presence erlaubt den Kestrel-Managern die Verwaltung verfügbarer Ressourcen (Worker) in Echtzeit und verhindert das Scheduling von Jobs zu nicht aktiven oder gerade nicht erreichbaren Workern. Kestrel nutzt das Prinzip der Well-Known-JIDs, um dem Manager neue Jobs zu übermitteln, den Status gerade bearbeiteter Jobs abzufragen und neue Worker oder Clients in den Pool aufzunehmen. Der Nutzername des JID wird verwendet, um die jeweiligen Bereiche voneinander abzugrenzen. Die Pool-Verwaltung geschieht über den Nutzernamen pool und die Annahme neuer Jobs unter submit. Ist die Subdomain der Manager-Komponente zum Beispiel manager.example.org, dann sind die entsprechenden Well-Known-JIDs und und die XMPP-Nachrichten werden an diese Adressen von den Clients und Workern gesendet. Für das Monitoring laufender Jobs wird ein eigenes Schema verwendet. Dabei beginnt der Nutzername, unter dem Informationen zu einem Job erreichbar sind, immer mit user_, ergänzt um die interne Job-ID. Jobs teilen sich in mehrere Tasks auf 17 Sto SMG https://github.com/legastero/kestrel Monitoring verteilter Dienste für Datenextraktion 11

26 2 Grundlagen 2.3 Verwandte Arbeiten und die Ressource des JID wird genutzt um einen bestimmten Task des Jobs zu adressieren adressiert zum Beispiel Task 99 von Job 37). Wird ein neuer Job durch einen Client angestoßen, dann wird ihm nach dem obigen Schema ein JID zugewiesen und dieser JID in den Roster des übermittelnden Clients aufgenommen. Kestrel nutzt das Roster-Management, um auf laufende Jobs Einfluss zu nehmen. Ein laufender Job wird zum Beispiel abgebrochen, wenn der JID des Jobs aus dem Roster des Clients entfernt wird. Um einen Job zu übermitteln, definiert Kestrel spezielle IQ-Stanzas. Beim Aufnehmen von Workern in den Pool nutzt Kestrel Service Discovery. Ein Worker schließt sich dem Pool an, indem er an den Well-Known-JID eine Presence-Subscription-Nachricht sendet. Der Manager schickt ebenfalls eine Presence-Subscription-Nachricht an den Worker und sobald sich beide gegenseitig über Änderungen bei ihrer Presence informieren, fragt der Manager per Service Discovery an den JID des Workers an, welche Features dieser unterstützt. Der Worker signalisiert mit dem Feature kestrel:tasks seine Fähigkeit Jobs auszuführen. Für die Verteilung von Jobs an die Worker definiert Kestrel wiederum spezielle IQ-Stanzas, die die nötigen Informationen transportieren. Der Autor Lance Stout weist mit Kestrel die Eignung von XMPP zur Übermittlung von Informationen in einem verteilten Netzwerk nach. XMPP sorgt bei Kestrel für eine robuste Kommunikation der beteiligten Entitäten, ohne dass diese auf die zugrundeliegende Netzwerk- Struktur Rücksicht nehmen müssen. Durch die Verwendung von XMPP wird diese für die Entitäten gewissermaßen transparent. Performance-Aspekte werden ebenfalls untersucht und es wird nachgewiesen, dass die XMPP-Komponente problemlos mit hunderten Workern und Clients im Pool umgehen kann und XMPP somit nicht zum Flaschenhals bei der Kommunikation wird Intelligent Server Management Framework over Extensible Messaging and Presence Protocol In dieser Arbeit 20 beschreiben die Autoren ein XMPP-basiertes Framework zur Verwaltung von Servern. Das Framework sieht verschiedene Arten von Agenten vor, die alle als XMPP- Clients implementiert werden. Auf einem Server befinden sich zwei Agenten. Einer sammelt Informationen über den Server selbst, wie zur Auslastung von Ressourcen, der andere dient zur Steuerung des Servers. Dieser kommuniziert mit einem zentralen Management-Agenten, der zu verwaltende Server registriert und Steuerinformationen an diese versendet. Administratoren verwalten und beobachten die Server über Client-Agenten, welche ebenfalls mit den zentralen Management-Agenten verbunden sind. XMPP wird verwendet, weil es Netzwerk-Transparenz gewährleistet (analog wie beim Kestrel- System) und seine Leistungsfähigkeit beim Betrieb von Netzwerken mit mehreren tausenden Clients bewiesen hat und somit als Transportmechanismus für ein Framework zur Verwaltung von verteilten Servern ideal geeignet ist. JIDs dienen zur einfachen Identifikation von verwalteten Servern. Die Autoren führen an, das in klassischen Systemen zur Server-Verwaltung Administratoren häufig die genaue IP-Adresse oder den Hostnamen eines Servers im Netzwerk kennen müssen und vermeiden dies, indem im vorgestellten Framework alle beteiligten Entitäten über die JIDs der Agenten identifiziert werden. Eine Änderung der IP-Adresse des Servers ist aus Sicht des Verwaltungssystems somit transparent. Das Framework verwendet die XMPP-Erweiterung Multi-User-Chat 21 um die verwalteten Server dynamisch in virtuellen Gruppen zu organisieren und so die gemeinsame Verwaltung beliebiger Teilmengen der Server zu ermöglichen. 20 PCX Monitoring verteilter Dienste für Datenextraktion

27 2 Grundlagen 2.4 Django Web-Framework Für den Austausch von Daten, insbesondere den Informationen über den Zustand eines Servers, nutzt das Framework die in Abschnitt vorgestellte Erweiterung Publish-Subscribe und lässt die verwalteten Server Updates per Push übertragen. Es vermeidet so Probleme, in Bezug auf die Skalierbarkeit, anderer Verwaltungssysteme, die diese Daten von den verwalteten Servern pollen. Die Autoren betonen die Skalierbarkeit des System, die sich aus der Verwendung von XMPP ergibt und beleuchten zusätzlich Sicherheits-Aspekte. Sie ziehen den Schluss, dass XMPP aufgrund der bereitgestellten Mechanismen zur Verschlüsselung und Authentifizierung eine sichere Grundlage für den Austausch sensibler Daten über das Netz bietet. 2.4 Django Web-Framework Django 2223 ist ein Python 24 -basiertes Web-Framework nach dem Model-View-Controller (MVC)- Prinzip. Bei Django sind die Rollen Model, View und Controller anders bezeichnet. Die Rolle des Controller wird in Django durch Views umgesetzt, die Rolle des View mittels Templates und die Rolle des Model durch Models, deswegen wird das Implementierungsmuster auch als Model-Template-View (MTV)-Prinzip bezeichnet [SMM10, Abschnitt II.A] [Ree11]: Model Models in Django repräsentieren Daten und abstrahieren gleichzeitig den Datenbankzugriff. Sie sind Python-Klassen 25, die von django.db.models.model erben. Django nutzt Object-Relational-Mapping (ORM) um die Objekte von Model-Klassen in einer relationalen Datenbank zu speichern. Um die Abbildung umzusetzen, besitzen die Model-Klassen Attribute bestimmten Typs, die im Python-Quellcode als normale Datentypen verwendet werden können (zum Beispiel int 26 oder unicode 27 ) und in der Datenbank in der Tabelle zur Model-Klasse mit Spalten passenden SQL-Typs abgebildet werden. Im Zuge dieser Abbildung setzt Django die Abstrahierung von der konkret verwendeten SQL-Datenbank um, da verschiedene SQL-Datenbanken sich im Verhalten und den unterstützten SQL- Datentypen unterscheiden. Im Python-Quellcode wird dann immer mit Objekten vom Typ der Model-Klasse gearbeitet und der Programmierer muss sich im Normalfall nicht mit SQL beschäftigen. Das Framework implementiert eine umfangreiche API, um die zu einer Model-Klasse vorhandenen Objekte anzufordern und unterstützt die Formulierung komplexer Anfragen, um nur Objekte mit bestimmten Eigenschaften zu erhalten. Template Templates dienen der Darstellung von Daten. Im Normalfall sind dies HTML-Dateien, die mit Ausdrücken der Django-Template-Sprache angereichert sind, um dem Template beim Rendern übergebende Daten zu verarbeiten. Die übergebenden Daten werden als Template-Kontext bezeichnet. Django ist nicht auf die Generierung von HTML-Seiten beschränkt, mit Hilfe der Django-Template-Engine können beliebige Darstellungen erzeugt werden, zum Beispiel die Generierung von PDF-Dateien 28. View In den Views wird die eigentliche Anwendungslogik umgesetzt. Sie verarbeiten die Requests an die Webanwendung. Bei der Verarbeitung nutzen sie die Models um Daten abzufragen, stellen Berechnungen an und implementieren die von der konkreten Webanwendung 22 HK https://www.djangoproject.com/ https://docs.djangoproject.com/en/1.4/howto/outputting-pdf/ Monitoring verteilter Dienste für Datenextraktion 13

28 2 Grundlagen 2.4 Django Web-Framework benötigte Funktionalität. Für die Darstellung fassen sie ihre berechneten und abgefragten Daten in einem Template-Kontext zusammen und nutzen die Django-Template-Engine, um die gewünschte Darstellung für die Antwort zu generieren. URL-Konfiguration Zusätzlich zu den beschriebenen Rollen spielt die URL-Konfiguration in Django eine wichtige Rolle. Sie legt fest welcher View für die Bearbeitung eines Requestes an eine bestimmte URL zuständig ist. Die Konfiguration erfolgt mit Hilfe von regulären Ausdrücken und der Verknüpfung dieser zu einem View. Geht ein Request ein, prüft Django die angefragte URL gegen die registrierten regulären Ausdrücke und beim ersten der matcht, wird dessen verknüpfter View zur Bearbeitung des Request aufgerufen. Der Vorteil ist die lose Kopplung der einzelnen Komponenten untereinander [HK09, Kapitel 1]. Dies ermöglicht zum Beispiel die Veränderung der URL-Konfiguration ohne den View, der unter einer bestimmten URL ausgeführt wird, zu verändern oder die Änderung an HTML-Templates, um die Darstellung anzupassen, ohne dass Views, die dieses Template nutzen, deswegen anzupassen sind. Das Framework stellt verschiedene Kernfunktionen in Python-Modulen 29, die in einer Modul- Hierarchie ausgehend vom Obermodul django eingeordnet sind. Mit diesen Modulen stellt Django vielfältige Hilfsmittel zur Entwicklung von Webanwendungen bereit und wird damit den Anforderungen an ein modernes Web-Framework gerecht [Ber09] 30 : Integrierte Testumgebung Abstraktion von Formularen in Python-Klassen mit eingebauter umfangreicher Validierungs- Unterstützung Caching-Mechanismen Verwendung von Middleware-Klassen um geteilte Funktionalität für mehrere Views umzusetzen Signal-System um ereignisbasierte Interaktion von Modulen umzusetzen Internationalisierung von Webanwendungen Integrierte Template-Engine Session-Verwaltung Authentifikations-Mechanismen und Benutzerrechte-Verwaltung Im Sprachgebrauch des Frameworks ist eine Web-Anwendung ein Django-Projekt, das aus mehreren Django-Anwendungen besteht. Die Anwendungen sind Module, die Funktionalität kapseln und in mehreren Projekten wiederverwendbar sind. Bei der Implementation von Django- Anwendungen wird dem MTV-Muster gefolgt und auf die vom Framework bereitgestellte Kernfunktionalität zurück gegriffen https://docs.djangoproject.com/en/1.4/ 14 Monitoring verteilter Dienste für Datenextraktion

29 3 Anforderungen 3 Anforderungen Abbildung 3.1: Intellix Indexing-Prozess [Sch+12] Ein Cluster von Index-Servern erzeugt bei der Verarbeitung von Dokumenten lokal Logging- Einträge pro Knoten. Abbildung 3.1 zeigt den Ablauf der Datenextraktion durch Intellix auf einem Cluster-Knoten. Jedes Dokument besitzt eine eindeutige ID und durchläuft diesen Indexing- Prozess. Jede am Prozess beteiligte Komponente generiert Logging-Einträge. Jeder Logging- Eintrag enthält die Dokumenten-ID, die verarbeitende Komponente, den aktuellen Modellraum und die Laufzeit der Komponente in Form von zwei Zeitstempeln für Beginn und Ende. Neben den allgemeinen Daten enthält jeder Logging-Eintrag eine von drei möglichen Logging- Informationen: Modellraum-Eskalation In Abbildung 3.1 kann es durch die Komponente Decider zu einer Modellraum-Eskalation kommen, d. h. das aktuelle Dokument wird in einem übergeordneten Modellraum weiter verarbeitet. Der Logging-Eintrag enthält als zusätzliche Information den Ziel-Modellraum. Extrahierter Wert Zu einem Attribut des Dokumentes wird durch die Komponente (zum Beispiel Combiner) ein Wert bestimmt. Der Logging-Eintrag enthält als zusätzliche Informationen den Attribut-Namen, den extrahierten Wert und einen Wert zwischen 0 und 1, der das Vertrauen der Komponente in den extrahierten Wert ausdrückt. Monitoring verteilter Dienste für Datenextraktion 15

30 3 Anforderungen 3.1 Datensammlung Feedback Die entsprechende Komponente ist nicht in Abbildung 3.1 enthalten. Der Logging- Eintrag enthält zusätzlich den Namen des Attributes für das Feedback hinterlegt wurde und den vom Nutzer eingetragenen Wert. Ziel ist die Zusammenführung der Logging-Einträge aller Knoten des Clusters durch das Monitoring und deren Speicherung in einem aggregierten Datenbestand. Die aggregierten Daten müssen dann in geeigneter Art und Weise per Web-Oberfläche dem Nutzer zugänglich gemacht werden. 3.1 Datensammlung Auf jedem Cluster-Knoten muss ein Logging-Client die Informationen entgegennehmen, kodieren und über einen Transportkanal zum Monitor übertragen. Um die Übertragung durchzuführen, muss der Logging-Client den Monitor im Netzwerk über einen automatischen Mechanismus auffinden können. Der gewählte Transport-Mechanismus muss eine robuste Verbindung des Logging- Clients zum Monitor bereit stellen und eine einfache Einbettung der Logging-Informationen gewährleisten. Es fließen Daten von potenziell vielen Quellen (Cluster-Knoten) zu einem Ziel (Monitor). Dadurch können potenziell mehr Logging-Einträge generiert werden, als der Monitor verarbeiten und speichern kann. Deshalb ist eine Strategie zum Umgang mit Überlast notwendig, für die folgende Fragen relevant sind: Welche Informationen werden bei Überlast verworfen und nicht persistent gespeichert? An welchem Punkt des Informationsflusses werden die Informationen verworfen? Sollen die Informationen verschiedener Quellen unterschiedlich behandelt werden? Der ausgewählte persistente Datenspeicher muss die Logging-Einträge zuverlässig speichern, darf die Verarbeitung von eingehenden Nachrichten mit Logging-Einträgen nicht übermäßig verzögern und muss vom gewählten Web-Framework zur Umsetzung der Web-Oberfläche leicht als Datenquelle zu nutzen sein. 3.2 Web-Oberfläche Die Web-Oberfläche wird durch zwei Nutzergruppen verwendet, einfache Nutzer und Administratoren. Die einfachen Nutzer lassen Dokumente indexieren und interessieren sich im Monitor nur für eine Darstellung aller Informationen, die diese Dokumente betreffen. Administratoren benötigen zusätzlich eine ganzheitliche Sicht auf das Modelspace-System. Zum einen auf die physische Struktur, die Anzahl und den Zustand der Cluster-Knoten, wie Informationen zur Belegung von Ressourcen und zum anderen eine Abbildung der Modellraum-Hierarchie. Die Darstellung der Hierarchie der Modellräume soll dabei dynamisch in Abhängigkeit von einem gewählten Zeitraum erfolgen. Aus den Logging-Einträgen für diesen Zeitraum wird die Struktur der Modellräume extrahiert und dargestellt. Die Modellraum-Hierarchie im Modelspace- System ist aktuell ein Wald aus Bäumen mit maximal drei Ebenen. Um die Anforderungen eines Nutzers an die Übersicht über seine indexierten Dokumente abzudecken, ist eine Sicht auf einen einzelnen Modellraum nötig. Derzeit ist einem Nutzer immer ein Blattknoten der Modellraum-Hierarchie zugeordnet. Diese Darstellung muss in der zeitlichen Dimension einstellbar sein und zeigt alle Dokumente des ausgewählten Modellraumes im vorgegebenen Zeitraum. 16 Monitoring verteilter Dienste für Datenextraktion

31 3 Anforderungen 3.2 Web-Oberfläche Die Präsentation eines einzelnen Dokumentes bereitet alle Logging-Einträge zur ID des betreffenden Dokumentes auf. Dem Nutzer muss eine Übersicht aller indizierten Felder, der dazu extrahierten Werte, der dafür verantwortlichen Komponenten und des Feedbacks angezeigt werden. Zwischen den einzelnen Ebenen der Präsentation muss navigiert werden können, d. h. aus der Modellhierarchie in die Ansicht eines einzelnen Modellraumes und aus dieser zur Darstellung für ein einzelnes Dokument. Auf allen Ebenen müssen dem Anwender die zu berechnenden Maße des Information Retrieval zur Verfügung gestellt werden. Diese Maße sind: Precision und Recall ROOC-Kurve Multi-Label- und Multi-Class-Evaluierung Makro- und Mikro-Average Bei der Extraktion der Indexdaten aus Dokumenten können unterschiedliche konfigurierte Cluster-Knoten oder auch unterschiedliche Trainings- bzw. Referenzdokumente zum Einsatz kommen. Dies hat Einfluss auf die Extraktionsleistung. Dem Nutzer der Web-Oberfläche muss es möglich sein Vergleiche von verschiedenen Modellräumen oder verschiedenen Zeitphasen eines Modellraumes vorzunehmen. Nur so ist eine systematische Untersuchung der Auswirkungen von Änderungen am Cluster-Knoten durchführbar und die gezielte Verbesserung der Exraktionsleistung erreichbar. Monitoring verteilter Dienste für Datenextraktion 17

32

33 4 Konzeption 4 Konzeption Im folgenden Kapitel werden für die gestellten Anforderungen Lösungsansätze erarbeitet und eine Datensammlung und Web-Oberfläche konzeptioniert. 4.1 Überblick Als Transport-Mechanismus zur Kommunikation zwischen den Cluster-Knoten wird das XMPP verwendet. Die genaue Struktur und die beteiligten Komponenten sind in Abschnitt 4.5 beschrieben. Die Logging-Einträge werden in XMPP-Nachrichten gekapselt (siehe 4.5.1) und durch einen XMPP-Client auf dem Cluster-Knoten (Logger, siehe 4.5.4) zum Monitor übertragen. Auf dem Monitor empfängt eine XMPP-Komponente (siehe 4.5.2) die Nachrichten, extrahiert die Logging-Einträge und speichert diese in einer relationalen Datenbank (siehe 4.5.3). Die Web-Oberfläche (siehe 3.2) stellt verschiedene Views bereit um die im Abschnitt 3.2 aufgestellten Anforderungen umzusetzen. 4.2 Logger und XMPP-Komponente des Monitors finden sich Folgende Varianten stehen für das gegenseitige Auffinden im XMPP-Netzwerk bereit, sie werden im Einzelnen erläutert und die getroffene Auswahl wird begründet. Publish-Subscribe (siehe Abschnitt 2.2.1) Well-Known-JID [Sto11, Abschnitt 4.1.1] Service Discovery (siehe Abschnitt 2.2.1) Bei der Nutzung von Publish-Subscribe suchen nicht die Logger die XMPP-Komponente und bestimmen deren JID, sondern die XMPP-Komponente abonniert Informationskanäle, die von den Loggern bereitgestellt werden. Jeder Logger veröffentlicht dazu per Publish-Subscribe genau einen Node, der den Strom seiner Logging-Einträge repräsentiert. Der Monitor abonniert diese Nodes, er erkennt die zu abonnierenden Nodes an einem bestimmten Feature, das diese unterstützen [MSM10, Abschnitt 5.4]. Neue Logging-Einträge veröffentlicht der Logger unter diesem Node und der Publish-Subscribe Mechanismus verteilt die entsprechenden XMPP-Nachrichten zur XMPP-Komponente des Monitors. Die Nutzung von Publish-Subscribe ist bei der Umsetzung des Monitors nicht sinnvoll. Laut den Anforderungen ist es gewollt, dass die Informationen aller Cluster-Knoten vollständig zu einem Monitor übertragen werden. Es gibt also nur einen Empfänger und dieser will von den Quellen keine Teilmenge ihrer Informationen, sondern diese vollständig erhalten. Publish-Subscribe ist eher für Szenarien gedacht bei denen eine Quelle unterschiedliche Informationen über mehrere Kanäle (Nodes) anbietet und mehrere Empfänger an jeweils unterschiedlichen Kanälen interessiert sind. Zudem müsste die XMPP-Komponente regelmäßig die veröffentlichten Nodes auf dem XMPP-Server abrufen, um zu überprüfen, ob Logger neuer Cluster-Knoten Nodes eingetragen haben. Dies ist ineffektiv und führt zu Latenz. Im Zeitraum zwischen dem Start des Cluster- Knotens und dem nächsten Polling des Monitors würden generierte Logging-Einträge verloren gehen. Monitoring verteilter Dienste für Datenextraktion 19

34 4 Konzeption 4.3 Push versus Pull Well-Known-JID und Service Discovery sind von der Umsetzung zwar unterschiedlich, aber bei beiden wird letztlich das Ziel erreicht, dass der JID der XMPP-Komponente dem Logger zur Verfügung steht und die Kommunikation per XMPP zu diesem JID aufnehmen kann. Bei Nutzung eines Well-Known-JID wird ein fester, im Betrieb unveränderlicher JID für die XMPP-Komponente des Monitors vorgesehen. Der Logger kennt diesen JID, da sie entweder fest im Quelltext hinterlegt oder als Konfigurations-Parameter bei der Initialisierung übergeben wird. Service Discovery ermöglicht das automatische Auffinden des Monitors durch die Logger, wenn der XMPP-Teil des Monitors, wie vorgesehen, als XMPP-Komponente nach XEP-0114 implementiert wird. Beide Methoden ziehen Einschränkungen nach sich. Die Nutzung eines Well-Known-JID ermöglicht mehr Freiheiten bei der Implementierung, da der XMPP-Teil des Monitors ein normaler XMPP-Client oder eine XMPP-Komponente nach XEP-0114 sein kann. Dafür ist im Betrieb der JID des Monitors nicht einfach änderbar, die Logger müssen entweder neu konfiguriert oder, bei Hinterlegung im Quelltext, neu kompiliert werden. Bei der Nutzung von Service Discovery ist für die Umsetzung des Monitors die Implementation einer XMPP- Komponente notwendig und die Komponente muss beim XMPP-Server konfiguriert werden, ist dafür im Betrieb flexibler und die JIDs der am Cluster-Monitoring beteiligten XMPP-Agenten sind frei wählbar. Beim XMPP-Server muss die Komponente konfiguriert werden. Für die Umsetzung wurde Service Discovery als Mechanismus ausgewählt, da eine größere Flexibilität auf Seiten der Logger wichtiger ist, als die Einschränkungen auf Seiten des Monitors. Dem liegt die Annahme zu Grunde, dass der Monitor einmal installiert und aktiviert, aus Sicht der XMPP-Kommunikation selten Konfigurations-Änderungen erfahren wird. Neue Logger können dann sofort nach Anmeldung im XMPP-Netzwerk den Monitor finden und Logging-Einträge übermitteln. 4.3 Push versus Pull Bei der Nutzung von Publish-Subscribe wären die Logging-Einträge per Push übermittelt worden. Die Konzepte Well-Known-JID und Service Discovery lassen beide Ansätze zu. In diesem Kontext repräsentiert Pull einen klassischen Request-Response-Ansatz [PCX13, Abschnitt 3.2.4]. Der Monitor fragt bei den Cluster-Knoten nach Logging-Einträgen an (Request) und wenn beim angefragten Cluster-Knoten Logging-Einträge vorhanden sind, werden diese in der Antwort übermittelt (Response). Bei einem Pull-Ansatz sind folgende Punkte zwingend: Cluster-Knoten müssen sich beim Monitor anmelden Der Monitor muss eine Liste der aktiven Cluster-Knoten verwalten Periodisches Polling nach Logging-Einträgen und Prüfung, ob Cluster-Knoten überhaupt noch aktiv sind Push bedeutet in diesem Fall, dass die Cluster-Knoten neue Logging-Einträge von selbst an den Monitor übermitteln, ohne Anfrage von diesem. Im Gegensatz zum Pull-Ansatz ist eine Registrierung der Cluster-Knoten beim Monitor nicht erforderlich und es entsteht kein zusätzlicher Aufwand für die Verwaltung der Cluster-Knoten. Aufgrund der Kommunikationsstruktur ist der Pull-Ansatz nicht sinnvoll. Im Monitoring- System ist der Monitor das Ziel jeglichen Datenflusses, d. h. der Ansatz der unmittelbaren Übertragung der Logging-Einträge per Push erzeugt den geringsten Overhead. Der Push-Ansatz hat gleichbleibende Kosten unabhängig von der Anzahl der Knoten im Cluster. Beim Pull- Ansatz hingegen nimmt mit steigender Anzahl der Knoten im Cluster die Belastung zu, selbst wenn überhaupt keine Logging-Einträge übermittelt werden, da das Polling für jeden Knoten im Cluster nötig ist. 20 Monitoring verteilter Dienste für Datenextraktion

35 4 Konzeption 4.4 Flusssteuerung Für die Umsetzung wird deshalb der Push-basierte Ansatz gewählt, d. h. Logger übermitteln von sich aus XMPP-Nachrichten an die XMPP-Komponente, ohne vorherige Anfrage durch diese. Die Logging-Einträge können dann mittels IQ- oder Message-Stanzas zur XMPP-Komponente kommuniziert werden. IQ-Stanzas bilden dabei einen Request-Response-Zyklus ab. Der Empfänger eines IQ-Stanza muss auf diese mit einem IQ-Stanza vom Typ Result oder Error antworten [Sai11b, Abschnitt 8.2.3]. Dies bedeutet jedoch keineswegs, dass ein XMPP-Client auf die Antwort zu einem vorher abgeschickten IQ-Stanza warten muss, bevor er neue IQ-Stanzas an diesen Empfänger verschicken darf. Message-Stanzas werden beim XMPP als Push-Mechanismus genutzt und bilden keinen Request-Response-Mechanismus ab, es wird keine Antwort seitens des Empfängers vom Standard vorgeschrieben. 4.4 Flusssteuerung Flusssteuerung bedeutet zu entscheiden, welche Logging-Einträge von welchen Loggern verarbeitet werden, falls die Gesamtzahl der Logging-Einträge nicht durch den Monitor bewältigt werden kann. Der Monitor verarbeitet die Nachrichten potenziell vieler Logger und diese könnten eine Situation der Überlast herbeiführen. Die Flusssteuerung muss dann sicherstellen, dass die Anzahl eingehender Nachrichten begrenzt wird. Auf dem Monitor können prinzipiell zwei Faktoren für eine Überlastung sorgen. Die Verarbeitung der XMPP-Nachrichten selbst und das Eintragen der extrahierten Logging-Einträge in die Datenbank. Die Schreibgeschwindigkeit in die Datenbank ist I/O-bound und die Verarbeitung der XMPP-Nachrichten CPU- und Memory-bound Pull-Ansatz Beim Pull-Ansatz kann die Flusssteuerung im Zuge des Pollings erfolgen. Es werden nicht mehr Knoten gleichzeitig gepollt, als im Fall, dass alle gepollten Knoten Logging-Einträge zu übermitteln haben, als Auslastung bewältigt werden könnte. Dies ist ein ineffizienter Ansatz, da beim Polling vorher nicht bekannt ist, welche Knoten in welchem Umfang Logging-Einträge übermitteln. Dadurch könnte der Monitor nicht die maximale Anzahl an Logging-Einträgen verarbeiten, zu der er pro Zeit in der Lage wäre. Beim Push-Ansatz hängt die mögliche Flusssteuerung von der Art des verwendeten Stanza ab Push-Ansatz mit Message-Stanzas Beim Cluster-Knoten generierte Logging-Einträge werden unmittelbar durch den Logger per Message-Stanza an den Monitor übermittelt. Die Flusssteuerung kann auf zwei Arten geschehen. Entweder der Monitor übermittelt einzelnen Loggern explizit, wie diese ihr Sendeverhalten anpassen sollen oder der Monitor übermittelt an alle Logger Informationen bezüglich seiner Auslastung und jeder Logger passt sein Sendeverhalten anhand der aktuellen Auslastung des Monitors an. Für die Flusssteuerung durch explizite Steuerung einzelner Logger durch den Monitor müssen zusätzliche Nachrichten definiert werden, mit denen Befehle und Daten zur Flusssteuerung zwischen Monitor und Logger ausgetauscht werden. Mit diesen kann der Monitor einem Logger mitteilen, ob er weitere Nachrichten von diesem entgegennimmt oder ob die Anzahl an Logging- Einträgen pro Nachricht reduziert werden soll. Damit der Monitor entscheiden kann, welcher Logger in welchem Umfang gedrosselt werden soll, muss er intern eine Flusssteuerungs-Einheit implementieren. Diese braucht Kenntnis über die aktiv sendenden Logger, die Anzahl der von jedem Logger übermittelten Logging-Einträge und die aktuelle Auslastung des Monitors. Die Einheit entscheidet ob eine Drosselung der eingehenden Logging-Einträge notwendig ist und Monitoring verteilter Dienste für Datenextraktion 21

36 4 Konzeption 4.4 Flusssteuerung welchen Loggern Steuerbefehle geschickt werden müssen. Erschwerend kommt hinzu, dass nicht bekannt ist, ob und wie viele Nachrichten ein Logger übermitteln wird. Das bedeutet, wenn der Monitor einen Logger drosselt, kann es sein, dass von diesem keine weiteren Nachrichten mehr empfangen werden und stattdessen ein anderer Logger mit der Übertragung beginnt. Diese erfolgt dann ungedrosselt und die Auslastung beim Monitor wird nicht gesenkt. Dieses Problem vermeidet der zweite Ansatz. Der Monitor veröffentlicht seine aktuelle Auslastung und die Logger leiten daraus ihr Sendeverhalten ab, versenden zum Beispiel weniger Nachrichten an den Server oder aggregieren weniger Logging-Einträge pro Nachricht. Um Logging-Einträge verzögern oder aggregieren zu können, ist beim Logger ein Zwischenspeicher für Logging-Einträge nötig. Die Kommunikation der Auslastung des Monitors an die Logger kann über verschiedene Mechanismen erfolgen: Presence als boolesches Flag Server ist erreichbar oder nicht erreichbar. Für die Logger bedeutet dies, sie können entweder Nachrichten ungedrosselt versenden oder gar nicht. Presence-Stanza mit <show>-element Mapping der definierten Werte auf ein bestimmtes Verhalten der Logger. Es können unterschiedliche Stufen für das Sende-Verhalten definiert werden, von ungedrosselt über Zwischenstufen (steigender Abstand zwischen Nachrichten, weniger Logging-Einträge pro Nachricht) bis zum Übertragungsstopp. Der Standard sieht nur vier mögliche Werte (away, chat, dnd und xa) vor, damit können vier Sendeverhalten implementiert werden [Sai11c, Abschnitt 4.7]. Presence mit <status>-element Der Ansatz ist analog der Verwendung des <show>-elementes, bietet aber eine größere Flexibilität. Die möglichen Werte für den Status sind frei wählbar, es können also beliebig viele Sendeverhalten implementiert werden. Notwendig ist die Definition der Werte und die Unterstützung seitens der Logger, so dass sie auf den jeweiligen Wert mit dem gewünschten Sender-Verhalten reagieren [Sai11c, Abschnitt 4.7]. Personal Eventing Protocol nach XEP-0163 Logger erhalten Event Notifications vom Monitor. Will der Monitor eine Änderung des Sendeverhaltens der Logger erreichen, veröffentlicht er ein Event, dessen Inhalt das gewünschte Sendeverhalten beschreibt. Die Logger empfangen die Event Notification vom XMPP-Server und ändern ihr Verhalten entsprechend. Die Event-Notification ist ein Message-Stanza mit dem Kind-Element <event>. In <event> kann eine beliebige XML-Struktur eingebettet werden. Die einzubettende Struktur zur Flusssteuerung muss definiert und von den Loggern verarbeitet werden. Dieser Ansatz bietet die größte Flexibilität, da, je nach definierter XML-Struktur für die Events, beliebige Informationen vom Monitor an die Logger übertragen werden können [SS10, Kapitel 3] Push-Ansatz mit IQ-Stanzas Werden generierte Logging-Einträge unmittelbar per IQ-Set an den Monitor übertragen und vor dem Abschicken wird nicht auf das IQ-Result vorhergehender Übermittlungen gewartet, können prinzipiell die gleichen Mechanismen wie bei den Message-Stanzas verwendet werden. Die explizite Steuerung einzelner Logger erfolgt durch eine gleichartige Flusssteuerungseinheit und für die Übermittlung der Steuerinformationen bietet sich das IQ-Result an, mit dem der Monitor auf jedes IQ-Set antworten muss. Die Steuerung per an alle Logger übermittelter Auslastung erfolgt analog und nutzt die gleichen Mechanismen. Durch die Verwendung von IQ-Stanzas ergibt sich die Möglichkeit alternativ eine implizite Flusssteuerung umzusetzen. Die Logger werden so implementiert, dass sie ein neues IQ-Set erst nach Erhalt des IQ-Result für die letzte Übermittlung verschicken. Der Nachrichtenstrom mit 22 Monitoring verteilter Dienste für Datenextraktion

37 4 Konzeption 4.4 Flusssteuerung Logging-Einträgen eines Loggers zum Monitor wird dadurch serialisiert, folglich sind niemals mehrere IQ-Set-Nachrichten eines Loggers parallel beim Monitor in Verarbeitung. Bei einem Logger, der auf ein IQ-Result wartet, können sich in der Zwischenzeit weitere Logging-Einträge ansammeln und diese müssen in einem Puffer zwischengespeichert werden. Da dieser Puffer nur endlich groß sein kann, ist es möglich, dass mehr Logging-Einträge gepuffert werden sollen, als der Puffer aufnehmen kann. Das Verwerfen von Logging-Einträgen muss bereits beim Logger erfolgen und nicht erst im Monitor. Dies hat positive Auswirkungen bezüglich der Skalierbarkeit, da es sinnvoll ist, dass zu verwerfende Logging-Einträge gar nicht erst Teil einer XMPP- Nachricht werden. Jede XMPP-Nachricht, die erst auf dem Monitor verworfen würde, ist bereits vorher im XMPP-Client des Cluster-Knotens und im XMPP-Server verarbeitet worden. Diese Rechenleistung wird dann eingespart Prioritäten Prioritäten sind notwendig, wenn die Logging-Einträge bestimmter Logger wichtiger sind, als die anderer Logger. Ist dies erwünscht, so muss der Logger dem Monitor seine Priorität mitteilen. Dafür bietet sich das <status>-element des Presence-Stanzas an, wenn der Logger seine Presence-Informationen an den Monitor übermittelt. Alternativ müsste dafür eine eigene Nachricht definiert werden, die der Logger nach dem Auffinden des Monitors (siehe Abschnitt 4.2) an diesen sendet. Bei der Nutzung von Message-Stanzas sind Prioritäten in beide Ansätze relativ leicht zu integrieren. Beim expliziten Steuern einzelner Logger durch eine Flusssteuerungseinheit, bezieht diese die Prioritäten der Logger in die Entscheidung, welche gedrosselt werden sollen, mit ein und drosselt Logger niedrigerer Priorität zuerst. Bei der Vorgabe des Sendeverhaltens durch Bekanntmachung der Auslastung können Prioritäten durch Nutzung der großen Flexibilität des Personal Eventing Protocol nach XEP-0163 umgesetzt werden. Der Monitor erzeugt nicht nur Events, die seine Auslastung beschreiben, sondern er erzeugt pro Prioritäts-Klasse Events, die das aktuelle Sendeverhalten der Logger dieser Klasse vorgeben. Bei der Nutzung von IQ-Stanzas ohne warten auf das IQ-Result gelten die gleichen Bedingungen wie bei Message-Stanzas und Prioritäten können analog abgebildet werden. Wird vor dem Versenden eines neuen IQ-Set auf das IQ-Result des vorhergehenden IQ-Set gewartet, erfolgt die Abbildung von Prioritäten in der XMPP-Komponente. Diese nutzt dazu eine Eingangs-Queue und ordnet ankommende IQ-Nachrichten in diese ein. Bei der Verarbeitung werden Nachrichten von Loggern höherer Priorität bevorzugt, diese erhalten schneller ein IQ-Result und können dadurch mehr Nachrichten an den Monitor senden, als ein Logger mit niedriger Priorität, der länger auf sein IQ-Result wartet. Die Auswahl des nächsten zu bearbeitenden IQ-Set muss dabei sicherstellen, dass Nachrichten hoher Priorität nicht vollständig die Verarbeitung von Nachrichten niedriger Priorität blockieren. Es geht um die Aufteilung der gesamten Empfangskapazität auf die Prioritäts-Klassen, so dass hohe Prioritäten bei Überlast einen größeren relativen Anteil erhalten, jedoch keine Priorität explizit blockiert wird. Soll dies trotzdem möglich sein, so muss eine Klasse niedrigster Priorität vorgesehen werden, die explizit für Logger vorgesehen ist, die vollkommen von der Verarbeitung ausgenommen werden können Auswahl und Begründung Die Umsetzung erfolgt durch die Versendung von IQ-Stanzas in der serialisierten Variante. Der Ansatz verspricht die größtmögliche Effizienz und einfache Implementierbarkeit: Verwerfen auf Seiten der Logger, dadurch keine unnötigen XMPP-Nachrichten. Monitoring verteilter Dienste für Datenextraktion 23

38 4 Konzeption 4.5 Datensammlung Keine explizite Flusssteuerungseinheit beim Monitor. Dieser muss seinen eigenen Zustand und die aktuell aktiven Logger nicht explizit verwalten und spart dadurch Rechenleistung. Keine zusätzlichen Nachrichten, die definiert und im Netzwerk verschickt werden müssen. Die Flusssteuerung ergibt sich aus dem implementierten Verhalten der Logger und des Monitors beim Versenden und Verarbeiten der IQ-Stanzas. Keine zusätzlichen XEPs, die von den Loggern oder dem Monitor unterstützt werden müssen. Im Konzept kommen nur XMPP: Core [Sai11b], XEP-0114: Jabber Component Protocol [Sai12] und XEP-0030: Service Discovery [Hil+08] zum Einsatz. Der sich ergebende Ablauf setzt eine effektive und faire Flusssteuerung um (siehe Abschnitt 4.5.6). 4.5 Datensammlung Abbildung 4.1: Gesamtüberblick Struktur Abbildung 4.2: Interface ILogger Die Abbildung 4.1 beschreibt die Gesamtstruktur des Monitoring-Systems. Auf dem Cluster- Knoten greift der Indexierer mittels des definierten Interfaces ILogger (Abbildung 4.2) auf den Logger (Abschnitt 4.5.4) zu, um Logging-Einträge zu übergeben. Das Interface stellt zwei Methoden bereit. Die Methode logentry dient dazu einen einzelnen Logging-Eintrag zu übergeben und der Methode logdocument wird eine Liste von Logging-Einträgen als Argument übergeben 24 Monitoring verteilter Dienste für Datenextraktion

39 4 Konzeption 4.5 Datensammlung und sie kann benutzt werden, falls der Indexierer bereits intern alle Logging-Einträge für ein Dokument aggregiert. Abbildung 4.3: XMPP-Kommunikation: Logging Der Monitor stellt die Webanwendung (Abschnitt 4.6), eine Datenbank zur persistenten Speicherung (Abschnitt 4.5.3) und die XMPP-Komponente (Abschnitt 4.5.2) zur Verarbeitung der per IQ-Stanza durch den Logger übermittelten Logging-Einträge bereit. Der grundsätzliche Ablauf der Kommunikation zwischen Logger und XMPP-Komponente wird in Abbildung 4.3 gezeigt. Ein Logger findet die XMPP-Komponente durch Nutzung von Service-Discovery (Abschnitt 4.5.5) XML-Struktur Die im Kapitel 3 aufgeführten drei Arten von Logging-Informationen werden mittels einer XML- Struktur für die Einbettung kodiert, es gibt also nicht für jede Art eine eigene XML-Struktur. Die Logging-Einträge werden mittels definierter XML-Tags in den XMPP-Nachrichten eingebettet. Die definierten Tags sind unter dem XML-Namespace modelspace:logentries eingeordnet. Um mehrere Logging-Einträge in einer Nachricht zu aggregieren, gibt es ein Container-Element. Dieses enthält eine Liste von Kind-Elementen, in der jedes Kind-Element einen Logging-Eintrag beschreibt. Drei verschiedene Formate sind für die Beschreibung der Logging-Einträge definiert. Sie unterscheiden sich darin, ob die Informationen zu einem Logging-Eintrag mittels Tags oder Attributen beschrieben werden und ob die Bezeichner der Elemente ausgeschrieben oder verkürzt sind: Verbose-Tags Informationen in Tags deren Namen lang und beschreibend sind. Einfach für Menschen zu lesen, falls die ausgetauschten XMPP-Nachrichten direkt untersucht werden. Kompakt-Tags Informationen in Tags deren Namen abgekürzte Varianten der Namen bei den Verbose-Tags sind, dadurch wird die erzeugte XMPP-Nachricht kleiner. Monitoring verteilter Dienste für Datenextraktion 25

40 4 Konzeption 4.5 Datensammlung Kompakt-Attribute Attribute deren Namen die gleichen wie bei den Kompakt-Tags sind. Dient als Vergleich zu den Kompakt-Tags, um zu prüfen, ob die Geschwindigkeit des Parsens der XML-Nachricht von der Verwendung von Tags oder Attributen beeinflusst wird. Im Abschnitt 6.1 werden die drei Formate evaluiert. Die vollständige Defintion der XML- Struktur um die Logging-Einträge in XMPP-Nachrichten einzubetten, ist im Listing B.1 dokumentiert. Zur Definition wird die XML Schema Definition Language (XSD) [GST12] [Pet+12] genutzt. Die Variante Verbose-Tags ist dabei durch das Element logentry, die Variante Kompakt- Tags durch das Element lec und die Variante Kompakt-Attribute durch das Element lea definiert. Das Container-Element ist logentries. Die Validität des erstellten Schemas wurde mit dem Validator for XML Schema 1 des World Wide Web Consortium (W3C) 2 überprüft Monitor als XMPP-Komponente Die Komponente implementiert die Vorgaben des Jabber Component Protocol (siehe Abschnitt 2.2.1). Beim XMPP-Server ist ein Zugang für die Komponente konfiguriert und diese meldet sich mit den entsprechenden Zugangsdaten beim Server an. Intern verwendet die Komponente eine Queue fester, bei der Initialisierung konfigurierbarer Größe. In diese werden eingehende IQ-Set-Nachrichten zwischengespeichert. Werden mehr IQ-Set-Nachrichten empfangen, als die Queue aufnehmen kann, wird die entsprechende IQ-Set-Nachricht sofort mit einem IQ-Error beantwortet. Worker, aus einem Worker-Pool der Komponente, entnehmen die IQ-Set-Nachrichten aus der Queue und verarbeiten diese. Sie extrahieren die Logging-Einträge und nutzen die nötigen SQL-Befehle, um diese in der relationalen Datenbank zu speichern. Die Befehle werden gegen das Schema, wie in Listing B.2 beschrieben, generiert. Jede verarbeitete IQ-Set-Nachricht wird mit einem IQ-Result beantwortet. Die Größe des Worker-Pools ist wiederum eine bei der Initialisierung konfigurierbare Größe. Die Komponente unterstützt XEP-0030: Service Discovery (siehe Abschnitt 2.2.1), um am im Abschnitt beschriebenen Ablauf teilnehmen zu können Persistente Datenspeicherung Die persistente Datenspeicherung erfolgt in einer relationalen Datenbank. Die Komponente greift per Structured Query Language (SQL) auf die Datenbank zu und legt die Logging-Einträge mit den aus den XMPP-Nachrichten extrahierten Informationen an. Die relationale Datenbank wurde gewählt, da sie sich für die Speicherung strukturierter Informationen, wie der durch die Cluster-Knoten generierten Logging-Einträge sehr gut eignet und Web-Frameworks typischerweise einfache Methoden zur Integration relationaler Datenbanken als Datenquelle bereit stellen Logger des Cluster-Knoten als XMPP-Client Der Logger implementiert das Interface ILogger und kapselt einen XMPP-Client. Für die Teilnahme am Monitoring ist nur ein angelegter Account auf dem XMPP-Server nötig und dessen Zugangsdaten müssen dem Logger bei der Initialisierung mitgegeben werden. Der Logger unterstützt XEP-0030: Service Discovery [Hil+08] und nutzt dies, um den JID des Monitors, wie in Abschnitt beschrieben, zu bestimmen. Der Logger besitzt einen Aggregator. Dieser fasst die Logging-Einträge zu einem Dokument aus einem Indexierungslauf zusammen, wenn diese jeweils einzeln durch die Methode logentry übergeben werden. Das Argument lastfordocumentid der Methode logentry dient zur Anzeige, dass für ein bestimmtes Dokument der letzte Logging- Eintrag übergeben wird. Der Logger besitzt außerdem einen Puffer, dieser speichert aggregierte Logging-Einträge, ist also eine Liste von Listen mit Logging-Einträgen. Beim Aufruf von Monitoring verteilter Dienste für Datenextraktion

41 4 Konzeption 4.5 Datensammlung Abbildung 4.4: Ablauf des Pufferns im Logger logentry mit lastfordocumentid == true, wird die aktuell vom Aggregator geführte Liste von Logging-Einträgen in den Puffer übertragen. Beim Aufruf von logdocument wird die übergebende Liste von Logging-Einträgen direkt in den Puffer eingetragen. Die Ausführung der vom Interface vorgegebenen Methoden muss nicht blockierend sein und sollte eine minimale Laufzeit haben. Das bedeutet in ihnen wird keine XMPP-Kommunikation abgewickelt, weil dann das Laufzeitverhalten unvorhersehbar wäre. Sie füllen nur den internen Puffer. Die XMPP- Kommunikation erfolgt in einem Sender-Thread. Dieser entnimmt dem Puffer Logging-Einträge und verpackt eine konfigurierbare, maximale Anzahl in ein IQ-Set, schickt dieses ab und wartet auf das IQ-Result des Monitors. Der Logger wartet einen konfigurierbaren, maximalen Zeitraum auf das IQ-Result. Wird bis dahin kein Ergebnis empfangen, wird von einem Fehler seitens des Monitors ausgegangen. Die im IQ-Set enthaltenen Logging-Einträge werden wieder in den Puffer eingetragen und der aktuell zwischengespeicherte JID des Monitors wird gelöscht. Empfängt der Logger stattdessen einen IQ-Error, so ist dies das Zeichen, dass die Queue des Monitors voll ist. Die Logging-Einträge werden wieder in den Puffer eingetragen und nach einer konfigurierbaren Wartezeit wird ein erneuter Übertragungsversuch unternommen. Dieser Ablauf wird im Sender-Thread wiederholt, solange im Puffer Logging-Einträge vorhanden sind. Der Puffer wird durch logentry und logdocument befüllt und asynchron dazu durch den Sender-Thread geleert. Da dieser nur endlich viele Einträge fassen kann, kommt es zur Verdrängung, wenn schneller Logging-Einträge hinterlegt werden, als durch den Sender-Thread verarbeitet werden. Die ältesten Einträge im Puffer werden dann während der Ausführung von logentry und logdocument aus dem Puffer verdrängt, dabei werden immer ganze Aggregationen für eine Dokumenten-ID verworfen, da es nicht sinnvoll ist, zu einem Dokument nur einen Teil der Logging-Informationen zum Monitor zu übertragen. Die Abläufe im Puffer sind in Abbildung 4.4 schematisch dargestellt Nutzung von Service Discovery Die Logger auf den Cluster-Knoten nutzen Service Discovery, um den Monitor zu finden und dessen JID zu bestimmen. Die Abbildung 4.5 zeigt den Ablauf. Der Logger fragt beim XMPP- Server alle Items für dessen Domain an, dessen Antwort enthält auch alle Komponenten, die auf dem Server aktiv sind [Hil+08, Abschnitt 4.1, Beispiele 11 und 12]. Zu jedem Item fragt der Logger dessen unterstützte Features ab [Hil+08, Kapitel 3] und wenn der Monitor eine Monitoring verteilter Dienste für Datenextraktion 27

42 4 Konzeption 4.5 Datensammlung Abbildung 4.5: XMPP-Kommunikation: Service Discovery der aktiven Komponenten ist, so enthält seine Antwort das Feature modelspace:logentries. Der JID der Komponente, die dieses Feature anzeigt, ist der JID des Monitors und wird vom Logger zwischengespeichert. Aus diesem Ablauf ergibt sich auch die Notwendigkeit der Implementierung des Monitors als Komponente, da nur Komponenten vom Server als Items bei der Anfrage für die Domain des Servers mit angegeben werden. Ein normaler XMPP-Client könnte die Features des Monitors nur abfragen, wenn dieser dessen JID schon kennen würde und dann wäre Service Discovery als Mechanismus den JID des Servers zu bestimmen nicht verwendbar Ablauf der Flusssteuerung Das Verhalten des Monitoring-Systems hängt maßgeblich von folgenden Parametern für die Logger und den Monitor ab: Q, Queue-Größe des Monitors W, Worker-Pool-Größe des Monitors P, Puffergröße des Loggers X, maximale Anzahl von Logging-Einträgen pro IQ-Set 28 Monitoring verteilter Dienste für Datenextraktion

43 4 Konzeption 4.5 Datensammlung t wait_max, maximale Wartezeit auf IQ-Result des Loggers t retry, Wartezeit vor erneutem Zustellversuch des Loggers Und von folgenden Parametern während des Betriebes: L, Anzahl der Logger im Monitoring-System E logger, Anzahl der Logging-Einträge pro Zeit, die ein Indexierer während der Verarbeitung eines Dokumentes generiert t send, Zeit, die ein Durchlauf beim Sender-Thread benötigt t set_create, Zeit, die der Logger zum Erstellen eines IQ-Set braucht t set_xmpp, Zeit, die ein IQ-Set beim Verschicken unterwegs ist, einschließlich Verarbeitung auf dem XMPP-Server t queue, Zeit, die ein IQ-Set in der Queue des Monitor wartet t process, Zeit, die der Monitor zur Bearbeitung eines IQ-Set aus seiner Queue benötigt t result_xmpp, Zeit, die ein IQ-Result beim Verschicken unterwegs ist, einschließlich Verarbeitung durch XMPP-Server C, Anzahl der Prozessor-Kerne auf dem Monitor-System Es bestehen folgende Beziehungen zwischen den Parametern: t process ist abhängig von X, da mehr Logging-Einträge pro Nachricht das Extrahieren und Speichern in die Datenbank verlängern t set_xmpp ist abhängig von X, da größere Nachrichten länger zum Verschicken brauchen und die Verarbeitung durch den XMPP-Server langsamer ist t result_xmpp ist unabhängig von X, da die Antwort immer gleich groß ist Berechnung der Sende-Zeit (Zeit die für eine Nachricht zum Monitor benötigt wird) des Sender-Threads des Loggers: t send = t set_create +t set_xmpp +t queue +t process +t result_xmpp, erfolgreich verarbeitetes IQ-Set t send_min = t set_create + t set_xmpp + t process + t result_xmpp, erfolgreich verarbeitetes IQ-Set mit minimaler Bearbeitungszeit (t queue = 0) t send_max = t set_create +t set_xmpp +t process Q+t result_xmpp, erfolgreich bearbeitetes IQ-Set mit maximaler Bearbeitungszeit (t queue = (Q 1) t process ) Folgende Bedingungen sollten gelten: Q > L, dies gewährleistet Fairness, da von jedem Logger maximal ein IQ-Set gleichzeitig bearbeitet wird, wird so kein Logger von der Verarbeitung ausgeschlossen W C, mehr parallel arbeitende Worker als Prozessor-Kerne sind nicht sinnvoll, da dies die Schreibleistung in die Datenbank nicht erhöht Monitoring verteilter Dienste für Datenextraktion 29

44 4 Konzeption 4.5 Datensammlung P > E logger t send_max, damit, wenn der Puffer völlig leer ist und die Verarbeitung des ersten IQ-Set maximal lange dauert, alle in der Zwischenzeit übergebenden Logging-Einträge nicht verworfen werden X so bestimmen, dass eine einzelne Nachricht keine zu lange Verarbeitungszeit hat, also t process eher klein ist t wait_max > Q t process + t result_xmpp, damit der Logger mindestens solange auf das IQ- Result wartet, wie die maximale Bearbeitungszeit ohne Fehler sein kann t retry > t process, damit ein Platz in der Queue überhaupt freigeworden sein kann, bei Einhaltung von Q > L kommt t retry gar nicht zum Zug Abbildung 4.6: Ablauf des Sendens im Logger Die Abbildungen 4.6 und 4.7 legen die Abläufe im Logger und Monitor schematisch dar und illustrieren bei welchen Verarbeitungsschritten die verschiedenen Zeitparamter eine Rolle spielen. Einträge werden verworfen, wenn dauerhaft E logger > X t send, der Puffer füllt sich bis zur Obergrenze P und ab diesem Zeitpunkt verdrängen neue Logging-Einträge die älteren. Überlast beim Monitor zeigt sich dadurch, dass t send für die Logger ansteigt und so groß wird, dass mehr Logging-Einträge pro Zeit in den Puffer eingetragen werden, als durch den Sender-Thread verarbeitet werden. Gilt E logger < X t send_max und Q > L, werden, solange keine Fehler auftreten oder durch ein Netzwerkproblem die Kommunikation verzögert ist, keine Logging-Einträge verworfen. Die maximale Anzahl an Logging-Einträgen die der Monitor pro Zeit verarbeiten kann, ist E monitor_max = X t process W, wenn W C, mit einer absoluten Obergrenze in Abhängigkeit der Datenbank, da diese auch durch parallel arbeitende Worker nicht ihre Schreibleistung unendlich steigern kann. Bei Q > l ist der Ansatz fair und effektiv. Fair bedeutet in diesem Zusammenhang, dass keine Logger von der Verarbeitung ausgeschlossen werden und bei Überlast kommt es zu einer 30 Monitoring verteilter Dienste für Datenextraktion

45 4 Konzeption 4.5 Datensammlung Abbildung 4.7: Ablauf der Vearbeitung im Monitor gleichmäßigen Drosselung aller Logger. Effektiv meint alle generierten und versendeten XMPP- Nachrichten werden verarbeitet, es werden keine unnötigen Nachrichten erzeugt. Das Handling von Überlast findet auf den Loggern statt, Logging-Einträge werden höchstens einmal gepuffert und wenn notwendig eventuell verworfen. Ist Q < L, kann die Behandlung der Logger unfair werden, weil in die Queue des Monitors nach dem Prinzip First-Come, First-Serve eingefügt wird. Je nach Laufzeitverhalten der XMPP-Nachrichten ist nicht sichergestellt, dass alle Logger zum Zuge kommen. Wenn bei einer Queue-Größe von fünf, sechs Logger senden, können die XMPP-Nachrichten beim Monitor so eintreffen, dass die Logger eins bis fünf die Queue füllen, Logger sechs abgewiesen wird und in seine Retry-Wartezeit geht und innerhalb der Retry-Wartezeit versenden die Logger eins bis fünf weitere Nachrichten genau so, dass immer wenn Logger sechs einen Versuch startet, die Queue gerade voll ist. Logger sechs kann erst beginnen, nachdem einer der anderen Logger fertig ist und muss in der Zwischenzeit eventuell Logging-Einträge verwerfen. Gegenüber den anderen ist er benachteiligt worden. Ineffektiv wird es, weil dann der Retry-Mechanismus zum Einsatz kommt. Dadurch werden XMPP-Nachrichten generiert und verschickt, die dann nicht verarbeitet werden (Verschwendung von Netzwerkkapazität und Rechenleistung auf dem XMPP-Server und in den Loggern) und die Logger tragen Logging-Einträge erneut in ihre Puffer ein, was ebenfalls Rechenleistung verschwendet. Die Sicherstellung von Q > L ist einfach möglich, auch wenn die Anzahl der Logger im Vorfeld nicht abzuschätzen ist, da Q deutlich größer als L sein kann, ohne dass dies Auswirkungen auf den Ablauf hat. Da ein Logger immer nur ein IQ-Set gleichzeitig in Bearbeitung haben kann, ist der Füllgrad der Queue auf maximal L beschränkt, wenn also Q > L gilt, kann in den obigen Formeln Q durch L ersetzt werden. Aufgrund der verwendeten XML-Struktur wird angenommen, dass, von den in Abschnitt 4.4 beschriebenen zwei Faktoren für Überlast, die Datenbank der limitierende Faktor beim Monitor sein wird. Die Extraktion der Logging-Informationen erfordert das Parsen der XML-Struktur ohne weitere Verarbeitungsschritte, da die benötigten Daten direkt als Attribute oder Text-Wert eines Elementes hinterlegt sind und aus dem geparsten Ergebnis nur noch ausgelesen werden müssen. Für das Parsen von XML-Dokumenten stehen in den Programmiersprachen hochperfor- Monitoring verteilter Dienste für Datenextraktion 31

46 4 Konzeption 4.6 Web-Oberfläche mante Bibliotheken zur Verfügung. Diese parsen eine bestimmte Anzahl an Logging-Einträgen in der XML-Struktur aus Abschnitt wesentlich schneller, als die für die gleiche Anzahl an Einträgen notwendigen SQL-Anweisungen zum Einfügen in die Datenbank zur Ausführung benötigen. 4.6 Web-Oberfläche Browser HTML-Container Abruf Antwort ViewsTder Ansichten Webserver DynamischerTTeil dertwebanwendung Web-Framework JavaScript- Applikation JSON-API Datenbank statischetinhalte referenziert.css.js Abbildung 4.8: Struktur der Web-Oberfläche Die Abbildung 4.8 zeigt den schematischen Aufbau der Webanwendung. Zur Umsetzung der im Abschnitt 3.2 genannten Anforderungen werden drei verschiedene Views konzipiert. Der erste View präsentiert den Gesamtüberblick über die Modellraum-Hierarchie (siehe Abschnitt 4.6.1) und aus diesem View heraus sind die verschiedenen Möglichkeiten zum Vergleich von Modellräumen zugänglich (siehe Abschnitt 4.6.2). Die Darstellung eines einzelnen Modellraumes beschreibt der Abschnitt und die Ansicht eines einzelnen Dokumentes der Abschnitt Die Umsetzung der Views erfolgt mit Hilfe eines Web-Frameworks. Dieses stellt grundlegende Funktionen wie Session-Management, Zugriff auf die Datenbank oder eine Template-Engine bereit. Die Views sind unter einer festen URL aufrufbare Hypertext Markup Language (HTML)- Seiten, wobei die HTML-Seiten nur als Container für referenzierte JavaScript-Applikationen dienen. Die Funktionalität der Ansichten wird in den JavaScript-Applikationen gekapselt und umgesetzt. Die Container-HTML-Seiten und die JavaScript-Applikationen bilden zusammen das Frontend der Web-Oberfläche und implementieren, was der Nutzer sieht. Sie stellen die Funktionen bereit, mit denen der Nutzer mit der Web-Oberfläche interagieren kann. Damit die JavaScript-Applikationen auf den im Zuge der Datensammlung in der Datenbank aggregierten Datenbestand zugreifen können, besitzt die Web-Oberfläche ein Backend. Dieses stellt Daten in JavaScript Object Notation (JSON) zur Verfügung und wird im weiteren Verlauf als JSON-API bezeichnet. Es wird per HTTP aufgerufen und als Antwort wird kein HTML gesendet, sondern Daten in JSON-kodierter Form. 32 Monitoring verteilter Dienste für Datenextraktion

47 4 Konzeption 4.6 Web-Oberfläche Die Gestaltung der Oberfläche erfolgt durch Definition von Cascading Stylesheets (CSS), welche ebenfalls von den HTML-Containern referenziert werden Ansicht Modellraum-Hierarchie Die Ansicht der Modellraum-Hierarchie dient der Darstellung der Struktur der Modellräume und als Werkzeug zur Auswahl von Gruppen von Modellräumen, um für diese Vergleiche durchzuführen. Die dargestellte Hierarchie wird dynamisch aus einer Menge von Logging-Einträgen generiert. Diese Datengrundlage ist durch den Nutzer bestimmbar. Der Nutzer kann einen Zeitraum festlegen, aus dem Logging-Einträge für die Generierung herangezogen werden sollen. Per Filterung der Index-Server kann die Menge ebenfalls beeinflusst werden, falls sich der Nutzer nur für die Logging-Einträge einer bestimmten Teilmenge der Index-Server interessiert. Die Benutzeroberfläche der Hierarchie-Darstellung hat drei Hauptbestandteile. Der erste ist eine Toolbar, welche permanent sichtbar am oberen Rand des Browsers platziert ist. Sie enthält die notwendigen Eingabeelemente, um die Grundmenge der Logging-Einträge zu bestimmen, aus denen die Hierarchie dynamisch extrahiert wird. Darunter befindet sich der Bereich für den eigentlichen Inhalt. Dieser ist in zwei Spalten aufgeteilt. Die linke Spalte dient als Container für die Visualisierung der Baum-Struktur. Die rechte Spalte dient zur Darstellung der aktuellen Vergleichsgruppen. Die Spalte für die Visualisierung nimmt dabei den überwiegenden Teil des horizontal zur Verfügung stehenden Platzes ein. Die beiden Inhaltsspalten scrollen unabhängig voneinander, so dass der Nutzer immer die aktuellen Vergleichsgruppen einsehen kann, unabhängig davon an welcher Stelle innerhalb der Visualisierung des Baumes er sich gerade befindet. Die Darstellung der Hierarchie erfolgt in einem Grid-basierten Layout. Die Wurzeln der Hierarchie befinden sich in der linken Spalte. Die Darstellung wächst nach rechts, d. h. jede weitere Ebene der Hierarchie nimmt eine neue, eigene Spalte ein. Initial sind nur die Wurzeln der Hierarchie im Grid zu sehen. Um die Darstellung der Hierarchie im Grid zu beeinflussen, stehen für jedes Element im Grid verschiedene Interaktionsmöglichkeiten zur Verfügung. Verfügt ein Element über Kind-Knoten, so können diese aus- und eingeklappt werden. Zwischen Kind- und Eltern-Knoten wird im Graph eine Kante eingefügt. Im eingeklappten Zustand wird die Anzahl der Kind-Knoten dargestellt. Im Graph wird durch Verwendung unterschiedlich gefärbter Elemente für die Knoten visualisiert, ob ein Knoten einer Vergleichsgruppe zugeordnet ist oder nicht. Jedes Elemente im Graph besitzt einen Button, um den zugehörigen Modellraum einer Vergleichsgruppe hinzuzufügen. Der Grid-Layout-Algorithmus bestimmt für jeden sichtbaren Modellraum der Hierarchie die Position (bestehend aus einem X- und Y-Wert), an der der zugehörige Knoten im Grid angezeigt wird. Die Koordinaten des Grids beginnen links oben jeweils bei 0. Das Grid wächst im Zuge der Abarbeitung nach rechts und nach unten. Der X-Wert für jeden Knoten ist die Ebene des Modellraums in der Hierarchie. Die Wurzeln der Hierarchie befinden sich in der Ebene null. Die Ebene von Kind-Modellräumen ist die Ebene des Eltern-Modellraumes plus eins. Während der Positionsbestimmung verwaltet der Algorithmus für alle Spalten des Grids den größten bis dahin verwendeten Y-Wert in dieser Spalte. Der Algorithmus durchwandert die Hierarchie von den Wurzeln aus und führt dabei eine Tiefensuche aus. Bei nicht sichtbaren Modellräumen bricht der Algorithmus für diesen Zweig der Hierarchie ab, d. h. auch für alle Nachfolger eines nicht sichtbaren Modellraums wird keine Bestimmung der Position vorgenommen. Ist der aktuell untersuchte Modellraum sichtbar, ist das weitere Vorgehen davon abhängig, ob dieser sichtbare Kind-Modellräume hat. Bei Modellräumen mit sichtbaren Kind-Modellräumen wird zuerst die Position dieser ermittelt, bevor die Position des Modellraumes selbst bestimmt wird. Aus diesem Ablauf ergibt sich, dass der Algorithmus die Hierarchie wie bei einer Tiefensuche durchwandert. Monitoring verteilter Dienste für Datenextraktion 33

48 4 Konzeption 4.6 Web-Oberfläche X höchsterxyuwertx sichtbarxund keinexkinder GridULayouter : : 5 4 KeinXEintragXfürXXX=X: deswegenxyx=x:xundxupdate 3 name Anwalt visible children name visible children Notar name true false Arzt true visible children einlesen X Y : Hierarchie Wurzelg XX=X: EintragenXan PositionX::: name DrpXMüller visible children true name DrpXMeier visible children true : 3 4 Anwalt Abbildung 4.9: Grid-Layout-Algorithmus: Bearbeitung Blattknoten Hat der Modellraum keine sichtbaren Nachfolger, ordnet der Algorithmus ihm als X-Wert seine Ebene und als Y-Wert den kleinstmöglichen für diese Spalte zu. Kleinstmöglich meint, der Modellraum wird im Grid direkt unterhalb des letzten in der Spalte eingetragenen Knotens platziert. Zur Bestimmung des entsprechenden Y-Wertes nutzt der Algorithmus seine verwaltete Liste der höchsten Y-Werte pro Spalte. Der Y-Wert ist im Regelfall der aktuell höchste für die Spalte hinterlegte Wert plus eins. Sollte noch kein Wert für die Spalte hinterlegt sein, ist der Y-Wert null, dann ist der aktuell bearbeitete Modellraum der erste Knoten in dieser Spalte. Die Abbildung 4.9 zeigt den beschriebenen Ablauf. Sind zu einem Modellraum alle Nachfolger bearbeitet, kann die Position für dessen Knoten im Grid bestimmt werden, die Abbildung 4.10 beschreibt den Ablauf für diesen Fall. Der X-Wert ist wieder die Ebene des Modellraumes und der Y-Wert wird in Abhängigkeit der sichtbaren Kind-Modellräume berechnet. Ziel ist es, den Y-Wert so zu bestimmen, dass der Knoten des gerade bearbeiteten Modellraumes von der Höhe her auf der Hälfte der Höhe eingetragen wird, die durch die Knoten seiner Kind-Modellräume bestimmt wird. Die Sicherstellung dieser räumlichen Nähe ermöglicht es die Kanten zwischen den Knoten besser zu zeichnen und gruppiert Knoten von Modellräumen, die auf gleichen Pfaden liegen in der Hierarchie. Der Y-Wert wird dabei zweistufig berechnet. Im ersten Schritt werden der minimale und maximale Y-Wert der Knoten der sichtbaren Kind-Modellräume bestimmt. Der vorläufige Y-Wert berechnet sich folgendermaßen: Y vorlaeufig = Y Kinder_min + (Y Kinder_max Y Kinder_min )/2. Dieser vorläufige Y-Wert muss noch gegen den derzeit höchsten Y-Wert für die Spalte, in der der Knoten eingefügt wird, geprüft werden. Ist der vorläufige Y-Wert größer, dann ist er auch der endgültige Y-Wert und die Position des Modellraums ist bestimmt (X-Wert: Ebene des Modellraumes, Y- 34 Monitoring verteilter Dienste für Datenextraktion

49 4 Konzeption 4.6 Web-Oberfläche Hierarchie GridVLayouter X 0 höchsterxyvwertx name Anwalt Y vorlaeufig?<=?y Spalte_max? 0?<=?0 visible children 2 name visible children Notar Y endgueltig?=?y max_x=0?+?1 1?=?0?+1 name true false Arzt true Y vorlaeufig?=?y Kinder_min?+? (Y Kinder_max?-?Y Kinder_min )?/?2 0?=?0?+? (1?-?0)?/? Y Offset?=?Y Spalte_max?+?1?-?Y vorlaeufig 1?=?0?+?1?-?0 visible children X Y name DrOXMüller visible children true name DrOXMeier visible children true EintragenXanXPositionX0: Anwalt Arzt DrOXMüller DrOMeier 4 Verschieben umxy Offset 4 2 Abbildung 4.10: Grid-Layout-Algorithmus: Knoten mit Kindern und Verschiebung der Nachfolger Wert: Y Kinder_min + (Y Kinder_max Y Kinder_min )/2 ). Ist der vorläufige Y-Wert kleiner oder gleich des aktuell höchsten Y-Wert der Spalte, muss der vorläufige Y-Wert noch mal angepasst werden, da sonst mehrere Knoten die gleiche Position im Grid belegen würden. Der endgültige Y-Wert bestimmt sich also folgendermaßen: Y endgueltig = Y Spalte_max + 1, dies ist eine Verschiebung nach unten und der Offset berechnet sich wie folgt: Y Offset = Y Spalte_max + 1 Y vorlaeufig. Die Berechnung des Offsets wird benötigt, um die Gruppierung verknüpfter Modellräume zu erhalten. Die Knoten aller sichtbaren Nachfolger (nicht nur unmittelbare Kinder) des Modellraumes werden ebenfalls nach unten verschoben, indem Y Offset zu ihrem Y-Wert addiert wird. Generell nimmt der Algorithmus bei jeder Eintragung eines Y-Wertes für einen Knoten eine Aktualisierung der verwalteten Liste der höchsten Y-Werte pro Spalte vor. Die Darstellung der Vergleichsgruppen erfolgt als Gruppe von Listen. Die Elemente jeder Gruppe werden in einer HTML-Liste eingetragen und diese Listen werden untereinander platziert. Einzelne Listen sind auf- und zuklappbar Entwicklungen bei Modellräumen vergleichen Vergleiche werden auf der Basis von Vergleichsgruppen durchgeführt. Eine Vergleichsgruppe ist eine Menge von Modellräumen mit einem zugeordneten Zeitraum. Im Zuge der Vergleiche werden pro Gruppe die vom Nutzer gewünschten Kennzahlen berechnet, indem die Dokumente aus den gewählten Modellräumen für den gewählten Zeitraum als Datenbasis benutzt werden. Beim Vergleich mehrerer Gruppen miteinander, kann die Menge der Modellräume pro Gruppe Monitoring verteilter Dienste für Datenextraktion 35

50 4 Konzeption 4.6 Web-Oberfläche auch die gleiche sein und nur der Zeitraum unterschiedlich. Dies dient dazu eine Untersuchung der zeitlichen Entwicklung der Kennzahlen für diese Menge von Modellräumen durchzuführen. Zwei grundsätzliche Arten der Darstellung sind vorgesehen. Die erste Form berechnet pro Gruppe die gewünschten Kennzahlen und stellt diese tabellarisch oder als Balkendiagramm dar. Der Nutzer kann in der tabellarischen und der Balken-Diagramm-Darstellung Min- und Max- Werte markieren und den berechneten Durchschnitt (zusätzliche Spalte in Tabelle, zusätzlicher Balken in Diagramm) einblenden lassen. Als zweites kommt ein Sliding-Window-Diagramm zum Einsatz. Dabei wird für alle gewählten Vergleichsgruppen der gleiche Vergleichs-Zeitraum (V ) benutzt. Der Nutzer legt die Sliding- Window-Größe (S) fest. Aus dem gewählten emphvergleichs-zeitraum werden diskrete Zeitpunkte abgeleitet, zum Beispiel jeder Tag des Zeitraums wird zu einem Zeitpunkt. Zu jedem diskreten Zeitpunkt Z werden für jede Vergleichsgruppe alle gewünschten Kennzahlen berechnet. Als Grundlage der Berechnungen zu einem Zeitpunkt Z dienen dann die Dokumente aus den Modellräumen der jeweiligen Gruppe aus dem Zeitraum Z S bis Z. Die Darstellung erfolgt als Verlaufs-Diagramm Ansicht für einen einzelnen Modellraum Die Ansicht präsentiert alle Dokumente zum gewählten Modellraum und ermöglicht das Aufrufen der Detailansicht jedes einzelnen Dokumentes. Die Ansicht unterstützt die Auswahl eines bestimmten Zeitraumes aus dem Dokumente angezeigt werden und lässt die Beschränkung nach dem übermittelnden Logger zu. Die Filtermechanismen für den Zeitraum und die Logger funktionieren dabei analog zu den Mechanismen aus der Hierarchie-Darstellung. Die Darstellung der Dokumente erfolgt als Liste und nutzt dabei wahlweise Pagination. Aktiviert der Nutzer Pagination, so ist die Anzahl an Dokumenten pro Seite einstellbar. Bei deaktivierter Pagination erfolgt die Darstellung analog zu den Timeline-Darstellungen moderner sozialer Netzwerke. Beim Scrolling durch den Nutzer werden im Hintergrund weitere Dokumente der Liste nachgeladen und die Liste nach unten verlängert Ansicht für einzelnes Dokument Auf der Grundlage der Logging-Einträge zu einem einzelnen Dokument, werden drei Ansichten implementiert. Zusammenfassung In dieser Ansicht werden die Logging-Einträge zum Dokument nach indexentryname (siehe Daten-Schema in Listing B.2) gruppiert, also eine Übersicht über alle gefundenen Attribute des Dokumentes und deren Werte angezeigt. Dies ist die Standard-Ansicht bei Aufruf eines Dokumentes. Zu jedem Attribut kann der Nutzer einsehen, welche Komponente in welchem Modellraum welchen Wert ermittelt hat, wie die Einschätzung der Verlässlichkeit durch die Komponente war und welcher Wert als der finale ermittelt wurde. Ist zu diesem Attribut Feedback für das Dokument hinterlegt, wird dieses ebenfalls mit aufgeführt und es wird markiert, ob der vom System bestimmte Wert korrekt war. Flussansicht Die Flussansicht präsentiert den Verarbeitungsablauf im Indexierer für das Dokument. Abbildung 4.11 zeigt das Layout der Flussansicht, dabei kommt ein Grid analog zu der Hierarchie- Darstellung zum Einsatz. Jede Zeile im Grid steht dabei für einen Modellraum. In jeder Zeile 36 Monitoring verteilter Dienste für Datenextraktion

51 4 Konzeption 4.6 Web-Oberfläche Modellräume X Y Arzt 0 Layout Colonial Combiner Decider übergeordnet Dr.äMüller 1 Layout Colonial Combiner Decider KomponentenäproäModellraum Abbildung 4.11: Layout der Flussansicht werden von links nach rechts die Komponenten angeordnet, die beim Indexieren für das Dokument Logging-Einträge generiert haben. Jede Komponente im Grid ist anklickbar und öffnet ein Overlay mit näheren Informationen zur Komponente. Es zeigt die von der Komponente übermittelten Attribute mit dazugehörigem Wert, die angegebene Verlässlichkeit und ob der extrahierte Wert dem finalen Wert für das Attribut des Dokumentes entspricht. Ist zu dem Dokument Feedback verfügbar, wird dieses in der Darstellung des Overlay mit angezeigt, so dass nicht nur der Vergleich mit dem finalen Wert eines Attributes Teil des Overlay ist, sondern auch der Vergleich zum Feedback. Auflistung der Logging-Einträge Die Auflistung erfolgt in einer Tabelle, die zu jedem Logging-Eintrag, die in der Datenbank gespeicherten Informationen anzeigt. Die Tabelle enthält drei Arten von angezeigten Einträgen, die eine eigene Darstellung haben und somit schnell durch den Nutzer unterschieden werden können. Bei den Arten handelt es sich um Modellraum-Eskalation, Feedback und normaler Attribut-Wert-Eintrag. Zu jeder Art werden nur die relevanten Spalten des Daten-Schemas (siehe Listing B.2) angezeigt (die Information runtime wird aus begin und end generiert): Modellraum-Eskalation modelspace, component, escalateto und runtime Feedback modelspace, indexentryname, feedback und end (bei Feedback ist Zeitpunkt der Übermittlung für Nutzer interessant) Attribut-Wert-Eintrag modelspace, component, indexentryname, extractedvalue, confidence und runtime Die Ansicht unterstützt das Filtern nach Modellraum, Komponente und Typ des Eintrages Darstellung des Systemzustandes der Cluster-Knoten Ein Administrator des Clusters interessiert für Kennzahlen, die nichts mit der Extraktion von Daten aus den Dokumenten zu tun haben, sondern den physischen Zustand der Cluster-Knoten beschreiben, auf dem die Indexierungs-Software ausgeführt wird. Dies sind zum Beispiel Informationen zur Prozessor-Auslastung, zum verwendeten Speicherplatz oder zur Netzwerkverbindung. Zur Sammlung und Präsentation dieser Informationen gibt es erprobte und frei verfügbare Monitoring verteilter Dienste für Datenextraktion 37

52 4 Konzeption 4.6 Web-Oberfläche Frameworks wie Nagios 34 oder Icinga 5, deswegen ist eine Reimplementierung dieser Funktionalität auf der Grundlage des konzeptionierten, XMPP-basierten Mechanismus nicht sinnvoll. Die Sammlung entsprechender Daten wird mit einem der Frameworks implementiert und die Anzeige der Daten in die Monitoring-Web-Oberfläche integriert. Die Frameworks stellen eigene Web-Oberflächen zur Verfügung, deswegen wird deren Gestaltung mittels CSS an die Gestaltung der Monitoring-Web-Oberfläche angepasst und ein einheitliches Aussehen der beiden umgesetzt. In der Navigation der Monitoring-Web-Oberfläche wird die Web-Oberfläche des genutzten Frameworks referenziert und in dieser wiederum die Monitoring-Web-Oberfläche, so dass der Administrator leicht zwischen den Logging-Informationen zur Dokumentenverarbeitung und den Informationen zum physischen Zustand des Clusters wechseln kann ID07. 5 https://www.icinga.org/ 38 Monitoring verteilter Dienste für Datenextraktion

53 5 Implementation 5 Implementation Das folgende Kapitel stellt die Umsetzung der konzeptionierten Lösungsansätze vor und dokumentiert die genutzten Programmiersprachen, Bibliotheken und Frameworks. 5.1 Datensammlung Abbildung 5.1: Gesamtstruktur modelspace und Abhängigkeiten Die Implementation der Datensammlung erfolgt vollständig in Java, sowohl der Logger als auch die XMPP-Komponente des Monitors. Die Abbildung 5.1 zeigt die Grob-Struktur der Implementation und die Abhängigkeiten zu externen Bibliotheken anhand eines Paket-Diagramms. Als externe Bibliotheken wurden Whack 1, Smack 2, Tinder 3 (Paket xmpp), Joda Time 4, BoneCP 5, Monitoring verteilter Dienste für Datenextraktion 39

54 5 Implementation 5.1 Datensammlung JDBC Driver for MySQL 6, JCommander 7, dom4j 8 und Apache Commons Lang 9 eingesetzt XMPP-Komponente nach XEP-0114 Abbildung 5.2: Klassendiagramm Monitor Die Abbildung 5.2 führt die zur Implementierung der XMPP-Komponente umgesetzten Klassen auf. Die zentrale Klasse ist MonitorComponent, die von AbstractComponent aus der Bibliothek Tinder abgeleitet ist. Die Klasse AbstractComponent implementiert das nach XEP [Sai12] spezifizierte Verhalten und stellt Methoden bereit, die von erbenden Klassen überschrieben werden, um die im konkreten Anwendungsfall gewünschte Funktionalität der Komponente umzusetzen. AbstractComponent implementiert die Queue für die Komponente und die Abarbeitung dieser durch mehrere Worker-Threads. Es setzt dazu ThreadPoolExecutor 10 und eine LinkedBlockingQueue 11 ein. Die Implementation stellt dabei sicher, dass auf Nachrichten, die nicht in die Queue übernommen werden können, mit einem IQ-Error reagiert wird und erfüllt damit die Vorgaben des Konzeptes (siehe Abschnitt 4.5.6). MonitorComponent überschreibt discoinfofeaturenamespaces, damit die Komponente des Monitors beim Service Discovery (siehe Abschnitt 4.5.5) das Feature modelspace:logentries meldet. Als zweite Methode wird handleiqset überschrieben und in dieser die Extraktion der Logging-Einträge und deren Speicherung in die Datenbank umgesetzt. Der Methode handleiqset wird beim Aufruf die zu verarbeitende Nachricht als Objekt vom Typ IQ 12 übergeben und mit der Methode Monitoring verteilter Dienste für Datenextraktion

55 5 Implementation 5.1 Datensammlung getchildelement wird der Inhalt des IQ-Set abgerufen. Die Rückgabe von getchildelement ist ein Objekt vom Typ Element 13 (aus der Bibliothek dom4j, die von Tinder intern zum Parsen von XML genutzt wird). In handleiqset wird geprüft, ob das Element die XML-Struktur (siehe Abschnitt 4.5.1) zur Übermittlung von Logging-Einträgen enthält (Vergleich ob der Tag- Name lofentries und der Namespace modelspace:logentries sind). Ist dies der Fall, wird über alle Kind-Elemente iteriert und Objekte vom Typ LogEntryVerbose, LogEntryCompact oder LogEntryAttr, je nach Tag-Name des Kind-Elementes, werden erzeugt und in einer Liste zwischengespeichert. Aus handleiqset wird insertlogentriesinfodb mit der erzeugten Liste als übergebenden Parameter aufgerufen. In insertlogentriesinfodb werden die extrahierten Logging-Einträge in die Datenbank gespeichert. Dies erfolgt in einer eigenen Methode, um den von MonitorComponent abgeleiteten Klassen das Überschreiben zu ermöglichen. Jede Komponenten-Klasse (MonitorComponent, TransactionMonitorComponent, Transaction- BatchMonitorComponent, NotSavingMonitorComponent und NoProcessingMonitorComponent) setzt eine eigene Strategie beim Zugriff auf die Datenbank um, indem insertlogentriesinfodb jeweils unterschiedlich implementiert wird. Bei der Evaluierung werden die unterschiedlichen Strategien untersucht (Abschnitt 6.2). Drei der Komponenten speichern wirklich Einträge in der Datenbank. Sie greifen auf die Datenbank unter Verwendung von Connection-Pooling 14 aus der Bibliothek BoneCP zu und nutzen zur Generierung der SQL-Anweisungen unterschiedliche Methoden: MonitorComponent Nutzt java.sql.preparedstatement 15 und führt die Methode execute- Update für jedes Statement einzeln aus. Autocommit ist aktiviert, somit wird jeder Logging- Eintrag einzeln in die Datenbank geschrieben. TransactionMonitorComponent Implementiert den gleichen Ablauf wie bei TransactionMonitorComponent, aber Autocommit ist deaktiviert. Dadurch werden alle Logging-Einträge die aus einem IQ-Set extrahiert wurden, in einer Transaktion beim Speichern zusammengefasst. TransactionBatchMonitorComponent Nutzt ebenfalls PreparedStatement und führt die Methode executebatch aus, nachdem alle Statements generiert wurden. Autocommit ist deaktiviert und die Logging-Einträge werden mit einer einzigen SQL-Anweisung in einer Transaktion in die Datenbank geschrieben. Die anderen beiden schreiben nicht in die Datenbank und dienen im Zuge der Evaluation zur Bestimmung von Overhead: NotSavingMonitorComponent Verarbeitet nur bis zur Generierung der Liste mit Objekten vom Typ LogEntryVerbose, LogEntryCompact oder LogEntryAttr und insertlogentries- InfoDb ist ohne Funktion. NoProcessingMonitorComponent Überschreibt handleiqset und vollzieht überhaupt keine Verarbeitung, sondern antwortet direkt mit einem IQ-Result. Nach erfolgreicher Verarbeitung erfolgt die Rückkehr aus insertlogentriesinfodb nach handleiqset und es wird ein IQ-Result zum Logger geschickt. Dazu wird ein Objekt vom Typ IQ generiert, welches das IQ-Result zur gerade verarbeiteten Nachricht repräsentiert: Monitoring verteilter Dienste für Datenextraktion 41

56 5 Implementation 5.1 Datensammlung 1 result = IQ. createresultiq ( iq); Listing 5.1: Generierung des IQ-Result Das erzeugte IQ-Objekt ist der Rückgabe-Wert von handleiqset. Die Implementierung von AbstractComponent ist so, dass die Rückgaben von handleiqset automatisch als XMPP- Nachricht versendet werden. Würde handleiqset null zurückgeben, wird automatisch ein passender IQ-Error erzeugt, dadurch ist sichergestellt, dass auf jedes verarbeitete IQ-Set auch eine Antwort erfolgt SQL-Datenbank Die Implementation nutzt MySQL 16 als SQL-Server mit InnoDB 17 als Format für die angelegten Tabellen. InnoDB unterstützt effektiv parallele Schreibvorgänge und ermöglicht dadurch, dass mehrere Worker-Threads in der Komponente überhaupt zu einer Leistungssteigerung führen können XMPP-Client als Logging Komponente des Indexierungsservers Die Abbildung 5.3 zeigt die Klassen, die zusammen den Logger ausmachen. Die zentrale Klasse ist Logger, sie implementiert das Interface ILogger und ein Objekt vom Typ Logger ist dazu gedacht, in der Indexer-Software instanziiert und für das Logging benutzt zu werden. Die Klasse kapselt eine Instanz von XMPPConnection 18 aus der Bibliothek Smack, welche die Funktionen zur Kommunikation über XMPP bereit stellt. Um den JID des Monitors zu bestimmen, wird die von Smack bereitgestellte Klasse ServiceDiscoveryManager 19 und deren Methoden verwendet: Listing 5.2: Service Discovery durch Logger 1 String foundmonitor = null ; 2 3 ServiceDiscoveryManager discomanager = ServiceDiscoveryManager. getinstancefor ( this. conn ); 4 5 DiscoverItems discoitems = discomanager. discoveritems ( this. server ); 6 Iterator < DiscoverItems. Item > it = discoitems. getitems (); 7 while (it. hasnext ()) { 8 DiscoverItems. Item item = it. next (); 9 String entityid = item. getentityid (); DiscoverInfo info = discomanager. discoverinfo ( entityid, item. getnode ()); 12 Iterator < DiscoverInfo. Feature > itf = info. getfeatures (); 13 while ( itf. hasnext ()) { 14 DiscoverInfo. Feature fe = itf. next (); if (fe. getvar (). equals (" modelspace : logentries ")) { 17 foundmonitor = entityid ; 18 break ; 19 } 20 } if ( foundmonitor!= null ) { 23 break ; 24 } 25 } Zuerst wird die Instanz von ServiceDiscoveryManager für die XMPPConnection des Logger referenziert (Zeile eins). In den Zeilen fünf bis sieben wird der XMPP-Server nach seinen Service Monitoring verteilter Dienste für Datenextraktion

57 5 Implementation 5.1 Datensammlung Abbildung 5.3: Klassendiagramm Logger Discovery Items befragt und über das Ergebnis iteriert (die Items des Servers enthalten auch die aktiven Komponenten und somit auch den JID des Monitors). Im Rumpf der ersten Schleife werden zu jedem Item dessen unterstützte Features abgefragt und über diese wieder iteriert. Ist eines der Features eines Items modelspace:logentries, dann ist der Monitor gefunden, der JID dieses Items wird in foundmonitor zwischengespeichert und die Schleifendurchläufe abgebrochen. Zur besseren Lesbarkeit wurde das Listing ohne jegliche Fehlerbehandlung eingefügt. Die Implementation der Methode discovermonitor von Logger fängt die möglichen Fehler ab und stellt der Klasse eine robuste Methode zur Verfügung, den JID des Monitors mittels Service Directory zu bestimmen. Der im Konzept vorgesehene Aggregator wird durch die Klasse LogEntriesAggregator implementiert. Beim initialisieren von Logger wird ein Objekt vom Typ LogEntriesAggregator erzeugt und von Logger referenziert. LogEntriesAggregator stellt zwei Methoden bereit. Die Methode addlogentry hat als Parameter ein Objekt vom Typ LogEntry und fügt dieses der intern gepflegten Liste (logentries) der aktuellen Einträge hinzu, wenn die Dokumenten-ID des übergebenden Objektes mit dem Attribut documentid des Aggregator übereinstimmt. Ist dies nicht der Fall, wird die Liste geleert, documentid mit der Dokumenten-ID des übergebenen Objektes belegt und das übergebene Objekt als erstes Element der List eingetragen. Bei Auf- Monitoring verteilter Dienste für Datenextraktion 43

58 5 Implementation 5.1 Datensammlung ruf der Methode getlogentries wird die aktuelle Liste zurückgegeben und logentries und documentid auf null gesetzt. Der Puffer des Logger wird durch die Klasse LogEntriesBuffer implementiert. Mit der Methode adddocument wird er befüllt und mit der Methode getdocuments werden Einträge entnommen. Die Klasse Logger erzeugt bei der Initialisierung ein Objekt vom Typ Log- EntriesBuffer mit der konfigurierten, maximalen Anzahl an Einträgen. Innerhalb der Klasse Logger sind alle Zugriffe auf das Puffer-Objekt durch einen ReentrantLock 20 geschützt (Logger.logEntriesBufferLock), da mehrere Methoden auf den Puffer zugreifen und diese, durch das asynchrone Versenden in einem eigenen Thread, parallel aufgerufen werden können. Die Klasse für das asynchrone Versenden von XMPP-Nachrichten ist LoggerSender, eine private, innere Klasse von Logger, die von Thread 21 abgeleitet ist. Durch die Implementation ist sichergestellt, dass höchstens ein Sender-Thread zur gleichen Zeit instanziiert und aktiv ist. In seiner Methode run führt er die Methode send des Logger-Objektes aus, von dem aus der Thread instanziiert wurde, der Zugriff auf das Logger-Objekt ergibt sich aus der Implementation als innere Klasse: Listing 5.3: Implementation der Methode run der Klasse LoggerSender 1 private class LoggerSender extends Thread { 3 public void run () { 4 Logger. this. send (); 5 } 6 } Zur Sicherstellung das nur eine Instanz von LoggerSender aktiv ist, kommt ein weiterer ReentrantLock 22 zum Einsatz (Logger.sendingLock). In der Methode send von Logger, die durch LoggerSender.run aufgerufen wird, wird Logger.sendingLock gesetzt, d. h. ein laufender Sender-Thread zeigt sich durch den gesetzten Lock. Der Start eines Sender-Threads erfolgt aus den Methoden logentry und logdocument heraus: Listing 5.4: Start des Sender-Thread 1 if ( this. sendinglock. trylock ()) { 2 try { 3 LoggerSender sender = new LoggerSender (); 4 sender. start (); 5 } finally { 6 this. sendinglock. unlock (); 7 } 8 } Mit der Methode trylock wird innerhalb von logentry und logdocument geprüft, ob es bereits einen Sender-Thread gibt. Die Methode trylock liefert true zurück und akquiriert den Lock, wenn er derzeit frei ist, andernfalls wird false zurück geliefert. Die Implementation in Listing 5.4 nutzt dieses Verhalten, um genau dann einen Sender-Thread zu starten, wenn der Lock akquirierbar ist, also aktuell kein Sender-Thread läuft. Die von LoggerSender aufgerufene Methode send ruft solange die Methode _send auf, wie der Puffer Logging-Einträge enthält und _send setzt die Kommunikation per XMPP um. Es erzeugt dazu ein Objekt vom Typ LogEntriesIQ, welches die zu übertragenden Logging-Einträge übergeben bekommt. LogEntriesIQ erbt von org.jivesoftware.smack.packet.iq 23 und durch Überschreiben der Methode getchildelementxml wird die in Abschnitt beschriebene XML-Struktur eingehalten. Das IQ-Objekt wird mit der XMPPConnection des Logger verschickt Monitoring verteilter Dienste für Datenextraktion

59 5 Implementation 5.1 Datensammlung und die zugrundeliegende Bibliothek Smack sorgt für die Verschickung der XMPP-Nachricht. In _send wird auch die Serialisierung des Nachrichtenstromes implementiert: Listing 5.5: Auf IQ-Result warten 1 PacketCollector collector = this. conn. createpacketcollector ( 2 new AndFilter ( 3 new OrFilter ( 4 new IQTypeFilter (IQ. Type. RESULT ), 5 new IQTypeFilter (IQ. Type. ERROR )), 6 new PacketIDFilter (iq. getpacketid ()))); 7 8 this. conn. sendpacket (iq); 9 10 IQ result = ( IQ) collector. nextresult ( this. waittimeforiqresult ); 11 collector. cancel (); Der instanziierte PacketCollector 24 arbeitet mit definierten Filtern. In Listing 5.5 wartet der Code auf ein IQ vom Typ Result oder Error und mit der gleichen ID wie das vorher abgeschickte IQ-Set. Dabei wird maximal this.waittimeforiqresult lange gewartet. Je nach empfangenen IQ-Typ wird dann entweder repuffert und der Thread pausiert seine Ausführung kurz (IQ-Error) oder die Verarbeitung von _send ist beendet. Abbildung 5.4: Ablauf Logging mit den implementierten Klassen 24 Monitoring verteilter Dienste für Datenextraktion 45

60 5 Implementation 5.2 Web-Oberfläche Abbildung 5.4 zeigt den Ablauf des Logging mit den implementierten Klassen. Sie verdeutlicht, dass das Versenden von Logging-Einträgen asynchron zur ihrer Übergabe ist und legt die Abhängigkeiten und Aufrufe zwischen den unterschiedlichen Klassen dar. 5.2 Web-Oberfläche Die Web-Oberfläche ist als Django-Projekt implementiert. Die Funktionalität ist in der Django- Anwendung monitor gekapselt, welche im Abschnitt vorgestellt wird. Die in der Konzeption vorgesehenen JavaScript-Funktionalitäten sind als jquery 25 -Plugins umgesetzt. Am Beispiel des Views»Ansicht Modellraum-Hierarchie«wird die Implementation in Abschnitt beschrieben Django-Anwendung monitor Listing 5.6: Die Klasse RawLogEntry als Abbildung des gewählten SQL-Schemas in Django 1 class RawLogEntry ( models. Model ): 2 indexer = models. CharField ( max_length =255) 3 dokumentid = models. CharField ( max_length =255) 4 indexentryname = models. CharField ( max_length =255) 5 extractedvalue = models. CharField ( max_length =255) 6 component = models. CharField ( max_length =255) 7 modelspace = models. CharField ( max_length =255) 8 confidence = models. DecimalField ( max_digits =9, decimal_places =8) 9 escalateto = models. CharField ( max_length =255, blank =True, null = True ) 10 feedback = models. CharField ( max_length =255, blank =True, null = True ) 11 begin = models. DateTimeField () 12 end = models. DateTimeField () Listing 5.6 zeigt die Implementation der Klasse RawLogEntry, sie bildet das SQL-Schema aus Listing B.2 auf ein Django-Model ab. Über diese Klasse wird in monitor auf die Logging-Einträge in der Datenbank zugegriffen. Listing 5.7: Queryset-API von Django 1 RawLogEntry. objects. filter ( indexer in = indexer, 2 end gte = begin_dt, 3 end lte = end_dt ) Der Ausschnitt demonstriert den Zugriff auf die Datenbank über die Klasse RawLogEntry. Jedes Model in Django besitzt das Attribut objects, mit dem auf eine Manager-Instanz 26 zugegriffen werden kann. Über diese Instanz kann Djangos QuerySet-API 27 angesprochen und Abfragen formuliert werden. In Listing 5.7 werden alle Logging-Einträge abgefragt, die von den Loggern in der Liste indexer übermittelt und zwischen begin_dt und end_dt erzeugt wurden. Das Listing 5.8 zeigt die von Django daraus generierte SQL-Abfrage, wenn die Liste indexer das Element»indexer1«enthält, begin_dt den Wert» :00:00«darstellt und end_dt den Wert» :59:59«repräsentiert. Listing 5.8: SQL-Anweisung die aus Listing 5.7 durch Django generiert wird 1 SELECT 2 monitor_rawlogentry. id, 3 monitor_rawlogentry. indexer, 4 monitor_rawlogentry. dokumentid, 5 monitor_rawlogentry. indexentryname, https://docs.djangoproject.com/en/1.4/topics/db/managers/ 27 https://docs.djangoproject.com/en/1.4/topics/db/queries/ 46 Monitoring verteilter Dienste für Datenextraktion

61 5 Implementation 5.2 Web-Oberfläche 6 monitor_rawlogentry. extractedvalue, 7 monitor_rawlogentry. component, 8 monitor_rawlogentry. modelspace, 9 monitor_rawlogentry. confidence, 10 monitor_rawlogentry. escalateto, 11 monitor_rawlogentry. feedback, 12 monitor_rawlogentry. begin, 13 monitor_rawlogentry. end 14 FROM 15 monitor_rawlogentry 16 WHERE 17 ( 18 monitor_rawlogentry. indexer IN ( indexer1 ) 19 AND monitor_rawlogentry. end <= :59:59 20 AND monitor_rawlogentry. end >= :00:00 ) Django verarbeitet die Daten, die von der Datenbank auf die Abfrage zurückgeliefert werden und erstellt für jeden Logging-Eintrag ein Objekt vom Typ RawLogEntry. Alle erzeugten Objekte werden in Form eines QuerySet-Objektes 28 als Ergebnis des Aufrufs von filter zurückgegeben. Die drei konzeptionierten Ansichten sind als Django-Views implementiert und diese in der URL-Konfiguration des Projektes entsprechend referenziert. Die Django-Views liefern die in Abschnitt 4.6 beschriebenen Container-HTML-Seiten aus und nutzen die Django-Template-Engine, um diese zu generieren. Die Views für das JSON-API unterscheiden sich in ihrem Aufbau nicht von den Views für die Container-HTML-Seiten. Der Unterschied liegt nur in den ausgelieferten Daten. Anstatt HTML zu generieren nutzen sie die in Python eingebaute Funktionalität zur Erzeugung von JSON-Datenstrukturen 29, um mit diesen Anfragen zu beantworten Implementation der JavaScript-Funktionalität am Beispiel der Hierarchie-Darstellung Die Funktionalität der Ansicht wird als jquery-plugin umgesetzt, dieses dann im Template zum Django-View referenziert und eine Instanz des Plugins erzeugt. Die Implementation des Plugins ist in einer eigenen JavaScript-Datei gekapselt und ist abhängig von den externen Bibliotheken jquery 30, Raphaël 31, handlebars 32 und strftime for Javascript 33. Listing 5.9: Template für Container-HTML-Seite mit Einbindung und Initialisierung eines jquery-plugins 1 <body > 2 <div id=" modelspace " 3 data-modelspace-forest = {{ hierarchy safe }} 4 data-modelspace-forest-indexer = {{ hierarchy_indexer safe }} 5 data-modelspace-forest-begin ="{{ hierarchy_begin }}" 6 data-modelspace-forest-end ="{{ hierarchy_end }}" 7 data-modelspace-forest-api-url ="{{ json_api_url safe }}" > 8 </div > 9 10 < script src ="{{ STATIC_URL }} monitor / js/ strftime. js" type =" text / javascript " charset =" utf-8 " ></ script > 11 < script src ="{{ STATIC_URL }} monitor / js/ raphael. js" type =" text / javascript " charset =" utf-8 " ></ script > 12 < script src ="{{ STATIC_URL }} monitor / js/ modelspace. js" type =" text / javascript " ></ script > 28 https://docs.djangoproject.com/en/1.4/ref/models/querysets/#django.db.models.query.queryset Monitoring verteilter Dienste für Datenextraktion 47

62 5 Implementation 5.2 Web-Oberfläche 13 < script src ="{{ STATIC_URL }} monitor / js/ handlebars. runtime. js" type =" text / javascript " ></ script > 14 < script src ="{{ STATIC_URL }} monitor / handlebars / activenodes. js" type =" text / javascript " ></ script > 15 < script src ="{{ STATIC_URL }} monitor / js/ jquery. modelspace. js" type =" text / javascript " ></ script > 16 < script type =" text / javascript "> 17 $( document ). ready ( function () { 18 $( div # modelspace ). modelspace (); 19 }); 20 </ script > 21 </body > Listing 5.9 zeigt den Ablauf anhand eines Ausschnittes aus dem entsprechenden Template. Im Fuß des <body>-elementes werden die benötigten JavaScript-Dateien referenziert. Das <div>-element mit der ID modelspace dient als Container für das Plugin. In der Zeile 18 wird mit $( div#modelspace ).modelspace(); eine Instanz des Plugins erzeugt. Mittels data- Attribute werden die Initialisierungs-Parameter übergeben. Bei der Ausführung des zugehörigen Django-Views werden die entsprechenden Variablen dem Template-Kontext hinzugefügt und beim Rendern des Templates durch die Django-Template-Engine werden die Ausdrücke der Form {{ Variablenname }} durch die entsprechenden Werte ersetzt. Dies dient nur der initialen Übergabe von Daten, so dass im Browser des Nutzers sofort die Anzeige der Informationen durch das Plugin erfolgen kann. Spätere Updates der dargestellten Daten fragt das Plugin über das JSON-API ab. Dieses Vorgehen ermöglicht es, dass Filter-Parameter Teil der URL sein können und bei der Generierung der initialen Daten vom Django-View beachtet werden. Dadurch können Nutzer Filteransichten per URL austauschen. Die Darstellung des Graphen der Hierarchie wird in der JavaScript-Klasse ModelspaceForestDrawer (implementiert in modelspace.js) umgesetzt. Die Anzeige wird mittels Scalable Vector Graphics (SVG) 34 realisiert. Die Klasse implementiert den in Abschnitt beschriebenen Grid-Layout-Algorithmus und nutzt die Funktionen der Bibliothek Raphaël um die SVG- Grafik zu erzeugen. Die dynamischen Interaktionsmöglichkeiten, wie Teile des Baumes auf- und einzuklappen, werden mittels Events und den zugehörigen, an die SVG-Elemente gebundenen, Event-Handlern realisiert. ModelspaceForestDrawer implementiert die Darstellung, wird aber nicht direkt verwendet, sondern vom jquery-plugin genutzt. Das Plugin verarbeitet die mittels <data>-attributen übergebenen Initialisierungsdaten, insbesondere die JSON-kodierten Hierarchie-Daten und erzeugt die konzeptionierte Aufteilung des User-Interfaces. Die Toolbar und die Liste aktiver Vergleichsgruppen werden durch Nutzung der JavaScript-Template-Engine handlebars erzeugt und für die Graph-Darstellung wird ein Container-<div>-Element angelegt. Eine generierte Instanz der Klasse ModelspaceForestDrawer erzeugt die Graph-Darstellung im dafür vorgesehenen Container. Bei der Interaktion mit den Elementen des Graphen verarbeiten Event-Handler die Eingaben des Nutzers und aktualisieren die internen Datenstrukturen des Plugins und dieses wiederum aktualisiert die Darstellung der Elemente des User-Interfaces auf der Grundlage der aktualisierten Daten Monitoring verteilter Dienste für Datenextraktion

63 6 Evaluation 6 Evaluation Um Messungen durchführen zu können, besitzt die Klasse Logger einen verzögerten Versand- Modus, der mit dem Parameter deferedsending beim Konstruktor aktiviert werden kann. Verzögert bedeutet, dass der Sender-Thread nicht aus den Methoden logentry und logdocument heraus gestartet wird, sondern dies mit der Methode startdeferedsending manuell durch den Verwender der Logger-Instanz geschieht. Der verzögerte Versand-Modus ermöglicht nun folgenden Ablauf: Eine bestimmte Anzahl x an Logging-Einträgen soll für eine Messung generiert werden. Das Logger-Objekt wird mit einem Puffer der Größe x und deferedsending == true initialisiert. Die Logging-Einträge werden dem Puffer hinzugefügt und die Methode startdeferedsending wird aufgerufen. Dadurch lässt sich präzise die Dauer bestimmen, die für das Versenden aller Logging-Einträge benötigt wird. Die Messung beginnt mit dem Aufruf von startdeferedsending und endet sobald der Puffer leer ist. Die Klasse Logger implementiert zusätzlich die Möglichkeit, die gemessenen Werte in eine CSV-Datei zu speichern. Das in Python geschriebene Skript evaluation_runner.py ist die Laufzeit-Umgebung zur Ausführung der Evaluations-Läufe. Es verarbeitet XML-Dateien nach dem Schema aus Listing B.3 und führt das spezifizierte Setup aus. Ein Setup beschreibt die Anzahl paralleler Logger, die Anzahl generierter Logging-Einträge, wie viele Logging-Einträge pro Nachricht aggregiert werden und mit welchem Repräsentations-Format gearbeitet wird. Eine Evaluation kann von Typ lokal oder remote sein. Bei lokalen Evaluationen wird eine Monitor-Instanz durch das Skript gestartet und die XML-Datei beschreibt, welche Komponenten-Klasse verwendet wird und wie diese konfiguriert sein soll. Im andern Fall beschreibt die XML-Datei nur die Konfiguration eines, über das Netzwerk erreichbaren, Monitors und kontrolliert nur die Logger. Mit dem Skript werden verschiedene Evaluationen durchgeführt und deren Messwerte in CSV-Dateien gespeichert. Mit Hilfe zweier weiterer Python-Skripte (results_combiner.py und multi_client_run_summary.py) werden diese CSV-Dateien aggregiert und mit der Tabellenkalkulation von LibreOffice 1 aufbereitet. Die Aufbereitungen sind die Grundlage der im Folgenden dargestellten Erkenntnisse. Das Setup der Evaluationsläufe ist wie folgt: Evaluation 1 Die Evaluation ist lokal, ein Logger verschickt Logging-Einträge mit einem bis Logging-Einträgen pro Nachricht. Der Logger testet alle XML-Repräsentationen gegen alle Komponenten-Klassen. Die Monitor-Klassen benutzen die Standard-Parameter (17 Worker und Queue-Größe von 1000). Jede Kombination aus Logging-Einträgen pro Nachricht, XML-Repräsentation und Komponenten-Klasse wird acht mal ausgeführt. Evaluation 2 Die Evaluation ist remote, zehn Logger verschicken jeweils Logging-Einträge mit 250 Logging-Einträgen pro Nachricht. Die genutzte XML-Repräsentation ist»kompakt- Attribute«und beim Monitor wird die Klasse TransactionBatchMonitorComponent verwendet. Die Queue-Größe ist immer 1000 und die Anzahl der Worker eins bis vier. Die Verbindung über das Netzwerk erfolgt über Funk per Wireless Local Area Network (WLAN) und per kabelgebundenem Ethernet (LAN). Jede Kombination wird vier mal vermessen. Evaluation 3 Die Evaluation ist remote über LAN. Ein Logger verchickt Logging-Einträge mit 50 bis 2500 Logging-Einträgen pro Nachricht. Die genutzte XML-Repräsentation ist 1 https://www.libreoffice.org/ Monitoring verteilter Dienste für Datenextraktion 49

64 6 Evaluation 6.1 Vergleich der unterschiedlichen XML-Strukturen»Kompakt-Attribute«und beim Monitor wird die Klasse TransactionBatchMonitor- Component verwendet. Die Queue-Größe ist 1000 und die Anzahl der Worker zwei. Jede Kombination wird vier mal vermessen. Evaluation 4 Nutzt die gleichen Parameter wie Evaluation 3, aber es senden zehn Logger gleichzeitig. In den folgenden Abschnitten ist mit dem Begriff Nachrichtengröße, die Anzahl der in einer XMPP-Nachricht aggregierten Logging-Einträge gemeint. Die für die Messungen genutzten Rechner haben folgende Konfiguration: Lokale Evaluation Monitor, Datenbank, XMPP-Server und die Logger werden auf dem gleichen Rechner ausgeführt. Dieser besitzt einen Dual-Core-Prozessor»Intel Core2 Duo P8700«, vier GB Arbeitsspeicher und die für die Datenbankperformance wichtige Festplatte, war ein Solid-State-Drive (SSD) vom Typ»Samsung P830«. Remote-Evaluation Monitor, Datenbank und XMPP-Server verbleiben auf dem zuvor beschriebenen Rechner. Die Logger werden auf einem Computer mit einem Quad-Core-Prozessor (»Intel Core i7-3740qm«) und 16 GB Arbeitsspeicher gestartet. 6.1 Vergleich der unterschiedlichen XML-Strukturen Abbildung 6.1: Vergleich der XML-Repräsentationen Nach den Ergebnissen von Evaluation 1 ist die verwendete XML-Struktur unerheblich für die Geschwindigkeit der Verarbeitung. Unabhängig von der eingesetzten Komponenten-Klasse und der Nachrichtengröße werden die Logging-Einträge bei einer bestimmten Kombination von Komponenten-Klasse und Nachrichtengröße mit allen drei XML-Strukturen gleich schnell vom Logger an den Monitor übertragen. Abbildung 6.1 zeigt beispielhaft anhand der Klasse 50 Monitoring verteilter Dienste für Datenextraktion

65 6 Evaluation 6.2 Vergleich der Zugriffsstrategien auf die Datenbank TransactionBatchMonitorComponent die ermittelten Ergebnisse. Im Anhang befindet sich der Vergleich aller möglichen Kombinationen, siehe Abbildung A Vergleich der Zugriffsstrategien auf die Datenbank Abbildung 6.2: Vergleich der Komponenten-Klassen Die Messungen von Evaluation 1 zeigen, dass die Zugriffsstrategie auf die Datenbank erheblichen Einfluss auf die Geschwindigkeit der Verarbeitung hat. Abbildung 6.2 stellt einen Vergleich der Komponenten-Klassen dar (aufgrund der Erkenntnisse aus dem vorhergehenden Abschnitt ist nur die Repräsentation»Kompakt-Attribute«aufgeführt). Sie zeigt, dass bei einer Nachrichtengröße von eins, die Klasse MonitorComponent schneller ist, als die anderen, in die Datenbank schreibenden Klassen TransactionMonitorComponent und TransactionBatch- MonitorComponent (12742ms zu 14483ms und 14543ms). Bei jeder anderen Nachrichtengröße implementiert MonitorComponent die langsamste Strategie und die anderen beiden Klassen sind deutlicher schneller. Zum Beispiel mehr als doppelt so schnell im Bereich der Nachrichtengröße von 50 bis 1000, mit dem absoluten Minimum durch TransactionBatchMonitorComponent bei der Nachrichtengröße 250 von 2459ms. Mit MonitorComponent als Komponente benötigt der Logger, bei einer Nachrichtengröße von 250, 5377ms für das Versenden. Bei fast allen Nachrichtengrößen ist der Unterschied zwischen TransactionMonitorComponent und Transaction- BatchMonitorComponent vernachlässigbar gering, erst ab 2500 Logging-Einträgen pro Nachricht wird dieser zugunsten von TransactionBatchMonitorComponent größer. Daraus lässt sich schlussfolgern, das die konkrete Implementation der beiden Klassen in Java eher zweitrangig ist. Entscheidend ist, dass beide Klassen die Logging-Einträge einer Nachricht in einer Transaktion zusammenfassen. Der Nachteil bei sehr kleinen Nachrichtengrößen ist nicht entscheidend, da bei diesen die Verarbeitungsgeschwindigkeit an sich auf einem niedrigen Niveau ist (alle Verläufe haben ihr Minimum bei den mittleren Nachrichtengrößen) und die Logger folglich nicht mit Monitoring verteilter Dienste für Datenextraktion 51

66 6 Evaluation 6.3 Extraktion der Logging-Einträge einer kleinen Nachrichtengröße im Produktivbetrieb arbeiten sollten. Zusammenfassend geht TransactionBatchMonitorComponent als beste Implementation aus dem Vergleich hervor und sollte im Produktivbetrieb genutzt werden. 6.3 Extraktion der Logging-Einträge Abbildung 6.2 demonstriert, dass die implementierte Extraktion durch Überführung der Daten in Objekte vom Typ LogEntryVerbose, LogEntryCompact oder LogEntryAttr (siehe Abschnitt 5.1.1) keine Performance-Einbußen verursacht. Die Klasse NotSavingMonitorComponent (führt nur die Extraktion aus) ist bei allen Nachrichtengrößen nur wenige Millisekunden langsamer als die Klasse NoProcessingMonitorComponent, die überhaupt keine Verarbeitung durchführt. Der Unterschied ist genau die für die Erzeugung der Objekte benötigte Zeit. 6.4 Performance-Kosten des Datenbank-Zugriffs Der Vergleich von TransactionBatchMonitorComponent, als schnellste speichernde Komponente und NotSavingMonitorComponent zeigt die Verzögerung, die durch das Speichern in der Datenbank verursacht wird. Im Bereich der mittleren Nachrichtengrößen, wo die Performance des Systems an sich am größten ist, ist TransactionBatchMonitorComponent rund 1,5 mal langsamer als NotSavingMonitorComponent (bei der Nachrichtengröße 250 zum Beispiel 2459ms zu 1401ms. Durch die persistente Speicherung kann der Monitor also weniger XMPP-Nachrichten in gleicher Zeit verarbeiten. Abbildung 6.3: Einfluss der Größe des Worker-Pools 52 Monitoring verteilter Dienste für Datenextraktion

67 6 Evaluation 6.5 Performance bei praxisnahem Setup 6.5 Performance bei praxisnahem Setup Die Evaluation 1 dient vor allem der Bestimmung, welche Klassen in einem praxisnahen Setup mit Netzwerk-Kommunikation und parallel sendenden Loggern einzusetzen sind. Aufbauend auf den gewonnenen Erkenntnissen werden in den Evaluationen 2 bis 4 beim Monitor die Komponente TransactionBatchMonitorComponent und als XML-Struktur»Kompakt-Attribute«verwendet. Abbildung 6.3 zeigt die Ergebnisse von Evaluation 2. Bei einem Durchlauf senden zehn Logger gleichzeitig. Im Diagramm steht der Wert Minimum zu einem Eintrag für den schnellsten der zehn Logger bei einer bestimmten Worker-Pool-Größe. Der Durchschnitt ist der Mittelwert der Sendezeiten aller zehn Logger und das Maximum ist die Sendezeit des langsamsten Loggers. Abbildung 6.4: Optimale Nachrichten-Größe bei einem sendenden Logger Ziel ist es, die optimale Größe des Worker-Pools zu bestimmen, allerdings lassen sich weitere Erkenntnisse aus der Abbildung gewinnen. Sie zeigt den Einfluss des Transport-Mediums, mit dem Logger und Monitor verbunden sind. Bei der Nutzung von WLAN ist die Verarbeitungsgeschwindigkeit mehr als doppelt so langsam wie bei LAN und insbesondere sehr viel schwankender. Das Diagramm mittelt über vier Messläufe, die bei LAN alle sehr ähnlich sind. Aus den Rohdaten ist zum Beispiel für eine Pool-Größe von eins ersichtlich, dass in den vier Läufen die Sendezeit des schnellsten Loggers bei WLAN zwischen 50034ms und ms variiert, also sehr großen Schwankungen innerhalb der vier Messläufe unterliegt. Bei den anderen Pool-Größen verhält es sich ähnlich. Bei LAN schwanken die Werte innerhalb der vier Messläufe immer um höchstens zwei Sekunden. Aufgrund dieser Schwankungen kann für WLAN keine Entscheidung bezüglich der optimalen Pool-Größe aus der Abbildung abgeleitet werden. Die Größe drei hat zwar nominal die besten Werte, aber die Messläufe zur Pool-Größe können einfach zufällig zu einem Zeitpunkt stattgefunden haben, als das Funknetzwerk vergleichsweise wenig Störungen ausgesetzt war und deswegen eine höhere Geschwindigkeit ermöglichte. Für LAN lässt sich eine Aussage treffen, wenn auch keine eindeutige. Eine Pool größer als eins ist auf jeden Fall sinnvoll und dies korrespondiert mit den Überlegungen aus Abschnitt 4.5.6, da der Monitor auf einem Monitoring verteilter Dienste für Datenextraktion 53

68 6 Evaluation 6.5 Performance bei praxisnahem Setup Rechner mit zwei Prozessor-Kernen läuft. Die nominal besten Werte werden bei einer Pool- Größe von drei gemessen, aber der Unterschied zu den Größen zwei und vier ist sehr gering. Der Anstieg zwischen den Größen drei und vier lässt vermuten, dass eine zu hohe Worker-Anzahl die Geschwindigkeit wieder senken würde. Abbildung 6.5: Optimale Nachrichten-Größe bei zehn sendenden Loggern Da bei Nutzung von WLAN die Messungen keine eindeutigen Erkenntnisse zulassen, wird in den Evaluationen drei und vier nur noch LAN untersucht. Die beiden Evaluationen dienen der Bestimmung der optimalen Nachrichtengröße. Abbildung 6.4 zeigt das Verhalten, wenn ein Logger Logging-Einträge bei verschiedenen Nachrichtengrößen verschickt. Ein einzelner Logger erreicht die größte Geschwindigkeit bei einer Nachrichtengröße von 500. Dann werden 3192ms für Logging-Einträge benötigt, d.h. das System verarbeitet rund 3 Einträge pro ms. Abbildung 6.5 zeigt das Verhalten bei zehn sendenden Loggern. Dies beste Leistung wird bei einer Nachrichtengröße von 100 erzielt. Das Maximum von 20595ms bei 100 bedeutet, das nach dieser Zeitspanne alle zehn Logger ihre Einträge versendet und deren Verarbeitung vom 54 Monitoring verteilter Dienste für Datenextraktion

XMPP: Extensible Messaging and Presence Protocol

XMPP: Extensible Messaging and Presence Protocol XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Jabber. Florian Holzhauer. Proseminar Uni Ulm, 27. April 2005.

Jabber. Florian Holzhauer. Proseminar Uni Ulm, 27. April 2005. <page=1 max=22/> Jabber Florian Holzhauer Proseminar Uni Ulm, 27. April 2005 Idee, Geschichte Nachrichtentechnik Ausblick, Zukunft Gründe / Intention Grosse

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Sensordaten mit SNMP verteilen

Sensordaten mit SNMP verteilen Sensordaten mit SNMP verteilen Axel Wachtler und Ralf Findeisen Chemnitzer Linux Tage 17.03.2013 Einleitung Systembeschreibung Was ist SNMP? Implementierung Demo Ausblick Systemüberblick Sensor- und Gatewayknoten

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

drupal + nodejs erste schritte. @frega - fl@flink-solutions.de

drupal + nodejs erste schritte. @frega - fl@flink-solutions.de drupal + nodejs erste schritte. @frega - fl@flink-solutions.de am konkreten beispiel (inkl. code-schnipsel und live-demo, what could go wrong...) eine "shoutbox", d.h. ein kleinstmöglicher chatroom. nodejs?

Mehr

Inhaltsverzeichnis Vorwort Konzepte des Active Directory

Inhaltsverzeichnis Vorwort Konzepte des Active Directory Vorwort.................................................................. XI Warum dieses Buch.................................................... XI Kapitelübersicht.......................................................

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Loadbalancing und Clustering mit Tomcat 6

Loadbalancing und Clustering mit Tomcat 6 Loadbalancing und Clustering mit Tomcat 6 Java Forum Stuttgart 3. Juli 2008 Michael Heß ORDIX AG, Paderborn mhe@ordix.de www.ordix.de Agenda Zielsetzung des Vortrags Webserver Integration Loadbalancing

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009 RSS Push Verfahren Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI 18. November 2009 1 Übersicht RSSFeeds Polling Push RSSCloud PubSubHubBub Vergleich Quellen 2 Feeds FU-Berlin Institut

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.4 SIP 1 SIP (1) SIP (Session Initiation Protocol), dient als reines Steuerungsprotokoll (RFC 3261-3265) für MM-Kommunikation Weiterentwicklung des MBONE-SIP.

Mehr

Technische Beschreibung: Modul Datei und Ordnerverwaltung

Technische Beschreibung: Modul Datei und Ordnerverwaltung EPOD Encrypted Private Online Disc Technische Beschreibung: Modul Datei und Ordnerverwaltung Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Internet - Grundzüge der Funktionsweise. Kira Duwe

Internet - Grundzüge der Funktionsweise. Kira Duwe Internet - Grundzüge der Funktionsweise Kira Duwe Gliederung Historische Entwicklung Funktionsweise: -Anwendungen -Rechnernetze -Netzwerkschichten -Datenkapselung -RFC -Verschiedene Protokolle (Ethernet,

Mehr

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007 OSEK / COM Florian Hohnsbehn PG AutoLab Seminarwochenende 21.-23. Oktober 2007 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einführung 1.1 Was ist OSEK COM? OSEK COM ist eine vom OSEK-VDX-Konsortium entwickelte

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Mobilkommunikation REST-basierte Dienste für verteilte, mobile Anwendungen A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Fachhochschule Köln, Institut für Nachrichtentechnik Fachhochschule Köln Anton Gillert,

Mehr

XMPP - Jabber. Noch ein IM. 2010-05-11 (v. 1273584047) Thomas Merkel (tm@core.io)

XMPP - Jabber. Noch ein IM. 2010-05-11 (v. 1273584047) Thomas Merkel (tm@core.io) XMPP - Jabber Noch ein IM 2010-05-11 (v. 1273584047) Thomas Merkel (tm@core.io) Agenda Motivation Das Kaffee Problem Andere... AGBs Was ist Jabber? Warum ist Jabber cool? Beispiel Architektur Features

Mehr

SINT Rest App Documentation

SINT Rest App Documentation SINT Rest App Documentation Release 1.0 Florian Sachs September 04, 2015 Contents 1 Applikation 3 2 Rest Service 5 3 SOAP Service 7 4 Technologiestack 9 5 Deployment 11 6 Aufgabe 1: Google Webservice

Mehr

8 Das DHCPv6-Protokoll

8 Das DHCPv6-Protokoll 8 Das DHCPv6-Protokoll IPv6 sollte DHCP als eigenständiges Protokoll ursprünglich überflüssig machen, da viele DHCP- Funktionen serienmäßig in IPv6 enthalten sind. Ein IPv6-fähiger Rechner kann aus der

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Chatten mit der Glühbirne

Chatten mit der Glühbirne Chatten mit der Glühbirne Eine Einführung in Jabber und XMPP für normale User Tim Weber Chaostreff Mannheim 25. Mai 2007 Inhalt Worum geht's? Terminologie, Unterschiede, Vor- und Nachteile gegenüber anderen

Mehr

ERSTELLEN VON INCENTIVES IM ZANOX NETZWERK

ERSTELLEN VON INCENTIVES IM ZANOX NETZWERK ERSTELLEN VON INCENTIVES IM ZANOX NETZWERK USER GUIDE FÜR ADVERTISER INHALTSVERZEICHNIS 1. Einführung...3 2. Incentives veröffentlichen...4 3. Weitere Funktionen...9 ZANOX.de AG Erstellen von Incentives

Mehr

SolarWinds Engineer s Toolset

SolarWinds Engineer s Toolset SolarWinds Engineer s Toolset Monitoring Tools Das Engineer s Toolset ist eine Sammlung von 49 wertvoller und sinnvoller Netzwerktools. Die Nr. 1 Suite für jeden Administrator! Die Schwerpunkte liegen

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Apache HTTP-Server Teil 2

Apache HTTP-Server Teil 2 Apache HTTP-Server Teil 2 Zinching Dang 04. Juli 2014 1 Benutzer-Authentifizierung Benutzer-Authentifizierung ermöglicht es, den Zugriff auf die Webseite zu schützen Authentifizierung mit Benutzer und

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Vorstellung Schnittstellenanalyse und -spezifikation

Vorstellung Schnittstellenanalyse und -spezifikation Vorstellung Schnittstellenanalyse und -spezifikation Schnittstellenanalyse und -spezifikation zum Projektmanagement zur Überwachung von taktischer Projektplanung und durchführung Oliver Paech 11.06.2008

Mehr

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch SNMP4Nagios Grazer Linuxtage 2007 Peter Gritsch Inhalte Motivation für Network Monitoring SNMP Grundlagen Nagios Grundlagen SNMP4Nagios PlugIns Motivation für Network Monitoring Probleme erkennen bevor

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 ZIEL...3 2 FUNKTIONS-KONZEPT...3 2.1 Struktur...3

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht TCP/IP Datenübertragungsschicht Netzwerkschicht Anwendungsschicht 1 Schichtenmodell Schichtenmodell der Internet- Protokollsuite Ziel: Kommunikation unterschiedlicher Rechner mit verschiedenen Betriebssystemen

Mehr

Dazu stehen für alle gängigen Betriebssysteme die Command Line basierenden Tools snmpget, snmpset, snmptrap zur Verfügung.

Dazu stehen für alle gängigen Betriebssysteme die Command Line basierenden Tools snmpget, snmpset, snmptrap zur Verfügung. SNMP Einführung Command Line Tools Am Markt existieren jede Menge leistungsfähige, kommerzielle sowie open source Produkte, um Netzwerke und Serversysteme über das Simple Network Management Protokoll SNMP

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

CloudMatic V1.0. Inhalt

CloudMatic V1.0. Inhalt CloudMatic V1.0 Inhalt Einleitung... 2 CCUs hinzufügen... 3 meine-homematic.de... 4 Eigenes VPN... 4 View Editor... 5 Übersicht... 5 Allgemeine Einstellungen... 6 Kanäle hinzufügen... 6 Spezielle Kanäle...

Mehr

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

Mehr

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

AlwinPro Care Modul Schnittstelle TV-Steuerung

AlwinPro Care Modul Schnittstelle TV-Steuerung AlwinPro Care Modul Schnittstelle TV-Steuerung Beschreibung AlwinPro Care bietet die Möglichkeit TV für tageweise abzurechnen und stellt für die Freischaltung der Leistung einen Authentifizierungsserver

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07 Diameter KM-/VS-Seminar Wintersemester 2002/2003 Betreuer: Martin Gutbrod 1 Übersicht Einleitung AAA Szenarien Remote dial-in Mobile dial-in Mobile telephony Design von Diameter Ausblick Features Protokoll

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

14. Fachtagung Mobilkommunikation Osnabrück

14. Fachtagung Mobilkommunikation Osnabrück SOA-basierte Peer-to-Peer-Mehrwertdienstebereitstellung 14. Fachtagung Mobilkommunikation Osnabrück 13. - 14. Mai 2009 Dipl.-Ing. Armin Lehmann, Prof. Dr.-Ing. Ulrich Trick Fachhochschule Frankfurt am

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

DOMAINVERWALTUNG http://www.athost.at/

DOMAINVERWALTUNG http://www.athost.at/ DOMAINVERWALTUNG http://www.athost.at/ Bachstraße 47, 3580 Mödring office@athost.at 1 Die Domain Verwaltung... 3 1.1 Die Domainstatussymbole... 3 1.2 Eine Subdomain anlegen... 3 1.3 Allgemeine Einstellungen...

Mehr

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle Version: 1.0.0 Datum: 2013-11-20 Autor: Bernd Ennsfellner, Renate Pinggera gizmocraft, design and technology GmbH

Mehr