Thema: ICENI: Eine JXTA-basierte Service-Oriented Architecture

Transkript

1 Westfälische Wilhelms-Universität Münster Thema: ICENI: Eine JXTA-basierte Service-Oriented Architecture Seminararbeit im Rahmen des Seminars Services Computing und Service-Oriented Architectures im Fachgebiet Informatik am Lehrstuhl für Parallele und Verteilte Systeme Veranstalter: Betreuer: vorgelegt von: Prof. Dr. S. Gorlatch Dipl.-Inf. Jan Dünnweber Lisa Richter Emdener Straße Münster Abgabetermin:

2 - II - Inhaltsverzeichnis Inhaltsverzeichnis...II 1 Einleitung Die Imperial College e-science Networked Infrastructure (ICENI) Motivation und Entstehungsgeschichte von ICENI Design einer Service-Oriented Architecture im Rahmen von ICENI Rollen von Softwarekomponenten und Service Lifecycle Implementierungen auf Grundlage unterschiedlicher Basistechnologien Anforderungen an SOA-Basistechnologien Einführung in die Technologie JXTA Evolution und Besonderheiten von JXTA Eigenschaften einer Peer-to-Peer-Architektur Die JXTA-Architektur Technische Einführung in JXTA Grundbegriffe Protokolle Beispielapplikation Bewertung der Eignung von JXTA als Basis einer SOA Abbildung der grundlegenden Strukturen Erfüllung der Anforderungen an eine SOA-Basistechnologie Zusammenfassung und Ausblick...15 Literaturverzeichnis...16 Abbildungsverzeichnis...18 Abkürzungsverzeichnis...19 Anhang...20 A Beispiel eines Pipe Advertisements...20 B Die Protokollarchitektur von JXTA...20 C Beispielanwendung travelnet...21 C.a Java-Code einer Reiseagentur (Agency)...21 C.b Java-Code eines Reisenden (Traveller)...28

3 - 1-1 Einleitung Im Kontext des Grid Computing haben sich Service-Oriented Architectures (SOA) in den letzten Jahren als effiziente Organisationsform bewahrheitet. Idealerweise erlauben diese eine flexible Verwaltung und kooperative Nutzung von Services in dynamischen und heterogenen Umgebungen. Durch die Schaffung virtueller Organisationen sollen Ressourcen einer realen Organisation einer virtuellen Nutzergemeinschaft zugänglich gemacht werden. Der wachsende Bedarf in Wissenschaft und Praxis, Informationen, Software, Rechenkapazität und andere Ressourcen gemeinsam zu nutzen, hat inzwischen neben wohlbekannten Client/Server- Architekturen die Idee dezentraler Peer-to-Peer-Strukturen (P2P-Strukturen) vorangetrieben. Bisher hauptsächlich in untereinander inkompatiblen Anwendungen zum Einsatz gekommen, scheint diese Architektur mit zunehmender Standardisierung viel versprechend für die Nutzung auf anderen Gebieten. Im Rahmen dieser Arbeit wird die Umsetzung einer SOA mit Hilfe der P2P- Technologie JXTA diskutiert und bewertet. Das London e-science Centre (LeSC) hat im Rahmen der Imperial College e-science Networked Infrastructure (ICENI) eine idealtypische SOA als Grundlage einer Grid Middleware definiert und mittels verschiedener Technologien implementiert. In Abschnitt 2 wird eine Einführung in die Grundgedanken von ICENI vorgenommen und aus diesen Überlegungen heraus grundlegende Anforderungen an Technologien zur Realisierung einer SOA abgeleitet. Abschnitt 3 führt in das Projekt JXTA und dessen technische Umsetzung ein. Verdeutlicht wird die Funktionalität der Technologie anhand einer beispielhaften Implementierung. Die Zusammenführung beider Gedankengänge erfolgt in Abschnitt 4, wo die Eignung von JXTA als Basistechnologie einer SOA diskutiert wird. Abschnitt 5 resümiert die gewonnenen Erkenntnisse. 2 Die Imperial College e-science Networked Infrastructure (ICENI) 2.1 Motivation und Entstehungsgeschichte von ICENI Die Grundsteine für die Entwicklung der Imperial College e-science Networked Infrastructure (ICENI) [1] wurden bereits in den achtziger Jahren im Department of Computing am Imperial College London gelegt [2]. Motiviert durch das Bedürfnis, wissenschaftliche Berechnungen durch die parallele Nutzung mehrerer Ressourcen zu beschleunigen, war es zunächst Ziel des London e- Science Center (LeSC) [3], eine Forschungsplattform zu schaffen, die eine skalierbare, sichere und koordinierte Arbeitsumgebung für verteilte Anwendungen bereitstellt. Im Laufe der letzten Jahre hat sich der Fokus der Entwickler erweitert. Während sich die Anforderungen der Wissenschaft primär auf die bestmögliche Verteilung und Nutzung leistungsstarker Rechenressourcen bezogen, entwickelten sich im Kontext des E-Commerce Bedürfnisse nach der Integration heterogener verteilter Systeme, beispielsweise entlang einer ökonomischen Wertschöpfungskette. Abstrahiert man von der konkreten Ausprägung der benötigten Ressourcen beider Anwendungsszenarien, ist das Grundbedürfnis vergleichbar: Gefordert sind dynamische, skalierbare

4 - 2 - Architekturen, die kompatible Komponenten unabhängig von ihrer individuellen Implementierung erkennen, wieder verwenden und austauschen können [4]. Zum einen hatte die Grid Community den Aspekt der Dynamik bereits weit entwickelt; zum anderen war die E-Commerce-Forschung durch die Nutzung von Web-Service-Protokollen und die Etablierung gewisser Standards auf semantischer Ebene vorangeschritten. Durch die Zusammenführung der Vorzüge beider Entwicklungsströme verspricht sich das ICENI-Projekt die Schaffung wertvoller Synergieeffekte. 2.2 Design einer Service-Oriented Architecture im Rahmen von ICENI Im Rahmen des Projekts ICENI dient die Verwendung einer SOA der Bündelung von Ressourcen, die von einer realen Organisation verwaltet werden, zu einem Pool an Services, die von virtuellen Organisationen oder Rechengemeinschaften genutzt werden können [2]. Unter virtuellen Organisationen versteht man im Allgemeinen dynamische Zusammenschlüsse von Individuen, Institutionen und Ressourcen zum Zwecke einer gemeinsamen flexiblen, sicheren und koordinierten Ressourcennutzung [5]. Ziel der SOA ist es, Services unabhängig von der zu Grunde liegenden Basistechnologie als ICENI-Services zu behandeln. Somit können Protokolle und Formen der Kommunikation zwischen diesen definiert werden. Auf dieser Grundlage kann eine Grid Middleware entstehen, die über Standardschnittstellen und -protokolle von der verteilten Umgebung abstrahiert [6]. So können letztlich übergeordnete Ziele verfolgt werden, wie z. B. eine performancebasierte Workload-Verteilung [7] oder eine metadatenbasierte Servicevermittlung [8]. Bedeutsam ist an dieser Stelle die begriffliche Unterscheidung von Ressource und Service. Eine Ressource ist eine Fähigkeit (Rechenkapazität, Software, Hardware, Daten), die zu einer privaten Domäne gehört und durch ICENI einer virtuellen Organisation zur Verfügung gestellt werden kann. Ein Service ist folglich eine Ressource, die mit Informationen über ihre Nutzungsmodalitäten (Zugriff, Nutzungsrichtlinien und Lebensdauer) versehen ist und einer öffentlichen Gemeinschaft angeboten wird Rollen von Softwarekomponenten und Service Lifecycle Das LeSC definiert drei grundlegende Rollen, die eine Softwarekomponente einer idealtypischen SOA einnehmen kann [9]: Sie kann einen Service bereitstellen (Service Provider), einen Service nutzen (Service Consumer) oder aber die Verwaltung und Vermittlung von Diensten übernehmen (Service Broker). Der Lifecycle eines ICENI Services besteht dabei aus vier voneinander zu trennenden Phasen (vgl. Abbildung 1): (a) Erschaffung (Creation): Aus einer Ressource wird ein Dienst, indem diese Ressource mit einer Schnittstelle versehen wird, die andere Komponenten über die enthaltenen Fähigkeiten und Kontaktmöglichkeiten informiert. Der Dienst wird anschließend instanziiert und somit zur Nutzung bereitgestellt (b) Veröffentlichung (Advertisement): Der Service Provider veröffentlicht Informationen über einen Service, indem er diese Daten dem Service Broker bekannt gibt. Ein Service definiert

