Storage API und verteiltes Service-Hosting XMPP-basierter Dienste

Transkript

1 Storage API und verteiltes Service-Hosting XMPP-basierter Dienste Diplomarbeit Technische Universität Dresden 31. Oktober 2013 Philipp Grubitzsch Betreuender wissenschaftlicher Mitarbeiter : Dr.-Ing. 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 Verteiltes Service-Hosting Aufgabenstellung Diese Seite wird beim Druck durch die originale Aufgabenstellung ersetzt. Copyright TU Dresden, Philipp Grubitzsch III

4

5 Verteiltes Service-Hosting Erklärung Hiermit erkläre ich, Philipp Grubitzsch, die vorliegende Diplomarbeit zur Erlangung des akademischen Grades eines Diplom-Medieninformatikers zum Thema Storage API und verteiltes Service-Hosting XMPP-basierter Dienste selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben. Dresden, 31. Oktober 2013 Unterschrift Copyright TU Dresden, Philipp Grubitzsch V

6

7 Inhaltsverzeichnis Verteiltes Service-Hosting Inhaltsverzeichnis 1 Einleitung Motivation, Problem- und Zielstellung Aufbau der Arbeit Stand der Forschung und Technik Technische Grundlagen XMPP im Überblick Presence Roster und Rostergruppen Extension Protocols - XEPs Die Mobilis-Plattform Verwandte Arbeiten XMPP-basierte Multi-Agent Grid Computing Systeme XMPP-basierte Service und Cloud-Service-Systeme Zusammenfassung Anforderungsanalyse Anwendergruppen Anwendungsfälle Anforderungen Konzeption Mögliche Zielarchitekturen Idee: Sternförmige Netzarchitektur mit einem Coordinator Idee: Mobilis-P2P-Server-Architektur Detailbetrachtung des Rosterkonzepts Generelle Funktionsweise Roster als Service Registry Rostergruppen und initiale Konfiguration Algorithmen der Remote Service Registry Aufbau und Organisation des Kommunikationsprotokolls Deployment Service: Deployment-Protokoll Runtime Service: Runtime-Protokoll Coordinator Service: Coordinator-Protokoll Mobilis Service: Application-Protokoll Copyright TU Dresden, Philipp Grubitzsch VII

8 Verteiltes Service-Hosting Inhaltsverzeichnis 4.4 Storage API für verteilte Dienste SQLite Datenbank Externe MySQL Datenbank Implementierung Überblick über die Projektstruktur MobilisXMPP Der Mobilis-Server Die Klasse MobilisAgent Die Klasse RuntimeService Die Klasse CoordinatorService Wahl einer Runtime bei Create-Request Die Klasse DeploymentService Android-Clients: Am Beispiel Xhunt Remote Console Offene Aufgaben Evaluierung Funktion der verteilten Dienstlaufzeitumgebung Aufbau des Experiments Durchführung: 1. Teil Durchführung: 2. Teil Nutzen der verteilten Architektur Aufbau des Experiments Durchführung Erläuterung der aufgezeichneten Daten Ergebnisse und Interpretation Kosten der verteilten Architektur Aufbau Durchführung Ergebnisse und Interpretation Zusammenfassung der Evaluierung Zusammenfassung und Ausblick 99 A Abbildungen i B Listings vii Literaturverzeichnis xi VIII Copyright TU Dresden, Philipp Grubitzsch

9 Abbildungsverzeichnis Verteiltes Service-Hosting Abbildungsverzeichnis 2.1 Subscription Handshake vereinfachte Darstellung eines Discovery Trees Ablauf der In-Band Registration eines neuen Accounts Übersicht über aktuelle Architektur der Mobilis-Plattform [mob] Komponentenarchitektur von Mobilis im Detail [mob] Die Kernkomponenten der Runtime [Kie12] Generische Architektur für XMPP-basierte Many-Task-Computing-Systeme Cloudservice-Netzarchitektur [WSWW09] Asynchroner Methodenaufruf mit XMPP in [WSWW09] Architektur und Sessionaufbau bei Junction [BD11] Junction: wetube und weholdem Demoanwendungen [BD11] Anwendungsfälle in Mobilis Verteilung der Service Enviroment auf entfernte Runtimes Komponentenarchitektur der ersten Konzeptidee Getrennte Service Registry von zwei Mobilis 2.0 Servern Dienstsynchronisation der Service Registrierungen zweier Server Mobilis P2P-Server-Architektur Roster zur Verwaltung von Service Registry und Zugriffsberechtigungen Ablauf der allgemeinen Service Discovery Ablauf der speziellen Service Discovery Übersicht des Gesamtablaufs zum Erstellen von neuen Instanzen Teilprozess: Sammeln aller entfernten Runtimes, welche einen speziellen Dienst unterstützen Teilprotokolle mit ihren Endpunkten und Nachrichten Abblauf der Kommunikation bei Upload und Installation eines neuen Dienstes Problem und Lösung bei offline Synchronisation Nachrichtenverlauf beim Erstellen einer neuen Dienstinstanz Nachrichtenverlauf der Service Discovery Überblick über die wichtigsten Pakete der Implementierung Ausschnitt des Klassendiagramms des Mobilis-Servers Klassenstruktur der Remote-Service Registry Die Paketstruktur welche in das Android Projekt importiert werden muss 78 Copyright TU Dresden, Philipp Grubitzsch IX

10 Verteiltes Service-Hosting Abbildungsverzeichnis 6.1 Netzaufbau für das erste Experiment Leere Roster der beiden Runtimes mit den jeweils drei eigenen Ressourcen für Coordinator-, Runtime- und Deployment Service Beide Roster nach Subscription Handshake und Zuordnung zu srg:runtimes Beide Roster nach Installation des XHunt Dienstes Alice erstellt eine neue Instanz von Xhunt und tritt dieser bei Bob findet per Service Discovery Alices Instanz und tritt ihr bei Erweiterter Netzaufbau für das erste Experiment Verteilte Laufzeitumgebung für das 2. Experiment Mittlere Startzeit neuer Instanzen mit einer, zwei und drei Runtimes Aufbau des 3. Experiments in der maximalen Konfiguration Verteilte Laufzeitumgebung für das 2. Experiment A.1 Kommunikationsprotkoll gekapselt im MobilisXMPP-Projekt i A.2 Einstellungen der Konsole und Upload mit send-befehl i A.3 Nachrichtenverlauf des ersten Experimente am Coordinator von Runtime 1 ii A.4 Nachrichtenverlauf des ersten Experimente der XHunt-Instanz auf Runtime ii A.5 2. Teil v. Experiment 1: Die drei Roster von Runtime 1,2 und iii A.6 Maximaler Speicherverbrauch einer nicht mehr reagierenden Runtime... iii A.7 Vollständiger Graphs von Experiment iv A.8 Detailansicht des Graphs von Experiment v X Copyright TU Dresden, Philipp Grubitzsch

11 Tabellenverzeichnis Verteiltes Service-Hosting Tabellenverzeichnis 6.1 Anzahl der gestarteten Instanzen pro Konfiguration Skalierfaktor bei einer, zwei und drei Runtimes Copyright TU Dresden, Philipp Grubitzsch XI

12

13 Listingverzeichnis Verteiltes Service-Hosting Listingverzeichnis 2.1 Presence von Bobs Server an Alice Presence-probe von Bob an Alice Anforderung von Bobs Roster vom Server Bobs Roster Anfrage für alle assoziierten Items von example.com Antwort mit den Items Anfrage der unterstützten Features an conference.example.com Antwort mit den unterstützten Features von conference.example.com Nach XEP-0115 modifiziertes initiales Presence-Paket disco#info-anfrage mit Entity Capabilities disco#info Antwort mit Entity Capabilities zeigt welche Features der Verification String repräsentiert Anfrage einer neuen Account-Registrierung Server sendete erforderliche Anmeldefelder als Antwort Client sendet ausgefülltes Formular zu Server Server bestätigt erfolgreiche Account-Registrierung Feature-String einer Mobilis-Xhunt Instanz Entität Error IQ bei fehlender Nutzerautorisation Unveränderter Request an den Deployment Service Neuer Fehlertext als in Error IQ der Deployment Service Nachrichten Request zur Synchronisation Result bei erfolgreicher Synchronisation Error bei nicht erfolgter Synchronisation durch fehlende Autorisation Clientrequest zum Erzeugen einer neuen Dienstinstanz Leeres Result wird als IN BEARBEITUNG interpretiert Weiterleitung des Create-Requests an entfernte Runtime SendNewServiceInstance beinhaltet fulljid der neuen Instanz Leeres Result als Empfangsbestätigung von SendNewServiceInstance Weitergeleitetes SendNewServiceInstance an den ursprünglichen»requestor« Anhängen der Feature-Strings an eine Mobilis Entität Prüfung der Autorisation durch Abruf von Rostergruppen Abruf der Features in der Methode inmobilisservicediscovery() Verarbeitung der Features in der Methode inmobilisservicediscovery().. 75 Copyright TU Dresden, Philipp Grubitzsch XIII

14 Verteiltes Service-Hosting Listingverzeichnis 5.5 Auswahl einer entfernten Runtime bei einem Create-Request Prüfung der Zugriffsberechtigung in der Methode processpacket() Allgemeine Service Discovery-Anfrage an Runtime Service Discovery-Anfrage für Namespace von NineCards an Runtime B.1 In-Band Registration mit Data Forms: Server sendet Formular mit erforderlichen Feldern vii B.2 In-Band Registration mit Data Forms: Nutzer sendet ausgefülltes Formular zum Server vii B.3 SynchronizeRuntimes vom Typ Get mit Service JIDs als Payload von Runtime 1 an Runtime 2 gesendet viii B.4 SynchronizeRuntimes vom Typ Result auf Get-Request mit Service JIDs als Payload viii B.5 Request: Manuelles Ausführen der Synchronisation durch sync Befehl... viii B.6 Response: Befehl zur Synchronisation wurde empfangen viii B.7 Datensatz mit 3 Runtimes: Die letzten Einträge der Aufzeichnung..... ix XIV Copyright TU Dresden, Philipp Grubitzsch

15 Abkürzungsverzeichnis Verteiltes Service-Hosting Abkürzungsverzeichnis API BOSH CPU CSV DNS GUI HTTP ID IETF IP IQ IRC JAR JDBC JID JSON MAS MSDL MUC NFC P2P QR REST RFID Application Programming Interface Bidirectional-streams Over Synchronous HTTP Central Processing Unit Comma-separated values Domain Name System Graphical User Interface Hypertext Transfer Protocol Identifier Internet Engineering Task Force Internet Protocol Info / Query Internet Relay Chat Java Archive Java Database Connectivity Jabber Identifier JavaScript Object Notation Multi-Agent System Mobilis Service Description Language Multi User Chat Near field communication Peer-to-Peer Quick Response Code Representational State Transfer Radio-Frequency Identification Copyright TU Dresden, Philipp Grubitzsch XV

16 Verteiltes Service-Hosting Abkürzungsverzeichnis SMS SOAP TCP UDDI URI URL URN VM WSDL XEP XML XMPP Short Message Service Simple Object Access Protocol Transmission Control Protocol Universal Description, Discovery and Integration Uniform resource identifier Uniform Resource Locator Uniform Resource Name Virtuelle Maschine Web Services Description Language XMPP Extension Protocol Extensible Markup Language Extensible Messaging and Presence Protocol XVI Copyright TU Dresden, Philipp Grubitzsch

17 1 Einleitung Verteiltes Service-Hosting 1 Einleitung Mobile, kollaborative Anwendungen sind bedingt durch immer schnellere und weiter verbreitete mobile Netze und Netztechnologien sowie stark wachsende Verbreitung von mobilen Endgeräten stark im Kommen. Allein in den letzten dreieinhalb Jahren ist der Anteil von Smartphones in Deutschland von 16.5 % auf fast 60 % gestiegen [Sta13]. Setzt sich dieser Trend fort, was sehr zu erwarten ist, dann wird die potentielle Nutzeranzahl für solche Anwendungen weiter stark steigen. Bereits heute finden sich Nutzer virtuell trotz großer geografischer Distanzen, aber auch lokal zusammen, um gemeinsam zu arbeiten, zu spielen und zu kommunizieren. Man denke dabei an die typischen sozialen Treffpunkte wie Dienstberatungen, Schulhöfe, Kantinen, Sportstätten oder auch der gemeinsame Abend mit Freunden. Für all diese Konstellationen ergeben sich auch zusammen mit den vor Ort vorhandenen Peripheriegeräten völlig neue Möglichkeiten der sozialen Kollaboration. War noch vor knapp einem Jahrzehnt das Hauptkommunikationsgerät des digitalen Zeitalters der Heimcomputer mit einem einzigen weitverbreiteten Betriebssystem, so sieht man sich seit ein paar Jahren mit einem zunehmend heterogenen Feld an verschiedensten End- und Peripheriegeräten konfrontiert. Vor allem im stark wachsenden Smartphoneund Tablet-Sektor haben sich mit Google Android und Apple ios neben einer Vielzahl weniger verbreiteter Systeme [IDC13] zwei voneinander größtenteils unabhängige Ökosysteme entwickelt. Dies kann eine Barriere darstellen, will man als Nutzer von System A mit einem Nutzer von System B kollaborieren, da beide Systeme möglicherweise eigene proprietäre Protokolle und Schnittstellen nutzen. Infolgedessen steigt für Entwickler der Aufwand, ihre Anwendungen auf einer breiten Anzahl von Systemen bereitzustellen. Mit Mobilis wurde aufbauend auf der Infrastruktur von XMPP eine Dienstplattform geschaffen, welche es Entwicklern ermöglicht, kollaborative Anwendungen als Serverdienste für eine Client-Server-Architektur zu entwickeln [AS13]. Die Plattform bringt ein Framework mit, mit dessen Hilfe automatisch Code-Stubs für den Serverdienst sowie die Clientanwendung für unterschiedliche Zielplattformen generiert werden können. Grundlage dafür ist, dass alle Clients dasselbe anwendungsspezifische Kommunikationsprotokoll auf Basis von XMPP nutzen. 1.1 Motivation, Problem- und Zielstellung Die Mobilis-Architektur in ihrer bisherigen Form spielt ihre Stärken vor allem während des Entwicklungsvorgangs aus. Abgesehen davon, dass es sich bei Mobilis um ein Forschungsprojekt handelt, ist es von einem Produktivsystem besonders deswegen noch weit Copyright TU Dresden, Philipp Grubitzsch 1

18 Verteiltes Service-Hosting 1.2 Aufbau der Arbeit entfernt, weil es bestimmte Anforderungen der Skalierbarkeit bei großen Nutzerzahlen nicht erfüllt. Auch Sicherheitseigenschaften bei der Verwaltung des Servers und der auf dem Server installierten Dienste werden bisher praktisch nicht unterstützt. Gerade dadurch sind sind Nutzungsszenarien mit unterschiedlichen Beteiligten aktuell kaum möglich, da zum Beispiel keine Unterscheidung zwischen Serverbetreiber, Dienstanbieter und Dienstentwickler sowie deren jeweiligen Rechten gemacht werden kann. Das Hauptziel dieser Diplomarbeit ist es daher, die Ein-Server-Architektur von Mobilis in eine verteilte Multi-Server-Architektur umzugestalten, um eine horizontale Skalierung der Leistung der Gesamtarchitektur zu ermöglichen. Die Leistung ließe sich dann auch bei steigender Nutzerzahl kostengünstig steigern. Da durch ein verteiltes System auch Szenarien mit unterschiedlichen Serverbetreibern möglich werden, soll die Architektur in diesem Zuge auch um Sicherheitseigenschaften erweitert werden, die auch weitere Beteiligte wie Dienstanbieter, Dienstentwickler usw. abdeckt. 1.2 Aufbau der Arbeit In Kapitel 2 werden zuerst die technischen Grundlagen für die Weiterentwicklung der Mobilis-Architektur und anschließend ausgewählte verwandte Arbeiten im Bereich der verteilten XMPP-Systeme vorgestellt. Eine kurze Anforderungsanalyse in Kapitel 3 bildet die Grundlage für das in Kapitel 4 folgende Konzept. Ein Überblick über wichtige Implementierungsmerkmale der Konzeption wird in Kapitel 5 gegeben. Die Evaluierung in Kapitel 6 zeigt anhand von drei durchgeführten Experimenten, dass die neue Architektur die an sie gestellten funktionalen Anforderungen erfüllt. Außerdem wird untersucht, ob durch die nun mögliche horizontale Skalierung ein Leistungsvorteil des Gesamtsystems gegenüber einem bisherigen einzelnen Mobilis-Server erreicht wird. Abschließend wird in Kapitel 7 die in der Arbeit erbrachte Leistung kurz zusammengefasst und ein Ausblick für die Weiterentwicklung der Mobilis-Architektur gegeben. 2 Copyright TU Dresden, Philipp Grubitzsch

19 2 Stand der Forschung und Technik Verteiltes Service-Hosting 2 Stand der Forschung und Technik Dieses Kapitel soll einerseits die technischen Grundlagen zum Verständnis des Konzepts schaffen und andererseits einen Überblick der für die Problemstellung relevanten verwandten Arbeiten geben. 2.1 Technische Grundlagen In den folgenden Abschnitten wird eine kurze Einführung in XMPP und einige für die Mobilis-Architektur und das Konzept wichtige Erweiterungen gegeben XMPP im Überblick Das Extensible Messaging and Presence Protokoll (XMPP) ist ein quelloffenes, erweiterbares Kommunikationsprotokoll, welches ursprünglich unter dem Namen Jabber für Instant-Messaging entwickelt wurde und seit 2004 von der IETF unter dem heutigen Namen standardisiert ist [SAST09][PSA04]. Das Protokoll baut auf einer dezentralisierten Client-Server-Architektur auf. Im Gegensatz zum Web ist der Nachrichtenaustausch auch zwischen Servern üblich. Die Server können dabei auch unterschiedlichen Domänen angehören. Die Adressierbarkeit von Entitäten im Netzwerk basiert auf dem Domain Name System (DNS) und einer XMPP-Adresse, welche Jabber-ID (JID) genannt wird. Sie ähnelt einer -Adresse, welche ebenfalls auf DNS basiert. Eine JID»user1@example.com/device1«besteht aus dem Nutzername»user1«, der DNS- Serveradresse»example.com«und einer eindeutigen Anmelderessource. Letztere ermöglicht es, einen Nutzeraccount mit mehreren angemeldeten Geräten gleichzeitig zu verwenden. Eine JID ohne Ressource wird auch Bare-JID genannt. Die volle JID inklusive Ressource nennt man Full-JID [SAST09]. Will ein Client eine XMPP-Sitzung starten, wird zuerst eine langlebige TCP-Verbindung zum Server aufgebaut. Als nächstes handeln Server und Client jeweils einen XML-Stream zum jeweils anderen Kommunikationspartner aus. Über diese Streams werden beliebig viele XML-Schnipsel, sogenannte XML-Stanzas ausgetauscht. Sie stellen die Nachrichten auf der XMPP-Protokollschicht dar. Man unterscheidet drei Arten von Stanzas, die von Servern und Clients unterschiedlich behandelt werden: message-stanzas werden hauptsächlich für Menschenlesbaren Text wie Chatnachrichten verwendet und nach dem Fire-and-Forget Prinzip verschickt, da sie keine Antwort bedingen. Copyright TU Dresden, Philipp Grubitzsch 3

20 Verteiltes Service-Hosting 2.1 Technische Grundlagen presence-stanzas sind zum Verbreiten der Verfügbarkeit eines Clients im Netzwerk sowie für die vorherige Subscription vorgesehen Ein Info/Query-Stanza (IQ) implementiert einen Request-Response-Mechanismus und kann somit sicherstellen, ob eine Nachricht übertragen wurde. Das IQ-Stanza gibt es in den vier Typen: get, set, result und error. Mit»get«werden Informationen vom Empfänger abgerufen, und mit»set«werden Änderungen bei Empfänger angefordert. Die Antwort des Empfängers an den Absender ist im Normalfall ein»result«oder im Fehlerfall ein»error«. Alle Arten von Stanzas teilen zur Identifikation der beteiligten Entitäten und zum Routing der Nachrichten durch das XMPP-Netzwerk einige Standardattribute: from - die Absender-JID to - die Empfänger-JID id - Optional zur eindeutigen Identifikation von einzelnen oder zusammengehörigen Nachrichten type - Unterscheidung der Aufgaben eines Stanzas. Bei IQ-Stanza z.b. Typen: get, set usw Presence Für Instant Messaging ist es nützlich zu wissen, wer gerade online ist. Bei Webprotokollen wie HTTP wurde dazu in der Vergangenheit ein Pull-Mechanismus, der auch Polling genannt wird, genutzt. Dieser erfordert kontinuierlich Bandbreite und Serverprozesszeit. Mittlerweile gibt es auch für HTTP bessere Push-basierte Ansätze [SL11]. Für XMPP wurde von Anfang an ein Push-basierter Ansatz entwickelt. Diese Technologie wird Presence genannt und ist integraler und sogar namensgebender Bestandteil von XMPP und eine Spezialform von XEP-0060: Publish-Subscribe [SAST09][PSA04][PM10]. Das wichtigste Element für das Verbreiten der eigenen Präsenz ist das bereits in Abschnitt vorgestellte <presence>-stanza. Damit Nutzer sich gegenseitig ihren Status bekannt geben können, müssen sie zunächst einen Subscription Handshake durchführen. Dieser Vorgang gewährleistet, dass sich zwei XMPP-Nutzer erlauben, gegenseitig ihren Online-Status mitzuteilen. Der Vorgang wird durch einen der beiden Nutzer initiiert, indem wie in Abbildung 2.1 gezeigt, die Nutzerin Alice ein presence-stanza von Typ»subscribe«an den Nutzer Bob sendet. Erlaubt Bob die Anfrage, dass Alice seinen Status sieht, dann antwortet er mit einem presence-stanza vom Typ»subscribed«. Anschließend wiederholt sich der Vorgang mit umgekehrten Rollen, wenn Bob auch Alice Status sehen möchte. Die Verbreitung von Presence, wenn ein Nutzer»Bob«online kommt, läuft folgendermaßen ab: Nach dem Aufbau des XML-Streams zwischen Client und Server, sendet 4 Copyright TU Dresden, Philipp Grubitzsch

