Ein Kommunikations-Framework für die Selbstorganisation von Software-Systemen

Transkript

1 Fachhochschule Wiesbaden Fachbereich Design Informatik Medien Studiengang Allgemeine Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) Ein Kommunikations-Framework für die Selbstorganisation von Software-Systemen vorgelegt von Thorsten Stein am Referent: Prof. Dr. Kröger Korreferent: Dipl.-Inform. (FH) M.Sc. Markus Schmid

2 II

3 Erklärung gem. Prüfungsordnung Teil A Ich versichere, dass ich die Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Wiesbaden, Thorsten Stein Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit: Verbreitungsform Ja Nein Einstellung dieser Arbeit in die Bibliothek der FHW X Veröffentlichung des Titels dieser Arbeit im Internet X Veröffentlichung der Arbeit im Internet X Wiesbaden, Thorsten Stein III

4 IV

5 Vorwort Diese Diplomarbeit entstand im Labor für Verteilte Systeme an der Fachhochschule Wiesbaden. Ich möchte mich hiermit bei Herrn Prof. Dr. Kröger sowie bei Herrn Schmid für die hervorragende Unterstützung und Betreuung während der Erstellung dieser Arbeit bedanken. Ein besonderer Dank gilt meiner Verlobten Carmen, die die durch die Erstellung dieser Arbeit verursachten Zeiteinbußen geduldig ertrug und mich ständig neu ermutigte. Wiesbaden, im Februar 2006 Thorsten Stein V

6 VI

7 Inhaltsverzeichnis 1. Einleitung Grundlagen JXTA Begriffe Die Architektur Die Protokolle Rendezvous-Protokoll (RVP) Peer Resolver-Protokoll (PRP) Peer Discovery-Protokoll (PDP) Peer Information-Protokoll (PIP) Endpoint Routing-Protokoll (ERP) Pipe Binding-Protokoll (PBP) Das J2SE-Binding Starten der JXTA-Plattform Erzeugung einer Gruppe Erzeugung einer OutputPipe Senden einer Nachricht Veröffentlichen von Ressourcen Java Command Language Selbstorganisation Management Selbstmanagement Service-Level Agreements Wahl-Algorithmen Analyse Problembeschreibung Anwendungsszenario Allgemeine Überlegungen Rahmenbedingungen und Anforderungen Gruppenmanagement VII

8 3.6 Koordination Überblick Wahl Auktion Markt Vorgehensweise bei der Integration Design-Entscheidungen Design Grobarchitektur Kommunikation und Gruppenmanagement Kommunikation Gruppenmanagement Koordination Der Wahl-Mechanismus Der Auktions-Mechanismus Der Markt-Mechanismus Integration Überblick Der Strategie-Adapter Das Strategie-Modul Threading-Modell Implementierung Allgemeines Entwicklungsumgebung Namenskonventionen Initialisierung des JXTA-Frameworks Kommunikation und Gruppenmanagement Kommunikation Gruppenmanagement Koordination Hilfsklassen Der Wahl-Mechanismus Der Auktions-Mechanismus Der Markt-Mechanismus VIII

9 5.5 Integration Der Strategie-Adapter Das Strategie-Modul Die SalesAgents Hilfsklassen Zusammenfassung Bewertung Bewertung des zeitlichen Verhaltens Nachrichtenkomplexität des Wahl-Mechanismus Einbindung des Frameworks Einbindung des Auktions-Mechanismus Einbindung des Markt-Mechanismus Zusammenfassung Zusammenfassung Literaturverzeichnis A XML-Schemata A.1 reduziertes wsla-schema A.2 ElectionMessage A.3 CoordinatorMessage A.4 CoordinatorPipeMessage A.5 OfferMessage A.6 AuctionAckMessage A.7 AuctionRejectedMessage A.8 AuctionMessage A.9 BidMessage A.10 BidAckMessage A.11 AuctionWonMessage A.12 AuctionDoneMessage A.13 AuctionAbortedMessage A.14 AuctionEndMessage IX

10 A.15 MarketOfferMessage A.16 BuyMessage A.17 BuyAckMessage A.18 BuyRejectedMessage B Quelltexte B.1 Erzeugung der JXTA-Plattformkonfiguration X

11 Abbildungsverzeichnis Abbildung 2-1: Beispiel für in Gruppen organisierte Peers... 7 Abbildung 2-2: Schematische Darstellung einer Nachricht... 9 Abbildung 2-3: Schematische Darstellung der Schichten einer JXTA-Anwendung (nach [6]) Abbildung 2-4: Ablauf des Auffindens eines Peers und dessen Ressourcen Abbildung 2-5: Kopplung von Selbstmanager und Anwendung Abbildung 2-6: Struktur eines WSLA-konformen SLAs (nach [21]) Abbildung 2-7: Darstellung einer Wahl mit Hilfe des Bully-Algorithmus Abbildung 3-1: Beispiel eines Workflows mit einer Dienstgütevereinbarung (SLA) Abbildung 3-2: Anwendungsfälle Abbildung 3-3: Ablauf einer Wahl Abbildung 3-4: Ablauf einer Auktion Abbildung 3-5: Verkauf auf dem Marktplatz Abbildung 4-1: Grobarchitektur Abbildung 4-2: Struktur des Teilsystems Kommunikation Abbildung 4-3: Klassendiagramm Message Abbildung 4-4: Klassendiagramm MessageElement Abbildung 4-5: Klassendiagramm SimplePipe Abbildung 4-6: Klassendiagramm ServerPipe Abbildung 4-7 Klassendiagramm IServerPipeEvent Abbildung 4-8: Klassendiagramm BiDiPipe Abbildung 4-9: Klassendiagramm IMessageEvent Abbildung 4-10: Interaktion zwischen ServerPipe und BiDiPipe Abbildung 4-11: Struktur des Teilsystems Gruppenmanagement Abbildung 4-12: Klassendiagramm Peer Abbildung 4-13: Klassendiagramm Group Abbildung 4-14: Klassendiagramm IGroup Abbildung 4-15: Klassendiagramm UnprotectedGroup Abbildung 4-16: Klassendiagramm SecureGroup Abbildung 4-17: Klassendiagramm PasswordProtectedGroup XI