5 - 3 - sich dabei über zwei Aspekte: sein wohldefiniertes, für andere sichtbares Interface, das die bereitgestellten Methoden und erforderlichen Parameter kommuniziert und Metadaten, die seine Fähigkeiten beschreiben. Die Ankündigung eines Services kann in verschiedenen virtuellen Organisationen gleichzeitig geschehen und nach Bedarf mit unterschiedlichen Service Level Agreements (SLA) versehen sein, die definieren, zu welchen Bedingungen ein Service genutzt werden kann. Service veröffentlichen (b) Service Provider Service Broker Service erschaffen (a) Interagieren (d) Service-Oriented Architecture Service finden (c) Service Consumer Abbildung 1: Rollen und Lebenszyklus eines ICENI Services [9] (c) Entdeckung (Discovery): Eine andere Softwarekomponente (Service Consumer) fragt beim Service Broker einen Service mit bestimmten Fähigkeiten nach. Sie bekommt gegebenenfalls eine Rückmeldung über die Verfügbarkeit und die Kontaktdetails eines solchen Services innerhalb der virtuellen Organisation. (d) Interaktion (Interaction): Passen Angebot und Nachfrage nach einem Service zusammen, so kann auf Basis des SLA eine direkte Interaktion, d. h. die Nutzung des Dienstes durch den Service Consumer, erfolgen. Dieser muss sich in der Regel zunächst authentifizieren und wird gemäß der vom Provider vorgegeben Richtlinien zur Nutzung autorisiert Implementierungen auf Grundlage unterschiedlicher Basistechnologien Die erste Version der ICENI Grid Middleware wurde direkt auf das API der Jini Network Technology [9, 10] aufgesetzt. Zwar eignen sich die von der Jini-Bibliothek bereitgestellten Funktionalitäten sehr gut, um eine SOA abzubilden, allerdings bestehen Sicherheitsbedenken sowie Einschränkungen in der Reichweite der Kommunikation, beispielsweise über Firewalls hinweg. Die Umsetzung auf Basis von Jini brachte des Weiteren eine Restriktion auf Java-basierte Clientund Serverendpunkte mit sich. Um die Interoperabilität der Architektur zu erhöhen, wurde ICENI um Web-Service-Protokolle ergänzt und an die Open Grid Services Infrastructure (OGSI) [11] angepasst [10]. Im Rahmen der Anpassung wurde Jini weiterhin als primäre Serviceinfrastruktur genutzt, um der Dynamik des Systems gerecht zu werden; jedoch wurde im Sinne einer zweischichtigen Architektur auf einer höheren Ebene die Kommunikation durch Web-Services ermöglicht. Als weitere Variante wurde die in dieser Arbeit diskutierte Eignung des von SUN Microsystems [12] entwickelten Projekts JXTA [13] als Basistechnologie für eine SOA getestet.

6 Anforderungen an SOA-Basistechnologien Um das im Rahmen des ICENI-Projekts spezifizierte Design einer implementierungsunabhängigen SOA realisieren zu können, müssen Basistechnologien, auf die eine solche Architektur aufgesetzt wird, eine Reihe von Anforderungen erfüllen. Bei der Bewertung ist zu differenzieren, welche Eigenschaften der Technologie inhärent sind und welche Möglichkeiten einer SOA-konformen Erweiterung sich bieten. Das im Folgenden präsentierte Bewertungsframework basiert zum einen auf Anforderungen, die vom LeSC explizit oder implizit bewertet wurden [9]. Zum anderen werden generelle Eigenschaften verteilter Systeme sowohl mit einem Fokus auf Client/Server- Strukturen [14] als auch aus der Perspektive eines P2P-Netzwerks [15] bewertet. (1) Abbildung der grundlegenden Strukturen: Eine Basistechnologie sollte die in Abschnitt 2.2 definierten Strukturen einer SOA und den Lebenszyklus eines Services möglichst gut abbilden, um die mit diesem Design verbundenen Vorteile möglichst vollständig zu nutzen. (2) Lose Kopplung: Des Weiteren verlangt eine SOA nach Offenheit, so dass Services bestimmten Standardregeln (formalisiert in Protokollen) entsprechend angeboten werden. Insbesondere Schnittstellen sollten daher vollständig und neutral beschrieben sein, um die Interoperabilität zwischen verschiedenen Systemen (z. B. über Grenzen eines physischen Netzes hinaus) und die Portabilität von Anwendungen zu gewährleisten. Hierbei gilt es außerdem, das Einsatzfeld der SOA möglichst offen zu halten, um eine ubiquitäre Implementierung auf verschiedensten Gerätetypen anzuregen. (3) Dynamisches Verhalten: SOA sind potenziell einer großen Dynamik, d. h. einem stetigen Kommen und Gehen von Teilnehmern und Services, ausgesetzt. Dieser Dynamik gilt es, durch geeignete Mechanismen zu begegnen, um flexibel auf strukturelle Änderungen zu reagieren und die Beeinträchtigung anderer Komponenten zu verhindern. Dazu gehört die Robustheit des Systems bei unvorhergesehenen Vorkommnissen, z. B. bei Ausfall einzelner Komponenten. Außerdem ist eine gewisse Resistenz gegenüber Fehlern im Netzwerk oder anderen Diensten (z. B. falsche Routing-Informationen) sowie die Ermöglichung einer gewissen Spontaneität der Teilnehmer (z. B. mobile Geräte) wünschenswert. Gleichzeitig sollten sich Informationen über die Verfügbarkeit und Erreichbarkeit von Services schnell im Netz verbreiten, so dass die Nutzung veralteter Kontaktdaten vermieden wird. (4) Skalierbarkeit: Eng in Verbindung zum dynamischen Verhalten steht die Skalierbarkeit eines Systems. Unter Skalierbarkeit ist das Verhalten von Programmen [ ] bezüglich des Ressourcenbedarfs bei wachsenden Eingabemengen [16] zu verstehen. Im Kontext einer SOA sind daher die Einschränkung der Performance und das Ausmaß der Komplexitätssteigerung bei einer steigenden Anzahl an Services zu untersuchen. (5) Performance: Neben der Performance eines Systems unter starker Belastung, wie sie die Skalierbarkeit bewertet, können verschiedene Basistechnologien anhand ihres regulären Laufzeitverhaltens beurteilt werden. (6) Sicherheit: Durch die Zusammenführung nicht nur technisch sondern potenziell auch inhaltlich (d. h. in ihren Bedürfnissen, Absichten und Verhaltensweisen) heterogener Einheiten, ist es in einer SOA unabkömmlich, dass Sicherheitsvorkehrungen auf allen Ebenen der Infrastruktur