21 2 Stand der Forschung und Technik Verteiltes Service-Hosting Abbildung 2.1: Subscription Handshake der Client von Bob ein initiales <presence/>-stanza 1 an seinen Server. Dieser fügt dem presence-stanza die Full-JID mit der verbundenen (gerade online gekommenen) Ressource in Form eines from-attributs an und sendet es an alle Nutzer aus Bobs Roster, welche eine Subskription von Bob haben. Dazu wird die Bare-JID des jeweiligen Nutzers als Wert eines to-attributs angehängt. Listing 2.1 zeigt beispielhaft wie das presence- Stanza von Bob an Alice aussieht: 1 <presence 2 from="bob@example.com/mobile" 3 to="alice@example.com"/> Listing 2.1: Presence von Bobs Server an Alice Damit Bob weiß, ob Alice online ist, sendet Bobs Server außerdem ein presence-stanza vom Typ»probe«(Vgl. Listing 2.2) an den Server von Alice. Ihr Server prüft, ob Bob dazu berechtigt ist, Alice Status zu sehen und schickt Bob dann eine presence-stanza mit ihrem jeweiligen Status. 1 <presence 2 from="bob@example.com/mobile" 3 to="alice@example.com" 4 type="probe"/> Listing 2.2: Presence-probe von Bob an Alice Für den Fall, dass Alice offline ist, kann das Antwort-Stanza vom Typ»unavailable«zusätzlich noch ein <delay>-tag enthalten, was darüber Auskunft gibt, wann Alice das letzte Presence-Stanza vom Typ»unavailable«gesendet hat. Das»unavailable«- Presence-Stanza sendet Bobs Client dem Server auch, wenn er offline geht. Der eben beschriebene Broadcast-Vorgang wird für alle Nutzer im eigenen Roster angewendet. Möchte man Presence-Informationen auch einem Nutzer mitteilen, der nicht im Roster ist, können diesem auch direkt Presence-Nachrichten gesendet werden. Man nennt diesen Fall auch Directed Presence [SAST09]. 1 Dieses Stanza gilt als das kleinste XMPP-Stanza Copyright TU Dresden, Philipp Grubitzsch 5

22 Verteiltes Service-Hosting 2.1 Technische Grundlagen Neben available (Einfaches presence) und unavailable gibt es, wenn der Nutzer online ist, noch vier weitere vordefinierte Verfügbarkeitszustände, welche über das Presence-Stanza versendet werden können: chat soll die Bereitschaft oder aktive Suche für eine Chatsitzung bekannt geben away gibt an, dass der Nutzer gerade abwesend ist xa steht für»extended away«und bedeutet, dass der Nutzer für längere Zeit nicht erreichbar sein wird dnd ist die Abkürzung für»do not disturb«und bedeutet, dass der Nutzer zwar erreichhbar ist, aber nicht gestört werden will. Diese werden nicht als type-attribut mitgegeben, sondern in einem separaten Tag- Element <show/> gekapselt. Darüber hinaus kann zusätzlich ein beliebiger für Menschen besser lesbarer Informationstext für den aktuellen Zustand in dem Tag <status> angehängt werden. Das <status>-tag kann auch zum Verbreiten von erweiterten Presence-Informationen ohne das <show>-tag genutzt werden. In [SAST09] wird als Beispiel genannt, dass ein Client darüber die Musik, die der Nutzer gerade hört, anderen mitteilen könnte. Ein weiteres Beispiel könnte sein, dass Rechnerknoten oder Dienstagenten ihren aktuellen Auslastungszustand darüber mitteilen. Da es mit XMPP möglich ist, sich mit einem Account mit mehreren Geräten gleichzeitig anzumelden, ist es sinnvoll, dass bestimmte Nachrichten nur an bestimmte Geräte geroutet werden. Dazu kann das Tag <priority> verwendet werden. Der Wert dieses Tags darf im Bereich -128 bis 128 liegen. Je höher die Priorität eines am Netzwerk angemeldeten Geräts, desto eher wird ihn eine Nachricht erreichen, welche nur an die Bare-JID des Accounts gerichtet ist. Ist der Wert negativ, so kann das angemeldete Gerät nur mit seiner Full-JID erreicht werden Roster und Rostergruppen Zum Speichern der Subscription-Informationen eines Nutzers wird üblicherweise der Roster verwendet. Dieser ist eine Repräsentation aller Kontakte mit denen ein Subscription Handshake durchgeführt wurde oder bei denen noch unbeantwortete Subscription- Requests ausstehen. Der Roster wird vom Client verwaltet und ist meist als Kontaktliste implementiert. Gespeichert wird der Roster aber auf dem XMPP-Server, bei dem der Nutzer seinen Account erstellt hat. Meldet sich der Nutzer bei seinem XMPP-Server an, muss der Roster erst zum Client übertragen werden. Dazu sendet der Client ein Request-IQ vom Typ»get«an den Server: 1 <iq from="bob@example.com/mobile" 2 id="f4s67821" Listing 2.3: Anforderung von Bobs Roster vom Server 6 Copyright TU Dresden, Philipp Grubitzsch

23 2 Stand der Forschung und Technik Verteiltes Service-Hosting 3 to="bob@example.com" 4 type="get"> 5 <query xmlns="jabber:iq:roster"/> 6 </iq> Das to-attribut muss die Bare-JID des Nutzers sein, da der Server den Request in dessen Namen verarbeitet [SAST09]. Nachrichten zwischen Client und Server, die den Roster betreffen, enthalten immer das <query>-tag mit dem XML-Namespace jabber:iq:roster. Der Server holt den Roster des entsprechenden Nutzer aus der eigenen Datenbank und hängt ihn an das result-iq in folgender Form an: 1 <iq from="bob@example.com" 2 id="f4s67821" 3 to="bob@example.com/mobile" 4 type="result"> 5 <query xmlns="jabber:iq:roster"> 6 <item jid="alice@example.com" 7 name="alice" 8 subscription="both"> 9 <group>friends</group> 10 </item> 11 <item jid="charlie@test.de" 12 name="charlie Harper" 13 subscription="from"> 14 <group>friends</group> 15 <group>work</group> 16 </item> 17 </query> 18 </iq> Listing 2.4: Bobs Roster Jedes item repräsentiert einen Rostereintrag bzw. Kontakt und wird mit dem obligatorischen jid-attribut in Form der Bare-JID angegeben. Dies ist die Minimalkonfiguration der Items. Um die Darstellung des Rosters übersichtlicher zu machen, gibt es eine Reihe weiterer optionaler Attribute und Tags. Der Wert des Attributs»subscription«gibt den Zustand der Presence-Autorisation zwischen dem Nutzer des Rosters und dem Kontakt an. Mögliche Werte sind hier none, both, from und to. Das Attribut name ist zur alternativen Darstellung des Kontakts anstelle der JID gedacht. Um Einträge im eigenen Roster besser organisieren zu können, kann man diese Rostergruppen zuordnen. Die Gruppen, denen ein Kontakt zugeordnet ist, werden durch zusätzliche <group>-tags innerhalb eines <item> angegeben. Wird der Roster an einem Client des Nutzers geändert, dann schickt dieser Client ein IQ von Typ set zum Server. Dabei wird nur das geänderte <item> übertragen. Der Server leitet diesen Request an alle verbundenen Clients des Nutzers weiter, wodurch die Synchronität des Rosters auf allen Clients gewährleistet wird Extension Protocols - XEPs Eine weitere integrale ebenfalls namensgebende Eigenschaft von XMPP ist die Erweiterbarkeit. Eine Erweiterung wird als XMPP Extension Protocol, kurz XEP bezeichnet. Zum Zeitpunkt der Anfertigung dieser Diplomarbeit sind insgesamt 333 verschiedene Copyright TU Dresden, Philipp Grubitzsch 7

24 Verteiltes Service-Hosting 2.1 Technische Grundlagen Erweiterungen vorgeschlagen worden. Ihr aktueller Entwicklungsstand kann in [xep] eingesehen werden. Viele der vorgeschlagenen XEPs sind aber mittlerweile veraltet, obsolet oder wurden abgelehnt. Im folgenden werden einige für diese Arbeit wichtige XEPs vorgestellt. XEP-0030: Service Discovery In einem XMPP-Netzwerk können viele sehr verschiedenartige Entitäten miteinander kommunizieren. Deren Heterogenität ist bestimmt durch ihr Auftreten im Netzwerk als Server, Client, Bot, Multi-User-Chat usw., aber auch durch ihre Implementation, Konfiguration und ihre unterstützten Funktionen. Sucht man als Nutzer eine Entität die eine bestimmte Eigenschaft unterstützt oder möchte die unterstützten Funktionen einer Entität wissen, dann ist die XEP-0030: Service Discovery das richtige Werkzeug, um zum Ziel zu gelangen [SAST09][JH08b]. Eine Entität muss nach der Spezifikation drei Informationen über sich liefern können: 1. Die eigene Identität nach Kategorie und Typ 2. Ihre unterstützten Features (Eigenschaften und Protokolle) 3. Weitere mit ihr assoziierte Entitäten Dadurch dass eine Entität weitere assoziierte Entitäten 2 haben kann, wird ein Baum aufgespannt. Die Wurzel des Baums ist die angesprochene Entität selbst. Die Knoten des Baums sind weitere assoziierte Entitäten (welche wiederum eigene Discovery-Bäume aufspannen), und die Blätter repräsentieren die Features und Identitäten der aktuell angesprochenen Entität. Abbildung 2.2 links zeigt beispielhaft den vereinfachten Discovery Tree eines XMPP-Servers example.com. Um in diesem Baum zu navigieren bzw. zu suchen, gibt es zwei unterschiedliche <query>-methoden: disco#items: für die Suche nach weiteren assoziierten Entitäten einer angesprochenen Entität (oft ein XMPP-Server oder -Dienst), liefert im result-iq <item>- Elemente mit einem obligatorischen jid-attribut und optialem node- bzw. name- Attribut. disco#info: zum Abruf der unterstützen Funktionen einer Entität liefert als result- IQ <feature>-elemente und eine oder mehrere Identitäten in Form von <identity>- Tags. Ein kurzes Anwendungsbeispiel soll anhand der Abbildung 2.2 veranschaulichen, wie eine Service Discovery ablaufen könnte. Bob möchte ausgehend von seinem verwendeten XMPP-Server»example.com«einen Multi-User-Chat (MUC) finden. Seinem Client ist bekannt, dass ein MUC durch den Namespace» Die assoziierten Entitäten müssen in irgendeiner Weise unter der Kontrolle der Parent-Entität stehen [JH08b]. 8 Copyright TU Dresden, Philipp Grubitzsch

25 2 Stand der Forschung und Technik Verteiltes Service-Hosting Abbildung 2.2: vereinfachte Darstellung eines Discovery Trees beschrieben ist. Zuerst sendet Bobs Client ein IQ-get mit einem Query vom Typ disco#items: Listing 2.5: Anfrage für alle assoziierten Items von example.com 1 <iq from="bob@example.com/mobile" 2 id="n5432x21" 3 to="example.com" 4 type="get"> 5 <query xmlns=" 6 </iq> Als Antwort bekommt er vom Server eine Auflistung aller assoziierten Entitäten in <item>-tags gekapselt: Listing 2.6: Antwort mit den Items 1 <iq from="example.com" 2 id="n5432x21" 3 to="bob@example.com/mobile" 4 type="result"> 5 <query xmlns=" 6 <item jid="conference.example.com"/> 7 <item jid="notify.example.com"/> 8 </query> 9 </iq> Diese Entitäten fragt er nun wiederum einzeln mit einem Query vom Typ disco#info an. Abbildung 2.2 rechts zeigt die den Discovery Tree der Entität»conference.example.com«an welche eine der beiden Queries gerichtet ist: Copyright TU Dresden, Philipp Grubitzsch 9

26 Verteiltes Service-Hosting 2.1 Technische Grundlagen Listing 2.7: Anfrage der unterstützten Features an conference.example.com 1 <iq from="bob@example.com" 2 id="k23k46s7" 3 to="conference.example.com" 4 type="get"> 5 <query xmlns=" 6 </iq> Als Antwort von conference.example.com bekommt er: Listing 2.8: Antwort mit den unterstützten Features von conference.example.com 1 <iq from="conference.example.com" 2 id="k23k46s7" 3 to="bob@example.com/mobile" 4 type="result"> 5 <query xmlns=" 6 <identity category="conference" type="text" name="chatrooms"/> 7 <feature var=" 8 <feature var="jabber:iq:register"/> 9 <feature var="vcard-temp"/> 10 </query> 11 </iq> Bobs Client weiß nun anhand des entsprechenden Feature-Tags, dass diese Entität MUC- Fähigkeiten besitzt. Im Normalfall wird mit einer Anfrage nicht der gesamte Baum aus allen Entitäten durchlaufen, sondern nur die ersten Ebenen. Bob könnte den Baum weiter in die Tiefe durchsuchen und würde in der nächsten Ebene zum Beispiel die verschiedenen Chaträume des MUC und danach die verbundenen Clients eines Chatraums als Items per Service Discovery abrufen können. XEP-0115: Entity Capabilities Der in Abschnitt vorgestellte Mechanismus der Service Discovery birgt einen entscheidenden Nachteil: Er erzeugt sehr viel Netzwerk-Traffic. Besonders ungünstig ist dies wenn [SAST09]: 1. eine Entität wie ein einfacher Messenger-Client bereits sehr viele Features unterstützt und dadurch viele Zeichen lange Namespaces übertragen werden müssen 2. ein Kontakt mit vielen Ressourcen gleichzeitig verbunden ist und somit diese Informationen von vielen Entitäten abgerufen werden sollen 3. das Ganze auch noch mit allen Kontakten eines sehr großen Rosters geschehen soll Um den übermäßigen Netzwerkverkehr einzudämmen, wurde die Erweiterung XEP-0115: Entity Capabilities geschaffen [JH08a]. Sie funktioniert wie ein Abkürzungs- und Cachingmechanismus für die durch die Service Discovery übertragenen Informationen. Als Transportmittel werden die Presence-Pakete, die jeder Client bei der Anmeldung versendet, verwendet. Dazu wird in das <presence>-tag ein zusätzliches <c>-tag mit 10 Copyright TU Dresden, Philipp Grubitzsch

27 2 Stand der Forschung und Technik Verteiltes Service-Hosting folgenden Attributen eingeschlossen. Kommt ein Kontakt von Alice online, so erhält ihr Client ein modifiziertes Presence-Paket 3 : Listing 2.9: Nach XEP-0115 modifiziertes initiales Presence-Paket 1 <presence from= bob@example.com/mobile > 2 <c xmlns= 3 hash= sha-1 4 node= 5 ver= QgayPKawpkPSDYmwT/WM94uAlu0= /> 6 </presence> Das node-attribut gibt Auskunft, welche Client-Software von Bob verwendet wird. Das Attribut ver ist ein Verification String, welcher mit dem Hash-Algorithmus»sha-1«angegeben im hash-attribut aus den unterstützten Features (genauer gesagt den Namespaces) erstellt wurde. Beim ersten Kontakt mit diesem Verification String hat die empfangende Entität des Presence-Pakets keine Ahnung, was dieser bedeutet. Darum sendet der empfangende Client, hier»alice@example.com/pc«ein Service Discovery-Query disco#info wie in Abschnitt vorgestellt, aber mit dem zusätzlichen node-attribut, an welches durch»#«getrennt noch der Verification String angehängt wird: Listing 2.10: disco#info-anfrage mit Entity Capabilities 1 <iq from= alice@example.com/pc 2 id= disco1 3 to= bob@example.com/mobile 4 type= get > 5 <query xmlns= 6 node= /> 7 </iq> Wie in Abschnitt vorgestellt, antwortet der Client von Bob nun mit einem Result, welches sämtliche Features von Bobs Client enthält, und auch dieses wird um das node- Attribut mit dem Verification String erweitert: Listing 2.11: disco#info Antwort mit Entity Capabilities zeigt welche Features der Verification String repräsentiert 1 <iq from= bob@example.com/mobile 2 id= disco1 3 to= alice@example.com/pc 4 type= result > 5 <query xmlns= 6 node= > 7 <identity category= client name= Exodus type= pc /> 8 <feature var= /> 9 <feature var= /> 10 <feature var= /> 11 <feature var= /> 12 </query> 13 </iq> 3 Die Codebeispiele in diesem Abschnitt wurden der offiziellen Spezifikation (Quelle: [JH08a]) entnommen und entsprechend der bisherigen Beispiele angepasst. Copyright TU Dresden, Philipp Grubitzsch 11

28 Verteiltes Service-Hosting 2.1 Technische Grundlagen Alice Client weiß nun, welche Features der Verification String repräsentiert. Clients, die Entity Capabilities unterstützen, cachen diese Informationen. Beim nächsten Erhalt des selben Strings müssen keine Services Discovery-Queries mehr versendet werden. XEP-0077: In-Band Registration Bevor ein Nutzer Nachrichten mit anderen XMPP-Nutzern austauschen kann, muss er üblicherweise zunächst einen Account auf einem XMPP-Server anlegen. Dies kann zum Beispiel manuell durch einen Administrator geschehen, welcher den Nutzeraccount direkt am Server anlegt oder als Out-of-Band-Registrierung über ein Formular einer Webseite durchgeführt werden. Der für den Nutzer bequemere und technisch elegantere Weg ist die Registrierung über den Messenger-Client unter Verwendung des XMPP-Protokolls zwischen Server und Client. Ursprünglich war die In-Band Registration bereits im Jabber- Protokoll enthalten, wurde aber bei der Spezifizierung von XMPP nicht berücksichtigt. Daher wurde sie als XEP-0077 wieder eingeführt [SA12]. Abbildung 2.3: Ablauf der In-Band Registration eines neuen Accounts Die Grundfunktionalität der XEP-0077 gewährleistet das Registrieren eines Accounts, das Löschen eines bestehenden Accounts und das Ändern des Passworts eines Accounts, bei einem XMPP-Server. In diesem Abschnitt soll nur der für das Konzept relevante, Registriervorgang detailliert erläutert werden. Für die anderen Anwendungsfälle bzw. Fehlerfälle kann die Spezifikation der XEP eingesehen werden. Der grundlegende Kommunikationsablauf zum Registrieren eines Accounts ist in Abbildung 2.3 dargestellt. 1. Der Registriervorgang wird durch ein IQ-get vom Client eingeleitet. Alle Nachrichten bezüglich der In-Band Registration enthalten dabei ein <query>-tag mit dem XML-Namespace jabber:iq:register: Listing 2.12: Anfrage einer neuen Account-Registrierung 1 <iq type= get id= reg1 to= example.com > 2 <query xmlns= jabber:iq:register /> 12 Copyright TU Dresden, Philipp Grubitzsch

29 2 Stand der Forschung und Technik Verteiltes Service-Hosting 3 </iq> 2. Der Server antwortet im Idealfall mit einem IQ-result, welches die erforderlichen Formularfelder für die Registrierung enthält: Listing 2.13: Server sendete erforderliche Anmeldefelder als Antwort 1 <iq type= result id= reg1 > 2 <query xmlns= jabber:iq:register > 3 <instructions> 4 Bitten geben Sie einen Benutzername, ein Passwort 5 und ihre adresse an. 6 </instructions> 7 <username/> 8 <password/> 9 < /> 10 </query> 11 </iq> Unterstützt der Server die XEP-0077 nicht, so antwortet er mit einem <serviceunavailable>-error. Für den Fall, dass der Nutzer bereits registriert ist, so sendet der XMPP-Server ein Result mit den Tag <registered> und in weiteren Tags gekapselt dessen Account-Daten. 3. Nachdem der Nutzer die benötigten Informationen bereitgestellt hat, überträgt sein Client diese in einem IQ-set zum Server. Listing 2.14: Client sendet ausgefülltes Formular zu Server 1 <iq type= set id= reg2 > 2 <query xmlns= jabber:iq:register > 3 <username>bob</username> 4 <password>bobs_password</password> 5 < >bobby@yahoo.com</ > 6 </query> 7 </iq> 4. Der Server antwortet zur Bestätigung mit einem result und der zugehörigen ID. Listing 2.15: Server bestätigt erfolgreiche Account-Registrierung 1 <iq type= result id= reg2 /> Sollte der Benutzername bereits vergeben sein oder eine erforderliches Informationsfeld aus 2. nicht ausgefüllt sein, so antwortet der Server an dieser Stelle mit einem entsprechenden error, statt des result. Für komplexere Formulardaten empfiehlt die Spezifikation [SA12] auf die XEP-0004: Data Forms nach [RE07] zurück zu greifen. Der obligatorische XML-Namepace jabber:iq:register wird dabei als Wert eines»hidden fields«in das Data Form eingeschlossen. Ein Beispiel für die alternative Verwendung der Data Forms bei Listing 2.13 und 2.14 ist als Anhang unter B.1 und B.2 zu finden. Weiterhin wird empfohlen, die In- Band Registration nur bei verschlüsselten XMPP-Streams zu verwenden, da Copyright TU Dresden, Philipp Grubitzsch 13

30 Verteiltes Service-Hosting 2.2 Die Mobilis-Plattform Abbildung 2.4: Übersicht über aktuelle Architektur der Mobilis-Plattform [mob] mit ihr z.b. Passwörter im Klartext übertragen werden. Ob ein Server In-Band Registration unterstützt, kann er auch über die Service Discovery wie in Abschnitt vorgestellt, bekannt geben. Dazu gibt er dem Result einer Anfrage das Feature <feature var= jabber:iq:register /> mit. 2.2 Die Mobilis-Plattform Mobilis ist ein Forschungsprojekt für eine kollaborative, cross-plattformfähige Dienstlaufzeitumgebung auf Basis von XMPP an der TU Dresden [AS13][mob]. Abbildung 2.4 zeigt den Stand der Architektur der Mobilis-Plattform bei Beginn dieser Arbeit. Zur besseren Unterscheidung der alten und der in dieser Arbeit weiterentwickelten Architektur soll der alte Stand im Folgenden Mobilis 2.0 genannt werden. Dieser Stand basiert vor allem auf den Arbeiten von Danny Kiefner und Robert Lübke und kann in ihren Arbeiten sowie im Projekt-Wiki des GitHub-Repository detailliert nachgelesen werden [Kie12][Lü11][mob]. Dennoch soll zum besseren Verständnis hier eine kurze Zusammenfassung der für diese Arbeit relevanten Komponenten erfolgen. Eine Mobilis-Anwendung besteht immer aus einem serverseitigem Dienst und einer Clientanwendung, welche diesen Dienst nutzt. Der Client kann für verschiedene Plattformen implementiert sein. Aktuell werden durch das Mobilis-Entwickler-Framework Clients auf Basis von Android, ios, Java Desktop und dem Web unterstützt. Wie in der Übersicht in 2.4 zu sehen, ist in der Netzarchitektur zur Zeit nur ein einziger zentralen Server, der Mobilis-Server vorgesehen. Dieser bringt eine Laufzeitumgebung für die Dienste und eine 14 Copyright TU Dresden, Philipp Grubitzsch