12 Abbildung 4-18: Struktur des Teilsystems Koordination Abbildung 4-19: Klassendiagramm Subject Abbildung 4-20: Klassendiagramm Predicate Abbildung 4-21: Wahl-Automat Abbildung 4-22: Klassendiagramm ElectionMessage Abbildung 4-23: Klassendiagramm ElectionWorker Abbildung 4-24: Klassendiagramm IElection Abbildung 4-25: Zusammenspiel der Klassen des Wahl-Mechanismus Abbildung 4-26: Auktions-Automat, Rolle: Anbieter Abbildung 4-27: Auktions-Automat, Rolle: Bieter Abbildung 4-28: Auktions-Automat, Rolle: Auktionator Abbildung 4-29: Klassendiagramm AuctionAckMessage Abbildung 4-30: Klassendiagramm AuctionWorker Abbildung 4-31: Klassendiagramm IAuctionListener Abbildung 4-32: Zusammenspiel der Klassen des Auktions-Mechanismus Abbildung 4-33: Automat Markt-Mechanismus Abbildung 4-34: Klassendiagramm MarketOfferMessage Abbildung 4-35: Klassendiagramm MarketplaceWorker Abbildung 4-36: Klassendiagramm IMarketplaceListener Abbildung 4-37: Zusammenspiel der Klassen des Markt-Mechanismus Abbildung 4-38: Struktur des Teilsystems Integration Abbildung 4-39: Klassendiagramm Adapter Abbildung 4-40: Klassendiagramm StrategyModule Abbildung 4-41: Klassendiagramm MarketAgent Abbildung 4-42: Sequenzdiagramm zur Erzeugung des Strategie-Moduls Abbildung 5-1: Package de.fhwiesbaden.tstei001.sof.configuration Abbildung 5-2: Klassendiagramm Bootstrap Abbildung 5-3: Klassendiagramm PipeFactory Abbildung 5-4: Klassendiagramm ServerPipeHelper Abbildung 5-5: Klassendiagramm AsyncGroupDiscovery Abbildung 5-6: Klassendiagramm Alarmclock Abbildung 5-7: Klassendiagramm Election Abbildung 5-8: Klassendiagramm AuctionHandler Abbildung 5-9: Klassendiagramm MarketplaceHandler XII

13 Abbildung 6-1: Versuchsaufbau Abbildung 6-2: zeitliches Verhalten des Auktions-Mechanismus bei der Beauftragung von Auktionen Abbildung 6-3: zeitliches Verhalten des Auktions-Mechanismus bei der Abgabe von Geboten Abbildung 6-4: zeitliches Verhalten des Markt-Mechanismus bei dem Einstellen von Verkaufsangeboten Abbildung 6-5: zeitliches Verhalten des Markt-Mechanismus bei der Abgabe von Kaufangeboten Abbildung 6-6: Nachrichtenkomplexität des Wahl-Mechanismus Abbildung 6-7: Workflow des Fallbeispiels XIII

14 Quelltextverzeichnis Quelltext 2-1: Erzeugung der Weltgruppe Quelltext 2-2: Erzeugung einer JXTA-Gruppe Quelltext 2-3: Erzeugung einer OutputPipe Quelltext 2-4: Senden einer Nachricht Quelltext 2-5: Veröffentlichen einer Pipe Quelltext 2-6: Instanziieren des Jacl-Interpreters Quelltext 2-7: TCL-Beispiel Quelltext 2-8: Setzen und Abrufen von Variablen eines TCL-Skriptes Quelltext 4-1: Beispiel eines SLOs Quelltext 4-2: Beispiel einer ElectionMessage Quelltext 5-1: Quelltext der Methode startjxta(in objconfig:configuration, in objlogger:logger) Quelltext 5-2: Auszug der Methode run() der Klasse ServerPipeHelper Quelltext 5-3: Auszug der Methode run() der Klasse AsyncGroupDiscovery Quelltext 5-4: Auszug des Konstruktors der Klasse ElectionWorker Quelltext 5-5: Vorgänge nach dem Empfang einer CoordinatorPipeMessage Quelltext 5-6: Auszug der Methode start(in bforcepipe:boolean) der Klasse Election Quelltext 5-7: Auszug der Methode createpipes(in objgroup:group, in objlogger:logger) der Klasse AuctionWorker Quelltext 5-8: Auszug der Methode generateid(in objgroup:group) der Klasse AuctionWorker Quelltext 5-9: Abläufe nach dem Ablauf eines Gebotes Quelltext 5-10: Konfiguration des Strategie-Adapters Quelltext 5-11: Auszug der Methode transform(in objcomplex:complexcontentelement) der Klasse Adapter Quelltext 5-12: Auszug der Methode creategroupname(in objsubject:subject) der Klasse StrategyModule Quelltext 5-13: Auszug aus der Methode onbidreceived(in strauctionid:string, in strbidid:string, in nbid:double, in objgroup:group) der Klasse AuctionAgent XIV

15 Quelltext 5-14: Auszug aus der Methode onmarketplaceofferreceived(in strreference: String, in objsubject:subject, in nprice:double, in dtdeadline:date, in objgroup: Group) der Klasse MarketAgent XV

16 Tabellenverzeichnis Tabelle 3-1: Nachrichten der Wahl Tabelle 3-2: Nachrichten der Auktion Tabelle 3-3: Nachrichten auf dem virtuellen Marktplatz Tabelle 4-1: Bezeichner der Nachrichten des Wahl-Mechanismus Tabelle 4-2: Bezeichner der Nachrichten des Auktions-Mechanismus Tabelle 4-3: Bezeichner der Nachrichten des Markt-Mechanismus Tabelle 5-1: Implementierungsaufwand Konfiguration Tabelle 5-2: Implementierungsaufwand Kommunikation Tabelle 5-3: Implementierungsaufwand Gruppenmanagement Tabelle 5-4: Implementierungsaufwand der Hilfsklassen Tabelle 5-5: Implementierungsaufwand Wahl-Mechanismus Tabelle 5-6: Implementierungsaufwand Auktions-Mechanismus Tabelle 5-7: Implementierungsaufwand Markt-Mechanismus Tabelle 5-8: Implementierungsaufwand Strategie-Adapter Tabelle 5-9: Implementierungsaufwand Strategie-Modul Tabelle 5-10: Implementierungsaufwand der SalesAgents Tabelle 5-11: Hilfsklassen Tabelle 5-12: Implementierungsaufwand Tabelle 6-1: Abläufe bei der Initialisierung des Auktions-Mechanismus Tabelle 6-2: Vergleich der benötigten und zur Verfügung stehenden Antwortzeit Tabelle 6-3: statistisch relevante Werte Tabelle 6-4: Abläufe bei der Initialisierung des Markt-Mechanismus Tabelle 6-5: Vergleich der benötigten und zur Verfügung stehenden Antwortzeit Tabelle 6-6: statistisch relevante Werte XVI

17 Kapitel 1 - Einleitung 1. Einleitung Die rechnergestützte Bearbeitung von Geschäftsprozessen spielt in Unternehmen eine immer größere Rolle. Je schneller das Ergebnis der Bearbeitung vorliegt, desto mehr Wert kann in der Regel aus dem Ergebnis geschöpft werden. Die zur Bearbeitung von Aufgaben eingesetzten Software-Architekturen werden immer komplexer, und es sind immer mehr unterschiedliche Softwaresysteme an der Durchführung einer einzelnen Aufgabe beteiligt. Hierzu werden Aufgaben in Teilaufgaben aufgeteilt und unter den beteiligten Komponenten verteilt. In solchen Architekturen kann in der Regel keine zuverlässige statische Aussage über die Bearbeitungsdauer einer Aufgabe getroffen werden. Trotzdem soll zur Bearbeitung einer Aufgabe nicht beliebig viel Zeit benötigt werden, vielmehr soll die Aufgabe innerhalb einer vorgegebenen Zeit abschließend bearbeitet werden. Hierzu werden spezielle Vereinbarungen getroffen bzw. Vorgaben erstellt. Solche Vereinbarungen werden auch als Dienstgütevereinbarungen bzw. als Service Level Agreements (SLAs) bezeichnet. In SLAs können z.b. Vorgaben bezüglich der Verfügbarkeit einer Dienstleistung oder bezüglich der maximal zulässigen Antwortzeit einer Anwendung für einen Anwendungsfall festgehalten werden. Diese Vorgaben sind in Form von Service Level Objectives (SLOs) in einem SLA enthalten, die zu überwachenden Werte werden durch SLA-Parameter beschrieben. Die zur Durchführung von flexiblen Geschäftsprozessen bzw. zur Erbringung von Leistungen geschaffenen Architekturen werden als Service-orientierte Architekturen (SOA) bezeichnet. Da die Komplexität der zu erbringenden Leistungen ständig wächst, werden auch die Abläufe innerhalb von SOA- Umgebungen zunehmend komplexer. In der Regel arbeiten in einer SOA- Umgebung mehrere Softwaresysteme zur Erbringung einer Dienstleistung zusammen. Solche kooperativen Szenarien werden auch als Workflows bezeichnet. Bei Bedarf können einer SOA-Umgebung dynamisch weitere 1