7 - 5 - getroffen werden. Sicherheitsanforderungen an ein Kommunikationssystem lassen sich hinsichtlich der Vertraulichkeit von Informationen, der Integrität von Nachrichteninhalten, der Verfügbarkeit der Kommunikationsinfrastruktur und der Zurechenbarkeit von Aktionen unterteilen [17]. (7) Organisation/Verwaltung: Um eine SOA zielgerichtet einsetzen und steuern zu können, ist es wünschenswert, Möglichkeiten zur systematischen Organisation und Verwaltung von Ressourcen bereitzustellen. Begünstigend wirken hierbei Mechanismen zur Bildung virtueller Organisationen, die Schaffung von Richtlinien (policies), die Überwachung (monitoring) und Aktivitätsmessung (metering) einzelner Komponenten sowie die Verwaltung von Metadaten einzelner Services. 3 Einführung in die Technologie JXTA 3.1 Evolution und Besonderheiten von JXTA Das Projekt JXTA (Kurzform für das englische juxtapose, zu deutsch nebeneinander stellen ) wurde im Jahr 2001 durch einen Mitbegründer von SUN Microsystems, Dr. Bill Joy, initiiert. Dessen Vision war es, P2P-Funktionalitäten in den Kern einer Netzwerkarchitektur zu integrieren und somit komplementäre Mechanismen zu bestehenden Client/Server-Architekturen zu etablieren. Die Technologie sollte dabei standardisierte Protokolle bereitstellen, die es ermöglichen, vom physischen Netzwerk zu abstrahieren und heterogene Peers miteinander zu verbinden. Diese Aspekte kamen bei herkömmlichen P2P-Netzwerken bislang zu kurz [15]. Ubiquität: JXTA is designed to be implemented on any device with a digital heartbeat [15]. Mit anderen Worten soll die Technologie auf jedem beliebigen elektronischen Gerät einsetzbar sein, so dass von Unterhaltungselektronik bis zu Archivsystemen verschiedenste Hardwareausprägungen eingebunden werden können. Plattformunabhängigkeit: Um den Gedanken der Ubiquität weiterzuführen, ist JXTA unabhängig von Programmiersprachen (z B. C oder Java), Betriebssystemen (z. B. Microsoft Windows oder UNIX) und Netzwerkplattformen bzw. -protokollen (z. B. TCP/IP, Bluetooth oder Heimnetzwerke) implementierbar. Interoperabilität: Teilnehmer in verschiedenen P2P-Systemen und Communities sollen sich grenzüberschreitend finden, miteinander kommunizieren und sich gegenseitig Dienste anbieten können. Bislang operiert der Großteil aller P2P-Netze unabhängig voneinander, so dass für verschiedene Anwendungszwecke eigene, inkompatible Communities bestehen, an denen ein Nutzer nur über unterschiedliche Applikationen teilnehmen kann. Die JXTA-Technologie, wie sie seit dem Start des Projekts von SUN Microsystems und einer wachsenden Entwicklergemeinschaft vorangetrieben wurde, stellt eine Menge an einfachen, offenen P2P-Protokollen bereit, die die Kommunikation, Kollaboration und das Teilen von Ressourcen zwischen jeglicher Art von vernetzten Geräten ermöglichen soll [9]. Die zu Grunde liegende Kom-

8 - 6 - plexität soll dem Entwickler dabei verborgen bleiben, so dass die zeit- und ressourcenintensive Programmierung eines Frameworks für verteilte Applikationen entfallen kann. Um die Verbreitung der Technologie zu unterstützen und wertvolles Know-how außerhalb des Unternehmens zu nutzen, ist JXTA als Open-Source-Projekt aufgesetzt. Jeglicher Quellcode unterliegt der Sun Project JXTA Software License 1, welche auf der Apache Software License Version 1.1 basiert Eigenschaften einer Peer-to-Peer-Architektur Während der letzten zwei Jahrzehnte war es verbreitet, Teilnehmer eines Netzes hierarchisch in Clients und Server zu unterscheiden, denen unterschiedliche Aufgaben obliegen. Der Client spielt in dieser Konstellation eine passive Rolle, in der er Dienste bei einem Server anfragt, jedoch selbst keine zur Verfügung stellt. Der Server hingegen empfängt und verarbeitet Anfragen, führt die gewünschte Aktion aus und schickt eine Antwort mit dem Ergebnis an den Client zurück. Dieses Konzept fand zunächst in geschlossenen, einheitlichen Local Area Networks (LAN) Anwendung und wurde später in Kombination mit universellen Clients (Web-Browsern) und Kommunikationsstandards (z.b. HTTP, HTML) auf eine Anwendung in heterogenen Umgebungen wie dem Internet ausgeweitet (vgl. Abbildung 2). Abbildung 2: Evolution von Client/Server- zu P2P-Architekturen [18] Diese zentrale Organisation von Informationen und Diensten ist besonders in den vergangenen Jahren durch die Idee einer dezentralen und hierarchielosen P2P-Architektur ergänzt worden. In einem P2P-Netz nimmt jedes System gleichzeitig die Rolle eines Clients und die eines Servers ein, so dass Kommunikation und Interaktion direkt und ohne zwischengeschaltete Instanz stattfinden können. Konkrete Anwendung hat diese Architektur bisher insbesondere in Instant-Messagingund File-Sharing-Applikationen sowie in Projekten des Distributed Computing gefunden [19]. Der grundsätzliche Einsatz einer P2P-Technologie hängt stark vom Anwendungskontext ab. Es ist zu erwarten, dass Client/Server- und P2P-Modelle in der praktischen Anwendung weniger konkurrierende als sich ergänzende Konzepte darstellen. Denkbar sind hybride Architekturen (vgl. 1 Die Lizenz ist unter verfügbar.

9 - 7 - Abbildung 2), die insbesondere für sicherheitskritische Operationen auf die Kontrollierbarkeit einer zentralen, serverbasierten Lösung setzen, für unkritische Transaktionen jedoch die Flexibilität eines P2P-Netzes nutzen [18, 20] Die JXTA-Architektur Um die durch JXTA bereitgestellten Protokolle so flexibel wie möglich einsetzen zu können, ist der Kern der Technologie sehr schlank gehalten. So ist JXTA prinzipiell in Verbindung mit jeder beliebigen Infrastruktur zu nutzen. Zugleich lässt sie dem Entwickler viel Spielraum in der konkreten Ausgestaltung von Anwendungen auf höheren Ebenen. Der Fokus liegt dabei auf der Schaffung von Mechanismen (mechanisms), ohne Verfahrensweisen (policies) festzulegen [9]. Referenzimplementierungen wurden von der JXTA Community bisher für J2SE, J2ME, C, C# und Perl entwickelt. 2 Abbildung 3 stellt den konzeptionellen Aufbau der Technologie und der darauf aufsetzenden Entwicklungen dar. Community JXTA Anwendungen SUN JXTA Anwendungen Community JXTA Services SUN JXTA Services Indizierung Suchfunktionen File Sharing JXTA Shell Peer Commands Peer Groups Peer Pipes Security Peer Monitoring Abbildung 3: Das Schichtenmodell der JXTA-Architektur [21] Der JXTA-Kern stellt grundlegende Mechanismen zur Verfügung, die für die Umsetzung einer P2P-Struktur unabkömmlich sind. Dazu gehört die Fähigkeit, einzelne Teilnehmer (Peers) zu identifizieren und in virtuellen Netzen (Peer Groups) zusammenzufassen, sowie die Kommunikation unter diesen zu ermöglichen (Peer Pipes) und individuelles Verhalten zu kontrollieren (Peer Monitoring). Analog zu der Vielzahl an Bibliotheken, die in einem UNIX-Betriebssystem Funktionen höherer Ebenen anbieten, ergänzen JXTA Services den Kern und vereinfachen damit die Anwendungsentwicklung. Beispiele für derartige Services sind Suchfunktionalitäten, Indizierungsmechanismen und gemeinsame Dateizugriffe. 2 Die aktuellen Versionen der Referenzimplementierungen sind unter frei verfügbar. Beispielapplikationen finden sich unter