31 2 Stand der Forschung und Technik Verteiltes Service-Hosting Service Discovery mit, über die Clients die von einem Mobilis-Server angebotenen Dienste finden und binden können. Die Kommunikation erfolgt über ein XMPP-Netzwerk. Der erforderliche XMPP-Server läuft meist auf dem selben physischen Computer wie der Mobilis-Server. Abbildung 2.5: Komponentenarchitektur von Mobilis im Detail [mob] Die Komponentenarchitektur ist in Abbildung 2.5 dargestellt. Der Mobilis-Server ist eine in Java programmierte Anwendung. Die Basis bilden die XMPP-Bibliothek Smack [ign] und die von Robert Lübke entwickelte Mobilis Bean-Komponente. Sie ist als eigenes Projekt MobilisXMPP implementiert und kapselt das gesamte Kommunikationsprotokoll zwischen Client und Server auf der Runtime-Schicht. Mit MobilisXMPP werden IQ- Nachrichten zwischen Client und Server als wiederverwendbare Java-Klassen bereitgestellt. Jede konkrete JavaBean-Klasse repräsentiert eine IQ-Nachricht. Client-Entwickler verwenden die IQ-Nachrichten unterhalb der Anwendungsschicht der von ihnen entwickelten Dienste für die Basiskommunikation mit dem Server. Dazu gehören z.b. die Service Discovery und Nachrichten zum Erstellen und Nutzen von Dienstinstanzen. Auf der Client-Seite wird MobilisXMPP bei Java-Clients als abhängiges Projekt mit eingebunden oder bei Android in Form des MXAClient.jar-Archivs. Die dynamische Dienstlaufzeitumgebung (Runtime) ist der eigentliche Kern des Mobilis-Servers. Die Runtime bringt ein Life-Cycle-Management und die Klassenstruktur wie in Abbildung 2.6 mit, auf der auch das Entwickler-Framework aufbaut. Der Copyright TU Dresden, Philipp Grubitzsch 15

32 Verteiltes Service-Hosting 2.2 Die Mobilis-Plattform Abbildung 2.6: Die Kernkomponenten der Runtime [Kie12] Mobilis Manager ist die wichtigste Verwaltungsklasse des Servers. Sie steuert sämtliche andere Komponenten und Dienste. Ein Mobilis-Dienst ist immer von der Klasse Mobilis Service abgeleitet. Von dieser Klasse werden dann Concrete Services instanziiert (Dienstinstanzen). Als externe Kommunikationsschnittstelle nutzt jede Mobilis-Service- Instanz auch eine eigene Instanz der Klasse Mobilis Agent. Ein Mobilis-Agent stellt eine XMPP-Entität mit einer spezifischen Full-JID dar. Das wiederum bedeutet, dass sich jede Dienstinstanz extern eindeutig adressieren lässt. In Mobilis 2.0 wird die Adressierung auf Basis eines einzigen XMPP-Kontos alle Agenten gemacht. Die Unterscheidung geschieht durch verschiedene Ressourcen für jede Dienstinstanz: die siebente gestartete Instanz eines Dienstes MobilisXHunt mit der Versionsnummer v3. Verwaltet werden die Mobilis-Dienste durch den Mobilis Manager. Dazu wird das JAR- Archiv eines Dienstes nach dem Upload zum Server in eine eigene Instanz eines Service Container geladen. Der Service Container ist eine Klasse, welche alle Methoden für das Life-Cycle Managements mitbringt. Folgenden Methoden werden unterstützt: install, register, start, stop, update, unregister und uninstall. Die Metainformationen für die Installation werden in einer MSDL-Datei mitgeliefert die ebenfalls im JAR-Archiv enthalten ist. Die wichtigsten Metainformationen eines Dienstes sind der Servicename, der Service Namespace und die Service Version. Alle drei werden für die Service Discovery benötigt. Der Mobilis Manager verwaltet alle Service Container und alle Agents. Die externen Verwaltungsschnittstellen der Runtime des Servers bilden der Coordinator Service, der Admin Service und der Deployment Service. Sie sind als Spezialfälle eines Mobilis-Service implementiert, da von ihnen nur eine Instanz auf jedem Mobilis-Server laufen darf und werden ebenfalls vom Mobilis Manager gesteuert. Da sie obligatorische Verwaltungskomponenten des Mobilis-Servers sind, werden diese auch als System 16 Copyright TU Dresden, Philipp Grubitzsch

33 2 Stand der Forschung und Technik Verteiltes Service-Hosting Services zusammengefasst. Sie stellen gemeinsam den serverseitigen Endpunkt des von MobilisXMPP bereitgestellten Mobilis Kommunikationsprotokolls dar und lassen sich nach Aufgaben unterscheiden: Coordinator Service: Beantwortet Service Discovery-Anfragen und ist für das Starten und Stoppen von Dienstinstanzen verantwortlich und stellt damit die externe Schnittstelle der Service Registry dar. Deployment Service: Ist für Upload-Anfragen und Installation von neuen Diensten zuständig Admin Service: Ist die externe Schnittstelle für die Life-Cycle Methoden der Service Container. Für die Serververwaltung steht der Console Client zur Verfügung. Mit ihm lassen sich sämtliche von MobilisXMPP unterstützte Nachrichten an einen Mobilis-Server senden. Mit ihm aber lassen sich Dienste vor allem auf einen Mobilis-Server hochladen, installieren und verwalten. Für Software Entwickler steht mit der Mobilis Service Description Language (MSDL) eine Beschreibungsmöglichkeit des Kommunikationsprotokolls ihrer zu entwickelnden Anwendung zur Verfügung. Es ist ein von WSDL speziell für Mobilis abgeleitetetes XML- Format. Ein Entwickler definiert in der MSDL-Datei seiner Anwendung alle Nachrichten, welche zwischen Clients und Serverdienst ausgetauscht werden. Aus der MSDL können dann automatisch Code-Stubs für den Mobilis-Service sowie die Clients für unterschiedliche Plattformen erzeugt werden. Neben dem Vorteil, dass der Entwicklungsaufwand für mehrere zu unterstützende Plattformen sinkt, wird dadurch auch gewährleistet, dass Serverdienst und Client stets die selben XMPP-IQs verwenden. 2.3 Verwandte Arbeiten Das Extensible Messaging and Presence Protocol hat seinen Ursprung im Bereich des Instant Messaging. Seit ein paar Jahren findet es aber zunehmend Anwendung in vielen anderen Domänen. [HW10] stellt eine Taxonomie auf, in die sich die verschiedenartige Nutzung einordnen lassen soll. Sie besteht aus den Klassen Instant Messaging, Interactive Social Media, Cooperative Work Flow, Internet of Things, Multi-Agent System und Cloud Computing. Um geeignete Konzepte für eine neue Mobilis-Architektur für verteiltes Diensthosting zu finden, kann man sich eventuell bei ähnlich strukturierten Architekturen bedienen. Bedingt durch die Intention mit der die Mobilis-Plattform als Software-Entwickler- Framework geschaffen wurde, werden Instant Messaging, Interactive Social Media und Cooperative Work Flow durch entsprechende Anwendungen unterstützt. Die Beschreibung für das Internet of Things umfasst human-to-object Kommunikation. Auch diese Copyright TU Dresden, Philipp Grubitzsch 17

34 Verteiltes Service-Hosting 2.3 Verwandte Arbeiten wird durch Mobilis bereits in einfacher Form unterstüzt. So ist es möglich Public Displays zu verwenden oder in einem lokalen Subnetz einen Lichtschalter fernzusteuern [Sch11]. Für diese Diplomarbeit ist aber vor allem die Klasse der Multi-Agent-Systeme (MAS) interessant, die wie folgt definiert sind:»mases consist of dispersed cooperating elements which are used for problems that benefit from outsourcing tasks to specialized agents [...]«. Als Beispielsysteme werden Grid Computing Systeme genannt, welche eine Form von MAS ist. Cloud Computing wird auch als nächste Evolutionsstufe von MAS angesehen. Es ist ein Schritt von einem System, welches hauptsächlich Ressourcenprobleme lösen soll, hin zu einer allgemeineren Anwendungsinfrastruktur. Die Definition der Charakteristiken dieser Klasse spiegelt schon recht genau das Ziel dieser Diplomarbeit für eine neue Mobilis-Architektur wieder:»[...] a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services); that can be dynamically reconfigured to adjust to a variable load (scale) and optimum resource utilization«. Im Sinne von Mobilis kann der Ressourcenbegriff als ein Mobilis-Dienst verstanden werden, der genutzt und für Lastverteilung bzw. horizontale Skalierung optimal konfiguriert werden soll. Da jede Instanz eines Mobilis-Dienstes seinen eigenen (XMPP) Agenten verwendet, ist Mobilis ebenfalls ein Multi-Agent-System. Nützliche Konzepte für eine horizontale Skalierung könnten also, bezogen auf die Taxonomie in [HW10], in den Klassen MAS und Cloud-Computing gefunden werden. Daher werden im weiteren Verlauf dieses Kapitels einige dieser speziellen XMPP-nutzenden verteilten Systeme vorgestellt XMPP-basierte Multi-Agent Grid Computing Systeme Erstmalig Erwähnung findet die Verwendung von XMPP im Bereich Grid Computing bereits 2004 in [TGSR04]. Das am CERN entwickelte System DIRAC nutzt die Möglichkeit des asynchronen Aufrufs mittels IQ-Stanzas, um entfernte APIs ansprechen zu können und zum Echtzeitmonitoring der Verfügbarkeit von Entitäten per Roster und Presence. In zwei aktuelleren Arbeiten soll nun detaillierter auf die Möglichkeiten der Nutzung von XMPP in solchen Systemen eingegangen werden. Weis und Lewis beschreiben in [WL09] eine Architektur, welche XMPP als Kommunikationsprotokoll nutzt, um Labor Computer zu einem Ad-hoc Grid zu verbinden. Ihr Anwendungbeispiel ist RFID-Antennen mittels Ant Colony Optimization zu optimieren, wobei eine große Anzahl automatisch generierter Antennen Designs auf ihre Effizienz untersucht werden sollen. Die Computer sollen dazu je nach Verfügbarkeit spontan ein Grid dynamischer Größe bilden. Ihre Wahl für XMPP begründen sie mit der hohen Flexibilität und der einfachen Adaptierung auf andere Anwendungen als Instant Messaging. Hervorgehoben wird außerdem, dass Presence sich ideal für»flüchtige«umgebungen eignet. Damit ist gemeint, dass sich die verfügbaren Rechnerknoten spontan ändern können und sich diese Änderung mit XMPP-Presence in Echtzeit nachvollziehen lässt. Die vorgestellte Grid-artige Architektur besteht aus einem Controller, welcher als Job 18 Copyright TU Dresden, Philipp Grubitzsch

35 2 Stand der Forschung und Technik Verteiltes Service-Hosting Scheduler fungiert und Rechnerknoten, welche die Jobs abarbeiten können. Beide stellen jeweils XMPP-Endpunkte dar. Der Controller hält eine statische Liste aller Rechnerknoten, aus denen er je nach Verfügbarkeit wählt, um Teilaufgaben an einzelne Knoten zu senden. Zur gleichmäßigen Verteilung der Jobs an die verfügbaren Knoten in der Liste kommt Round-Robin Scheduling zum Einsatz. Für das Senden eines Jobs bzw. des Ergebnisses wurde eigens ein Subprotokoll in Form eines IQ-Stanzas geschaffen. Der Controller sendet den Job mit einem Request an einen ausgewählten Knoten und erhält von diesem entweder das berechnete Ergebnis in einem Result oder ein Error zurück. Dieses IQ-Stanza ist ganz speziell auf die Aufgabe zum Optimieren der RFID-Antennen zugeschnitten. Es stellt sozusagen das Kommunikationsprotokoll der eigentlichen Anwendung dar. Da die Computer auch anderweitig von Studenten genutzt werden, war es wünschenswert, Aufgaben nicht an gerade genutzte Computer zu delegieren. Hierzu konnte auf einfache Weise die XMPP-Funktion des Presence-Status genutzt werden. Ein Computer, der gerade verwendet wird, hat den Status»DND - do not disturb«. Erhält er währenddessen ein Job-Request, so beantwortet er diesen mit einem Error. Der Controller versucht dann, diesen Job entweder an einen anderen Knoten weiter zu delegieren oder reiht ihn, falls keiner verfügbar ist, in die Jobwarteschlange ein. Das Grid wurde ohne Performanceoptimierung mit Python implementiert und erzielte bei zehn Knoten eine nahezu achtfach kürzere Berechnungsgeschwindigkeit gegenüber einem einzelnen Knoten. Auch Stout et al. greifen in [SMG09] mit Kestrel die Idee einer XMPP-basierten Architektur für Many-Task-Computing auf. Dabei wird sich in erster Linie am Condor High Throughput Computing (CHTC) System orientiert. Eine Besonderheit von CHTC ist unter anderem, dass job Schedule Nodes und Execute Nodes über sogenannte ClassAds, welche die Fähigkeiten der jeweiligen Knoten repräsentieren, von einem Manager Node gematcht werden. Danach bauen der Schedule Node und der Execute Node eine direkte Verbindung zueinander auf. Zum einen ähnelt dies einer Service Discovery unter Nutzung von Entity Capabilities. Zum anderen ist der Ablauf vom Suchen eines passenden Execute Nodes durch einen Schedule Node mittels des Manager Nodes und anschließender Direktverbindung analog zur Service Discovery in Mobilis. Nachteile von CHTC sind, dass die Knoten nicht über NAT-Barrieren miteinander kommunizieren können sowie eine periodische, statt einer kontinuierlichen Aktualisierung (Polling) von verfügbaren Knoten. Diese beiden Nachteile versuchen Stout et al. in [SMG09] unter Nutzung von XMPP zu adressieren, während die oben genannten positiven Eigenschaften von CHTC mit einfließen sollen. Ihre Hauptanforderung war es, ein fehlertolerantes, skalierbares, Cross- Plattform fähiges Job-Scheduling System für dynamisch verfügbare Rechnerknoten zu schaffen. Die Vorzüge von XMPP die dabei genannt werden sind zum einen, dass XMPP sich in großen Instant Messaging System mit Millionen von Clients bewährt hat und so- Copyright TU Dresden, Philipp Grubitzsch 19

36 Verteiltes Service-Hosting 2.3 Verwandte Arbeiten mit auch für ein Many-Task-System mit Millionen Agenten geeignet wäre. Und zum anderen, wie schon in [WL09] angemerkt, eignen sich die Presence-Fähigkeiten von XMPP, um die Verfügbarkeit von jedem einzelnen Rechnerknoten des gesamten Pools als auch der User-Agenten, welche die Aufgaben an das System schicken, in Echtzeit zu überwachen. Dadurch kann Kestrel nicht mehr verbundene Rechnerknoten sofort aus dem Pool der verfügbaren Knoten entfernen und verhindern, dass Jobs an nicht mehr verfügbare Knoten geschickt werden. Das Cross-Plattform-Kriterium wurde durch eine Implementierung in Python unter Verwendung der SleekXMPP Bibliothek erfüllt. Die Netzarchitektur besteht aus den vier Knotentypen: Manager, Worker, User und XMPP-Server. Der XMPP-Server stellt die zentrale Kommunikationsschnittstelle bereit, mit der sich alle Endpunkte verbinden. Er hält auch die Roster und Statusinformationen aller Entitäten synchron und agiert als verteilte Datenbank. Ein Vorteil ist auch, dass NAT keine Barriere für XMPP-darstellt und somit eine unkomplizierte Kommunikation zwischen verschiedenen lokalen Subnetzen möglich wird. User-Knoten sind Clientanwendungen, welche die Job-Request an den Manager verschicken oder ein berechnetes Ergebnis zurück bekommen. Der User muss nach Absetzen des Job-Requests nicht mit dem Pool verbunden bleiben. Berechnete Ergebnisse, die während der Offline Phase nicht empfangen werden konnten, können bei der nächsten Sitzung abgerufen werden. Anders als beim CHTC werden sämtliche Nachrichten zwischen User und Worker über den Manager geroutet. Der Manager muss dadurch sehr viele Nachrichten verarbeiten. Da jeder verwaltete Knoten (User und Worker) als Eintrag im Roster des Managers vorhanden ist, dauert der Download des Manager Rosters vom XMPP-Server bei vielen verwalteten Knoten sehr lange. Während dieser Zeit werden alle anderen Nachrichten an den Manager blockiert. Daher wurde der Manager in zwei Versionen implementiert. Für bis zu 1000 verwaltete Knoten kann die Implementation als einfacher XMPP-Client verwendet werden. Die zweite Implementierung als XMPP-Serverkomponente ist für extrem große Umgebungen mit vielen tausend Entitäten gedacht und verwaltet dadurch den eigenen Roster selbst: Der langwierige Download beim Starten entfällt. Auch wenn der Manager eines Pools offline geht, können die Worker noch zuvor erhaltene Jobs beenden. Die Worker nutzen XMPP-Presence, um dem Manager ihren Status mitzuteilen. Kommt ein Worker online, so ist er»available«. In diesem Zustand würde der Manager ihm Jobs zusenden. Sobald er einen Job erhalten hat, wechselt er in den Presence-Status»busy«. Der Manager delegiert nun keine Jobs mehr an diesen Worker, wenn er Jobs in der Warteschlange hat. Geht ein Worker offline, sendet er den XMPP-Presence-Status»offline«. Sollte er währenddessen gerade einen Job verarbeitet haben, wird der Manager diesen Job dann an einen anderen, noch verfügbaren Worker weiterleiten. Jeder Worker stellt einen physischen Computer dar und nutzt jeweils einen eigenen XMPP-Account. Jeder Prozessorkern eines Workers kann sich darüber hinaus mit einer eindeutigen Ressource anmelden. Alternativ ist es in Kestrel auch möglich, einen XMPP-Account für alle 20 Copyright TU Dresden, Philipp Grubitzsch

37 2 Stand der Forschung und Technik Verteiltes Service-Hosting Worker zu verwenden und sie bzw. auch die einzelnen Prozessorkerne über die XMPP- Ressource zu unterscheiden. Der Manager Roster würde dadurch deutlich weniger Einträge benötigen. Das Verwenden von einem XMPP-Account pro Worker bringt aber einige sehr gewichtige Vorteile mit sich. So lassen sich die Worker einfacher in Kategorien wie Standort, Betriebssystem oder Nutzungsabsicht einsortieren. Außerdem wird die Systemsicherheit erhöht, wenn jeder Worker ein eigenen Login und Password verwendet. Anders als in [WL09] wird die Kommunikation von Kommandos und Daten zwischen Entitäten über XMPP-Messages an Stelle von IQs realisiert. Dadurch können zum Verwalten eines Kestrel Pools normale XMPP-Instant Messanger wie z.b. Pidgin 4 verwendet werden. Zum Formatieren der Anwendungsdaten, die in einer XMPP-Nachricht verschickt werden, wurde ein eigenes Subprotokoll auf Basis von JSON erstellt. Über Machine Profiles können Worker ihre Eigenschaften nach Außen definieren. Sie stellen Key-Value-Paare dar, mit denen der Manager in der Lage ist aufgrund der angegebenen Eigenschaften zu überprüfen, ob der jeweilige Worker zum Ausführen eines Jobs geeignet ist. Abbildung 2.7: Generische Architektur für XMPP-basierte Many-Task-Computing- Systeme Die Konzepte der zu XMPP-basierten Many-Task-Computing-Systemen vorgestellten Arbeiten [TGSR04][WL09][SMG09] lassen sich zu einer generischen Architektur für diese Systeme zusammenfassen, die in Abbildung 2.7 dargestellt ist. Die Bezeichnungen sind dabei nebensächlich. Entscheidend ist, dass es einen Knoten (hier Manager genannt) gibt, der aus einem Worker-Pool wählt und Aufgaben von Nutzern an einen dieser Worker- Knoten weiterleitet. Diese verarbeiten die Aufgabe und schicken das Ergebnis an den Manager zurück, welcher das Ergebnis an den Nutzer weiterleitet. Die Besonderheit bei diesen Systemen ist, die Verwendung von Rostern bzw. ähnlichen Nutzerlisten und XMPP-Presence, um Echtzeit Statusinformationen zur Verfügbarkeit von Teilnehmern des Gesamtsystems zu erhalten. Der Manager kann so entscheiden an welchen Worker er eine Aufgabe weiterleitet und ob der Nutzer das berechnete Ergebnis gerade empfangen kann. 4 Copyright TU Dresden, Philipp Grubitzsch 21

38 Verteiltes Service-Hosting 2.3 Verwandte Arbeiten Dabei zeigt sich eine Analogie zur Mobilis-Netztopologie:»Worker«können als die Mobilis-Dienste verstanden werden. Genutzt werden sie von den»nutzern«, welche den Mobilis-Clientanwendungen entsprechen. Ein»Manager«entspricht bei Mobilis dem Server, welcher die beiden anderen Parteien über entsprechende Eigenschaften zusammen bringt. Wendet man dieses Architekturmodell auf Mobilis an, so könnte dies ein Ansatz zur Verwaltung von verteilt laufenden Diensten sein XMPP-basierte Service und Cloud-Service-Systeme Wagener et al. stellen in [WSWW09] ein Framework einer XMPP-basierte Cloud- Service-Infrastruktur vor. Damit sollen die Nachteile von bisherigen HTTP-basierten Webservice Technologien wie SOAP und REST, welche nur eingeschränkte Service Discovery unterstützen, sowie fehlende Fähigkeiten von Services Statusinformationen zu senden, überwunden werden. Der Anwendungshintergrund sind Probleme der Bioinformatik, welche häufig das Bereitstellen und Verarbeiten von großen Datenmengen erfordern. Da in dieser Anwendungsdomäne häufig XML-basierte Sprachen verwendet werden, ermöglicht XMPP gegenüber HTTP darüber hinaus die nahtlose Integration der Daten in die übertragenen Nachrichten. Die verwendete Netzarchitektur ist in Abbildung Abbildung 2.8: Cloudservice-Netzarchitektur [WSWW09] 2.8 dargestellt. Für die Nachrichtenübertragung wurde die Erweiterung XEP-0244: IO Data geschaffen [JW08]. Die XEP soll laut der Autoren zwei Probleme lösen: 1. Die unnötige Trennung von WSDL-Beschreibung und des eigtl. SOAP-Dienstes 2. Die Möglichkeit des asynchronen Dienstaufrufes Durch die IO Data XEP sollten Dienste dazu fähig sein, ihre eigenen In- und Output- Typen zu veröffentlichen, diese asynchron aufzurufen und dabei den Vorteil zu erhalten, 22 Copyright TU Dresden, Philipp Grubitzsch