18 Kapitel 1 - Einleitung Softwaresysteme zur Unterstützung hinzugefügt werden. Diese unterstützenden Systeme werden anschließend wieder aus der Umgebung entfernt. Die Überwachung der Dienstgüte von angebotenen Services spielt eine immer größere Rolle in Unternehmen. Die Überwachung und Einhaltung von SLAs erfordert ein effektives Service Level Management (SLM). Dies kann nur noch bedingt von einem menschlichen Operator geleistet werden. Daher gilt es, Möglichkeiten zu finden, damit die an einer SOA-Umgebung beteiligten Softwaresysteme in der Lage sind, möglichst selbstständig für die Einhaltung der in der Dienstgütevereinbarung beschriebenen Ziele Sorge zu tragen bzw. möglichst stark dazu beizutragen. Im Rahmen dieser Möglichkeiten sollen die einzelnen Softwaresysteme in der Lage sein, selbsttätig Management-Aufgaben, z.b. permanente Überwachung und Rekonfiguration, durchzuführen. Diese Thematik wird mit dem Oberbegriff Selbstmanagement, einem aktuellen Forschungsthema, bezeichnet. Im Rahmen von Selbstmanagement sollen die anfallenden Management-Aufgaben von einer speziellen Management- Komponente, dem sog. Manager, übernommen werden. Ein Manager ist jeweils für das Management einer speziellen Software-Komponente zuständig. Im Labor für Verteilte Systeme an der Fachhochschule Wiesbaden existiert ein sog. Selbstmanager zur Durchführung von lokalen Management-Aufgaben, genauer: zur permanenten Überwachung und zur Rekonfiguration einer Softwarekomponente. Die Zusammenarbeit mit anderen Selbstmanagern ist bisher nicht vorgesehen. Da in der Regel jedoch mehrere unterschiedliche Softwaresysteme an der Erfüllung einer Aufgabe mitwirken, genügt es nicht, wenn das Selbstmanagement lokal für eine einzige Komponente betrieben wird. Vielmehr ist es nötig, die lokalen Management-Bemühungen aller Management- Komponenten zu koordinieren und somit einen insgesamt akzeptablen Zustand zu erreichen. Das Ziel dieser Arbeit ist es, Möglichkeiten zur Koordination von lokalen Selbstmanagern zu entwickeln und somit eine SOA-weite Koordination von Management-Komponenten zu ermöglichen. Hierzu wird zunächst eine geeignete Kommunikationsplattform zum Austausch von Nachrichten benötigt. Über diese Kommunikationsplattform soll es anschließend möglich sein, dass sich die 2

19 Kapitel 1 - Einleitung einzelnen Selbstmanager in einer bestimmten Relation zueinander organisieren und sich bezüglich der Einhaltung der in einem SLA vereinbarten Schranken gegenseitig unterstützen. Hierzu werden einige Koordinationsformen evaluiert, ausgewählte Koordinationsformen werden anschließend in Form eines Frameworks implementiert. Dieses Framework soll auch die zugrundeliegenden Kommunikationsmechanismen enthalten. Abschließend werden die implementierten Koordinationsmechanismen in Hinblick auf verschiedene Kriterien bewertet und die Ergebnisse analysiert. Im Folgenden werden lediglich die zeitlichen Parameter eines SLAs, z.b. die maximale Antwortzeit, beachtet. Die Betrachtung von Parametern wie Zuverlässigkeit und Korrektheit würde den Umfang dieser Arbeit sprengen und wird daher bewusst ausgelassen. Die vorliegende Arbeit gliedert sich wie folgt: das folgende Grundlagenkapitel geht zunächst auf die Kommunikationsplattform JXTA ein. Im Anschluss daran wird die Java Command Language als eine Möglichkeit zur Einbettung von externem Code in Java-Applikationen erläutert. Darauf folgend werden die Prinzipien von Selbstorganisation und Management erläutert. Abschließend wird auf Wahl-Algorithmen eingegangen. Kapitel 3 zeigt zunächst die Problemstellung dieser Arbeit auf, danach wird ein entsprechendes Anwendungsszenario eingeführt. Anschließend folgen allgemeine Überlegungen zur Problemstellung, und es werden die an diese Arbeit gestellten Anforderungen sowie die Rahmenbedingungen erläutert. Mit diesem Hintergrund werden anschließend die Themenbereiche Gruppenmanagement und Koordination untersucht. Hierbei werden auch verschiedene Koordinationsmechanismen eingehend betrachtet. Darauf folgend wird die Anbindung des im Rahmen dieser Arbeit zu entwickelnden Frameworks zur Selbstorganisation von Software-Systemen an den existierenden Selbstmanager untersucht. Abschließend werden aus den im Rahmen der Analyse gewonnenen Erkenntnissen die für den weiteren Verlauf dieser Arbeit maßgeblichen Design- Entscheidungen beschrieben. Anhand der Design-Entscheidungen wird in Kapitel 4 das konkrete Design des zu entwickelnden Frameworks ausgearbeitet. Hierzu wird zunächst eine 3

20 Kapitel 1 - Einleitung Grobarchitektur erstellt und die zu entwickelnde Funktionalität in drei Teilsysteme unterteilt. Diese Teilsysteme werden im weiteren Verlauf des Kapitels getrennt betrachtet und anschließend bis auf Klassenebene detailiert entworfen, wobei auch jeweils ein Überblick über das Zusammenspiel der einzelnen Klassen gegeben wird. Zu Beginn des Entwurfs der Umsetzung der in Kapitel 3 betrachteten Koordinationsmechanismen wird die Funktionalität dieser Mechanismen in Form von Automaten beschrieben. Abschließend wird ein Threading-Modell für eine vorgesehene Nebenläufigkeit erstellt. Im folgenden Kapitel 5 wird anschließend die Implementierung des Frameworks sowie dessen Anbindung an den Selbstmanager besprochen. Die Beschreibung der Implementierung beschränkt sich auf die interessanten Aspekte. Diese sind, neben den verwendeten Werkzeugen, die Konfiguration und das Starten des JXTA- Frameworks, die Implementierung der im Rahmen des Design-Kapitels erstellten Automaten sowie einige spezielle Punkte der im Rahmen des Designs entworfenen Teilsysteme. Den Abschluss des Kapitels bildet die Angabe des gesamten Implementierungsaufwandes der vorliegenden Arbeit. Nach der Beschreibung der Implementierung werden in Kapitel 6 die zu implementierenden Koordinationsmechanismen in Hinblick auf ihr zeitliches Verhalten und auf die Nachrichtenkomplexität bewertet. Anschließend wird das Framework exemplarisch in einen vorgegebenen Kontext eingebunden. Die Arbeit endet mit einer Zusammenfassung und einem Ausblick auf mögliche Erweiterungen. 4