10 - 8 - Die Anwendungsschicht nutzt schließlich die vom Kern und von erweiternden Services bereitgestellten Mechanismen, um vollständige P2P-Applikationen zu entwerfen. Diese werden teils von der JXTA Community, teils von SUN Microsystems selbst entwickelt. Eine besondere Rolle spielt in diesem Zusammenhang die JXTA Shell 3 als Konsolenanwendung mit einer kleinen Auswahl an Kommandos, um ohne signifikanten Programmieraufwand grundlegende Funktionen der Technologie zu testen. 3.2 Technische Einführung in JXTA Grundbegriffe Um die Funktionsweise von JXTA zu verstehen, gilt es zunächst, einige zentrale Grundbegriffe zu klären [15, 19, 22]. Ein Peer ist eine Einheit im P2P-Netzwerk, die mindestens eines der grundlegenden Protokolle beherrscht und auf diese Weise am Geschehen des Netzes teilhaben kann. Es kann sich dabei um beliebige Geräte mit einem digitalen Herzschlag [15] handeln, wobei ein Peer nicht notwendigerweise an eines gebunden ist, sondern geräteübergreifend oder zusammen mit anderen Peers auf einer physikalischen Einheit implementiert sein kann. Peers identifizieren sich über eine eindeutige Peer ID 4, die nicht systemgebunden ist. JXTA Peers lassen sich entsprechend ihres Verhaltens in Simple Peers, Rendezvous Peers und Relay Peers gruppieren: Simple Peers: Simple Peers sind die einfachste Form eines Peers, die grundsätzlich das Angebot und die Nachfrage von Diensten ermöglichen, jedoch keinerlei Verpflichtungen haben, Nachrichten weiterzuleiten oder andere Peers mit Informationen zu versorgen. Rendezvous Peers: Ein Rendezvous Peer dient dem Netzwerk als Treffpunkt. Er sammelt Informationen über Peers im Netzwerk und verteilt diese auf Anfrage, um Antwortzeiten zu reduzieren und das Verkehrsaufkommen im Netz zu begrenzen. Der Relay Peer: Ein Relay Peer hält Informationen über Wege zu einzelnen Peers vor, indem er eine Peer ID beispielsweise in eine IP-Adresse und einen zugehörigen TCP-Port umwandelt. Um einen Peer zu erreichen, kann es notwendig sein, mehrere Relay Peers zu durchlaufen, z. B. um inkompatible Transportprotokolle zu übersetzen. Sie dienen außerdem der Überbrückung von Firewalls und Network Address Translation (NAT). Peers organisieren sich in hierarchischen, über Peer Group IDs identifizierbaren Peer Groups, um das Gesamtnetz (die sog. NetPeerGroup) zu zerlegen und übersichtlicher zu gestalten. Indem sie sich auf ein bestimmtes Portfolio an Services einigen, können Peers beliebig viele Peer Groups 3 4 Die JXTA Shell ist unter verfügbar. Jede Entität wird in JXTA über einen Universally Unique Identifier (UUID), ein 128-Bit-Datum, zumindest mit sehr großer Wahrscheinlichkeit eindeutig identifiziert.