39 2 Stand der Forschung und Technik Verteiltes Service-Hosting die XMPP-Standard Service Discovery nach [JH08b] zu verwenden. Die vorgeschlagene Erweiterung hat sich nie durchgesetzt, und die Weiterentwicklung wird aktuell nicht weiterverfolgt. Der in der XEP beschriebene asynchrone Methodenaufruf (Vgl. Abb. 2.9) ist aber dennoch einen kurzen Blick wert. Er ist vor allem für die Abarbeitung von sehr zeitintensiven Aufgaben durch den Service erforderlich. Ein Nutzer ruft den Dienst auf und überträgt dabei auch die Input-Daten. Der Server antwortet dem Nutzerclient mit dem Hinweis, dass der Dienst aufgerufen wurde und der zugehörigen Session-ID. Sobald der Dienst die Verarbeitung abgeschlossen hat, benachrichtigt er den Nutzerclient mit einem eigenen Request und der zugehörigen Session-ID. Da der Dienst sehr lange brauchen könnte, um die Aufgabe zu verarbeiten, würde der Client bei einem synchronen Aufruf an dieser Stelle sonst auf eine Antwort warten und ggf. den Request mehrfach neu versenden, was weitere unerwünschte Methodenaufrufe zur Folge hätte. Abbildung 2.9: Asynchroner Methodenaufruf mit XMPP in [WSWW09] Eine Referenzimplementierung zum Erzeugen und Aufrufen der Services wurde in Form der Java Bibliothek»xws4j«entwickelt. Für die vielen unterschiedlichen Datentypen im wissenschaftlichen Alltag wurde darüber hinaus eine weitere Java Bibliothek»xws4jbinding«geschaffen. Mit ihr ist es möglich, aus XML-Schemata, welche von den zuvor (mit xws4j) erstellten XMPP-Diensten erhalten werden können, Java Bindings und Clientstubs automatisch zu generieren. Als Beispielanwendungen wurden für einige Domänen übliche Softwarewerkzeuge aufbauend auf dem Framework und der Architektur Plugins entwickelt. Für Bioclipse zum Beispiel, eine Eclipse-basierte grafische Arbeitsumgebung, wurden aufbauend auf xws4j ein Client-Plugin entwickelt, welches nutzerfreundliche, generische Funktionen für die Service Discovery und das Aufrufen von XMPP-Diensten mit Hilfe der GUI sowie eine integrierte Skripting-Umgebung mitbringt. Die Service Discovery ermöglicht es dem Plugin, sämtliche verfügbare Dienste auch in entfernten XMPP-Domänen zu listen, solange der jeweilige XMPP-Server für»public access«konfiguriert ist. Die Dienste veröffentlichen außerdem ihre unterstützten Funktionen. Durch die XMPP-Architektur sind sämtliche Änderungen eines Dienstes wie die Copyright TU Dresden, Philipp Grubitzsch 23

40 Verteiltes Service-Hosting 2.3 Verwandte Arbeiten Verfügbarkeit oder die Fähigkeiten sofort durch den Client feststellbar. Zusammenfassend wurde festgestellt, dass Dienste direkt von einer solchen vorgestellten XMPP-Architektur profitieren und bisherige Workaround-Ansätze mit»polling- Mechanismen«überflüssig machen könnten. Die Cloud-Dienste und ihre Semantiken müssen auch publiziert werden, damit Nutzer sie finden können. Auch unterstützt XMPP»out of the box«service-status, -Verfügbarkeit und -Discovery und ist gegenüber SOAPbasierten Webdiensten im Vorteil, da diese Funktionen zusätzlich z.b. UDDI erforderlich machen. Ein Vertreter der XMPP-basierten Dienstumgebungen wird als Teil des Junction Protocols von Dodson et al. in [BD11] beschrieben. Die Dienstumgebung ist primär für Adhoc Verbindungen von mehreren Teilnehmern ausgelegt. Anders als der Titel es vermuten lassen würde, handelt es sich dabei nicht nur um ein Kommunikationsprotokoll, sondern auch um eine Implementierung von Diensthosts und ein Softwareentwickler-Framework. Die Referenzimplementierung der Hosts wurde auf Basis von verschiedenen unterliegenden Transportprotokollen gemacht: Bluetooth, TCP/IP, IRC, XMPP und OpenFlow. Der Fokus soll hier hauptsächlich auf dem XMPP-nutzenden Teil liegen. Die Autoren wollen mit Junction die Entwicklung und Nutzung von Anwendungen erleichtern, die folgende Eigenschaften aufweisen: mobil: Smartphones, Tablets nativ: für bessere Performance auf ressourcenbeschränkten Geräten Cross-Plattform fähig: Entwickler sollen ihre Anwendungen leichter für mehrere Plattformen entwickeln können Multi-User: Anwendungen mit mehreren Nutzern Geräteunabhängigkeit: Ein Konto identifiziert einen Nutzer für alle Geräte gleichzeitig Dazu wird eine dezentralisierte Netzwerkarchitektur aus leichtgewichtigen, 5 verteilten Nachrichtenroutern angestrebt, die Switchboards genannt werden. Die sie nutzenden Anwendungen sollen für ein Switchboard transparent bleiben, d.h. dass sie jeder Junction Anwendung als Host dienen können. Abbildung 2.10 (links) zeigt die vereinfachte Architektur. Anwendungsspezifischer Code läuft nur auf den Clients. Ein Switchboard kann von einem Teilnehmer auf seinem Endgerät oder einem Third-Party-Hoster bereitgestellt werden. Dieses Prinzip wird assisted peer-to-peer genannt. Auf jedem Client läuft ein activity director, der ähnlich wie ein Browser, protokollbezogene Aufrufe ausführen kann. Mit ihm wird auch eine Junction-Anwendung gestartet. Eine Junction URI macht ein Switchboard adressierbar. 5 im Sinne der Ressourcen die sie benötigen 24 Copyright TU Dresden, Philipp Grubitzsch

41 2 Stand der Forschung und Technik Verteiltes Service-Hosting Abbildung 2.10: Architektur und Sessionaufbau bei Junction [BD11] Sie beschreibt, wie man auf das Switchboard einer Anwendung zugreift, einer Sitzung beitritt und wie der Client den für ihn benötigten Cross-Plattform-Code der Anwendung downloaden kann. Die Junction URI hat die Form: junction://[host]/[session]#[transport]?role=[role] Der host ist die IP-Adresse des Geräts auf dem das Switchboard gehostet wird. Die session gibt die eindeutige Session-ID einer Activity an und transport das unterliegende Protokoll, z.b. XMPP. Der letzte Teil role beschreibt, in welcher Rolle man mit seinem Gerät einer Activity unter Nutzung der URI beitritt. Eine Rolle kann z.b. ein Mitspieler beim Poker sein oder ein Public-Display in Form eines großen Fernsehers, auf dem der virtuelle Pokertisch angezeigt wird. Abbildung 2.10 (rechts) zeigt, wie mehrere Benutzer gemeinsam eine Anwendungssitzung starten. Zuerst erstellt der Sessioninitator auf dem Switchboard eine Anwendungssitzung. Für diese wird eine Junction-URI generiert. Diese kann ähnlich wie ein HTTP-Link auf verschiedene Weise weitergeben werden: Eingebettet in eine , als SMS, als QR-Code, per Bluetooth oder NFC. Der Nutzer, der teilnehmen möchte, klickt auf die URI und der auf seinem Gerät laufende Activity Director verbindet sich mit dem zugehörigen Switchboard, lädt und installiert den benötigten Plattform-Code der Anwendung, startet diese und tritt der Session in einer bestimmten Rolle bei. Diese Rollen werden innerhalb der Anwendungssession durch Activity Scripts beschrieben und führen zum plattformspezifischen Code, den der eigene Activity Director dann herunterlädt. Das Junction-Framework bringt den Activity Director, Methoden zum Einladen per Junction URI, mehrere Switchboard Implementierungen u.a. für XMPP und eine Bibliothek, um Zustände über mehrere Geräte synchron zu halten. Für die Kommunikation Copyright TU Dresden, Philipp Grubitzsch 25

42 Verteiltes Service-Hosting 2.4 Zusammenfassung zwischen Entitäten wird ein High-Level-Kommunikationsprotokoll auf Basis der oben genannten möglichen Transportprotokolle verwendet. Ein Anwendungsentwickler muss sich bei der Programmierung daher nicht mit XMPP-Nachrichten auseinandersetzen. Die gesamte Infrastruktur von Junction ist bereits für Desktop, Android, ios und das Web verfügbar. Die XMPP-Implementation von Junction nutzt einem XMPP-MUC als Switchboard. Dadurch kann vollständig auf bestehende XMPP-Infrastruktur zurückgegriffen werden und somit jedes beliebige XMPP-Netzwerk genutzt werden. Da ein XMPP-MUC aber auf einem XMPP-Server und nicht auf einem Endpunkt läuft, handelt es sich in diesem Fall um Third-Party-Hosting. Für sicherheitsrelevante Anwendungen stellt dies kein Problem dar, da XMPP eigene Mechanismen mitbringt, um die Kommunikation zu verschlüsseln. Laut der Autoren kann der Schlüssel als Teil der Einladung geteilt werden, da diese bei Junction out-of-band ist. Zur Illustration der Fähigkeiten von Junction wurden eine ganze Reihe kollaborativer Beispielanwendungen entwickelt, welche auch die Möglichkeiten der Nutzung unterschiedlicher Gerätetypen und Rollen zeigen. Abbildung 2.11: Junction: wetube und weholdem Demoanwendungen [BD11] Ein interessantes Beispiel ist das bereits oben erwähnte Pokerspiel wehold em (Abb links). Hier wird ein großes Public-Display für die Rolle des Pokertischs zum Anzeigen der Community-Cards verwendet, während die persönlichen Smartphones den Mitspieler anzeigen, was sie auf der»hand«haben. Ein weitere Anwendung ist wetube (Abb rechts) Ein kollaborativer Videodienst, der ebenfalls Smartphones und ein Public Display verwendet. Nutzer können mit ihren Geräten Videos in eine Warteschleife setzen, welche dann der Reihe nach auf dem Public-Display abgespielt werden. Nach dem gleichen Prinzip funktioniert auch ein Fotodienst namens wepix. 2.4 Zusammenfassung XMPP ist ein seit fast 10 Jahren standardisiertes und vielseitiges Kommunikationsprotokoll. Es bringt eine ganze Reihe nützlicher Funktionen mit und ist durch die Er- 26 Copyright TU Dresden, Philipp Grubitzsch

43 2 Stand der Forschung und Technik Verteiltes Service-Hosting weiterbarkeit auch in Zukunft für neue Anforderungen anpassbar. Besonders interessant für diese Arbeit ist die Methodik, Presence-Informationen zu verbreiten und somit in Echtzeit Zustände von Entitäten zu verfolgen. Die Mobilis-Plattform baut bereits auf XMPP auf, nutzt aber nicht ansatzweise dessen volles Potenzial. Eine der größten Schwächen ihrer bisherigen Architektur ist die nicht vorhandene horizontale Skalierbarkeit. Diese wird üblicherweise durch ein verteiltes System erreicht, indem Teilaufgaben auf andere Rechnerknoten ausgelagert werden. Darüber hinaus fehlen ihr wichtige Sicherheitsmerkmale, die besonders in einem verteilten System von großer Bedeutung sind. Die in Abschnitt vorgestellten XMPP-Eigenschaften könnten dazu eingesetzt werden, um dieses Ziel zu erreichen. Anregungen für Möglichkeiten, auf welche Weise die vorgestellten XMPP-Funktionalitäten in einem verteilten System eingesetzt werden können, wurden in den verwandten Arbeiten in Abschnitt 2.3 vorgestellt. In ihrer Netzarchitektur ähneln vor allem die XMPP-nutzenden Grid-Computing-Systeme der von Mobilis. Beide Systemtypen können den Multi-Agent-Systemen zugeordnet werden, wodurch sich einige Analogien bei ihrer Organisation ergeben. Dabei ist insbesondere die Nutzung von Roster und Presence für das Echtzeit-Tracking und die Organisation von verteilten Entitäten hervorzuheben. Diese werden sich im Konzept für eine neue verteilte Mobilis-Server-Architektur in Kapitel 4 als sehr wertvoll herausstellen. Copyright TU Dresden, Philipp Grubitzsch 27

44

45 3 Anforderungsanalyse Verteiltes Service-Hosting 3 Anforderungsanalyse In diesem Kapitel sollen die Anforderungen der neuen verteilten Mobilis-Architektur definiert werden, welche für die Konzeption in Kapitel 4 als Grundlage herangezogen werden. Um Klarheit über die Rolle der verschiedenen Anwendergruppen in der Dienstumgebung zu schaffen, werden diese zunächst in Abschnitt 3.1 eindeutig definiert. Anschließend werden ihnen in Abschnitt 3.2 Anwendungsfälle zugeordnet, aus denen dann in Abschnitt 3.3 die Anforderungen abgeleitet werden. 3.1 Anwendergruppen Der Mobilis-Server wird von verschiedenen Anwendergruppen verwendet und verwaltet. Durch eine Verteilung der Dienstumgebung ergeben sich neue Möglichkeiten der Nutzung und als Folge dessen neue Anwendergruppen und Anwendungsparadigmen. Administratoren: Sie sind die Verwalter eines Mobilis-Servers mit allen Rechten. In der alten Architektur mit nur einem Server haben alle Administratoren den selben Server verwaltet. Durch eine Verteilung ist es nun möglich, dass Administratoren unterschiedliche Server verwalten, wodurch neue Interaktionen innerhalb dieser Gruppe entstehen. Dienstanbieter u. -administratoren: In der alten Architektur konnte jeder Nutzer uneingeschränkt Dienste auf einen Mobilis-Server hochladen und installieren. Praktisch konnte jeder Benutzer mit einem XMPP-Account Dienstanbieter sein. Darüber hinaus konnte jeder Nutzer auch jeden Dienst auf dem Mobilis-Server ändern bzw. deinstallieren. Dieser Zustand ist aus sicherheitstechnischen Gründen unerwünscht. Da eine verteilte Dienstumgebung ohnehin diverse Sicherheitsmechanismen erforderlich macht, soll in diesem Zuge die Gruppe der Dienstanbieter hierfür neu definiert werden. Dienstanbieter nutzen einen Mobilis-Server, der nicht unter ihrer Kontrolle steht, um einen Mobilis-Dienst anzubieten. Dazu müssen sie von einem Administrator eines Mobilis-Servers das Recht bekommen, Dienste auf einen bestimmten Server hochzuladen und zu installieren. Ein Dienstanbieter besitzt standardmäßig nur das Recht, die Konfiguration der selbst installierten Dienste zu ändern. Das Recht, einen Dienst zu ändern, kann einem Nutzer aber von einem Serveradministrator oder Dienstadministrator gegeben werden. Dienstnutzer: Sie stellen die eigentlichen Anwender einer Mobilis-Anwendung dar. Sie können mit einer Mobilis-Clientanwendung einen serverseitigen Mobilis- Dienst nutzen. Copyright TU Dresden, Philipp Grubitzsch 29

46 Verteiltes Service-Hosting 3.2 Anwendungsfälle Abbildung 3.1: Anwendungsfälle in Mobilis Jeder Anwender mit einem Account im XMPP-Netzwerk kann auch Rollen in mehreren Gruppen gleichzeitig einnehmen. 3.2 Anwendungsfälle Den drei Anwendergruppen lassen sich wie in Abbildung 3.1 gezeigt Anwendungsfälle zuordnen. Die Rechteverwaltung des Administrators sowie das Ändern der Dienstkonfiguration und der Dienstrechte durch den Dienstanbieter sind komplexe Anwendungsfälle und lassen sich weiter in Teilfälle zerlegen. Das Ändern der Dienstkonfiguration ist bereits vollständig in Mobilis 2.0 implementiert und umfasst z.b. das Stoppen von Dienstinstanzen, das Installieren einer neueren Version des selben Dienstes, das Deinstallieren des Dienstes und das Ändern von Konfigurationsparametern. Die genauen Teilfälle der Rechteverwaltungen beider Anwendergruppen sind von der Konzeption abhängig und werden später an entsprechender Stelle präzisiert. An den Anwendungsfällen wird sich auch im Konzept orientiert, da ein atomarer Anwendungsfall oft einer einzelnen Nachricht im Kommunikationsprotokoll entspricht. 3.3 Anforderungen Hier werden die Anforderungen an die neue Architektur aufgelistet: A-01: Wenn ein Administrator eine Mobilis-Dienstumgebung auf einem Server wie bisher aufgesetzt hat, muss es möglich sein, die Dienstumgebung auf andere physische Rechnerknoten so zu erweitern, dass sich die benötigten Ressourcen für die gesamte Dienstumgebung verteilen lassen. Dies soll die horizontale Skalierbarkeit ermöglichen, um die Plattform an unterschiedlich große Nutzerzahlen anpassen zu können. 30 Copyright TU Dresden, Philipp Grubitzsch

47 3 Anforderungsanalyse Verteiltes Service-Hosting A-02: Dem Administrator eines Servers müssen Sicherheitsmechanismen zur Verfügung stehen, die gewährleisten, dass nur vertrauenswürdige Server der eigenen Dienstumgebung angehören. Dazu muss er einschränken können, auf welchen anderen Servern seine eigenen Dienste über die entfernte Service Discovery verbreitet werden, bzw. welche fremden Dienste die eigene Service Discovery den angebundenen Clients verfügbar macht. A-03: Der Verfügbarkeitszustand der Dienste und Dienstinstanzen aller Server der Dienstumgebung soll in Echtzeit nachvollzogen werden können. Das bedeutet, wenn ein neuer Dienst oder eine neue Dienstinstanz auf einem entfernten Server B verfügbar wird, diese Information allen angebunden Clients sofort über die Service Discovery eines Servers A in der Dienstumgebung zur Verfügung steht. A-04: Administratoren eines Servers müssen einschränken können, wer auf den von ihnen verwaltetem Server Dienstanbieter ist, d.h. neue Dienste hochladen und installieren darf. A-05: Ein Dienstanbieter darf nur Rechte zur Kontrolle 1 der eigenen Dienste haben. Die Serveradministratoren und der Dienstanbieter müssen darüber hinaus die Möglichkeit haben, anderen Nutzern das Administrationsrecht der eigenen Dienste zu geben oder zu entziehen. A-06: Clients müssen Dienstinstanzen finden und nutzen können, die nicht auf dem Server laufen, dessen Service Discovery die Clients nutzen. Das kann der Fall sein, wenn ein bestimmter gewünschter Kommunikationspartner die gemeinsam zu nutzende Dienstinstanz auf einem anderen Server erstellt hat. Für die Clients soll die Information auf welchem Server ein Dienst läuft transparent bleiben. Das heißt, sie kommunizieren für die Service Discovery nur mit ihrem eigenen Server. A-07: Clients müssen ggf. Dienstinstanzen auf einem anderen, entfernten Server starten können als auf dem Server, dessen Service Discovery sie nutzen. Dies kann erforderlich sein, falls der eigene Server einen Dienst nicht anbietet oder ausgelastet sein sollte. Auch dieser Vorgang soll für die Clients transparent bleiben. A-08: Der Algorithmus der entscheidet, auf welchem entfernten Server eine neue Dienstinstanz gestartet wird, muss so gestaltet sein, dass die Ressourcenlast möglichst gleichmäßig auf die Server der verteilten Dienstumgebung verteilt wird. A-09: Es soll möglich sein, ggf. neue Dienstinstanzen so zu verteilen, dass der Auslastungszustand der Server in der Dienstumgebung berücksichtigt wird. Dieser sollte dazu in Echtzeit bekannt sein. A-10: Es soll eine Möglichkeit gefunden werden, dass Dienste eine Schnittstelle zu einer 1 install, uninstall, usw. Copyright TU Dresden, Philipp Grubitzsch 31

48 Verteiltes Service-Hosting 3.3 Anforderungen Datenbank nutzen, um Informationen dauerhaft persistent halten zu können. A-11: Die Änderungen am Kommunikationsprotokoll zwischen Clients und Server sollen so gering wie möglich ausfallen. Dadurch wird gewährleistet, dass Entwickler bestehende Anwendungen mit wenig Aufwand auf die neue verteilte Architektur portieren können. A-12: Die bisher entwickelten Dienste sollen nach Möglichkeit ohne oder nur mit minimalen Änderungen weiterverwendet werden können. Dienste sollen weiterhin nur ihr eigenes Anwendungsprotokoll nutzen, um mit Clients zu kommunizieren. Für einen Dienst soll transparent bleiben auf welchem Server er läuft. A-13: Für die Verwaltung aller Aufgaben soll nach Möglichkeit die Grundlage für eine zukünftige grafische Benutzeroberfläche in Form einer Schnittstelle geschaffen werden, welche die verschiedenen Rollen der Serveradministratoren und Dienstanbieter unterstützt. 32 Copyright TU Dresden, Philipp Grubitzsch

49 4 Konzeption Verteiltes Service-Hosting 4 Konzeption In Abschnitt 2.2 wurde bereits der aktuelle Stand der Mobilis-Plattform vorgestellt. Hauptziel der Konzeption ist es, diese in eine verteilte Architektur zu überführen, um eine horizontale Skalierung zu erreichen. Dabei sollen die in Kapitel 3 aufgestellten Anforderungen berücksichtigt werden. In Abschnitt 4.1 werden zunächst zwei Konzeptideen, die im Laufe der Bearbeitungszeit der Diplomarbeit entstanden sind, vorgestellt. Durch die Betrachtung von deren Vor- und Nachteilen, sowie der Machbarkeit im Rahmen der Diplomarbeit wurde aus diesen eine Idee ausgewählt. Diese wird anschließend in Abschnitt 4.2 zur eigentlichen Konzeption verfeinert und detailliert beschrieben. In Abschnitt 4.3 folgt die Aufarbeitung des Kommunikationsprotokolls und ihrer zugehörigen serverseitigen Endpunkte. Abschließend wird in Abschnitt 4.4 eine Möglichkeit betrachtet, wie die von Johannes Völker in [Vö13] vorgestellte Datenbankanbindung eines Dienstes erweitert werden könnte. 4.1 Mögliche Zielarchitekturen Wie bereits erwähnt soll die Skalierbarkeit der Plattform vor allem durch das Verteilen von Diensten auf weitere Rechnerknoten ermöglicht werden. Im Falle der Mobilis- Plattform muss dazu die Laufzeitumgebung, welche zur Ausführung der Dienste benötigt wird, ebenfalls auf andere Rechnerknoten verteilt werden können. Die entscheidenden Komponenten sind hier der Mobilis Manager und der Deployment Service. Damit aber die verteilten Dienste auch genutzt werden können, muss auch die Service Discovery angepasst werden. Die hierfür verantwortliche Komponente ist der Coordinator Service Idee: Sternförmige Netzarchitektur mit einem Coordinator In der ersten Konzeption wurde die Idee verfolgt, die Komponenten Coordinator Service und Deployment Service in zwei einzelne Serverimplementierungen aufzuteilen. Die Implementierung mit der Coordinator-Komponente sollte Discovery-Server heißen und die andere, mit der eigentlichen Laufzeitumgebung und dem Deployment Service, Runtime- Server. Durch Trennen der beiden Aufgabenbereiche Service Discovery und Laufzeitumgebung sowie das Verteilen der Laufzeitumgebung erhält man eine sternförmige Netzarchitektur wie in Abbildung 4.1 dargestellt. Dieser Ansatz stellt eine Möglichkeit dar, ein verteiltes Diensthosting zu realisieren und Copyright TU Dresden, Philipp Grubitzsch 33