21 2.1 JXTA Kapitel 2 - Grundlagen 2. Grundlagen In diesem Kapitel werden die zur Durchführung dieser Arbeit benötigten Grundlagen erläutert. Abschnitt 2.1 beschäftigt sich mit JXTA, einer offenen Protokollsammlung zur Kommunikation von Anwendungen. In Abschnitt 2.2 wird eine kurze Einführung in die Java Command Language gegeben, Abschnitt 2.3 erläutert Grundlagen zu Selbstorganisation. In Abschnitt 2.4 werden Grundlagen des Managements erläutert, wobei auch auf den im Labor für Verteilte Systeme der Fachhochschule Wiesbaden entwickelten Selbstmanager eingegangen wird. Abschließend werden in Abschnitt 2.5 Wahl-Algorithmen aufgezeigt. 2.1 JXTA Bei JXTA ( Juxtapose, dt.: Nebeneinanderstellung ; siehe [1]) handelt es sich um eine Sammlung und Spezifikation offener Protokolle für die Kommunikation in Peer-to-Peer Netzwerken (P2P) sowie für die Erzeugung und Gruppierung von im P2P-Netz teilnehmenden Knoten (Peers) [2]. Die durch JXTA spezifizierten Protokolle [3] liegen zum Zeitpunkt der Erstellung dieser Arbeit in der Version 2.0 vor. Zurzeit werden von den Entwicklern drei verschiedene Referenz- Implementierungen (Bindings) bereitgestellt: J2SE (Version 2.4.1): diese Variante wurde mittels der Java Standard Edition ( implementiert und ist daher unter den gängigen Betriebssystemen verfügbar. JXME (Version 2.1.3): durch die Verwendung der Java Micro Edition ist die Implementierung von JXTA-Anwendungen auch auf zahlreichen mobilen Geräten möglich. 5

22 Kapitel 2 - Grundlagen 2.1 JXTA JXTA-C (Version 2.5): bei dieser Variante handelt es sich um die C/C++ - Implementierung der JXTA-Protokolle Begriffe Zum Verständnis der Arbeitsweise von JXTA ist die Kenntnis der JXTA- Terminologie und des zugrundeliegenden Konzeptes unumgänglich. Auf der höchsten Abstraktionsebene besteht JXTA lediglich aus dessen Protokollen, die Verwendung bzw. der Zugriff auf die Protokolle erfolgt durch Methoden, welche von dem jeweiligen Binding bereitgestellt werden. Jedes der Protokolle definiert eine oder mehrere Nachrichten, wobei jede dieser Nachrichten ein festes Format besitzt. Zur Implementierung und zur Verwendung dieser Protokolle ist das Verständnis der folgenden Grundbegriffe [2,4] notwendig. Unter einem Peer wird ein Teilnehmer in einem JXTA-Netzwerk verstanden. Hierzu muss der Teilnehmer mindestens eines der JXTA-Protokolle implementieren. Die Hardware-Plattform, auf welcher ein Peer existieren kann, wird einzig und allein von den zur Verfügung stehenden Bindings begrenzt, wobei mehrere Peers pro Hardware-Einheit, z.b. PC, Mobiltelefon usw. möglich sind. Zur Kommunikation mit anderen Peers muss ein Peer mindestens ein geeignetes Interface bereitstellen (Kommunikationsendpunkt). Ein Peer wird durch dessen ID identifiziert. Ein Advertisement ist ein XML-Dokument, welches eine JXTA-Entität bzw. eine JXTA-Ressource beschreibt. Sämtliche von JXTA spezifizierten Ressourcen werden durch Advertisements beschrieben und anderen Peers in dieser Form bekannt gegeben. Zur Identifikation der einzelnen Peers in einem JXTA-P2P-Netzwerk verwendet JXTA 128-Bit Zeichenketten (Identifier), im Folgenden kurz ID genannt. Mit Hilfe einer solchen ID kann eine beliebige JXTA-Entität, z.b. ein Peer oder ein Advertisement, eindeutig identifiziert werden. Obwohl die Eindeutigkeit einer ID 6

23 2.1 JXTA Kapitel 2 - Grundlagen nicht explizit gefordert wird, sollten Kollisionen durch das jeweilige Binding verhindert bzw. eingeschränkt werden. Logische Zusammengehörigkeit von Peers wird durch Gruppen (Peer Group) erreicht. Gruppen werden durch IDs identifiziert. Einzelne Peers können sich in Gruppen organisieren und innerhalb der Gruppe miteinander kommunizieren, die Teilnahme an der Gruppenkommunikation von Peers außerhalb der Gruppe ist nicht möglich. Zusätzlich ist die Bildung von Untergruppen möglich und der Beitritt in eine Gruppe kann z.b. durch Passwörter oder Zertifikate eingeschränkt werden. JXTA schränkt die Verwendung von Gruppen in keiner Weise ein, es existiert jedoch immer eine spezielle Gruppe, die sogenannte World Peer Group, im Folgenden auch Weltgruppe genannt. In dieser Weltgruppe sind sämtliche Peers enthalten und ein Peer kann zusätzlich in mehreren anderen Gruppen Mitglied sein. Ein Grund zur Gruppenbildung könnte z.b. der Wunsch nach einer sicheren, d.h. zutrittsbeschränkten Umgebung sein. Abbildung 2-1: Beispiel für in Gruppen organisierte Peers In Abbildung 2-1 sind Peer 1, Peer 2 und Peer 3 Mitglieder der Gruppe 1. Peer 3 ist zusätzlich gemeinsam mit Peer 4, Peer 5 und Peer 6 in Gruppe 2 enthalten. 7

24 Kapitel 2 - Grundlagen 2.1 JXTA Peer 6 ist zusätzlich Mitglied in Gruppe 3. Sämtliche Peers sind Mitglied der übergeordneten Weltgruppe. Zur Kommunikation innerhalb des JXTA-Netzwerkes werden Pipes verwendet. Eine Pipe ist ein unidirektionaler Kommunikationskanal und kann entweder zum Empfangen (Input Pipe) oder zum Senden (Output Pipe) von Nachrichten verwendet werden. Die Nachrichtenübertragung erfolgt asynchron, d.h. die Nachricht trifft zu einem nicht definierbaren Zeitpunkt nach dem Absenden bei dem Empfänger ein. Es werden drei verschieden Arten von Pipes unterschieden: Point-to-Point Pipes verbinden exakt zwei Kommunikationsendpunkte und können zur gezielten Kommunikation zwischen zwei Peers verwendet werden. Propagate Pipes sind an mehrere Empfänger gerichtet und können z.b. zum Senden von Nachrichten an alle Mitglieder einer Gruppe verwendet werden. Hierzu muss jeder potentielle Empfänger dieser Nachrichten einen geeigneten Kommunikationsendpunkt als Input Pipe bereitstellen, welcher mit der verwendeten Output Pipe des Senders korrespondiert. Secure Unicast Pipes sind eine spezielle Form der Point-to-Point Pipes. Die Inhalte der durch diese Pipes versendeten Nachrichten werden durch den Einsatz von Transport Layer Security (TLS) [5] geschützt und die Vertraulichkeit somit gewährleistet. Mit Ausnahme der Secure Unicast Pipes gibt es keinerlei Garantie, dass eine gesendete Nachricht auch zugestellt wird. Daher werden Pipes auch als unzuverlässig bezeichnet, die Implementierung von Zuverlässigkeit wird dem jeweiligen Binding überlassen. Zurzeit unterstützen die Referenz- Implementierungen der JXTA-Protokolle lediglich zuverlässige Unicasts, zuverlässige Multicasts werden noch nicht angeboten. Die Kommunikation zwischen Peers erfolgt durch den Austausch von Nachrichten (Messages) zwischen Kommunikationsendpunkten. Diese 8

25 2.1 JXTA Kapitel 2 - Grundlagen Nachrichten sind spezielle XML-Dokumente. Ähnlich wie bei anderen Protokollen besteht eine Nachricht aus einem Umschlag und den eigentlichen Daten (Abbildung 2-2). Der Umschlag besteht aus einem Header, einer optionalen Signatur, einer optionalen Absenderangabe sowie der zwingend erforderlichen Angabe des Empfängers. Header Signatur Absender Empfänger Element Element... Abbildung 2-2: Schematische Darstellung einer Nachricht Der Nachrichteninhalt ist beliebig und besteht aus mehreren Inhaltselementen. Die eigentlichen Nutzdaten der einzelnen Inhaltselemente unterliegen keinen prinzipiellen Beschränkungen, einzelne Implementierungen können jedoch Beschränkungen generieren. So könnte beispielsweise die Gesamtgröße der Nachricht beschränkt werden oder die Anzahl der Inhaltselemente limitiert sein Die Architektur Anwendungen, welche JXTA verwenden, bestehen in der Regel aus drei Schichten (Abbildung 2-3). Die unterste Schicht, der JXTA Core, besteht aus der Implementierung der grundlegendsten JXTA-Protokolle. Diese Protokolle sind für die Erzeugung von Peers und Gruppen sowie für die Abwicklung der Kommunikation und Interaktion unter den einzelnen Peers zuständig. Die darüber liegende Schicht (JXTA Services) stellt die zur Suche nach Ressourcen sowie zu 9

26 Kapitel 2 - Grundlagen 2.1 JXTA deren Indizierung und Verwendung benötigten Funktionalitäten bereit und implementiert die entsprechenden Protokolle. Auf dieser Schicht setzt nun die eigentliche JXTA-Anwendung, z.b. eine Software zum Instant Messaging, auf. Abbildung 2-3: Schematische Darstellung der Schichten einer JXTA-Anwendung (nach [6]) Ein JXTA-Netzwerk besteht aus Peers und den durch sie aufgespannten Gruppen. Um mit der hochgradig dynamischen Struktur eines JXTA-Netzes umgehen zu können, definiert JXTA vier verschiedene Arten von Peers: Ein Minimal edge peer kann lediglich Nachrichten senden und empfangen, besitzt keinen Zwischenspeicher für Advertisements und leitet keine Nachrichten von anderen Peers weiter. Diese Art von Peers sind in der Regel Netzwerkgeräte mit geringen Hardware-Kapazitäten, z.b. Mobilfunktelefone oder PDAs. Full-featured edge peers arbeiten wie Minimal edge peers, besitzen aber zusätzlich einen Zwischenspeicher zur Reduktion des Nachrichtenaufkommens. Mit Hilfe dieses Zwischenspeichers können auch Anfragen anderer Peers beantwortet werden. Dies ist der Standardmodus eines Peers. 10

27 2.1 JXTA Kapitel 2 - Grundlagen Ein Rendezvous-Peer arbeitet wie ein Full-featured edge Peer, leitet aber zusätzlich Nachrichten anderer Peers weiter bzw. beantwortet diese aus seinem lokalen Zwischenspeicher. Jede JXTA-Gruppe besitzt mindestens einen Rendezvous-Peer. Nachdem ein Peer einer Gruppe beigetreten ist, versucht er zunächst eine Verbindung mit dem zuständigen Rendezvous-Peer herzustellen. Wird kein passender Peer gefunden, so ernennt sich das neue Gruppenmitglied selbst zum Rendezvous-Peer. Ein Relay-Peer besitzt Informationen über die Routen zu anderen Peers und arbeitet daher als eine Art Peer-Router. Ein solcher Peer beantwortet Suchanfragen aus seinem lokalen Zwischenspeicher heraus oder stößt eine Suche innerhalb des JXTA-Netzwerkes an. Diese Peers sind zusätzlich für das Weiterleiten von Nachrichten über Netzwerkgrenzen, wie das Internet, hinweg und für das Überwinden technischer Schranken, beispielsweise Firewalls, zuständig Die Protokolle Es existieren insgesamt sechs verschiedene JXTA-Protokolle. Mit Hilfe dieser Protokolle werden die Kooperation, die Selbstorganisation sowie die Selbstkonfiguration der einzelnen Peers und Gruppen untereinander ohne Verwendung einer zentralen Kontrollinstanz realisiert Rendezvous-Protokoll (RVP) Das Rendezvous-Protokoll ([3], Seiten 41-45) wird zum Verbreiten von Nachrichten innerhalb einer Gruppe von Peers verwendet. Hierzu stellt es Mechanismen zur kontrollierten Verbreitung bereit. Diese Aufgabe wird innerhalb einer Gruppe von Rendezvous-Peers übernommen. Solche Peers verwenden den sog. Rendezvous-Service. Der Rendezvous-Service ist für das Auffinden von Peers und für das Weiterleiten von Nachrichten zuständig. Rendezvous-Peers werden durch spezielle Advertisements, die sog. Rendezvous-Advertisements, beschrieben und können dadurch von anderen Peers aufgefunden werden. Rendezvous-Peers arbeiten zum Verbreiten der Nachrichten mit anderen Peers 11

28 Kapitel 2 - Grundlagen 2.1 JXTA zusammen, wobei diese Peers ebenfalls wieder Rendezvous-Peers sein können. Sämtliche Rendezvous-Peers einer Gruppe bilden gemeinsam eine Liste aller Rendezvous-Peers innerhalb ihrer Gruppe, den sog. PeerView. Mit Hilfe dieser Liste können Nachrichten innerhalb der Gruppe ohne Verwendung einer zentralen Kontrollinstanz verbreitet werden. Das Rendezvous-Protokoll unterteilt sich in drei Sub-Protokolle: 1. Die Implementierung des Rendezvous Propagation-Protokolls ist für Peers, sofern diese den Rendezvous-Service verwenden, verpflichtend. Dieses Protokoll ist für die Verbreitung der Nachrichten innerhalb einer Gruppe verantwortlich und verwaltet hierzu verschiedene Informationen, u.a. die Quelle einer Nachricht sowie eine Liste der Peers, welche die Nachricht bereits erhalten haben. Dieses Protokoll trifft keinerlei Aussagen über die Zuverlässigkeit der Kommunikation oder über die Atomarität der Nachrichtenzustellung. In den aktuell zur Verfügung stehenden Bindings ist für die Nachrichtenverteilung ein best-effort-mechanismus zuständig. 2. Das PeerView-Protokoll ist optional und kann zur eigenständigen Organisation der Rendezvous-Peers untereinander genutzt werden. Hierzu erstellt jeder Rendezvous-Peer seinen eigenen PeerView und wartet diesen durch Austausch spezieller Nachrichten mit den übrigen Rendezvous-Peers der Gruppe. 3. Die Implementierung des Rendezvous Lease-Protokolls ist ebenfalls optional und ermöglicht anderen Nicht-Rendezvous-Peers das Senden von Nachrichten an alle Peers der Gruppe und den Empfang solcher Nachrichten. Hierzu muss sich ein Peer an einem Rendezvous-Peer anmelden und erhält daraufhin eine zeitlich begrenzte Freigabe zur Teilnahme an der Gruppenkommunikation. Diese Freigabe muss ständig erneuert werden und kann beiderseitig jederzeit gekündigt werden. Ein Peer kann zur Laufzeit dynamisch zu einem Rendezvous-Peer werden bzw. sich mit einem Rendezvous-Peer verbinden. Auf diese Art und Weise organisieren sich Peers innerhalb einer Gruppe, ohne dass ein Eingreifen von außen nötig ist. 12

29 2.1 JXTA Kapitel 2 - Grundlagen Peer Resolver-Protokoll (PRP) Das Peer Resolver Protokoll ([3], Seiten 25-30) definiert eine Schnittstelle, welche von Peers zum Senden von Anfragen an andere Peers sowie zum Senden von Antworten als Reaktion auf zuvor empfangene Anfragen verwendet wird. Hierzu definiert das PRP zwei generische Nachrichtentypen: Resolver Query Messages und Resolver Response Messages. Der erste Typ wird zum Senden von Anfragen an einen oder mehrere andere Peers verwendet. Hierzu wird jede Query mit einer ID versehen. Zusätzlich enthält eine solche Nachricht noch den Namen des Handlers, an welchen die Nachricht gerichtet ist, sowie die ID des sendenden Peers. Wird eine derartige Nachricht empfangen, wird diese zunächst an den in der Query angegebenen Handler weitergereicht und bearbeitet. Antworten werden als Resolver Response Message gesendet und beziehen sich auf die ID der Query. Eine Resolver Query Message kann von beliebig vielen Peers innerhalb einer Gruppe empfangen und bearbeitet werden. Zum Senden von Nachrichten an einen oder mehrere Peers wird typischerweise der Rendezvous-Service verwendet. Es werden keinerlei Aussagen über die Zuverlässigkeit des Transports und die zu verwendenden Mechanismen getroffen; das Senden einer Antwort als Reaktion auf eine Anfrage ist optional Peer Discovery-Protokoll (PDP) Das Peer Discovery Protokoll ([3], Seiten 37-41) spezifiziert die Art und Weise, wie ein Peer andere Peers und deren Ressourcen im Netzwerk auffinden kann. Die auffindbaren Ressourcen müssen hierzu jeweils mit einem Advertisement beschrieben sein, und diese Advertisements müssen zuvor veröffentlicht werden. Ressourcen können Peers, Gruppen, Pipes, Module oder andere durch ein Advertisement beschriebene Komponenten sein. Hierzu definiert das PDP zwei verschiedene Arten von Nachrichten: die Discovery Query Message und die Discovery Response Message. Die Discovery Query Message wird verwendet, um fremde Peers und deren Ressourcen ausfindig zu machen. Es können insgesamt drei unterschiedliche Kategorien von Ressourcen gesucht und gefunden werden, wobei je Nachricht nur die Suche nach einer Kategorie möglich ist: 13

30 Kapitel 2 - Grundlagen 2.1 JXTA fremde Peers, Gruppen, sowie jede andere durch ein Advertisement beschriebene Ressource. Empfängt ein Peer eine solche Nachricht, antwortet dieser mit einer Discovery Response Message. In einer solchen Nachricht beschreibt ein Peer je nach Anfrage sich selbst, ihm bekannte Gruppen oder seine den anderen Peers zur Verfügung stehenden Ressourcen. Abbildung 2-4 veranschaulicht das Auffinden eines neuen Peers und das anschließende Abfragen seiner Ressourcen: Abbildung 2-4: Ablauf des Auffindens eines Peers und dessen Ressourcen Das PDP legt weder fest, ob ein Peer überhaupt auf eine Discovery Query Message antworten muss, noch wann die Antwort erfolgen muss. Die Art des Transportmechanismus wird ebenfalls der Implementierung überlassen, d.h. es sind sowohl zuverlässige als auch unzuverlässige Transportmechanismen möglich. Für den Transport der Nachrichten ist das PRP zuständig Peer Information-Protokoll (PIP) Das Peer Information-Protokoll ([3], Seiten 45-47) definiert eine Reihe von Nachrichten, mit deren Hilfe Statusinformationen eines anderen Peers angefragt werden können. Dieses Protokoll basiert auf dem PRP, seine Verwendung ist optional. Zum Ermitteln von Status-Informationen von anderen Peers wird die PIP Query Message verwendet. Hierzu enthält dieser Nachrichtentyp ein spezielles Feld, 14

31 2.1 JXTA Kapitel 2 - Grundlagen durch welches die Art der angefragten Information spezifiziert werden kann. Fehlt diese Angabe, antwortet der gefragte Peer mit Standard-Informationen, z.b. seiner Uptime. Der gefragte Peer antwortet auf eine solche Nachricht mit dem Senden einer PIP Response Message. Eine solche Nachricht enthält die angefragten Informationen. Das PIP trifft keine Aussage über die Art des verwendeten Transports. Ebenso ist das Antworten auf eingehende Anfragen optional Endpoint Routing-Protokoll (ERP) Das Endpoint Routing-Protokoll ([3], Seiten 30-34) beschreibt diejenigen Nachrichten, welche zum Weiterleiten von Nachrichten innerhalb des sich ständig verändernden JXTA-Netzwerkes verwendet werden. Soll eine Nachricht zu einem Peer gesendet werden, zu welchem die Route durch das Netzwerk noch nicht bekannt ist, wird zunächst eine Route Query Message zu den verfügbaren Peer-Routern gesendet. Diese Peer-Router besitzen eine Liste der Routen zu bekannten Peers und können zusätzlich die Routen zu noch unbekannten Peers im Netzwerk ausfindig machen. Mit Hilfe von Peer-Routern ist auch die Überbrückung von logischen bzw. physischen Netzwerk-Grenzen möglich. Ein Peer kann eine beliebige Anzahl von Peer-Routern nutzen. Diese Router können entweder dynamisch ermittelt oder vorkonfiguriert werden. Ebenso können Peers dynamisch zu Peer-Routern gewählt werden. Empfängt ein Peer-Router eine Route Query Message, so ermittelt dieser die gesuchte Route und antwortet mit einer Route Response Message Pipe Binding-Protokoll (PBP) Das Pipe Binding-Protokoll ([3], Seiten 47-50) wird zur Kommunikation mit anderen Peers verwendet. Eine Pipe ist ein virtueller, unidirektionaler Kommunikationskanal und wird durch ein spezielles Advertisement, das sog. Pipe-Advertisement beschrieben. Das Pipe Binding-Protokoll beschreibt die beiden Enden einer Pipe: das empfangende Ende einer Pipe wird als Input Pipe, 15

32 Kapitel 2 - Grundlagen 2.1 JXTA das sendenden Ende einer Pipe als Output-Pipe bezeichnet. Zum Versenden der Nachrichten wird das ERP verwendet. Zusätzlich zum Typ der Pipe enthält das die Pipe beschreibende Advertisement noch deren ID sowie eine optionale, nicht zwingend eindeutige Beschreibung der Pipe. Das Auffinden von Pipes geschieht durch das Senden von Pipe Resolve Messages. Als Antwort auf eine solche Nachricht wird eine Pipe Response Message gesendet. Diese Nachricht enthält die Daten der jeweiligen Pipes und wird von dem Empfänger der Nachricht ausgewertet Das J2SE-Binding Das von den JXTA-Entwicklern zur Verfügung gestellte Java-Binding liegt zum Zeitpunkt der Erstellung dieser Arbeit in der Version vor. Dieses Binding besteht aus 2 Bereichen: Implementation und API. Implementation enthält die Referenz-Implementierung der JXTA-Protokolle. Die Implementierung erfolgte unter Verwendung der Java Standard Edition 5.0 und besteht aus einer Reihe von Packages, wobei net.jxta.impl.access die Bezeichnung des übergeordneten Packages ist. Die API verwendet diese Referenzimplementierung, um die Zugriffe und die Verwendung der JXTA-Protokolle abzuwickeln. Bei der Verwendung des Java-Bindings sollte darauf geachtet werden, ausschließlich auf API-Methoden zuzugreifen und lediglich die durch die API zur Verfügung gestellten Klassen zu verwenden, da sich die dahinterliegende Referenz-Implementierung mit jedem neuen Release ändern kann. Allerdings bietet die Referenz-Implementierung Funktionalitäten, welche durch die API nicht angeboten werden, z.b. die Erstellung zutrittsbeschränkter Gruppen Starten der JXTA-Plattform Zum Starten der JXTA-Plattform sind zwei Schritte nötig: 1. Erzeugung einer Instanz der Klasse NetPeerGroupFactory 2. Erzeugung der Weltguppe 16

33 2.1 JXTA Kapitel 2 - Grundlagen Das Starten der JXTA-Plattform erfolgt durch die API implizit bei der Erzeugung der Weltgruppe. Da die direkte Erzeugung der Weltgruppe nicht möglich ist, muss mit einer sog. Factory gearbeitet werden (Quelltext 2-1). 01 PeerGroup objworldgroup = null; 02 try 03 { 04 final NetPeerGroupFactory objfactory = 05 new NetPeerGroupFactory(); 06 objworldgroup = objfactory.getinterface(); 07 } 08 catch (PeerGroupException e) 09 { 10 e.printstacktrace(); 11 } Quelltext 2-1: Erzeugung der Weltgruppe Erzeugung einer Gruppe Die Erzeugung einer neuen JXTA-Gruppe unterteilt sich in zwei Schritte (Quelltext 2-2): 1. ein Advertisement erzeugen und 2. eine Gruppe unter Verwendung des Advertisements erzeugen Zuerst muss ein Allzweck -Advertisement erzeugt werden (Zeilen 4-5). Dieses wird anschließend zur Erzeugung der neuen Gruppe verwendet (Zeilen 6-8). Zusätzlich müssen noch der Name der Gruppe und eine Beschreibung angegeben werden. Soll einer dieser beiden Parameter nicht genutzt werden, empfiehlt sich die Übergabe eines leeren Strings anstelle von null, da es ansonsten zu Fehlern innerhalb der API kommen kann. Optional ist noch die Übergabe der Gruppen-ID möglich. Hierauf sollte jedoch verzichtet werden, da die Verwaltung und Erzeugung von IDs JXTA überlassen werden sollte. Die Methode getallpurposepeergroupimpladvertisement() (Zeile 5) liefert bei Fehlern lediglich ein Objekt der Klasse Exception. Diese Exception sollte als letzte Ausnahme des try-catch-blockes abgefangen werden. Da eine neue JXTA- Gruppe stets innerhalb einer bereits existierenden Gruppe erzeugt wird, muss das 17

34 Kapitel 2 - Grundlagen 2.1 JXTA Advertisement aus der bereits bestehenden, künftig übergeordneten Gruppe bezogen werden (Zeile 4). 01 PeerGroup objgroup = null; 02 try 03 { 04 final ModuleImplAdvertisement objadv = objworldgroup. 05 getallpurposepeergroupimpladvertisement(); 06 objgroup = objworldgroup.newgroup(null, objadv, 07 "Name der Gruppe", 08 "Beschreibung der Gruppe"); 09 } 10 catch (PeerGroupException e) 11 { 12 e.printstacktrace(); 13 } 14 catch (Exception e) 15 { 16 e.printstacktrace(); 17 } Quelltext 2-2: Erzeugung einer JXTA-Gruppe Erzeugung einer OutputPipe Zur Erzeugung einer neuen OutputPipe sind insgesamt fünf Schritte notwendig: 1. ein neues Advertisement erzeugen, 2. eine neue Pipe-ID generieren, 3. die Daten des Advertisements setzen, 4. den Pipe-Service ermitteln und 5. die Pipe erzeugen Quelltext 2-3 veranschaulicht die Erzeugung einer OutputPipe. Zunächst muss, ähnlich der Erzeugung einer neuen Gruppe, ein passendes PipeAdvertisement erzeugt werden (Zeilen 1-4). Diesem Advertisement muss nun eine neue Pipe-ID zugeordnet werden, welche zuvor über die IDFactory generiert wird (Zeile 6). Zusätzlich hierzu muss spezifiziert werden, um welchen Typ von Pipe es sich handelt (in diesem Beispiel handelt es sich um eine unzuverlässige Multicast- Pipe). Das Setzen von Namen und Beschreibung der Pipe sind optional, sollte aber zum besseren Verständnis erledigt werden. Um die Pipe abschließend zu 18

35 2.1 JXTA Kapitel 2 - Grundlagen erzeugen, muss nur noch der PipeService der betreffenden Gruppe ermittelt werden (Zeile 14). Der PipeService repräsentiert die Implementierung des PBP und ist für die Erzeugung sowie für die Verwaltung von Pipes einer Gruppe zuständig. Anschließend muss die Methode createoutputpipe(pipeadvertisement, long) aufgerufen werden (Zeilen 18-19). Der erste Parameter bezieht sich auf das zuvor erzeugte Advertisement, der zweite Parameter gibt die Zeitspanne an, welche auf die Erzeugung der Pipe gewartet werden soll. Kann innerhalb dieser Zeitspanne keine Pipe erzeugt werden, wird eine Exception geworfen. Der Wert 0 bedeutet in diesem Zusammenhang eine unendliche Wartezeit, d.h. der aktuelle Thread blockiert, bis die Erzeugung der Pipe abgeschlossen ist. Die erzeugte Pipe steht anschließend in der Gruppe des ermittelten PipeService zur Verfügung. 01 final PipeAdvertisement objadvertisement = 02 (PipeAdvertisement) AdvertisementFactory. 03 newadvertisement(pipeadvertisement. 04 getadvertisementtype()); final PipeID objpipeid = IDFactory.newPipeID( 07 objgroup.getpeergroupid()); objadvertisement.setpipeid(objpipeid); 10 objadvertisement.settype(pipeservice.propagatetype); 11 objadvertisement.setname("name der Pipe"); 12 objadvertisement.setdescription("beschreibung der Pipe"); final PipeService objservice = objgroup.getpipeservice(); 15 OutputPipe objpipe = null; 16 try 17 { 18 objpipe = objservice.createoutputpipe( 19 objadvertisement, 0); 20 } 21 catch (IOException e) 22 { 23 e.printstacktrace(); 24 } Quelltext 2-3: Erzeugung einer OutputPipe Senden einer Nachricht Um eine Nachricht versenden zu können, muss diese zunächst erzeugt und mit einzelnen Nachrichtenelementen befüllt werden. Quelltext 2-4 veranschaulicht das Erzeugen und anschließende Senden einer Nachricht. 19

36 Kapitel 2 - Grundlagen 2.1 JXTA 01 final Message objmsg = new Message(); 02 final StringMessageElement objelem = 03 new StringMessageElement("Name", "Inhalt", null); 04 objmsg.addmessageelement(objelem); try 07 { 08 objpipe.send(objmsg); 09 } 10 catch (IOException e) 11 { 12 e.printstacktrace(); 13 } Quelltext 2-4: Senden einer Nachricht Nachdem eine Nachricht erzeugt wurde, muss diese zunächst mit Inhalten befüllt werden. Hierzu stellt das Binding verschiedene Nachrichtenelemente bereit, zum Versenden von Zeichenketten eignet sich eine Instanz der Klasse StringMessageElement. Zur Erzeugung eines solchen Elementes werden drei Parameter benötigt: der Name des Elementes, welcher innerhalb der Nachricht eindeutig sein sollte und nicht null sein darf, der eigentliche Inhalt und eine optionale Signatur (Zeilen 2-3). Nachdem das Nachrichtenelement der eigentlichen Nachricht hinzugefügt wurde (Zeile 4), muss diese nur noch der Methode send(message) einer zuvor erzeugten OutputPipe übergeben werden (Zeile 8) Veröffentlichen von Ressourcen Damit JXTA-Ressourcen von anderen Peers gefunden werden können, müssen diese zuvor innerhalb der Gruppe bekanntgegeben werden. Für das Bekanntgeben und Auffinden von Ressourcen ist der DiscoveryService der jeweiligen Gruppe zuständig. Der DiscoveryService besteht aus der Referenzimplementierung des PDP. Das Veröffentlichen von Ressourcen erfolgt durch das Veröffentlichen des entsprechenden Advertisements (Quelltext 2-5). Hierzu muss zunächst der DiscoveryService der entsprechenden Gruppe ermittelt werden (Zeilen 1-2). Anschließend kann das Advertisement innerhalb der Gruppe bekanntgegeben werden. Zu diesem Zweck existieren zwei verschiedenen Methoden. Die Methode 20

37 2.2 Java Command Language Kapitel 2 - Grundlagen publish(advertisement) (Zeile 6) veröffentlicht das Advertisement im lokalen Cache des Peers. Dieser Schritt wird in der Regel bei Erzeugung der Ressource automatisch im Hintergrund vorgenommen und kann daher normalerweise entfallen. Mit Hilfe der Methode remotepublish(advertisement) (Zeilen 13-14) wird eine Ressource den anderen Peers innerhalb der Gruppe bekanntgegeben und kann von diesen anschließend aufgefunden werden. Für die Verteilung eines Advertisements innerhalb einer Gruppe ist der jeweilige Rendezvous-Peer zuständig. Da durch diese beiden Methoden lediglich Advertisements veröffentlicht werden, können diese für jede beliebige Art von JXTA-Ressourcen verwendet werden. 01 final DiscoveryService objdiscoservice = 02 objgroup.getdiscoveryservice(); try 05 { 06 objdiscoservice.publish(objpipe.getadvertisement()); 07 } 08 catch (IOException e) 09 { 10 e.printstacktrace(); 11 } objdiscoservice.remotepublish( 14 objpipe.getadvertisement()); Quelltext 2-5: Veröffentlichen einer Pipe 2.2 Java Command Language Die Java Command Language [7] (kurz: Jacl, siehe [8]) ist eine Java- Implementierung der Skriptsprache Tcl [9] und ermöglicht es, Java-Applikationen um Skript-Anteile zu erweitern. Tcl wurde 1988 von John Ousterhout an der Universität von Kalifornien (Berkeley) entwickelt und hat sich seitdem rasant verbreitet [10]. Je nach Aufgabenstellung kann es sinnvoll sein, bestimmte Logik-Anteile einer Applikation in eine externe Skript-Datei auszulagern. Hierdurch kann bei geringfügigen Änderungen an der Geschäftslogik einer Applikation die Neu- Kompilierung der gesamten Anwendung bzw. einzelner Klassen vermieden 21

38 Kapitel 2 - Grundlagen 2.2 Java Command Language werden, die Änderungen sind dann lediglich an der entsprechenden Skript-Datei vorzunehmen. Eine Möglichkeit, diese Eigenschaft in einer Java-Anwendung zu realisieren, bietet Jacl. Neben der Verwendung einer externen Skript-Datei ist außerdem die Generierung von Tcl-Code zur Laufzeit möglich. Da der Skript-Anteil einer Applikation in einer getrennten Datei gehalten wird, muss zum Abarbeiten der Tcl-Anweisungen zunächst ein Interpreter instanziiert werden. Dieser Interpreter ist anschließend für den Ablauf der Tcl-Anweisungen verantwortlich (Quelltext 2-6). 01 final Interp objinterpreter = new Interp(); try 04 { 05 objinterpreter.evalfile("test.tcl"); 06 } 07 catch (TclException e) 08 { 09 e.printstacktrace(); 10 } Quelltext 2-6: Instanziieren des Jacl-Interpreters Die Tcl-Syntax selbst ist sehr schlicht gehalten. Quelltext 2-7 veranschaulicht das Vergleichen des Wertes einer Variablen mit einem vorgegebenen Wert und setzt basierend auf dem Vergleichsergebnis den Wert einer zweiten Variablen. 1 set Ergebnis 0 2 if {$Betrag > 100} { 3 set Ergebnis 1 4 } Quelltext 2-7: TCL-Beispiel Das Setzen des Wertes der Variablen Betrag kann aus der aufrufenden Java- Klasse heraus erfolgen, ebenso wie das Ermitteln des Inhalts der Variablen Ergebnis nach Beendigung des Skriptes (Quelltext 2-8). Vor dem Aufruf des Skriptes muss zunächst der Wert der Variablen Betrag gesetzt werden (Zeilen 5-6), danach kann das Skript gestartet werden (Zeile 7). 22