11 - 9 - gründen und diesen beitreten. Hauptmotivation für die Gründung von Peer Groups ist die Schaffung einer sicheren Umgebung, in der bestimmte Richtlinien gelten und gemeinsame Ziele oder Interessen verfolgt werden. Die Suche nach geeigneten Ressourcen und Inhalten kann so auf eine überschaubare Anzahl Peers beschränkt wird. Letztlich kann eine Peer Group als Überwachungsinstrument dienen, um beispielsweise ein Minimallevel an Serviceverfügbarkeit innerhalb der Gruppe zu gewährleisten. Innerhalb des P2P-Netzes kommunizieren Peers, um Services zu veröffentlichen, zu entdecken und aufzurufen. Man unterscheidet dabei einerseits Peer Services, die lediglich von einem bestimmten Peer angeboten werden und somit bei Ausfall des Peers vom Netzwerk nicht mehr verfügbar sind. Andererseits existieren Peer Group Services, die Mitgliedern einer Peer Group angeboten werden. Im Regelfall werden diese von mehreren Peers zur Verfügung gestellt, so dass die Funktionalität nicht von einer einzelnen Instanz abhängt. Insbesondere beim Eintritt in eine Peer Group kann es für einen Peer erforderlich sein, einen bestimmten Service anzubieten, den er zunächst aus dem Netz laden muss. Um auch heterogenen Systemen die Instanziierung gleichartiger Dienste zu ermöglichen, sind diese oft in Form abstrakter Verhaltensbeschreibungen, sog. JXTA Modulen, dargestellt. So kann ein Peer das erforderliche Verhalten in einer Sprache seiner Wahl und plattformunabhängig implementieren. Um Daten untereinander auszutauschen, benötigen Peers Mechanismen, die den Netzwerktransport managen. Die Quelle bzw. das Ziele einer Übertragung stellen dabei sog. Endpoints dar, die letztlich der Netzwerkschnittstelle eines Peers entsprechen. Die Verbindung zwischen zwei Peer Endpoints wird über unidirektionale, asynchrone, virtuelle Kommunikationskanäle, sog. Pipes, realisiert. Zur Laufzeit wird eine Pipe mit einer eindeutigen Pipe ID an einen sendenden Endpoint (Output Pipe) und einen empfangenden Endpoint (Input Pipe) geknüpft, um die Übertragung einer Nachricht auf virtuell direktem Wege zu ermöglichen. Bei einer Unicast Pipe korrespondiert eine Output Pipe (Sender) genau mit einer Input Pipe (Empfänger), wohingegen eine Propagate Pipe mehrere Input Pipes adressieren kann und somit die Grundlage für einen Broad- oder Multicast bildet. Eine entscheidende Bedeutung kommt sog. Messages zu, da sie die Basiseinheit des Datenaustauschs zwischen Peers bilden. Sie stellen Behälter für Daten im XML-Format dar und bestehen aus einer geordneten Folge von Elementen, die sich jeweils aus einer Bezeichnung (Tag) und einem Inhalt (Body) zusammensetzen. Der Header einer Message enthält administrative Informationen, z. B. über Ziel und Quelle der Übertragung sowie Berechtigungsnachweise. Advertisements stellen den Schlüssel zur Bekanntmachung verfügbarer Ressourcen im Netzwerk dar. Es handelt sich dabei um Metadaten, die in Form eines XML-Dokuments veröffentlicht werden, um auf Peers, Peer Groups, Pipes und Services/Module aufmerksam zu machen und ihre Eigenschaften strukturiert zu beschreiben. Advertisements können im lokalen Cache oder innerhalb der gesamten Peer Group veröffentlicht werden. Um die Aktualität gecacheter Advertisements zu verbessern, sind diese mit einer Lebensdauer versehen, nach deren Ablauf sie verworfen werden Das Basisset an Advertisements lässt sich durch XML-Schemata in Subtypen weiterentwickeln. Ein Beispiel eines Pipe Advertisements findet sich in Anhang A.

12 Protokolle Der Informationsaustausch jeglicher Art wird in JXTA über Protokolle realisiert. JXTA-Protokolle spezifizieren eine Menge an XML-Nachrichtenformaten, die durch asynchrone Anfrage- und Antwortmodelle ausgetauscht werden. Im Folgenden wird die Funktion der sechs JXTA-Protokolle kurz umrissen [15, 19, 22]. In Anhang B befindet sich ergänzend ein entsprechendes Schichtenmodell. Peer Discovery Protokoll (PDP): Das PDP definiert zwei XML-Schemata, die dem Veröffentlichen und Auffinden von Ressourcen (d. h. Peers, Peer Groups, Pipes etc.) mittels ihres Advertisements dienen. Peer Information Protocol (PIP): Sobald eine Ressource gefunden ist, können mit Hilfe des PIP Statusinformationen abgefragt werden. Pipe Binding Protocol (PBP): Zu Kommunikationszwecken kann unter Verwendung des PBP eine virtuelle Verbindung (Pipe) errichtet werden, die an Peer Endpoints geknüpft ist. Das PBP definiert Anfragen und entsprechende Antworten, um den zu einem Pipe Advertisement gehörenden Endpoint zu finden. Peer Resolver Protocol (PRP): Über das PRP können Peers beliebige Anfragen an alle oder ausgewählte Peers in der Peer Group verschicken. Es dient als Grundlage für Messages, die über das PDP oder PIP verschickt werden. Rendezvous Protocol (RVP): Das RVP dient der Verbreitung einer Message innerhalb der Peer Group und über das lokale Netz hinaus. Es übernimmt gleichzeitig die Kontrolle über diesen Vorgang (z. B. Prüfung der Lebenszeit von Advertisements, Erkennen von Loopbacks). Endpoint Routing Protocol (ERP): Das ERP stellt die letzte abstrakte Schicht vor dem eigentlichen Netzwerktransport dar. Im Regelfall sind Peers, die miteinander kommunizieren möchten, nicht direkt physisch verbunden, sondern durch eine Firewall getrennt oder Teil von Netzen mit unterschiedlichen Netzwerkprotokollen. Wege durch das Netzwerk müssen dann mittels ERP bei einem Peer mit Routingfunktionalitäten angefragt werden Beispielapplikation Um die Funktionsweise und Einsatzzwecke von JXTA zu demonstrieren, wird im Rahmen dieser Seminararbeit beispielhaft auf ein Anfrage-Antwort-Szenario für Reiseinformationen zurückgegriffen (siehe Anhang C). 5 Es wird zunächst eine Peer Group (travelnet) erschaffen, der Reisende (Traveller) und Reiseagenturen (Agency) beitreten können. Ein Reisender kann innerhalb dieses Netzes nach Agenturen suchen und allen entsprechenden Peers eine Anfrage für einen Zielort und eine Anzahl Personen schicken. Die Agenturen empfangen diese Anfrage und rufen eine simple 5 Das Szenario basiert auf Beispielen aus [15, 22].

13 Methode auf, die den Preis für die gewünschte Spezifikation berechnet. Anschließend schicken sie dem Reisenden ihr Angebot zurück. Abbildung 4 illustriert den Aufbau dieses Szenarios. Abbildung 4: Aufbau der Beispielapplikation travelnet Dieses Beispiel verdeutlicht die Vorteile einer dynamischen P2P-Basis, die es Agenturen und Reisenden erlaubt, der travelnet Peer Group spontan beizutreten und Services flexibel anzubieten oder zu nutzen. Die Funktionalität des Netzes ist nicht von einzelnen Komponenten, wie einem zentralen Server, abhängig und kann unterschiedlichste Hard- und Softwareplattformen einbinden. Peers können gleichzeitig sowohl Mitglieder anderer Peer Groups sein als auch mehrere Rollen einnehmen. Beispielsweise könnte eine Agentur gleichzeitig Service Consumer sein, wenn sie auf Anfrage eines Reisenden zunächst Angebote von Airlines und Hotels einholt, um dem Reisenden dann ein Komplettpaket anbieten zu können. Die Eigendynamik eines P2P-Netzes ermöglicht es einem Peer darüber hinaus, nach Bedarf untergeordnete Peer Groups, z. B. speziell für Abenteuerreisen, zu bilden und diese mit einem Advertisement innerhalb der travelnet Peer Group zu veröffentlichen. 4 Bewertung der Eignung von JXTA als Basis einer SOA In Anlehnung an die in Abschnitt 2.3 abgeleiteten Anforderungen an eine Basistechnologie zur Realisierung einer SOA, soll im Folgenden die Eignung von JXTA überprüft werden. 4.1 Abbildung der grundlegenden Strukturen Die Rollen, welche Services in einer SOA einnehmen können, lassen sich in JXTA nicht eindeutig abbilden. Die in Abschnitt vorgestellte Dreiecksarchitektur aus Service Provider, Service Consumer und Service Broker lässt sich lediglich auf das Konstrukt eines JXTA Peers zurückführen, wie in Abbildung 5 dargestellt. Ein JXTA-Peer kann eine oder mehrere dieser Rollen übernehmen. Fungiert er beispielsweise als Rendezvous Peer, so kommen ihm Aufgaben ähnlich denen eines Service Brokers zu.