50 Verteiltes Service-Hosting 4.1 Mögliche Zielarchitekturen Abbildung 4.1: Verteilung der Service Enviroment auf entfernte Runtimes damit die Mobilis-Plattform skalierbar zu machen. Die Idee ist, die verteilte Laufzeitumgebung in folgender Weise auf- bzw. auszubauen. Steht das XMPP-Netzwerk und sind die erforderlichen Accounts eingerichtet, wird zunächst der Mobilis-Discovery-Server und ein Runtime-Server in Betrieb genommen. Der Runtime-Server wird beim Coordinator registriert. Dann werden auf dem Runtime-Server die gewünschten Dienste installiert. Dies kann entweder in Form eines direkten Dienst Uploads einer JAR-Datei wie bisher mit dem Console Client oder z.b. in Form eines Downloads von einem entfernten Dienste- Repository geschehen. Die neu installierten Dienste werden ebenfalls beim Coordinator Service registriert. Der Discovery-Server verwaltet in diesem Fall die vollständige Service Registry der gesamten verteilten Dienstlaufzeitumgebung. Eine Clientanwendung macht die Service Discovery wie bisher bei seinem Mobilis-Coordinator, um nach verfügbaren Diensten oder Dienstinstanzen zu suchen. Im Unterschied zum bisherigen Mobilis-Server werden Instanzen durch den Coordinator nicht lokal erzeugt, sondern auf einem entfernten Runtime-Server. Mit diesem einfachen Fall kann bereits die vollständige Funktionalität der derzeitigen Mobilis-Architektur abgebildet werden. Im Falle von sehr vielen Nutzern und Dienstinstanzen käme aber zusätzlich der Vorteil zum tragen, dass die Architektur einfach um weitere Runtime-Server erweitert werden kann. Sollte z.b. der Runtime-Server 1 an seine Leistungsgrenze geraten, können neue Dienstinstanzen ggf. einfach auf einem weiteren Runtime-Server 2 erzeugt werden. Ein weiterer positiver Nebeneffekt ist, dass dadurch überhaupt erst die Möglichkeit geschaffen wird, das Diensthosting unabhängigen Drittparteien zu überlassen. Abbildung 4.2 zeigt einen ersten Entwurf der Komponentenarchitektur für diese Konzep- 34 Copyright TU Dresden, Philipp Grubitzsch

51 4 Konzeption Verteiltes Service-Hosting Abbildung 4.2: Komponentenarchitektur der ersten Konzeptidee tidee. Der CoordinatorService sollte von nun an Discovery heißen, und der Deployment- Service wird in Runtime umbenannt. Der AdminService des bisherigen Mobilis-Servers wird aus der Architektur entfernt und sämtliche Funktionalität in die Komponente Runtime übertragen. Dadurch ergibt sich eine logische, sauber getrennte Aufgabenverteilung. Die Discovery Komponente besitzt drei externe Kommunikationsschnittstellen. Erstens ist sie wie bisher für die Koordination der Kommunikation zwischen den Clients und den Diensten zuständig und übernimmt dabei die Aufgaben der Service Discovery sowie transparent für die Clients das Starten von Dienstinstanzen auf den Runtimes. Diese Schnittstelle wird durch das Discovery-Protokoll beschrieben. Zweitens verwaltet sie Informationen und steuert Dienste auf den entfernten Runtimes. Das Protokoll, welches die Kommunikation zwischen Coordinator-Server und Runtime-Server abbildet, heißt Runtime-Protokoll. Es beschreibt u.a., wie sich Runtimes beim Coordinator anmelden und ihn über verfügbare Dienste und laufende Dienstinstanzen informieren. Außerdem leitet der Coordinator mit diesem Protokoll die Anfragen zum Starten und Beenden von Dienstinstanzen des Discovery-Protokolls an die entsprechende Ziel-Runtime weiter. Die Runtime-Komponente beinhaltet die Logik und Kommunikation für die verteilte Laufzeitumgebung. Sie besitzt zwei externe Schnittstellen. Die Erste, zum Discovery Server wird durch das Runtime-Protokoll beschrieben und wurde bereits erläutert. Die zweite Schnittstelle ist die für die Dienstentwickler und Dienstanbieter. Verwaltet werden kann ein Server unabhängig von seiner Rolle mit der Remote Console. Das Remote Protokoll definiert die Kommunikation zwischen Remote Console und dem verteilten Server. Beschrieben werden u.a. Dienstupload, Dienstkonfiguration und Serverkonfiguration je nach Nutzerautorisation. Eine weitere wesentliche Änderung sieht das Verwenden von je einem eigenen XMPP- Account pro Dienst vor. Bisher wurde für den Mobilis-Server typischerweise nur ein XMPP-Account z.b. verwendet. Die Komponenten sowie sämtliche Dienste bzw. Dienstinstanzen wurden nur auf Basis der Ressource z.b. /coordinator, /de- Copyright TU Dresden, Philipp Grubitzsch 35

52 Verteiltes Service-Hosting 4.1 Mögliche Zielarchitekturen ployment, /xhunt1, /xhunt2 unterschieden. Da Dienste nun aber auf entfernten Runtime- Servern laufen, sollten deren Dienste ohnehin mindestens die Bare-JID des jeweiligen Runtime-Servers verwenden. Betreiber von Runtime- und Discovery-Server sollten aber schon aus sicherheitstechnischen Gründen nicht den selben XMPP-Account verwenden. In diesem Zuge wurde beschlossen, dass jeder Dienst gleich seine eigene Bare-JID und dessen Dienstinstanzen abgeleitet davon ihre eigene Full-JID erhalten. Dadurch kann auch die zentrale Service Registry effizienter und übersichtlicher verwaltet werden. Bei einem Blick in den Roster kann jeder XMPP-Account bzw. jede Bare-JID eindeutig einem Dienst und die Ressourcen in Form der Full-JIDs jeweils eindeutig einer Dienstinstanz zugeordnet werden. Diskussion Der größte Nachteil der gegen dieses Konzept sprach, sind die hohen Abhängigkeiten der einzelnen Serverkomponenten untereinander. Der Coordinator Service, der Deployment Service und der Admin Service sind bisher als Mobilis-Dienste implementiert. Das heißt sie benötigen ebenfalls die Laufzeitumgebung, um ausgeführt werden zu können. Das Auftrennen der Komponenten in zwei Serverimplementierungen wäre dadurch sinnlos. Der Implementierungsaufwand, um diese Abhängigkeiten zu beseitigen, wurde als zu hoch und der resultierende Ressourcengewinn als vernachlässigbar eingeschätzt. Der Umstand, dass verschiedenste Nutzer, Nutzergruppen und auch entfernte Serverkomponenten von Fremdanbietern mit einem Server kommunizieren können, macht es erforderlich Zugriffsberechtigungen in der Architektur abzubilden und dauerhaft zu speichern. Auch die Informationen über die entfernt verfügbaren Dienste müssen in irgendeiner Form persistent gehalten werden. In dieser Konzeptidee war dafür eine Datenbank pro Server vorgesehen. Dadurch wären Ressourcenverbrauch, Entwicklungs- und Konfigurationsaufwand für die Architektur deutlich angestiegen. Darüber hinaus hätte auch ein Großteil des Kommunikationsprotokolls neu entwickelt werden müssen, was den Entwicklungsaufwand ebenfalls in die Höhe getrieben hätte. Auf Basis dieser Überlegungen und Erkenntnisse ergab sich dann die Idee eines zweiten, fortschrittlicheren Konzepts. Vorangetrieben wurde die zweite Konzeptidee in erster Linie durch die Überlegung einen XMPP-Account pro Dienst zu verwenden Idee: Mobilis-P2P-Server-Architektur Die einfachste Möglichkeit, eine verteilte Laufzeitumgebung zu erhalten ohne die komplette Komponentenarchitektur des Mobilis-Servers verändern zu müssen ist, einfach mehrere Mobilis-Server in ihrer bisherigen Form gleichzeitig zu verwenden. Die Komponentenarchitektur wird wie in Abbildung 2.5 dargestellt, beibehalten und ggf. erweitert. Jeder einzelne Server bringt die Laufzeitumgebung für die Dienste und die auf der Service Registry aufbauende Service Discovery mit. 36 Copyright TU Dresden, Philipp Grubitzsch

53 4 Konzeption Verteiltes Service-Hosting Abbildung 4.3: Getrennte Service Registry von zwei Mobilis 2.0 Servern In dieser Form hat der Client in Abbildung 4.3, welcher die Service Discovery von Server A verwendet, allerdings noch keine Kenntnis über Dienste, welche auf Server B laufen. Da jede Dienstinstanz in Mobilis aber durch eine eigene Full-JID adressiert wird und der Endpunkt der Clientkommunikation immer diese Full-JID ist, spielt es keine Rolle, wo genau ein Dienst läuft, um ihn zu verwenden. Der Client könnte sich also bereits in der Mobilis 2.0-Architektur ohne Probleme mit einer entfernten laufenden Dienstinstanz verbinden, sobald er nur dessen Full-JID kennen würde. Abbildung 4.4: Dienstsynchronisation der Service Registrierungen zweier Server Wenn nun die Service Discovery von Server A Kenntnis über jeden auf Server B laufenden Dienst hätte, dann könnte der Client auch die Dienste von Server B nutzen. Die Lösung für das grundsätzliche Problem ist also eine Synchronisation der Service Registries zwischen den Servern wie in Abbildung 4.4 dargestellt. Server B teilt Server A mit, dass bei ihm ein Dienst B1 läuft. Server A nimmt den Dienst B1 in seine Service Registry auf. Nun hat der Client über die Service Discovery von Server A Kenntnis über Copyright TU Dresden, Philipp Grubitzsch 37

54 Verteiltes Service-Hosting 4.1 Mögliche Zielarchitekturen den Dienst B1. Abbildung 4.5 gibt einen Überblick, wie das Netz einer Mobilis-P2P-Server-Architektur beschaffen ist. Grundsätzlich ist es möglich, dass ein Server seine Registry mit der Registry jedes beliebigen anderen Mobilis-Servers synchronisieren kann. Sind zwei Server synchronisiert, so liefert die Service Discovery eines Servers auch die Informationen über die laufenden Dienste des jeweils anderen Servers. Ein Server sollte aber nur die eigenen lokal laufenden Dienste mit einem anderen Server synchronisieren dürfen. So wird sichergestellt, dass ein Server A die verfügbaren Dienste von Server B nicht unberechtigt an Server D weitergibt. In der Abbildung kann Client 3 zum Beispiel nur die Dienste von Server D und A nutzen. Server A hat zwar auch Informationen von entfernten Diensten auf den Servern B und C, diese werden aber nicht mit Server D synchronisiert. Client 1 wiederum kann die Dienste aller Server verwenden, da sein Server A mit allen anderen Servern synchronisiert ist. Abbildung 4.5: Mobilis P2P-Server-Architektur Im Vergleich zur ersten Konzeptidee ist also die Notwendigkeit der Synchronisation von Service Registry-Einträgen erhalten geblieben. Damit ein Client einen entfernten Dienst jederzeit nutzen kann, sobald er verfügbar ist, muss die von ihm verwendete Service Registry diese Informationen in Echtzeit verwalten können. Darüber hinaus besteht auch weiterhin die Problematik Zugriffsbeschränkungen abzubilden und persistent zu halten. Statt nun extra eine Datenbankanbindung für jeden Server für eben diese beiden Problematiken einzusetzen, wurde für diese Konzeptidee von vornherein eine deutlich elegantere Lösung vorgesehen: Der Einsatz von XMPP-Presence und XMPP-Roster. Die Grundidee ist, dass jede Dienstinstanz bereits in Mobilis 2.0 über eine eigene Full- JID adressiert wird, d.h. sie sind als XMPP-Entitäten in der Lage, eigene Presence- Informationen zu verbreiten. Bereits im ersten Konzeptentwurf wurde vorgesehen, dass jeder installierte Dienst in Zukunft auch einen eigenen XMPP-Account verwendet. In 38 Copyright TU Dresden, Philipp Grubitzsch

55 4 Konzeption Verteiltes Service-Hosting diesem Konzept kann dadurch jeder Dienst als Rostereintrag des Mobilis-Servers verwaltet werden. Dadurch wird einerseits die Datenbank für die Persistenz der Service Registry überflüssig, da der XMPP-Server diese Informationen im Roster des Servers speichert, andererseits wird durch Verwenden von bestehenden Mechanismen zum Verbreiten von Verfügbarkeitsinformationen in Echtzeit der Entwicklungsaufwand für ein neues Kommunikationsprotokoll erheblich reduziert. Auch das Abbilden von Zugriffsbeschränkungen kann durch den Roster umgesetzt werden. Jeder Nutzer von Mobilis muss in Zukunft, genauso wie jeder Dienst, seinen eigenen XMPP-Account haben. Nutzeraccounts mit bestimmten Administrationsrechten kann der Mobilis-Server dann ebenfalls seinem Roster hinzufügen. Durch Zuordnen zu verschiedenen Rostergruppen können die Rechte eines Nutzers ähnlich wie bei Sicherheitsgruppen in modernen Betriebssystemen definiert werden. Wie schon für die Service Registry übernimmt der auf dem XMPP-Server gespeicherte Roster die Rolle der externen Datenbank. Die detailierte Vorstellung dieses Konzept folgt in Abschnitt Diskussion Durch das Weiterverwenden der bisherigen Architektur würde sich der Entwicklungsaufwand bereits deutlich verringern, da die eigentliche Struktur der Komponenten nicht verändert wird, sondern die Komponenten selbst in ihrer Funktion lediglich erweitert werden müssen. Mit der P2P-Architektur können genauso verteilte Dienstumgebungen zur horizontalen Skalierung aufgebaut werden wie in der ersten Konzeptidee. Sie bietet aber zusätzlich den Vorteil der höheren Ausfallsicherheit, da jeder Mobilis-Server die Rolle eines Discovery-Servers einnehmen und einen ausgefallenen Discovery-Server so leicht ersetzen kann. Durch sie können auch lose zusammenhängende Gesamtnetze gebildet werden, bei denen jeder Server oder jedes Teilnetz von unterschiedlichen Betreibern geführt wird. In einem solchen Szenario steht vor allem das deutlich erhöhte Dienstangebot im Vordergrund. Serverbetreiber können ihren Clients auch Dienste anbieten, die sie nicht selbst hosten. Der Roster als Ersatz für eine Datenbank und die Echtzeitverfügbarkeit durch XMPP- Presence bringen geeignete Mechanismen mit, um die Service Registry für verteilte Dienste mit deutlich reduziertem Aufwand zu erweitern. Copyright TU Dresden, Philipp Grubitzsch 39

56 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts Abbildung 4.6: Roster zur Verwaltung von Service Registry und Zugriffsberechtigungen 4.2 Detailbetrachtung des Rosterkonzepts In diesem Abschnitt wird das Konzept für das verteilte Dienst-Hosting auf Basis des XMPP-Rosters vorgestellt. Dazu werden benötige Technologien, Informationen und Strukturen zusammengetragen und die Integration in die bisherige Architektur beschrieben Generelle Funktionsweise Im Zentrum der Konzeption der ausgewählten P2P-Server-Architektur steht zur Verwaltung von Service Registry und Zugriffsberechtigungen der XMPP-Roster. Abbildung 4.6 gibt einen Überblick über das Funktionsprinzip der verteilten Dienstumgebung mit zwei Servern. Ein Mobilis-Server soll von nun auch Runtime-Server oder einfach nur kurz Runtime genannt werden. Runtime 1 soll im Beispiel die Rolle der entfernten Laufzeitumgebung spielen, während Runtime 2 die Service Discovery für Nutzer übernimmt. Das Beispiel berücksichtigt dabei auch Sicherheitsmechanismen. 1. Upload des Dienstes a) Runtime 1 prüft im eigenen Roster, ob sich der Account dev1@xmpp.com in der Rostergruppe»deploy«befindet. b) Der Nutzer ist berechtigt, und der Dienst wird hochgeladen. 2. Installation des Dienstes 40 Copyright TU Dresden, Philipp Grubitzsch

57 4 Konzeption Verteiltes Service-Hosting a) Runtime 1 legt für den Dienst einen XMPP-Account mit der Bare-JID»rt1.xhunt@xmpp.com«an. b) Runtime 1 legt eine Rostergruppe mit der Bezeichnung des Dienstes an und fügt den hochladenden Nutzer als Dienstadministrator hinzu. 3. Synchronisation mit entfernten Runtimes a) Runtime 1 prüft in der Rostergruppe»runtimes«, welche vertrauenswürdigen entfernten Runtimes sie kennt. Die einzige in der Rostergruppe ist»rt2@xmpp.com«b) Runtime 1 schickt an Runtime 2 eine Nachricht zur Synchronisation, welche die Bare-JID»rt1.xhunt@xmpp.com«des neuen Dienstes enthält. c) Runtime 2 prüft, ob in der eigenen Rostergruppe»runtimes«die Bare-JID von Runtime 1 enthalten und somit berechtigt ist, Dienste mit Runtime 2 zu synchronisieren d) Runtime 2 fügt die Bare-JID des neuen Dienstes der eigenen Rostergruppe»services«hinzu. 4. Publikation neuer Dienstinstanzen a) Wird auf der Runtime 1, eine Instanz des Dienstes»Xhunt«gestartet, so verwendet der zugehörige Mobilis-XMPP-Agent (Vgl. Abb. 2.6), ebenfalls den Account»rt1.xhunt@xmpp.com«, aber pro neuer Dienstinstanz erweitert um eine Ressource»/i1«,»/i2«usw.. b) Durch XMPP-Presence wird der Roster von Runtime 2 automatisch in Echtzeit über die Verfügbarkeit von neu angemeldeten und verfügbaren Ressourcen des Accounts mit der Bare-JID»rt1.xhunt@xmpp.com«informiert. 5. Binden von entfernten Diensten a) Der Coodinator Service der Runtime 2 durchsucht den eigenen Roster, um Informationen über entfernte Dienste zu erhalten b) Bei einer Service Discovery-Anfrage durch einen Nutzer werden die Full-JIDs der entfernten Dienstinstanzen geliefert. c) Der Nutzer wählt mit seinem Client eine Dienstinstanz zum Verbinden aus. Durch diesen Ablauf kennt die Runtime 2 bereits alle Full-JIDs der entfernten Dienstinstanzen auf der Runtime 1. Was aber, wenn die Runtime 2 bei einer Discovery-Anfrage durch den Nutzer aus allen Diensten im Roster nur Dienstinstanzen von»xhunt«liefern soll? Hierfür reicht dieser Ansatz allein noch nicht aus. Zudem ist es in diesem Beispiel dem Nutzer nicht möglich, von Runtime 2 aus eine Dienstinstanz auf Runtime 1 zu starten. Bei der Synchronisation zwischen den Runtimes müssen noch einige Spezialfälle berücksichtigt werden. Was passiert z.b., wenn Runtime 2 gerade offline ist, während Runtime 1 den XHunt-Dienst veröffentlicht und dann online kommt? Die folgenden Unterabschnitte sollen weitere notwendige Voraussetzungen für den Betrieb der Service Copyright TU Dresden, Philipp Grubitzsch 41

58 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts Registry für verteilte Dienste klären. Dabei wird unter Verwendung von Rostergruppen auch ein Ansatz zur einfachen Verwaltung der Zugriffsberechtigungen vorgestellt Roster als Service Registry Das in Abschnitt vorgestellte Konzept muss noch so erweitert werden, damit ein spezieller Dienst von allen Rostereinträgen in der Rostergruppe services unterschieden werden kann. In Abbildung 2.6 wurde bereits der Kern der bisherigen Laufzeitumgebung gezeigt. Diese Struktur wird für den lokalen Teil der Service Registry unverändert aus Mobilis 2.0 übernommen. Sie verwaltet die lokal installierten Dienste weiterhin als ServiceContainer durch den MobilisManager und die ServiceContainer wiederum verwalten sämtliche Dienstinstanzen die zu einem Dienst gehören. Der CoordinatorService durchsucht diese Struktur, um an die benötigten Informationen zu gelangen, sammelt diese und gibt eine Antwort entsprechend der Anfrage zurück. Die wesentlichen Informationen sind: ServiceNamespace ServiceVersion single/multi Instanz-Betriebsmodus Full-JIDs von Diensten Instanzname Bei der Remote Service Registry, welche die entfernten Dienste verwaltet, wird die Rostergruppe services durchsucht und alle Rostereinträge geholt (Vgl. Abb. 4.6). Dieser Schritt ist analog dem Holen aller ServiceContainer der lokalen Registry. Ein Rostereintrag alleine zeichnet sich aber nur durch eine Bare-JID aus. Darum müssen den angemeldeten Ressourcen die oben aufgelisteten Informationen angefügt werden, um sie unterscheidbar zu machen. Zusätzlich wird für die Remote Registry noch die Bare-JID der Host Runtime jedes Dienstes benötigt. Soll z.b. eine neue Instanz eines entfernten Dienstes erstellt werden, so muss die Anfrage zum Erstellen der Instanz an die Coordinator-JID der Runtime, auf welcher der Service läuft, weiter geleitet werden. Die XEP-0030: Service Discovery (Vgl. Abschnitt 2.1.4) ist das geeignete Werkzeug, um die benötigten Informationen einer XMPP-Entität als Feature-String hinzuzufügen. Bevor darauf ausführlicher eingegangen werden kann, muss noch ein weiteres Problem geklärt werden. Zusätzliche Ressource für verfügbaren Dienst Die bisher vorgestellte Funktionsweise einer Service Registry aufbauend auf dem XMPP- Roster benötigt noch eine Erweiterung. Im Roster sind die Dienstinstanzen als Res- 42 Copyright TU Dresden, Philipp Grubitzsch