14 Abbildung 5: Abbildung des SOA Designs auf JXTA-Strukturen [23] Nichtsdestotrotz lässt sich JXTA zum Aufbau einer SOA im Sinne von ICENI nutzen [9]. Hauptkonstrukt ist dabei die JXTA Peer Group, die es auf Grundlage einfachster Protokolle erlaubt, virtuelle Organisationen zu schaffen (vgl. Abbildung 6). So kann eine ICENI Peer Group eigene Peer Group Services definieren, welche allen Peers der Gruppe zur Verfügung stehen. Die weitere Strukturierung innerhalb der ICENI Peer Group kann über Subgruppen geschehen, die wiederum eigene Services implementieren oder allgemein verfügbare zu anderen Konditionen nutzen. Abbildung 6: Implementierung der ICENI SOA auf Basis von JXTA [9] Innerhalb der ICENI Peer Group durchlaufen Services den aus Abschnitt bekannten Lifecycle: (e) Erschaffung (Creation): Ein ICENI Service wird über die Erzeugung zweier Pipes ins Leben gerufen. Eine dieser Pipes fungiert als Empfangskanal für öffentliche Kontrollnachrichten, die an die gesamte Gruppe geschickt werden. Die andere ist ein privater Kanal, der für die Interaktion mit anderen Peers genutzt wird. (f) Veröffentlichung (Advertisement): Zum Zwecke der Bekanntmachung eines Services wird ein spezifisches Advertisement erstellt, das den Service identifiziert und die Servicedaten in Form eines XML-Dokuments beschreibt. Unter Verwendung eines Peer Group Services wird dieses Advertisement in der Gruppe veröffentlicht.

15 (g) Entdeckung (Discovery): Ein weiterer Group Service dient der Suche nach anderen Services entsprechend ihrer ID oder ihren Servicedaten innerhalb der ICENI Peer Group. (h) Interaktion (Interaction): Nachdem ein Service gefunden wurde, wird dieser über eine JXTA Message kontaktiert. Der Aufruf des Services selbst hängt individuell vom verwendeten Protokoll ab. So können Services unter anderem über bekannte APIs wie RMI oder SOAP angesprochen werden, sofern die entsprechenden Daten zur Übertragung in eine JXTA Message verpackt werden. 4.2 Erfüllung der Anforderungen an eine SOA-Basistechnologie Unter Hinzuziehung beispielhafter Details wird JXTA anhand der weiteren in Abschnitt 2.3 definierten Anforderungen bewertet. (1) Abbildung der grundlegenden Strukturen: Wie in Abschnitt 4.1 dargelegt, gibt es für die Konstrukte einer traditionellen SOA keine eindeutigen Entsprechungen, gleichwohl die Lebensphasen eines Services dennoch abgebildet werden können. (2) Lose Kopplung: Eine offene, von technischen Details abstrahierende Technologie bereitzustellen, waren grundlegende Ziele bei der Entwicklung der JXTA-Architektur (vgl. Abschnitt 3.1). Durch schlanke, plattformunabhängige Protokolle sind Interoperabilität und Portabilität gewährleistet. So erlaubt JXTA beispielsweise durch den Einsatz von Relay Peers und flexible Protokollwahl (z. B. HTTP) die Kommunikation über Firewalls und NAT hinweg. Weiterhin erlaubt der teils kritisierte hohe Grad an Flexibilität [19] der JXTA-Protokolle eine verhältnismäßig aufwandsarme Anpassung der Architektur an zukünftige Entwicklungen. (3) Dynamisches Verhalten: JXTA ist auf eine unkontrollierbare Dynamik im Netz ausgelegt. Durch die grundsätzliche Gleichberechtigung aller Peers gibt es nur schwache Abhängigkeiten von zentralen Instanzen (wie beispielsweise Rendezvous oder Relay Peers). Das System ist so robust, dass Peers flexibel in Peer Groups ein- und austreten, ihren Ort wechseln und unterschiedliche Rollen einnehmen können, ohne dass andere Peers signifikant davon betroffen wären. Problematisch ist an dieser Stelle die Geschwindigkeit, mit der sich Informationen über derartige Ereignisse im Netz verbreiten. Um das Netz zu entlasten, greifen Peers (inkl. Rendezvous Peers) auf gecachete Daten zurück, die jedoch veraltet sein können. Zwar kann ein Advertisement mit einer Lebensdauer versehen werden, jedoch fehlt eine strenge Gültigkeitskontrolle. Die Struktur des Netzes verhindert es sogar, eigene Advertisements zu löschen, wenn ein Service eingestellt, eine Pipe geschlossen oder ein Peer vom Netz genommen wird. So kann es zu wiederholten Kontaktversuchen nichterreichbarer Services mit einer entsprechend negativen Wirkung auf die Performance kommen. Ebenso können Anfragen an das Netz gänzlich ohne Antwort bleiben. Dem Problem mangelnder Aktualität kann zu einem gewissen Grad durch die Einrichtung von Peer Groups begegnet werden, die über die Core Services hinausgehende Prüfmechanismen anbieten. Innerhalb von Peer Groups besteht z. B. die Möglichkeit, die Verfügbarkeit gewisser

16 Services sicherzustellen, indem ein bestimmter Anteil an Mitgliedern verpflichtet wird, diese anzubieten. So kann über Redundanzen stets ein definiertes Service Level aufrechterhalten werden, auch wenn einzelne Peers die Mitgliedschaft kündigen oder ausfallen. (4) Skalierbarkeit: Grundsätzlich sind der Anzahl an Peers im Netz keine Grenzen gesetzt. Durch die dezentrale Architektur verteilt sich der Verkehr im Netzwerk relativ gleichmäßig, mit der Folge, dass Engpass-Problematiken, wie sie in einer Client/Server-Architektur oft vorkommen, vermieden werden. Auf der anderen Seite kann die Suche nach Ressourcen ohne zentrale Informationsverwaltung in einem großen Netz sehr aufwändig werden, so dass die Performance beeinträchtigt wird. Insbesondere Broadcast Messages können geringe Bandbreiten schnell überlasten. Gegensteuernd wirken hier die Bildung von Peer Groups zur Einschränkung des Suchradius und die Verwendung von Rendezvous Peers, die in Ansätzen wie ein Service Broker fungieren. (5) Performance: Wie bereits erwähnt sind Interaktionen zwischen Peers einerseits durch eine gute Verteilung des Verkehrsaufkommens begünstigt, andererseits durch suboptimale Informationsversorgung beeinträchtigt. Ein weiterer Aspekt ist die ausschließliche Verwendung XMLbasierter Nachrichtenprotokolle, die zwar Flexibilität garantieren, durch die damit verbundene Syntaxanalyse jedoch negativ auf die Performance wirken. Empirische Untersuchungen haben entsprechend hohe Latenzzeiten für JXTA Pipes ergeben [24]. Ebenso wurde festgestellt, dass der Startup-Prozess eines Peers durch den Verbindungsaufbau zu einem Rendezvous Peer und das Update des lokalen Caches viel Zeit in Anspruch nimmt [25]. Grid-Applikationen, wie sie beispielsweise im ICENI-Netz zum Einsatz kommen sollen, sind somit sehr schnell Grenzen gesetzt. (6) Sicherheit: JXTA berücksichtigt heutige Anforderungen an umfassende Sicherheitsvorkehrungen und legt den Grundstein für Vertraulichkeit, Authentifizierung, Autorisierung und Datenintegrität bereits im Kern [22]. Allerdings spezifiziert JXTA selbst kein High-level- Sicherheitsmodell, sondern überlässt es dem Entwickler, auf dieser Grundlage aufzusetzen und individuelle Mechanismen zu implementieren. In jeder JXTA Message ist beispielsweise ein Feld für Berechtigungsnachweise (credentials) vorgesehen, dessen Interpretation jedoch den Services überlassen ist. Die JXTA J2SE-Implementierung hat darüber hinaus grundlegende Sicherheitsvorkehrungen, wie Transport Layer Security (TLS), Zertifikate und einen Passwortschutz, eingerichtet [26]. Da der JXTA-Technologie immer wieder mangelnde Sicherheitsspezifikationen vorgeworfen werden, wurden inzwischen unabhängige Pakete und APIs entwickelt, die den Kern entsprechend ergänzen. 6 (7) Organisation/Verwaltung: Die Dezentralität einer P2P-Architektur macht die umfassende Verwaltung eines großen Netzes nahezu unmöglich. Anstelle einer Nutzung zentraler Instanzen ist JXTA auf die Selbstverwaltung von Peers in virtuellen Organisationen ausgerichtet. Peers können sich eigenständig in Peer Groups organisieren, in denen sie sich auf weitergehen- 6 Weitere Entwicklungen zur Verbesserung der Sicherheit von JXTA treibt das JXTA Security Project unter voran.

17 de organisatorische und überwachungstechnische Mechanismen einigen und somit nicht auf eine übergeordnete Verwaltung angewiesen sind. Dieser Aspekt impliziert jedoch die Problematik einer ggf. inkonsistenten oder unlogischen Strukturentwicklung, die es Peers ohne Vorwissen erschwert, effizient nach Services zu suchen. Innerhalb einer Peer Group können einzelne Peers durchaus zentrale Rollen einnehmen (z. B. als Informationssammelstelle), so dass hybride Strukturen entstehen. Alles in allem deckt JXTA viele Anforderungen an eine SOA-Basistechnologie ab. Insbesondere in Aspekten der Offenheit, Flexibilität und Dynamik hat JXTA Vorteile anderen Technologien und Netzstrukturen gegenüber. Als nachteilig erweist sich die Sicherheitsproblematik eines P2P-Netzes sowie Performanceeinbußen durch den Austausch von XML-Nachrichten und die Aktualisierung des lokalen Caches. 5 Zusammenfassung und Ausblick Im Rahmen dieser Seminararbeit wurde zunächst in die Vorstellung einer SOA zur Realisierung einer Grid Middleware eingeführt. Anschließend wurden das Projekt JXTA, die sich dahinter verbergende Motivation und relevante technische Grundlagen vorgestellt. Die Themen wurden in einem Abgleich der Eignung von JXTA zum Aufbau einer SOA zusammengeführt. Einerseits kann die JXTA-Technologie in ihrer Ursprungsform die Anforderungen an eine SOA- Basistechnologie nur bedingt erfüllen. Andererseits zeigt sich durch die Offenheit der Technologie in vielen Bereichen Entwicklungspotenzial. Zwar generiert gerade diese Offenheit eine gewisse Komplexität, die sich negativ auf Performance und Sicherheitsvorkehrungen auswirkt. Sie macht jedoch gleichzeitig die Zukunftsfähigkeit der Technologie aus. Das wachsende Interesse für effiziente Netzstrukturen in Forschung und Praxis bietet einer Technologie wie JXTA die Chance, sich in einem Markt zu behaupten, der bislang Client/Server-Systemen und inkompatiblen P2P-Netzen gehörte. Die aufgezeigten Defizite der Technologie lassen sich auf höheren Abstraktionsebenen, also durch Services oder Applikationen, behandeln, so dass sie langfristig kaum ins Gewicht fallen werden. Mit einem Blick über den Rahmen dieser Arbeit hinaus lässt sich feststellen, dass es Alternativen, wie beispielsweise Jini und OGSI, gibt, die andere Vor- und Nachteile mit sich bringen. Welche Entwicklung am besten geeignet ist, ist stark kontextabhängig. Letztlich scheint zum aktuellen Zeitpunkt eine Kombination mehrerer Technologien sinnvoll, um die jeweiligen Stärken bestmöglich zu nutzen [9].

18 Literaturverzeichnis [1] London e-science Centre (Hrsg.): ICENI Website. [2] Imperial College of London, ICENI Research Group (Hrsg.): Imperial College e-science Networked Infrastructure. London, [3] Imperial College of London (Hrsg.): London e-science Centre Website. [4] HAU, J. ; LEE, W. ; NEWHOUSE, S.: The ICENI Semantic Service Adaptation Framework. In: UK e-science All Hands Meeting. September Nottingham, UK. S [5] FOSTER, I. ; KESSELMAN, C. ; TUECKE, S.: The Anatomy of the Grid - Enabling Scalable Virtual Organizations. In: International Journal of Supercomputer Applications (2001), Nr. 15(3). [6] BENGEL, G.: Grundkurs Verteilte Systeme. Wiesbaden: Vieweg Verlag, [7] MCGOUGH, S. ; YOUNG, L. ; AFZAL, A. ; NEWHOUSE, S. ; DARLINGTON, J.: Performance Architecture within ICENI. In: UK e-science All Hands Meeting September 2004: EPSRC. S [8] HAU, J. ; LEE, W. ; NEWHOUSE, S.: Autonomic Service Adaptation using Ontological Annotation. In: 4th International Workshop on Grid Computing, Grid November Phoenix, USA. [9] FURMENTO, N. ; HAU, J. ; LEE, W. ; NEWHOUSE, S. ; DARLINGTON, J.: Implementations of a Service-Oriented Architecture on Top of Jini, JXTA and OGSI. In: Grid Computing: Second European AcrossGrids Conference, AxGrids Januar Nicosia, Zypern. S [10] FURMENTO, N. ; LEE, W. ; MAYER, A. ; NEWHOUSE, S. ; DARLINGTON, J.: ICENI: An O- pen Grid Architecture Implemented with Jini. In: SuperComputing November Baltimore, USA. [11] The Globus Alliance (Hrsg.): OGSA Website. [12] SUN Microsystems (Hrsg.): Jini Network Technology Website. [13] SUN Microsystems (Hrsg.): Projekt JXTA Website. [14] TANENBAUM, A. ; STEEN, M. V.: Verteilte Systeme - Grundlagen und Paradigmen. München: Pearson Studium, [15] OAKS, S. ; TRAVERSAT, B. ; GONG, L.: JXTA in a Nutshell. Sebastopol, SA: O'Reilly Associates Inc., 2002.