59 4 Konzeption Verteiltes Service-Hosting sourcen des vom Dienst verwendeten XMPP-Accounts angemeldet. Bei einer Discovery- Anfrage, ob überhaupt ein bestimmter Dienst verfügbar ist, kann das in dieser Konfiguration zum Problem werden. Falls gar keine Dienstinstanz gestartet, d.h. keine Ressource online ist, hätte die Runtime keine Information über den verfügbaren Dienst. Daher muss ein installierter Dienst, sobald er läuft 1, zusätzlich eine XMPP-Ressource mit seinem XMPP-Account anmelden. Dieser zeigt dessen Verfügbarkeit, auch wenn keine Instanz gestartet ist. Diese zusätzliche Ressource pro Dienst soll Service-Presence-Resource genannt werden. Sie muss ebenso die vorher genannten Informationen zu ServiceNamespace, Version usw. halten, um für die allgemeine Service Discovery und das Erzeugen von neuen Instanzen verwendet werden zu können. Damit die Registry zwischen den Ressourcen der Dienstinstanz und der Service-Presence-Ressource unterscheiden kann, sollte der Feature-String, welcher die Informationen über eine Mobilis-Service-Entität enthält, auch eine Unterscheidung diesbezüglich ermöglichen. Feature-String nach XEP-0030 für Informationen zu XMPP Entity Als Feature-String dienen eindeutige Identifier, wie definierte URNs oder URLs. Die Basis des Feature-Strings bildet die für das Mobilis-Projekt reservierte DNS-Adresse: Der gesamte String wird ähnlich wie eine klassische URL aufgebaut. An diese werden zusätzlich Parameter wie z.b. bei HTTP-Get-Requests angehängt. Zur Unterscheidung des Typs einer Entität folgt nun entweder eine Ressource /instance für eine laufende Dienstinstanz oder /service für die im voherigen Abschnitt eingeführte Service-Presence-Ressource. Danach steht ein Trennsymbol»#«als Abgrenzung zu den Parametern. Parameter folgen der Syntax»key=value«und werden untereinander durch»,«getrennt. Die angehängten Parameter müssen abhängig vom Entity-Typ unbedingt folgende Reihenfolge haben: /instance# - Entity zeigt laufende Instanz an 1. servicenamespace - Der vollständige Namespace des Dienstes 2. version - Versionsnummer als Integer 3. name - Instanzname der konkreten Instanz 4. rt - Bare-JID der Host-Runtime des Dienstes /service# - Entity zeigt verfügbaren Dienst an 1. servicenamespace 2. version 3. mode - single/multi Instanzmodus 4. rt 1 Damit ist nicht das Laufen von Dienstinstanzen gemeint, sondern die Verfügbarkeit in der Service Discovery seiner eigenen lokalen Runtime. Copyright TU Dresden, Philipp Grubitzsch 43

60 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts Durch die fest definierte Reihenfolge wird das Zerlegen des Strings erleichtert, wenn auf dessen Daten zugegriffen werden soll. Listing 4.1 zeigt zur Veranschaulichung noch ein Beispiel eines vollständigen Feature-Strings für eine Instanz von Mobilis-Xhunt 2 : Listing 4.1: Feature-String einer Mobilis-Xhunt Instanz Entität 1 services/mobilisxhuntservice,version=3,name=mobilisxhunt,rt=mruntime1@philipp-pc Diskussion zur Effizienz Die alleinige Verwendung der Service Discovery würde bei der Abfrage der Eigenschaften jeder angemeldeten Ressource einen enormen Netzwerkverkehr verursachen, da bei jeder Service Discovery-Anfrage ein disco#info-request an jede angemeldete Ressource in der Gruppe rsg:services geschickt werden müsste. Daher macht es Sinn, die Service Discovery unter der zusätzlichen Verwendung der in Abschnitt vorgestellten XEP-0115: Entity Capabilities zu implementieren. Nach der ersten Abfrage pro Instanz wird der Netzwerkverkehr bereits erheblich reduziert, da jede Runtime dann durch den gecachten Verification String dessen Bedeutung kennt. Weiter optimieren lässt sich der Netzwerkverkehr, wenn der Feature-String keine sich oft ändernden Parameter mehr enthält. Das wäre vor allem der Parameter name, welcher den konkreten Namen der Instanz hält. Ideal wäre es, wenn dieser in Zukunft direkt von der Dienstinstanz abgerufen wird, nachdem die Instanz selbst durch die Service Discovery gefunden wurde. Dadurch würden sich die einzelnen Dienstinstanzen eines speziellen Dienstes, einer Runtime in ihrem Feature-String nicht mehr unterscheiden, was die Verwendung der Entity Capabilities sehr effizient macht. Ähnliche Überlegungen könnten bei den Parametern rt und mode eine weitere Steigerung der Effizienz bewirken Rostergruppen und initiale Konfiguration Die Rostergruppen in diesem Konzept haben zwei Aufgaben. Erstens sie definieren, um was für einen Typ von Rostereintrag es sich handelt. Das können Nutzer, Dienste und Runtimes sein. Und zweitens definieren sie Zugriffsberechtigungen. Rostergruppen zur Sortierung nach Typ Der Hintergedanke hier ist hauptsächlich das schnelle Durchsuchen eines speziellen Typs von Rostereinträgen. Es gibt zwar die Möglichkeit, die Eigenschaften von angemeldeten Ressourcen von Rostereinträgen mittels XEP-0030: Service Discovery zu definieren, der Nachteil dabei ist aber, dass jedes Mal alle Einträge durchsucht werden müssen. Sinn macht das für dieses Konzept vor allem für die Rostergruppe services, die alle entfernten 2 Dass die Basis URL des Feature-Strings und die Basis des»servicenamespace«parameters dieselbe URL sind, ist hier Zufall. Ein Dienstentwickler kann für den Service Namespace auch eine eigene URL wählen. Da XHunt innerhalb des Mobilis-Projekts entstanden ist, sind beide hier identisch. 44 Copyright TU Dresden, Philipp Grubitzsch

61 4 Konzeption Verteiltes Service-Hosting Dienste hält und für die Rostergruppe runtimes, welche alle entfernten Runtimes hält mit denen eine Synchronisation der Registry durchgeführt werden darf. Soll der Server nun alle Dienstinstanzen aus dem Roster holen, muss er nur noch die Einträge holen, welche in der Rostergruppe services sind. Dies beschleunigt den Suchvorgang, besonders bei Mobilis-Service Discovery-Anfragen. Rostergruppen als Sicherheitsgruppen Wie schon erwähnt können auch Accounts von speziellen Nutzern in den Roster einer Runtime aufgenommen werden. Diese werden Rostergruppen zugeordnet, welche die Zugriffsberechtigung auf spezielle Ressourcen 3 regeln. Das sind zum einen die Rostergruppen der Dienste, welche deren Administrationsrecht widerspiegeln und zum anderen die Rostergruppen des Servers. Hier wäre als Beispiel eine Administratorengruppe administrators sowie die Gruppe der zum Upload berechtigten Nutzer deploy zu nennen. Die im vorherigen Abschnitt bereits genannte Gruppe runtimes nimmt eine Sonderrolle ein. Neben ihrer Funktion, für die Synchronisation eine schnelle Suche durch Sortierung nach Typ zu ermöglichen, stellt sich gleichzeitig auch eine Sicherheitsgruppe dar. Eine Synchronisation mit einer anderen Runtime darf nur durchgeführt werden, wenn sich diese in dieser Gruppe befindet. Die Sicherheits bzw. Rostergruppen der Dienste könnten auch in den Rostern ihrer XMPP-Accounts angelegt und von den zugehörigen XMPP-Agenten verwaltet werden. Dieser Ansatz wäre effizienter, da der Roster der Runtime besonders bei sehr vielen installierten Diensten schnell sehr groß werden kann. Für diese Konzeption werden des geringeren Aufwands wegen die Sicherheitsgruppen der Dienste im Runtime-Roster angelegt. Erweiterung der Rostergruppenbezeichnung Damit sich die verschiedenen Rostergruppen besser unterscheiden lassen, wird jeder Rostergruppe durch»:«getrennt, ein typendefinierendes Tag vorangestellt. Das hat den Vorteil, dass eine in Zukunft für die Runtimeverwaltung weiterentwickelte Remote Console oder ein Webinterface diese Tags zur automatischen Identifikation verwenden können. Dadurch wird es möglich, leicht eine grafische Benutzeroberfläche auf Basis des Rosters zu entwickeln, die weniger an die typischen Instant Messenger Kontaktlisten erinnert, sondern viel mehr auf die Aufgaben zur Verwaltung des Mobilis-Servers zugeschnitten ist. Der Roster und die Rostergruppen als Erweiterung können daher auch als Schnittstelle zur Implementation dieser Benutzeroberfläche verstanden werden. Es sollen drei Typen eingeführt werden: securityusergroup = sug: hält Nutzeraccounts, die Zugriff auf das Objekt haben, was durch den Namen der Rostergruppe bestimmt wird. Zum Beispiel wird 3 Gemeint sind hier nicht XMPP-Ressourcen, sondern Objekte wie Server und Dienste generell. Copyright TU Dresden, Philipp Grubitzsch 45

62 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts allen Sicherheitsgruppen der Dienste dieses Tag vorangestellt. Der Name der Rostergruppe definiert den Dienst, für den sie die Zugriffsrechte bestimmt. remoteservicegroup = rsg: hält alle Accounts entfernter Dienste für schnelle Service Discovery securityruntimegroup = srg: hält alle Accounts vertrauenswürdiger Runtimes für eine schnelle Synchronisation der Service Registries Zusammenfassung Durch Verwendung von Rostern und Rostergruppen wird die einfache Verwaltung der Zugriffsberechtigungen in einem beliebigen XMPP-Instant Messenger möglich. Darüber hinaus beschleunigen sie die Service Registry-Synchronisation und die Service Discovery, da für diese Aufgaben nicht mehr alle Rostereinträge durchsucht werden müssen. Für dieses Konzept sind ausgehend von den Erläuterungen der vorherigen Abschnitte folgende Rostergruppen vorgesehen: nach Zugriffsbeschränkungen sug:administrators: Mitglieder der Gruppe haben volles Administrationsrecht auf dem Server sug:deploy: Mitglieder dieser Gruppe dürfen Dienste auf der Runtime installieren sug:[servicename+serviceversion]: generische Sicherheitsgruppe der Dienste mit der Bezeichnung aus servicename und serviceversion nach Typ srg:runtimes: hält entfernte Runtimes rsg:services: hält entfernte Dienste rsg:local-services: hält die lokalen Dienste der Runtime Algorithmen der Remote Service Registry Die vorherigen Abschnitte haben in Form von Komponenten, Strukturen und Informationen die nötigen Voraussetzungen geliefert, um die Service Registry zum Bereitstellen verteilter Dienste zu ermöglichen. In diesem Abschnitt sollen die nötigen Algorithmen für die drei wesentlichen Aufgaben, der allgemeinen Service Discovery, der speziellen Service Discovery und dem Erstellen von neuen Dienstinstanzen beschrieben werden, welche diese Komponenten und Informationen nutzen. Es wird dabei nur auf die Algorithmen für die entfernten Dienste detailliert eingegangen. Die Algorithmen für die lokalen Dienste werden nur im Gesamtzusammenhang erwähnt, da sie sich prinzipiell nicht geändert haben. 46 Copyright TU Dresden, Philipp Grubitzsch

63 4 Konzeption Verteiltes Service-Hosting Allgemeine Service Discovery Bei einer allgemeinen Service Discovery-Anfrage soll die Antwort alle Dienste, die der angefragten Runtime bekannt sind, liefern. Dazu werden für die Antwort zunächst alle lokalen Dienste mit ihren zugehörigen Informationen gesammelt. Danach wird der Algorithmus für die entfernten Dienste durchlaufen, welcher durch den Flow Chart in Abbildung 4.7 dargestellt ist. Abbildung 4.7: Ablauf der allgemeinen Service Discovery Zuerst wird der Roster der Runtime geholt und aus diesem die Rostergruppe rsg:services. Aus dieser wiederum wird eine Sammlung aller Einträge geholt, welche die Accounts aller bekannten Dienste sind. Sollte diese Sammlung (noch) Einträge enthalten, wird für den nächsten Eintrag eine Sammlung aller Ressourcen geholt, die gerade online sind. Hat diese Sammlung noch nicht verarbeitete Ressourcen, dann wird mit der nächsten fortgefahren und für diese das Feature-Set nach XEP-0030 geholt. Wie in Abschnitt beschrieben, kann eine Ressource eine Instanz oder die spezielle Service-Presence-Resource sein, welche durch die zwei verschiedenen Feature-Strings unterschieden werden können. Neben einem der beiden Strings hat jede Ressource aber noch andere Features, daher wird für jedes Feature geprüft, ob es eine Übereinstimmung mit einem der beiden erwähnten Mobilis-Strings für /instance# oder /service# gibt. Falls nicht, wird das nächste Feature geholt und geprüft. Bei einem»match«für den Service werden die Parameter für Service Namespace, Version usw. extrahiert und in ein den Dienst beschreibendes Service Discovery-Datenobjekt gespeichert. Handelt es sich um eine Instanz, wird die Anzahl der Dienstinstanzen im selben Datenobjekt um eins erhöht. Dies wird solange wiederholt, bis alle Ressourcen eines Eintrags verarbeitet wurden. Dann wird das Datenobjekt für diesen Dienst an die Antwortnachricht gehangen und zum nächsten Eintrag übergegangen. Sind alle Einträge verarbeitet, wird die Antwortnachricht versendet. Copyright TU Dresden, Philipp Grubitzsch 47

64 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts Spezielle Service Discovery Der Grundlegende Ablauf ist mit der allgemeinen Service Discovery zum Großteil identisch. Abbildung 4.8 zeigt den Ablauf der speziellen Service Discovery. Abbildung 4.8: Ablauf der speziellen Service Discovery Ein wesentlicher Unterschied ist, dass der eingehende Request eine Einschränkung nach Service Namespace und Version enthält. Die Antwort soll nur Instanzen zurückliefern, welche dieser Einschränkung genügen. Daher wird nach dem»feature match«einer Ressource eines Eintrags zusätzlich geprüft, ob diese beiden Parameter mit denen im Request übereinstimmen. Diese Prüfung wird auch für die Service-Presence-Resource durchgeführt. Falls die Prüfung ein negatives Ergebnis zurückliefert, handelt es sich für alle Ressourcen des aktuellen Eintrags um einen anderen Dienst als die einschränkende Anfrage fordert 4, und es kann direkt mit dem nächsten Eintrag fortgefahren werden. Dadurch erreicht man eine nicht unwesentliche Beschleunigung der Service Discovery für alle entfernten Dienste. Bei einer positiven Übereinstimmung der Parameter des Feature-Strings wird im Falle, dass es sich um eine Instanz handelt, die Full-JID der Ressource inklusive Service Namespace und Version als Service Instanz Daten Objekt an die Antwort gehängt. Im Falle der Service-Presence-Resource wird zur nächsten Ressource übergegangen, da sie selbst keine Dienstinstanz darstellt. Der restliche Ablauf stimmt mit der allgemeinen Service Discovery überein. 4 Das liegt daran, weil jeder Eintrag im Roster ein XMPP-Account eines einzelnen Dienstes ist und nur dessen Instanzen diesen Account verwenden. 48 Copyright TU Dresden, Philipp Grubitzsch

65 4 Konzeption Verteiltes Service-Hosting Erstellen von Dienstinstanzen Das Erstellen von neuen Dienstinstanzen folgt zusammengefasst dem Ablauf in Abbildung 4.9. Als Grundvoraussetzung für den den Algorithmus gilt: Dienstinstanzen werden nur auf entfernten Runtimes erzeugt, falls der Dienst nicht lokal verfügbar ist. Außerdem darf ein solcher Request nur einmal an eine entfernte Runtime weitergeleitet werden. Das soll einerseits verhindern, dass Nachrichten unendlich oft weitergeleitet werden und andererseits sollen so vorrangig die eigenen lokalen Ressourcen einer angefragten Runtime genutzt werden. Die Anfrage beinhaltet wie bei der speziellen Service Disco- Abbildung 4.9: Übersicht des Gesamtablaufs zum Erstellen von neuen Instanzen very, Service Namespace und Version. Zuerst wird versucht, lokal einen aktiven Service Container zu finden, welcher Namespace und Version genügt. Ist die Suche erfolgreich, wird die Dienstinstanz lokal wie bei Mobilis 2.0 erzeugt und der Client benachrichtigt. Wird kein Service Container gefunden, wird versucht Runtimes im Roster zu finden, welche den Dienst unterstützen. Dazu wird in einem komplexen Teilprozess ein Set aus Runtime-JIDs zusammengestellt. Ist das Set leer, wurde auch hier kein entsprechender Dienst gefunden, und es wird dem Client eine Fehlermeldung gesendet prüft, ob der Runtime, dessen Service Discovery genutzt wird, eben dieser Dienst bekannt ist. Sind in dem Set eine oder mehrere JIDs von Runtimes enthalten, dann wird aus diesen eine zufällig ausgewählt und der Request an die Runtime, welche die JID repräsentiert, weitergeleitet. Durch die zufällige Wahl sollte sich nach dem Gesetz der großen Zahlen eine gleichmäßige Lastverteilung ergeben. Der komplexe Teilprozess zum Finden der Runtime-JIDs, welche den Dienst unterstützen, ist in Abbildung 4.10 dargestellt. Der Ablauf ähnelt ebenfalls sehr den beiden vorgestellten Service Discovery Fällen. Wurde ein Mobilis-Feature-String bei einer angemeldeten Ressouce gefunden, werden zunächst alle Parameter des Strings extrahiert. Dann folgt eine Prüfung, ob Service Namespace und Version der Anfrage genügen. Bei einer positiven Prüfung wird der Wert des Parameter»rt«dem Set der Runtime-JIDs hinzugefügt. Bei einer negativen Prüfung müssen alle Ressourcen des aktuellen Eintrags zu einem anderen Dienst gehören, daher kann sofort mit dem nächsten Eintrag fortgefahren werden. Sind alle Rostereinträge verarbeitet, gibt der Teilprozess das Set dem vorher vorgestellten Hauptprozess zurück. Copyright TU Dresden, Philipp Grubitzsch 49

66 Verteiltes Service-Hosting 4.2 Detailbetrachtung des Rosterkonzepts Abbildung 4.10: Teilprozess: Sammeln aller entfernten Runtimes, welche einen speziellen Dienst unterstützen Diskussion zu den Algorithmen Die Algorithmen wurden primär so entworfen, dass der Roster für eine Service Registry von entfernten Diensten nutzbar gemacht werden kann. An offensichtlichen Stellen wurde versucht, die Algorithmen so zu gestalten, dass eine möglichst hohe Suchgeschwindigkeit erreicht wird. Es kann aber nicht ausgeschlossen werden, dass es schnellere Suchalgorithmen gibt. Das Vorgehen der Algorithmen hängt unter anderem auch von deren Grundvoraussetzungen aus den vorherigen Abschnitten ab. Eine zukünftige Umstrukturierung des Rosters macht eventuell einen Neuentwurf der Algorithmen erforderlich. Des Weiteren ist beim Erstellen von Dienstinstanzen die zufällige Wahl einer Runtime- JID aus dem Set nicht zwangsläufig optimal. An dieser Stelle gäbe es als weitere triviale Lösung das Round-Robin-Verfahren. Eine elegantere und effizientere Methode könnte auch sein, aus allen möglichen Runtimes diejenige mit der geringsten Auslastung zu wählen. Der Algorithmus müsste dann nur geringfügig erweitert werden. Dazu publiziert jede Runtime über das in Abschnitt vorgestellte Presence-Tag <status> noch zu definierende Auslastungszustände. Das könnten z.b. Zahlenwerte von 1 bis 100 sein. Die JIDs im gefundenen SET müssen auch alle in der Gruppe srg:runtimes sein, in der die»befreundeten Runtimes«gehalten werden. Diese Einträge werden der Reihe nach durchlaufen und aus diesen, derjenige Eintrag mit dem geringsten Auslastungszustand im <status>-tag gewählt. An diese wird dann der Request zum Erstellen der Dienstinstanz weitergeleitet. Bis an diese Stelle wurde praktisch noch nichts über die Beschaffenheit der eigentlichen Kommunikation erwähnt. Dies soll das folgende Subkapitel zum Kommunikationsprotokoll klären. 50 Copyright TU Dresden, Philipp Grubitzsch

67 4 Konzeption Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Wie schon in der ersten Konzeptidee in Abschnitt sollen anhand der Aufgaben sowie der Endpunkte der zugehörigen Kommunikation Teilprotokolle der Kommunikation mit dem Mobilis-Server unterschieden werden. Abbildung 4.11 veranschaulicht die Teilprotokolle des Servers mit ihren zugehörigen Endpunkten und Nachrichten. Dabei sind geänderte Nachrichten im Vergleich zum bisherigen Protokoll von Mobilis 2.0 markiert. Abbildung 4.11: Teilprotokolle mit ihren Endpunkten und Nachrichten Besonders hervorzuheben ist zunächst der neu eingeführte Runtime Service, welcher für die Synchronisation von zwei Runtimes verantwortlich ist. Außerdem wurde der Admin Service aus der Architektur entfernt und dessen Funktionalität vollständig, wie bereits in der ersten Konzeptidee angedacht, in den Deployment Service übertragen. Die Protokolle wurde entsprechend ihren serverseitigen Endpunkten benannt. Die Modifikation einer Nachricht kann die Nachricht selbst betreffen, d.h. sie wird entweder in ihrer Struktur verändert, oder ihr möglicher Inhalt wird erweitert, wodurch sich die Verarbeitung an den Endpunkten verändern kann, aber nicht muss. Ein Beispiel für letzteres können z.b. neue Fehlerfälle sein, die als Antwort durch den Endpunkt an den»requestor«zurückgegeben werden. Die Nachricht selbst muss dabei nicht verändert werden. Die neuen Fehler werden weiterhin als error-typ einer Nachricht zurückgegeben. Auf der Client-Seite werden die Fehlertexte weiterhin nur zur Information des Nutzers ausgegeben. Copyright TU Dresden, Philipp Grubitzsch 51