19 [16] Wikimedia Foundation Inc. (Hrsg.): Wikipedia - Die freie Enzyklopädie. [17] MÜLLER, G. ; EYMANN, T. ; KREUTZER, M.: Telematik- und Kommunikationssysteme in der vernetzten Wirtschaft. München: Oldenbourg Wissenschaftsverlag, [18] SCHNEIDER, J.; O'Reilly Open p2p (Hrsg.): Convergence of Peer and Web Services. [19] WILSON, B.: JXTA. Indianapolis, Indiana: New Riders Publishing, [20] CONNOLLY, P. J.: Peer-to-peer. In: InfoWorld (2002), Nr. 24(1), S. 35. [21] DORNFEST, R.; OpenP2P.com (Hrsg.): JXTA Takes Its Position. [22] SUN Microsystems, Inc. (Hrsg.): JXTA v2.3.x: Java Programmer's Guide. Palo Alto, [23] FURMENTO, N. ; HAU, J. ; LEE, W. ; NEWHOUSE, S. ; DARLINGTON, J.: Präsentation: Implementations of a Service-Oriented Architecture on top of Jini, JXTA and OGSI. In: Access Grids Conference. Nicosia. [24] ANTONIU, G. ; HATCHER, P. ; JAN, M. ; NOBLET, D. ; Institut National de Recherche en Informatique et en Automatique (Hrsg.): Performance Evaluation of JXTA Communication Layers (extended version), ftp://ftp.inria.fr/inria/publication/publi-pdf/rr/rr pdf [25] HALEPOVIC, E. ; DETERS, R.: The Costs of Using JXTA. In: Proceedings of the 3rd International Conference on Peer-to-Peer Computing [26] BROOKSHIER, D. ; KRISHNAN, N. ; GOVONI, D. ; SOTO, J. C.: JXTA: Java P2P Programming: Sams Publishing, 2002.

20 Abbildungsverzeichnis Abbildung 1: Rollen und Lebenszyklus eines ICENI Services [9]...3 Abbildung 2: Evolution von Client/Server- zu P2P-Architekturen [18]...6 Abbildung 3: Das Schichtenmodell der JXTA-Architektur [21]...7 Abbildung 4: Aufbau der Beispielapplikation travelnet...11 Abbildung 5: Abbildung des SOA Designs auf JXTA-Strukturen [23]...12 Abbildung 6: Implementierung der ICENI SOA auf Basis von JXTA [9]...12 Abbildung 7: Das Schichtenmodell der JXTA-Protokolle [19]...20

21 Abkürzungsverzeichnis API HTML HTTP ICENI IP J2ME J2SE LAN LeSC NAT OGSI P2P RMI SLA SOA SOAP TCP TLS XML Application Programming Interface Hypertext Markup Language Hypertext Transfer Protocol Imperial College e-science Networked Infrastructure Internet Protocol Java 2 Platform, Micro Edition Java 2 Platform, Standard Edition Local Area Network London e-science Centre Network Address Translation Open Grid Services Infrastructure Peer-to-Peer Remote Method Invocation Service Level Agreement Service-Oriented Architecture Simple Object Access Protocol Transport Control Protocol Transport Layer Security Extended Markup Language

22 Anhang A Beispiel eines Pipe Advertisements <?xml version="1.0"?> <!DOCTYPE jxta:pipeadvertisement> <jxta:pipeadvertisement xmlns:jxta=" <Id> urn:jxta:uuid-9cccdf5ad8154d3d87a e59be4b888209a22 41A4A162A A9504 </Id> <Type> JxtaUnicast </Type> <Name> Agentur Sunshine </Name> </jxta:pipeadvertisement> B Die Protokollarchitektur von JXTA Peer Discovery Protokoll Peer Information Protokoll Pipe Binding Protokoll Über das Peer Resolver Protokoll Über das Peer Resolver Protokoll Über das Peer Resolver Protokoll Peer Discovery Protokoll Peer Information Protokoll Pipe Binding Protokoll Peer Resolver Protokoll Über das Endpoint Routing Protokoll Peer Resolver Protokoll Rendezvous Protokoll Über das Endpoint Routing Protokoll Rendezvous Protokoll Peer Endpoint Protokoll Über Netzwerkprotokolle Peer Endpoint Protokoll Netzwerktransport Über Netzwerkprotokolle Netzwerktransport Standard Service Protokolle Kernprotokolle Systematik der JXTA-Protokolle Abbildung 7: Das Schichtenmodell der JXTA-Protokolle [19]

23 C Beispielanwendung travelnet Im Folgenden wird der Javacode für eine simple Beispielanwendung einer SOA zur Verfügung gestellt. 7 Die Klasse Agency implementiert dabei eine Reiseagentur, während die Klasse Traveller einen Reisenden abbildet. Beide Objekte können mit unterschiedlichen Parametern beliebig oft instanziiert werden, so dass sich ein Netz aus Anbietern und Nachfragern bildet und Reisende unterschiedliche Angebote auf ihre Anfragen erhalten. Das Beispiel basiert auf der JXTA J2SE-Referenzimplementierung unter Verwendung von JXTA v C.a Java-Code einer Reiseagentur (Agency) import java.io.*; import java.util.*; import java.lang.*; import net.jxta.peergroup.peergroup; import net.jxta.peergroup.peergroupfactory; import net.jxta.exception.peergroupexception; import net.jxta.document.advertisementfactory; import net.jxta.document.structureddocumentfactory; import net.jxta.document.advertisement; import net.jxta.document.element; import net.jxta.document.mimemediatype; import net.jxta.document.structureddocument; import net.jxta.document.structuredtextdocument; import net.jxta.document.structureddocumentutils; import net.jxta.discovery.discoveryservice; import net.jxta.pipe.pipeservice; import net.jxta.pipe.inputpipe; import net.jxta.pipe.outputpipe; import net.jxta.pipe.pipeid; import net.jxta.protocol.pipeadvertisement; import net.jxta.protocol.peergroupadvertisement; import net.jxta.protocol.moduleimpladvertisement; import net.jxta.protocol.moduleclassadvertisement; import net.jxta.protocol.modulespecadvertisement; import net.jxta.endpoint.message; import net.jxta.endpoint.messageelement; import net.jxta.endpoint.inputstreammessageelement; import net.jxta.platform.moduleclassid; import net.jxta.platform.modulespecid; import net.jxta.id.idfactory; import net.jxta.id.id; /* Die Klasse "Agentur" repraesentiert eine Reiseagentur, die von Reisenden Anfragen fuer ein bestimmtes Ziel und eine Anzahl reisender Personen erhaelt. Jede Agentur kann beliebige Ziele und Preise anbieten und entsprechend auf Anfragen antworten. Zusaetzlich werden Informationen ueber ein Spezialangebot mitgeschickt. */ public class Agency { private PeerGroup netpg = null; // Die Standard Peer Group "NetPeerGroup" private PeerGroup travelnet = null; // Die neue Peer Group "travelnet" // Das Advertisement der neuen Gruppe 7 Die Anwendung ist auf Grundlage von Beispielen aus [15, 22] entstanden.