68 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Die Remote Console als Endpunkt nimmt eine Sonderrolle als Client ein, da sie neben dem Deployment-Protokoll auch das Coordinator-Protokoll voll unterstützt. Das ist durch ihre administrativen Aufgaben bedingt. Diese erfordern u.a. das Prüfen, welche Dienste verfügbar sind und das manuelle Starten und Beenden von Dienstinstanzen. In den folgenden Abschnitten werden die Teilprotokolle innerhalb serverseitiger Endpunkte, bzw. der zugehörigen Komponenten Runtime Service, Deployment Service und Coordinator Service nach deren Aufgaben sortiert abgehandelt. Dabei werden sämtliche Abläufe im Betrieb der verteilten Architektur beleuchtet, um einen Gesamtüberblick über die Kommunikation zwischen allen Entitäten in der Mobilis-Architektur zu vermitteln. Nachrichten, die in Mobilis 2.0 bereits verwendet wurden und keine Änderungen erfahren haben, werden dabei nur kurz erwähnt und in den Gesamtzusammenhang eingeordnet. Änderungen an in Mobilis 2.0 bestehenden Nachrichten und die in Mobilis 3.0 neu hinzu gekommenen Nachrichten werden ausführlicher vorgestellt. Das Application- Protokoll zwischen Dienstclient und Serverdienst ist nur mit aufgeführt, um die Kommunikationsstruktur zu vervollständigen. Hinweis: Die Nachrichten in den folgenden Abschnitten sind mit einem XML-Namespace-Tag»xmlns«versehen. Die Art und Weise der Verwendung ist zur Zeit noch fehlerhaft. Der Fehler ist bereits in Mobilis 2.0 vorhanden gewesen, konnte aber bisher aus zeitlichen Gründen nicht beseitigt werden. Die folgenden Erklärungen oder die Funktion des Konzepts wird dadurch allerdings nicht beeinträchtigt Deployment Service: Deployment-Protokoll Der Deployment Service ist für das Bereitstellen von neuen Diensten und die Verwaltung bereits installierter Dienste verantwortlich. Der clientseitige Endpunkt ist die Remote Console. Dieser stellt eine Kommandokonsole zur Verfügung, mit denen Befehle an den Server gesendet werden können. Sämtliche Nachrichten des Protokolls sind in Abbildung 4.11 aufgelistet. In den folgenden Abschnitten werden aber nur die wesentlichen Änderungen am Protokoll erwähnt. Dabei wird nach den Aufgaben Upload, Installation und Verwaltung unterschieden. Die Funktion der Nachricht ExecuteSynchronize wird im Zusammenhang der Synchronisation in Abschnitt erläutert. Sie gehört aber zum Deployment-Protokoll, da ihr clientseitiger Endpunkt die Remote Console ist. Upload eines Dienstes Der Upload wird wie bisher in Mobilis 2.0 von der Remote Console aus durch Senden des prepareserviceupload-iq initiiert. Nach Empfang der Nachricht prüft der Deployment Service wie gehabt, ob die zu übertragende Datei akzeptiert wird. Neu hinzu kommt an dieser Stelle die Prüfung, ob die im from-attribut enthaltene JID Mitglied der Rostergruppe sug:deploy ist. Ist dies nicht der Fall, wird ein error gesendet mit dem Hinweis, dass der Nutzer nicht autorisiert ist(vgl. Listing 4.2). 52 Copyright TU Dresden, Philipp Grubitzsch

69 4 Konzeption Verteiltes Service-Hosting Listing 4.2: Error IQ bei fehlender Nutzerautorisation 1 <iq id="mobilis_28" to="philipp@philipp-pc/remote_rt1" from="mruntime2@philipp-pc/deployment" type ="error"> 2 <prepareserviceupload xmlns=" XMPPBeans:admin:prepareServiceUpload"> 3 <error type="modify"> 4 <not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> 5 <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">user philipp@philipp-pc is not authorized to upload files to runtime mruntime2@philipp-pc/deployment!</text> 6 </error> 7 </prepareserviceupload> 8 </iq> Für den Fall, dass beide Prüfungen in Ordnung sind, wird wie bisher ein IQ-result gesendet und die Datenübertragung gestartet. Installation des hochgeladenen Dienstes Nach Abschluss der Datenübertragung beginnt der Server automatisch mit der Installation des Dienstes. Dazu wird, wie in Abschnitt beschrieben, für den Dienst per XEP- 0077: In-Band Registration ein neuer eigener XMPP-Account angelegt. Die JID folgt dem Schema [usernameruntime].[dienstname]@[xmppserverdomäne]. Dadurch wird einerseits sichergestellt, dass es zu keinem Namenskonflikt beim Erstellen kommt, wenn zwei Runtimes am selben XMPP-Server, den selben Dienst installieren wollen. Andererseits lässt sich dadurch bereits an der Dienst-JID ablesen, auf welcher Runtime ein Dienst läuft, was auch die Administration des XMPP-Servers und der Runtime-Roster erleichtert. Gleichzeitig wird eine neue Rostergruppe nach Schema sug:[dienstname][dienstversion] im Roster angelegt (Vgl. Abschnitt 4.2.3) und standardmäßig die JID des Nutzers mit dem Upload-Request der Gruppe hinzugefügt. Ist der Dienst lokal komplett installiert, wird für ihn noch die Service-Presence-Resource aus Abschnitt angemeldet, um die Verfügbarkeit des Dienstes in fremden Rostern anzeigen zu können. Je nach Erfolg oder Misserfolg der Installation wird ein serviceuploadconclusion-iq als set oder error gesendet. Zuletzt folgt ein lokaler Methodenaufruf zur Synchronisation des Dienstes mit fremden Runtimes, auf den in Abschnitt noch eingegangen wird. Spezialfall: Reinstallation eines installierten Dienstes Beim Upload eines Dienstes kann es passieren, dass der Dienst bereits installiert ist. In diesem Fall wird der erneute Upload als Reinstallation interpretiert. Die Runtime geht zunächst wie bei einer Neuinstallation vor und prüft, ob die Request-JID in der Rostergruppe sug:deploy ist. Zusätzlich wird nun aber in die Rostergruppe mit der Dienstbezeichnung geschaut, ob die»requestor«-jid auch in dieser enthalten ist. Für den Fall, dass der Eintrag enthalten ist, wird die Anfrage gestattet. Die Rostergruppe des Dienstes wird bei einer Reinstallation aber nicht verändert. Copyright TU Dresden, Philipp Grubitzsch 53

70 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Verwaltung installierter Dienste Der Deployment Service bzw. das Deployment-Protokoll ist neben dem Bereitstellen von neuen Diensten auch für Verwaltungsaufgaben von bereits installierten Diensten zuständig. Das betrifft alle Aufgaben, welche nicht über den XMPP-Roster durchgeführt werden, und umfasst die Nachrichten InstallService, ConfigureService, RegisterService, UnregisterService, UninstallService und UpdateService. Diese Nachrichten dienen alle dazu, einen einzelnen Dienst zu konfigurieren. Die Nachrichten selbst mussten für Mobilis 3.0 nicht verändert werden. Allerdings ändert sich ihre Verarbeitung im Deployment Service und damit ihr möglicher Inhalt. Dienste sollen nur noch von berechtigten Nutzern verändert werden können. Dazu wird wie bereits erwähnt bei der Installation des Dienstes eine Rostergruppe im Roster der Host-Runtime angelegt. Wird nun z.b. eine der genannten Nachrichten zum Ändern eines installierten Dienstes»MobilisXHunt«der Version»3«an den Deployment Service gesendet, dann prüft dieser, ob sich die JID des from-attributs in der Rostergruppe»sug:MobilisXHunt3«befindet. Am Beispiel Uninstall soll der neue Fall, stellvertretend für alle Nachrichten zur Verwaltung, gezeigt werden. Wie gehabt wird ein Uninstall-Request in Form eines IQ-set gesendet, welches den Service Namespace und die Version des zu ändernden Dienstes enthält: Listing 4.3: Unveränderter Request an den Deployment Service 1 <iq id="mobilis_26" to="mruntime2@philipp-pc/deployment" from="philipp@philipp-pc/remote_rt1" type ="set"> 2 <uninstall xmlns=" 3 <servicenamespace> servicenamespace> 4 <serviceversion>3</serviceversion> 5 </uninstall> 6 </iq> Sollte der»requestor«nicht in der Sicherheitsgruppe des Dienstes sein, dann wird ein IQ vom Typ error als Antwort zurückgegeben. Auch diese Nachricht ist an sich nicht neu, nur der eigentliche Fehlertext innerhalb Tags <text>, bedingt durch den neuen Kontext in dem sie gesendet wird: Listing 4.4: Neuer Fehlertext als in Error IQ der Deployment Service Nachrichten 1 <iq id="mobilis_26" to="philipp@philipp-pc/remote_rt1" from="mruntime2@philipp-pc/deployment" type ="error"> 2 <uninstall xmlns=" 3 <servicenamespace> servicenamespace> 4 <serviceversion>3</serviceversion> 5 <error type="modify"> 6 <not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> 7 <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"> 8 User philipp@philipp-pc is not authorized to modify service 9 version 3! 10 </text> 11 </error> 54 Copyright TU Dresden, Philipp Grubitzsch

71 4 Konzeption Verteiltes Service-Hosting 12 </uninstall> 13 </iq> Ist der»requestor«in der Gruppe, wird der Request normal wie bisher abgearbeitet und eine entsprechendes IQ vom Typ result als Bestätigung geschickt. Die Remote Console, welche die neuen Fehlertexte empfängt, gibt diese wie bisher einfach nur als Informationstext aus. Eine Anpassung ist an dieser Stelle daher ebenfalls nicht nötig. Sollte die Sicherheitsgruppe nicht existieren oder leer sein, dann hat falls der Dienst überhaupt installiert ist, jeder die Berechtigung den Dienst zu ändern Runtime Service: Runtime-Protokoll Das Runtime-Protokoll ist einzig und allein für die Synchronisierung der Remote-Service Registries zweier Mobilis-Server, genauer gesagt zwischen deren jeweiligen Runtime Services zuständig. Im wesentlichen gibt es einen allgemeinen Fall und zwei zu berücksichtigende Spezialfälle. Für alle drei Fälle wird nur eine einzige Nachricht benötigt: SynchronizeRuntimes. Allgemeine Synchronisation eines Dienstes Nach der erfolgreichen Installation eines Dienstes, ruft der Deployment Service beim Runtime Service seiner eigenen Runtime automatisch eine lokale Methode zur Synchronisation des neuen Dienstes mit anderen Runtimes auf. Abbildung 4.12 zeigt den genannten Methodenaufruf zwischem lokalem Deployment Service und Runtime Service sowie alle beteiligten externe Endpunkte und deren Nachrichtenaustausch. Der Teil des Deployment-Protokolls wurde bereits in in den Abschnitten Upload eines Dienstes und Installation des hochgeladenen Dienstes vorgestellt. Hier folgt nun die Beschreibung der Kommunikation ab dem internen Methodenaufruf zur Synchronisation. Die aufgerufene Methode holt sich zunächst die Rostergruppe srg:runtimes und schickt an alle Runtimes dieser Rostergruppe, die gerade online sind, einen Request, den neuen Dienst ihrem Roster hinzuzufügen (Vgl. Listing 4.5). Die Bare-JID des neuen Dientes wird dabei in dem Tag <servicejid> gekapselt. Der Request kann auch mehrere Dienst- JIDs enthalten (Dazu später mehr). Listing 4.5: Request zur Synchronisation 1 <iq id="mobilis_32" to="mruntime1@philipp-pc/runtime" from="mruntime2@philipp-pc/runtime" type=" set"> 2 <publishnewservice 3 xmlns=" 4 <servicejid>mruntime2.mobilisxhunt@philipp-pc</servicejid> 5 </publishnewservice> 6 </iq> Eine entfernte Runtime, welche diesen Request erhält, prüft nun wiederum im eigenen Roster, ob die JID im from-attribut des Requests in der eigenen Rostergruppe Copyright TU Dresden, Philipp Grubitzsch 55

72 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Abbildung 4.12: Abblauf der Kommunikation bei Upload und Installation eines neuen Dienstes srg:runtimes enthalten ist. Sollte dies der Fall sein, so wird die enthaltene Dienst-JID der Rostergruppe rsg:services hinzugefügt und anschließend eine Bestätigung der erfolgreichen Synchronisation gesendet: Listing 4.6: Result bei erfolgreicher Synchronisation 1 <iq id="mobilis_32" to="mruntime2@philipp-pc/runtime" from="mruntime1@philipp-pc/runtime" type=" result"> 2 <publishnewservice xmlns=" "/> 3 </iq> Sollte die anfragende Runtime nicht in der Rostergruppe srg:runtimes sein, so wird ein IQ-error mit dem Hinweis der fehlenden Autorisation gesendet: Listing 4.7: Error bei nicht erfolgter Synchronisation durch fehlende Autorisation 1 <iq id="mobilis_39" to="mruntime2@philipp-pc/runtime" from="mruntime1@philipp-pc/runtime" type=" error"> 2 <publishnewservice 3 xmlns=" 4 <servicejid>mruntime2.mobilisxhunt@philipp-pc</servicejid> 5 <error type="modify"> 6 <not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> 7 <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"> 8 mruntime2@philipp-pc is not an authorized Runtime of mruntime1@philipp-pc/runtime. Publish new service denied. 9 </text> 10 </error> 11 </publishnewservice> 12 </iq> 56 Copyright TU Dresden, Philipp Grubitzsch

73 4 Konzeption Verteiltes Service-Hosting Spezialfall 1: Gegenseitige Synchronisation aller Dienste Wenn eine Runtime 1 einen Dienst veröffentlicht, kann es vorkommen, dass eine»befreundete«runtime 2 in diesem Moment offline ist. Wenn Runtime 2 nun online kommt, hat sie keine exakten Informationen, welche Dienste aktuell von Runtime 1 unterstützt werden. Schlimmstenfalls kann es sogar vorkommen, dass Runtime 2 vorher ebenfalls Dienste veröffentlicht hat und in diesem Moment Runtime 1 offline war (Vgl. Abb. 4.13: 1.). In diesem Fall hätte keine der beiden Runtimes aktuelle Informationen über die jeweils entfernt laufenden Dienste (Vgl Abb. 4.13: 2.). Kommt eine Runtime online, sollte also eine zweiseitige Synchronisation mit jeder entfernten Runtime durchgeführt werden. Abbildung 4.13: Problem und Lösung bei offline Synchronisation Ein einfacher Ansatz die Service Registries der beteiligten Runtimes zu synchronisieren ist, dass wie im Beispiel eine online kommende Runtime 2 eine gegenseitige Synchronisation aller Dienste initiiert (Vgl. Abb. 4.13: 3.). Dazu kommt wieder das IQ synchronizeruntimes aus Listing 4.5, aber diesmal vom Typ get zum Einsatz. Runtime 1 setzt dieses als Request an alle»befreundeten«runtimes (im Beispiel nur Runtime 2) ab und hängt an dieses alle eigenen lokal laufenden Dienste jeweils in einem eigenen Tag <servicejid> an. Die empfangenden Runtimes fügen die übermittelten JIDs ihrer Rostergruppe rsg:services hinzu und hängen an das Result ihrerseits alle eigenen lokal laufenden Dienste an. Nun fügt auch Runtime 1 alle Dienste von Runtime 2 ihrem Roster hinzu. Copyright TU Dresden, Philipp Grubitzsch 57

74 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Wird ein Mobilis-Server runtergefahren, dann werden alle Dienst-JIDs in der Rostergruppe rsg:services aus dem Roster gelöscht. Dadurch wird jederzeit eine saubere Synchronisation aller Dienste gewährleistet. Der beschriebene Abblauf ist vom Ressourcenaufwand der Netzwerkkommunikation her nicht optimal, sondern soll lediglich die Machbarkeit der Synchronisation zeigen. Die Beispielnachrichten für get und result sind im Anhang unter Listing B.3 und B.4 zu finden. Speziallfall 2: Synchronisation nach Subscription Handshake Eine zweite Problematik bei der Synchronisation ergibt sich für den Fall, dass zwei Runtimes jeweils lokal Dienste installiert haben, bevor sie sich durch den»subscription Handshake«gegenseitig vertrauen. Sobald letzterer durchgeführt wurde, muss einer der beiden Runtimes die gegenseitige Synchronisation, wie in Spezialfall 1 beschrieben, initiieren. Grundsätzlich kann das automatisch durch einen Listener geschehen, der die Synchronisation ausführt, sobald in der Rostergruppe srg:runtimes ein neuer Eintrag auftaucht. Die Implementierung mit Smack machte es jedoch erforderlich, einen manuellen Mechanismus bereitzustellen. Dieser kann über den Befehl sync der Remote Console ausgeführt werden. Dazu wurde eigens eine IQ-Nachricht executesynchronizeruntimes erstellt. Diese wird allerdings an den Deployment Service gesendet, da er den serverseitigen Endpunkt der Kommunikation der Remote Console darstellt. Der Befehl erzwingt den bereits mehrfach genannten lokalen Methodenaufruf zur Synchronisation, allerdings für das im Spezialfall 1 vorgestellte IQ vom Typ get, da auch hier eine gegenseitige Synchronisation aller Dienste nötig ist. Die zugehörigen XML-Stanzas für das executesynchronizeruntimes-iq sind im Anhang unter Listing B.5 und B.6 dargestellt. Ein Nutzer muss Mitglied der Rostergruppe sug:administators des entsprechenden Runtime-Rosters sein, um diesen Befehl ausführen zu können Coordinator Service: Coordinator-Protokoll Das Coordinator-Protokoll beschreibt die Kommunikation zwischen Coordinator Service und Clients sowie zwischen zwei Coordinator Services verschiedener Runtimes. Es beinhaltet Nachrichten der Service Discovery zum Finden von Diensten und Dienstinstanzen sowie zum Starten und Beenden von neuen Dienstinstanzen. Das Stoppen von Dienstinstanzen ist dabei dem Console Client vorbehalten. Normale App Clients dürfen Instanzen nicht manuell beenden, da es sonst für einen Client möglich wäre, eine laufende Sitzung zu schließen, an der noch andere Clients beteiligt sind. Sobald alle Teilnehmer eine Instanz verlassen haben, wird die Instanz durch den Dienst automatisch beendet. 58 Copyright TU Dresden, Philipp Grubitzsch

75 4 Konzeption Verteiltes Service-Hosting Die wesentliche Kommunikation des Protokolls soll nun nach Aufgaben verteilt betrachtet werden. Dabei werden auch die in Abschnitt behandelten Algorithmen an den entsprechenden Stellen in den Kommunikationsablauf eingeordnet. Eine wichtige Anforderung in Kapitel 3.3 war, dass die Kommunikation zwischen Clients und Coordinator möglichst unverändert bleibt. Dadurch soll der Anpassungsaufwand der clientseitigen Anwendungen an die Mobilis 3.0-Architektur gering bleiben. Das konnte aber nicht vollständig erreicht werden. Erstellen von Dienstinstanzen Das Erstellen von Dienstinstanzen ist der einzige Teil des Coordinator-Protokolls, der für die neue Architektur angepasst werden musste. Nötig wurde dies, da die Nachricht zum Erstellen einer Instanz unter Umständen an eine entfernte Runtime weitergeleitet wird. Dabei können neben der längeren Nachrichtenlaufzeit auch die erforderlichen neuen Algorithmen zusätzliche Zeit in Anspruch nehmen. Mit dem alten Kommunikationsablauf könnte im schlimmsten Fall ein Client solange auf die Antwort für seine Instanz warten, dass er annimmt sein Request wurde vom Server nicht empfangen und sendet daher unnötig einen neuen Request. Abbildung 4.14: Nachrichtenverlauf beim Erstellen einer neuen Dienstinstanz Die Problematik wurde durch einen asynchronen Aufruf, ähnlich wie in Abbildung 2.9 in Kapitel 2.3 gelöst [WSWW09]. Abbildung 4.14 zeigt den neuen Ablauf der Kommunikation, an denen sich die folgenden Erläuterungen orientieren. Ein Client soll über die Runtime 1 eine neue Dienstinstanz von einem auf der Runtime 2 laufenden Dienst erzeugen. Copyright TU Dresden, Philipp Grubitzsch 59

76 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Zuerst wird wie gehabt ein IQ CreateNewServiceInstance vom Typ set gesendet, welches den Service Namespace und die Version sowie eine answerid beinhaltet (Vgl. Listing 4.8). Die»answerID«ist ein Schlüssel, der von dem Client, der den Request sendet, selbst erzeugt 5 wird. Dieser Schlüssel wird durch alle folgenden Nachrichten von den beteiligten Runtimes durchgeschleift und dient dazu, die entgültige Antwort diesem ursprünglichen Request wieder eindeutig zuordnen zu können. Listing 4.8: Clientrequest zum Erzeugen einer neuen Dienstinstanz 1 <iq id="mobilis_15" to="rt1@xmpp.com/coordinator" from="c1@xmpp.com/mxa" type="set"> 2 <createnewserviceinstance xmlns=" 3 <servicenamespace> </servicenamespace> 6 <serviceversion>3</serviceversion> 7 <answerid>fqhzy327</answerid> 8 </createnewserviceinstance> 9 </iq> Runtime 1 ruft nun den in Abschnitt vorgestellten Algorithmus zum Finden einer passenden Runtime auf. Da eine Runtime den angefragten Dienst unterstützt, muss sie als Antwort keinen Fehler senden. Stattdessen sendet sie nun als Antwort ein leeres IQ-result von CreateNewServiceInstance an den Client zurück: Listing 4.9: Leeres Result wird als IN BEARBEITUNG interpretiert 1 <iq id="mobilis_15" to="c1@xmpp.com/mxa" from="rt1@xmpp.com/coordinator" type="result"> 2 <createnewserviceinstance xmlns=" 3 </iq> Der Client hat diese Antwort nun in Mobilis 3.0 als»createserviceinstance in progress«zu interpretieren, d.h. er wartet bis der Server sich erneut bei ihm meldet! Gleichzeitig leitet Runtime 1 den Request des Clients, an die durch den Algorithmus gefundene Runtime 2 weiter. Dabei wird als zusätzliche Information der ursprüngliche»requestor«in Form von dessen Full-JID angehängt: Listing 4.10: Weiterleitung des Create-Requests an entfernte Runtime 1 <iq id="mobilis_22" to="rt2@xmpp.com/coordinator" from="rt1@xmpp.com/coordinator" type="set"> 2 <createnewserviceinstance xmlns=" 3 <originalrequestor>c1@xmpp.com/mxa</originalrequestor> 4 <servicenamespace> </servicenamespace> 7 <serviceversion>3</serviceversion> 8 <answerid>fqhzy327</answerid> 9 </createnewserviceinstance> 10 </iq> Runtime 2 führt nun ihrerseits den Algorithmus aus. Da bereits ein»requestor«an die Nachricht angehängt ist, darf sie diesen Request auf keinen Fall mehr weiterleiten, 5 Dazu sollte am besten ein sicherer Hash-Algorithmus verwendet werden, der den Schlüssel z.b. auf Basis von XMPP-Account und Datum nach dem Prinzip eines Salted Hashs erzeugt. 60 Copyright TU Dresden, Philipp Grubitzsch

77 4 Konzeption Verteiltes Service-Hosting weil dies bereits einmal geschehen ist. Im Normalfall sollte der Algorithmus aber ohnehin die Möglichkeit finden, eine Instanz des angefragten Dienstes lokal zu starten. In diesem Fall antwortet Runtime 2 ebenfalls mit einem leeren result-iq von CreateServiceInstance(Vgl Listing 4.9). Auch Runtime 1 hat diese Antwort mit»createserviceinstance in progress«zu interpretieren! Runtime 2 erzeugt nun die neue Instanz mit der JID»rt2.mobilisxhunt@xmpp.com/MobilisXHunt_v3#1«. Da Runtime 1 den eigentlichen Dienst bereits im Roster hat 6, wird die neue Dienstinstanz sobald sie ihr initiales Presence sendet sogar sofort per Service Discovery an Runtime 1 auffindbar. Damit der Client nun aber genau weiß, welche seine Instanz ist, muss ihm diese mitgeteilt werden. Dazu wurde die neue Nachricht SendNewServiceInstance eingeführt. Diese Nachricht nimmt die Route der ursprünglichen CreateNewService in umgekehrter Richtung. Runtime 2 sendet nun den neuen Dienst an Runtime 1. An die Nachricht von Typ set wird die Full-JID des neuen Dienstes und des ursprünglichen»requestors«angehängt: Listing 4.11: SendNewServiceInstance beinhaltet fulljid der neuen Instanz 1 <iq id="mobilis_97" to="rt1@xmpp.com/coordinator" from="rt2@xmpp.com/coordinator" type="set"> 2 <sendnewserviceinstance xmlns=" 3 <jidofnewservice>rt2.mobilisxhunt@xmpp.com/mobilisxhunt_v3#1</jidofnewservice> 4 <jidoforiginalrequestor>c1@xmpp.com/mxa</jidoforiginalrequestor> 5 <serviceversion>3</serviceversion> 6 <answerid>fqhzy327</answerid> 7 </sendnewserviceinstance> 8 </iq> Runtime 1 bestätigt den Emfang an Runtime 2 durch senden eines leeren IQ vom Typ result der selben Nachricht: Listing 4.12: Leeres Result als Empfangsbestätigung von SendNewServiceInstance 1 <iq id="mobilis_97" to="rt2@xmpp.com/coordinator" from="rt1@xmpp.com/coordinator" type="result"> 2 <sendnewserviceinstance xmlns=" 3 </iq> Danach entnimmt Runtime 1 den originalen»requestor«aus der empfangenen Nachricht und leitet die Nachricht an den Client, welcher eben genau diese Full-JID hat, weiter: Listing 4.13: Weitergeleitetes SendNewServiceInstance an den ursprünglichen»requestor«1 <iq id="mobilis_25" to="c1@xmpp.com/mxa" from="rt1@xmpp.com/coordinator" type="set"> 2 <sendnewserviceinstance xmlns=" 3 <jidofnewservice>rt2.mobilisxhunt@xmpp.com/mobilisxhunt_v3#1</jidofnewservice> 4 <serviceversion>3</serviceversion> 5 <answerid>fqhzy327</answerid> 6 </sendnewserviceinstance> 7 </iq> 6 Zur Erinnerung: Runtime 2 wurde sogar über die Service-Presence-Resource desselben Rostereintrag gefunden Copyright TU Dresden, Philipp Grubitzsch 61

78 Verteiltes Service-Hosting 4.3 Aufbau und Organisation des Kommunikationsprotokolls Der Client ordnet die Nachricht mit Hilfe der answerid wie beschrieben seinem eigenen ursprünglichen Request zu. Das ist auch aus Sicherheitsgründen sinnvoll, da sonst ein Angreifer zwischen der ursprünglichen CreateNewServiceInstance und einer echten SendNewServiceInstance-Antwort vom seiner Runtime, eine gefälschte SendNew- ServiceInstance platzieren und den Client so auf eine andere, möglicherweise gefährliche Dienstinstanz umleiten könnte. Der Client sendet nun noch ein leeres Result (Vgl. Listing 4.12), um dem Empfang zu bestätigen und beginnt danach die Kommunikation zu der erhaltenen Full-JID seiner neuen Dienstinstanz unter Nutzung des anwendungsspezifischen Kommunikationsprotokolls. Service Discovery Der Kommunikationsablauf für die generelle und die spezielle Service Discovery hat sich nicht geändert. Grundlegend handelt es sich dabei sowieso nur um eine Nachricht, welche entweder den Service Namespace und die Version enthält oder nicht. Der wesentliche Unterschied beider ist, dass die allgemeine Service Discovery Auskunft darüber gibt, welche Dienste überhaupt durch die angefragte Runtime angeboten werden, während die spezielle Service Discovery laufende Dienstinstanzen liefert. Abbildung 4.15 zeigt wie Abbildung 4.15: Nachrichtenverlauf der Service Discovery ein anderer Client den im vorherigen Anwendungsbeispiel erzeugten Dienst findet. Die Nachrichten werden hier nicht extra aufgelistet, da sie sich seit Mobilis 2.0 nicht verändert haben. Der Client macht mit seiner Anwendung gewöhnlich zunächst eine allgemeine Service Discovery bei Runtime 1. Diese ruft den in Abschnitt vorgestellten Algorithmus der allgemeinen Service Discovery auf, um den XHunt-Dienst im eigenen Roster zu finden und liefert als Antwort diesen als unterstützten Dienst. Die Clientanwendung weiß nun, dass XHunt überhaupt auf Runtime 1 unterstützt wird. Wäre dass nicht der Fall, 62 Copyright TU Dresden, Philipp Grubitzsch

79 4 Konzeption Verteiltes Service-Hosting würde die Clientanwendung von XHunt melden, dass Xhunt nicht an dieser Runtime unterstützt wird. Als nächstes sendet der Client eine spezielle Service Discovery-Anfrage mit Namespace und Version von Xhunt. Runtime 1 ruft nun ihrerseits den Algorithmus für die spezielle Service Discovery auf. Dadurch wird der im vorherigen Anwendungsbeispiel erzeugte Dienst im Roster von Runtime 1 gefunden, welcher nun als Antwort dem Client zurückgegeben wird. Dieser kann sich nun mit dem Dienst falls gewünscht verbinden. Diskussion zum Coordinator-Protokoll Interessant am in dieser Arbeit vorgestellten Konzept ist, dass für den Client vollkommen transparent bleibt, wo eine Dienstinstanz läuft. So werden von Anwendern trotz der neuen verteilten Architektur keine zusätzlichen Kenntnisse erwartet. Weiterhin ist bei einer Service Discovery-Anfrage durch die neue Architektur keine zusätzliche Kommunikation zwischen Runtime 1 und Runtime 2 erforderlich! (Vgl. Abb. 4.15) Die Informationen zu entfernten Diensten werden vollständig aus dem eigenen Roster geholt. Dadurch werden die Netzwerk Ressourcen geschont, während es grundsätzlich keine Einschränkungen der Service Discovery von Mobilis 3.0 gegenüber der von Mobilis 2.0 gibt. Mithilfe des geänderten Kommunikationsablaufs zum Erstellen von Nachrichten kann nun sichergestellt werden, dass Anfragen bei zu langer Bearbeitungszeit nicht unnötig mehrfach gesendet werden. Außerdem stellt die eingeführte answerid einen wichtigen Sicherheitsmechanismus dar. Der Ablauf der Clients: erstens allgemeine Service Discovery, zweitens spezielle Service Discovery, erzeugt unnötigen Netzwerkverkehr. Die Information, ob ein Dienst generell unterstützt wird, könnte als Feld an die Antwort der speziellen Service Discovery angehängt werden. Besser wäre aber einfach ein error-iq als Antwort zu senden. In beiden Fällen ließe sich die allgemeine Service Discovery vermeiden Mobilis Service: Application-Protokoll Das Anwendungsprotokoll ist für sämtliche Kommunikation der Anwendungsschicht einer generischen Mobilis-Anwendung aus Serverdienst, welche von der Klasse Mobilis- Service erbt und einem Anwendungsclient zuständig. Die Kommunikation auf dieser Protokollebene spielt erst eine Rolle, nachdem eine Verbindung von Service und Client durch das in der Arbeit relevante Coordinator-Protokoll etabliert wurde. Die Nachrichten des Anwendungsprotokolls werden durch den Dienstentwickler in der MSDL definiert und bei der automatischen Generierung der Code-Stubs in Java-Klassen gekapselt. Der genaue Ablauf wurde bereits in [Kie12] vorgestellt. Es soll hier nur der Vollständigkeit halber erwähnt werden. Copyright TU Dresden, Philipp Grubitzsch 63

80 Verteiltes Service-Hosting 4.4 Storage API für verteilte Dienste 4.4 Storage API für verteilte Dienste Im Laufe der Konzeption hat sich in Abstimmung mit dem Betreuer der Arbeit der Fokus aufgrund der Komplexität fast vollständig auf das verteilte Dienst-Hosting und die benötigten Security-Features verschoben. Dennoch soll ein kurzer Blick auf die Problemstellung der Storage API geworfen werden. In Mobilis gibt es bisher keine einheitliche Möglichkeit für die Entwickler, eine Datenbank zum Speichern ihrer Anwendungsdaten anzusprechen. Zum Betrieb des Mobilis-XHunt- Dienstes ist es z.b. nötig, am Server manuell eine speziell für den Dienst konfigurierte MySQL-Datenbank bereitzustellen. In einem Produktivsystem, bei dem die Betreiber von Mobilis-Server und der Anbieter eines Mobilis-Dienstes verschiedene Personen sein können, ist dies ein ungünstiger Umstand SQLite Datenbank Johannes Völker hat in seiner Diplomarbeit für seine Demoanwendung ebenfalls eine Datenbank benötigt [Vö13]. Sein FriendFinder Dienst legt dazu bei Bedarf eine SQLite- Datenbank an, welche vollständig in den Dienst eingebettet ist. Der Vorteil ist, dass hierdurch keine weitere Konfiguration vorgenommen oder ein separater Datenbank Server installiert werden müssen. Der Server muss lediglich Speicherplatz und Schreibzugriffe auf einen Ordner gewährleisten. Für Anwendungen, welche nur Datenstrukturen geringer Komplexität persistent halten müssen, sollte dieser Ansatz ausreichen. Der verwendete JDBC-Treiber erlaubt aber darüber hinaus auch eine externe MySQL-Datenbank zu verwenden Externe MySQL Datenbank Wie eine Datenbankschnittstelle für die Dienste implementiert werden müsste, hat Johannes Völker in [Vö13] gezeigt. Benötigt man nun eine leistungsfähigere Datenbank, wäre es denkbar, z.b. eine externe MySQL-Datenbank zu verwenden. Aufbauend auf der Arbeit von Johannes Völker benötigt der Dienst lediglich eine Konfiguration für den Datenbankzugriff. Ein Mobilis-Dienst wird vor der Installation als JAR-Archiv hochgeladen. In dieser Datei könnte eine Standardkonfiguration z.b. als XML-Datei enthalten sein. Bei der Installation des Dienstes auf dem Mobilis-Server, wird diese Datei in ein spezielles Verzeichnis gelegt und im Service Container des Dienstes verlinkt. Beim Start müsste der Dienst lediglich die in der XML-Konfigurationsdatei enthaltenen Informationen in die in [Vö13] vorgestellte Klasse DBProxy laden, um auf eine externe Datenbank zuzugreifen. Für die Anwendungsfälle, dass die Datenbank auf einen anderen Server umzieht oder sich die Login Daten ändern, müsste die Konfiguration angepasst werden. Das könnte in Zukunft als Erweiterung des Deployment Service in Mobilis implementiert werden. Die 64 Copyright TU Dresden, Philipp Grubitzsch

81 4 Konzeption Verteiltes Service-Hosting in Kapitel vorgestellten dienstabhängigen Rostergruppen gewährleisten, dass nur für einen Dienst autorisierte Nutzer diese Konfiguration ändern dürfen. Die eleganteste Möglichkeit wäre eine XMPP-IQ-Nachricht, welche folgende Informationen enthält: Die eigentliche Datenbankkonfiguration: Login, Passwort, Serveradresse, Datenbankname usw. Der Service Namespace Das from-attribut, welches den Nutzer der Anfrage enthält Für die eigentliche Datenbankkonfiguration wäre auch die Nutzung der Data Forms nach XEP-0004 denkbar. Der Ablauf nach Erhalt der Anfrage zum Ändern der Datenbankkonfiguration eines Dienstes am Server sähe folgendermaßen aus: 1. Der Server holt per Namespace den Service Container des Dienstes. 2. Er holt die zugehörige Rostergruppe des Dienstes mit den im Service Container hinterlegten Werten für Dienstname und -version. 3. Er prüft die Nutzerautorisation, indem er abgleicht, ob die JID des from-attributs in der Rostergruppe enthalten ist. 4. Er stoppt den Dienst und überschreibt die XML-Konfigurationsdatei mit den neuen Werten. 5. Bei Neustart des Dienstes wird die geänderte Konfiguration automatisch geladen. Dieser einfache Ablauf könnte unterschiedlichste Szenarien der Bereitstellung einer beliebigen Datenbank für jeden einzelnen Dienst eines Mobilis-Servers ermöglichen. Ein Dienstbetreiber könnte so selbst entscheiden, welche Datenbank er nutzt, wer sie betreibt und auf welchem Server sie läuft. Es wäre auf diesem Weg auch denkbar, dass der Betreiber eines Mobilis-Servers selbst eine Datenbank betreibt und bei der Installation der Dienste obligatorisch eine eigene Standardkonfiguration lädt. Eine detailliertere Konzeption und Referenzimplementierung müsste in Zukunft die Machbarkeit dieser Idee noch evaluieren. Copyright TU Dresden, Philipp Grubitzsch 65

82

83 5 Implementierung Verteiltes Service-Hosting 5 Implementierung Dieses Kapitel gibt einen Überblick über die Mobilis-Projektstruktur und einige wichtige Details der Implementierung. 5.1 Überblick über die Projektstruktur In Abbildung 5.1 ist ein Ausschnitt des Paketdiagramms des Mobilis-Projekts dargestellt. Es umfasst alle für die Implementierung dieser Diplomarbeit interessanten Pakete. Die wichtigsten Teilprojekte sind dabei der MobilisServer und MobilisXMPP. In ihnen wurde der wesentliche Teil der Implementierung des Konzepts vorgenommen. Die dabei wichtigsten Klassen sind in der Abbildung in den rot hervorgehoben Paketen zu finden. Details der Implementierung werden für Mobilis-XMPP in Abschnitt 5.2 und den Server in Abschnitt 5.3 vorgestellt. Bei den externen Bibliotheken spielt Smack für die Abbildung 5.1: Überblick über die wichtigsten Pakete der Implementierung Implementierung mit Abstand die größte Rolle. Ihre API stellt die wesentlichen Funktionen von XMPP bereit. Sie wurde bei Beginn der Implementierung auf die Version 3.3 aktualisiert. Das wurde nötig, da erst diese Version die XEP-0115: Entity Capabilities offiziell und vollständig unterstützt. Dadurch musste allerdings vorerst der BOSH-Support Copyright TU Dresden, Philipp Grubitzsch 67

84 Verteiltes Service-Hosting 5.2 MobilisXMPP aufgegeben werden, da für die neue Smack Version keine angepassten Bibliotheken zur Verfügung standen. Prinzipiell verlief das Update von Smack aber relativ problemlos und sollte in Zukunft regelmäßig durchgeführt werden. Die bisher entwicklelten Mobilis-Dienste (<Generic Mobilis Service>) können ohne Änderung weiter verwendet werden, da sie nicht selbst mit dem Server kommunizieren und die Änderungen an Protokoll und Service Registry sie dadurch nicht betreffen. Lediglich die zugehörigen Anwendungsclients müssen an die neue Architektur von Mobilis 3.0 angepasst werden. Dies wurde für die Android-Clients (<Generic Mobilis Android Service Client>) von XHunt und dem von Johannes Völker entwickelten FriendFinder exemplarisch durchgeführt. Die wichtigsten Änderungen werden in 5.4 am Beispiel von XHunt vorgestellt. Die Remote Console wird durch das Teilprojekt Mobilis_ConsoleClient zusammengefasst. Wie bei den Android-Clients mussten auch hier einige Anpassungen durch die Änderung am Kommunikationsprotokoll durchgeführt werden. Diese werden in Abschnitt 5.5 kurz abgehandelt. Das MXJ und das MXA Projekt stellen für verschiedene Zielplattformen (hier Java und Android) Funktionen zur Transformation von XML-basierten XMPP-Nachrichten in Java Beans und umgekehrt bereit 1. Die zu verarbeitenden Java Beans werden durch das Paket xmpp.beans im MobilisXMPP Projekt gekapselt. Eine plattformabhängige Implementierung einer Mobilis-Entität muss also sowohl die Beans als auch das plattformabhängige Projekt zur Transformation importieren. Zum Beispiel importiert der Mobilis_ConsoleClient als Java-Implementierung das MXJ und das MobilisXMPP Projekt. Ein Android-Client dagegen benötigt stattdessen das MXA, aber ebenfalls die Beans im MobilisXMPP Projekt. Eine Ausnahme stellt der Mobilis-Server dar, der als Java Implementierung die Klassen des MXJ selbst im Unterpaket xmpp.server hält. Eine vollständige Übersicht aller Pakete und deren Abhängigkeiten ist im Wiki des Mobilis-Git zu finden MobilisXMPP Das Projekt MobilisXMPP kapselt alle Nachrichten die zwischen Server und einem plattformabhängigen Client ausgetauscht werden in Form von Java Beans. Es bildet daher die Grundlage für fast alle Teilprojekte innerhalb der Mobilis-Architektur. Der komplette Aufbau der Vererbungshierarchie und der Abhängigkeiten sowie die Verarbeitung der Beans wurde in [Lü11] ausführlich beschrieben. 1 Nicht in der Abbildung: Für Javascript-Clients gibt es noch MXJS und für ios wurde zeitgleich zu dieser Arbeit noch das MXi entwickelt Copyright TU Dresden, Philipp Grubitzsch

85 5 Implementierung Verteiltes Service-Hosting Für die Implementierung des Konzepts nach Abbildung 4.11 wurden in diesem Projekt neue JavaBeans für die neuen Nachrichten des Kommunikationsprotokolls angelegt, bzw. die entsprechenden bestehenden Nachrichten angepasst. Die Gliederung der Paketstruktur erfolgt nach den Teilprotokollen des Kommunikationsprotokolls. Für das Runtime-Protokoll wurde zusätzlich unterhalb von xmpp.beans das Paket runtime angelegt. Die Nachrichten des ehemaligen AdminService wurden alle in das Paket deployment verschoben. Die Einordnung der JavaBeans in die entsprechende Pakete folgt damit bereits vollständig dem strukturellen Aufbau des Kommunikationsprotokolls im Konzept. Erwähnenswert an dieser Stelle ist noch die Einführung eines generalisierenden AdministrationBeans für einige Nachrichten des Deployment Protokolls. Diese vereinfachte die Verarbeitung der Zugriffsberechtigungen dieser Nachrichten am Server. Eine Übersicht der in die Paketstruktur einsortierten wichtigen Bean-Klassen ist im Anhang unter A.1 zu finden. Sämtliche Projekte die das MobilisXMPP-Projekt importieren, müssen eventuell in der Verarbeitung des Kommunikationsprotokolls angepasst werden. Das betrifft insbesondere den Mobilis-Server, die Java-, Javascript- und Android-Clients. 5.3 Der Mobilis-Server Der Mobilis-Server ist mit Abstand das umfangreichste Teilprojekt innerhalb der Mobilis- Architektur. An ihm wurde der Großteil der Änderungen durchgeführt. Die wichtigsten Pakete für die Implementierung des Konzepts am Server wurden im Paketdiagramm hervorgehoben. Aus diesen Paketen ist neben einigen Smack Strukturen der in Abbildung 5.2 dargestellte Ausschnitt des Klassendiagramms des Servers. Die meisten Abhängigkeiten wurden der Übersichtlichkeit wegen ausgeblendet. Die zentrale Klasse des Servers ist der MobilisManager. Er hält mehrere wichtige Komponenten und Sammlungen, welche die lokale und die entfernte Service Registry repräsentieren. Die Grundlage der lokalen Service Registry ist die bereits in Mobilis 2.0 existierende Struktur aus den Klassen ServiceContainer, MobilisService und Mobilis- Agent. Für die neu hinzu gekommene entfernte Service Registry sind die Klassen Roster, welche den Roster des Mobilis-Servers darstellt, sowie der ServiceDiscoveryManager und der EntityCapsManager welche die Funktionen der XEP-0030 und XEP-0115 in den Server integrieren, verantortlich. Die drei Klassen RuntimeService, CoodinatorService und DeploymentService stellen jeweils die serverseitigen Endpunkte eines der drei Kommunikationsprotokolle dar. Sie waren unter teilweise anderer Bezeichnung bereits in Mobilis 2.0 vorhanden und für die Logik der lokalen Registry verantwortlich. Sie nutzten dabei die oben bereits genannte Struktur. Für die neue entfernte Service Registry wird ähnlich vorgegangen. Dabei wird Copyright TU Dresden, Philipp Grubitzsch 69

86 Verteiltes Service-Hosting 5.3 Der Mobilis-Server Abbildung 5.2: Ausschnitt des Klassendiagramms des Mobilis-Servers allgemein zunächst der Roster vom MobilisManager geholt und anschließend die dahinter liegende Struktur aus den Klassen RosterEntry und Rostergroup. Um letztendlich Features von angemeldeten Ressourcen bestimmter Entries holen zu können, bedienen sie sich zusätzlich der Funktionen der Klassen ServiceDiscoveryManager und EntityCaps- Manager. In den folgenden Unterabschnitten werden einige wichtige Details der Klassen MobilisAgent, RuntimeService, CoordinatorService und DeploymentService vorgestellt Die Klasse MobilisAgent Die Verbindung jeder beim XMPP-Server angemeldete Ressource z.b. für eine Instanz eines Dienstes, wird durch jeweils eine Instanz der Klasse MobilisAgent gesteuert. Das bedeutet für die Implementierung des Konzepts, dass z.b. jede Service-Presence-Resource und jede angemeldete Instanz Ressource ihre eigene Instanz dieser Klasse verwenden. Damit im Roster einer entfernten Runtime später die Features eines Dienstes bzw. von dessen Instanzen ausgelesen werden können, müssen die Features vor der Anmeldung des XMPP-Agenten beim Server der Ressource hinzugefügt werden. Dazu hält jede Instanz des MobilisAgent einen eigenen ServiceDiscoveryManager und für die Unterstützung der Entity Capabilities einen EntityCapsManager. Beim Start des Agenten in der Methode startup() werden die Features auf die in Listing 5.1 dargestellte Weise angehängt. Listing 5.1: Anhängen der Feature-Strings an eine Mobilis Entität 1 mconnection.connect(); 2 servicediscoverymanager = ServiceDiscoveryManager.getInstanceFor(mConnection); 3 capsmaganger = EntityCapsManager.getInstanceFor(mConnection); 70 Copyright TU Dresden, Philipp Grubitzsch