Ein Vergleich auf die Eignung als Grundlage für eine Service-Oriented Architecture Sebastian Albrecht Westfälische Wilhelms - Universität Münster Fachbereich Mathematik und Informatik Arbeitsgruppe Parallele und Verteilte Programmierung Prof. Dr. habil. Sergei Gorlatch
Inhaltsverzeichnis 1. Einleitung... 3 1.1. Die ICENI SOA...3 2. Einführung in die Basistechnologie OGSI... 4 2.1. OGSI eine Abkürzung unter vielen... 4 2.2. Die Ergänzungen von OGSI zu Web-Services... 5 2.2.1. GSH und GSR: Wie finden sich die einzelnen Partner?... 5 2.2.2. porttypes legen wichtige Funktionen fest... 6 2.2.3. ServiceGroups: porttypes zur Umsetzung eines Service Brokers... 7 2.2.4. Notification... 8 2.3. Wie OGSI in der ICENI Welt eingesetzt wird... 8 2.4. Die Zukunft von OGSI... 8 3. Einführung in die Basistechnologie Jini... 9 3.1. Was ist Jini?... 9 3.1.1. Geschichtliches... 9 3.1.2. Ziele und Versprechungen von Jini... 9 3.1.3. Verständnis eines Services im Kontext von Jini... 10 3.1.4. Jini Architektur... 10 3.2. Implementierung einer SOA mit Hilfe von Jini... 11 3.2.1. Jini und die Verwandtschaft mit Java... 11 3.2.2. Lookup Service Die Zusammenführung von Klient und Service... 11 3.2.3. Events... 13 3.2.4. Wie Jini die ICENI SOA ermöglicht... 13 4. Bewertung von Jini und OGSI im Kontext von ICENI... 13 Literaturverzeichnis... 16-2 -
1. Einleitung Das Grid Computing wird immer wichtiger, daher verwundert es nicht, dass verschiedene Technologien und Konzepte für das Grid Computing entstehen. In dieser Arbeit werden zwei Technologien Open Grid Service Infrastructure (OGSI) und Jini, zuerst vorgestellt und dann miteinander verglichen. Der Focus dabei liegt auf ihrer Eignung für die Implementierung einer Service-Oriented-Architecture (SOA). Eine SOA kann für unterschiedliche Zwecke geschaffen werden und daher unterschiedliche Anforderungen an die zu Grunde liegende Technologie stellen. OGSI und Jini werden im Kontext der SOA, die vom Imperial College London für die ICENI Middleware festgelegt wurde, verglichen und bewertet. I 1.1. Die ICENI SOA Eine typische SOA legt drei Rollen fest. Der Service Anbieter stellt einen Service im Grid zu Verfügung. Der Service Broker ist ein Verzeichnis von Services, mit Information wo diese zu finden sind und was diese können, z.b. beschrieben durch ein XML-Dokument. Der Service Nutzer sucht einen Service für eine bestimmte Aufgabe. 1 Service Broker Werbung Auffinden Service Anbieter Interaktion Service Nutzer Abbildung 1.1. Service-Oriented Architecture Vier Schritte gibt es für den Lebenszyklus eines Services. 1. Entstehung: Durch den Aufruf einer Instanzierungsfunktion z.b. bei einer Factory, wird mit Hilfe des Interfaces eines Services, eine neue Instanz geschaffen. 2. Werbung: Die neue Instanz registriert sich mit einem Service Level Aggrement (SLA) beim Service Broker. Das SLA beschreibt den Service und legt Zugriffsberechtigungen fest. 3. Auffinden: Der Service Nutzer stellt eine Anfrage an den Broker, für einen Service der bestimmte Funktionen zur Verfügung stellt. Eine Referenz zu diesem wird dann übergeben. 4. Interaktion: Service Provider und Nutzer stimmen sich über I In der Arbeit Implementations of a Service-Oriented-Architecture on Top of Jini, JXTA and OGSI vom Imperial College London wird eine eine dritte Technologie JXTA betrachtet. Diese sowie eine ausführlichere Darstellung des allgemeinen Konzeptes finden sich in der Ausarbeitung von Lisa Richter Name. - 3 -
die Interaktionswege ab und der Provider leistet die gewünschten Aufgaben. Für alle vier Schritte sollte eine verwendete Technologie Standards festlegen und durch definierte Funktionen unterstützen. 2. Einführung in die Basistechnologie OGSI 2.1. OGSI eine Abkürzung unter vielen Wenn man sich mit OGSI (Open Grid Service Infrastructure) auseinander setzt, begegnet man vielen Abkürzungen und ähnlichen Begriffen, z.b. OGSA, Web-Services, Grid-Services, etc. Deshalb werden wichtige Begriffe, die mit OGSI in Verbindung stehen, im Folgenden gegen einander abgegrenzt. spezifiziert Implementiert in Java definiert und basiert auf Erweiterung von Abbildung 2.1. Einordnung von OGSI 2 Nutzt Standards: XML, WSDL, SOAP, Das Global Grid Forum (GGF) hat sich zum Ziel gesetzt Grid Computing zu vereinfachen und zu standardisieren. Hierfür haben sie die Open Grid Service Architecture (OGSA) definiert, die alle Anwendungen in einem Grid vereinheitlichen soll, so dass diese problemlos mit einander kommunizieren können. Bei OGSA handelt es sich jedoch nur um eine Architektur, dieser Bauplan sagt jedoch nichts über die zu Grunde liegende Technologie aus. Das GGF hat sich aus verschiedenen Technologien für Verteiltes Rechnen für Web-Services als Grundlage für OGSI entschieden. Diese Entscheidung begründet sich auf zwei entscheidenden Vorteilen gegenüber anderen Technologien: - 4 -
1. Web-Services sind plattform- und programmiersprachen-unabhängig. D.h. der Klient und Server können unterschiedliche Betriebssysteme verwenden und die kommunizierenden Anwendungen können sogar in unterschiedlichen Sprachen geschrieben sein. 2. http wird als Protokoll für den Transfer der Informationen verwendet, dies bedeutet das Schwierigkeiten bei der Überwindung von Firewalls und Systemgrenzen (Betriebssysteme, Programmiersprachen, etc.) reduziert werden. Web-Services waren jedoch nicht ausreichend um alle Anforderungen von OGSA abzubilden, daher hat das GGF OGSI definiert. OGSI erweitert die Spezifikation von Web-Services um entscheidende Komponenten. Um Web-Services, die die OGSI Spezifikationen erfüllen, abzugrenzen wurde der Begriff Grid-Service geschaffen. Web- und Grid-Services werden mit Hilfe von XML, Web-Service-Description-Language (WSDL) und Simple Object Access Protocol (SOAP) umgesetzt. Auf diese Technologien wird hier allerdings nicht näher eingegangen. Das Globus Toolkit (GT) ist eine Referenz Implementierung von OGSI in Java. ICENI verwendet für die Umsetzung seiner SOA in eine Middleware das GT3. 2.2. Die Ergänzungen von OGSI zu Web-Services Im nun folgenden Abschnitt werden die Ergänzungen erläutert, die OGSI zu den Web-Service Spezifikationen hinzufügt. Mit Hilfe dieser Ergänzungen soll es möglich sein, OGSA oder auch die SOA von ICENI zu realisieren. 2.2.1. GSH und GSR: Wie finden sich die einzelnen Partner? Ein Klient (im Sinne von Service Nutzer) kommuniziert immer mit einer Instanz von einem Grid Service. Es ist möglich, dass mehrere Instanzen desselben Services im Grid vorhanden sind. Damit ein Klient eine Instanz eines Services auffinden kann, ist in OGSI das Konzept von Grid Service Handle (GSH) und von Grid Service References (GSR) verankert. 3 Der GSH wird für jede Instanz, beim Erzeugen dieser, global einmalig vergeben. Mit einem GSH weiß der Klient allerdings nur, wo sich die Service-Instanz befindet, er hat noch keinerlei Informationen darüber wie er mit dem Service kommunizieren kann, z.b. welche Nachrichten er versendet oder empfangen kann. In einer GSR stehen genau diese Informationen zur Verfügung. Jedoch kann eine GSR im Zeitablauf ungültig werden. Ein Klient kann sich mit einem GSH an den Handle Resolver, ein wichtiger Service im Grid, wenden um eine aktuelle GSR zu erhalten. Ein Klient muss extern eine gültige GSR zu einem Handle Resolver vorgegeben bekommen, z.b. durch Konfiguration bei der Installation des Klienten. Für gewöhnlich ca- - 5 -
chen Klienten GSRs und senden nur wenn eine bestimmte GSR ungültig geworden ist, den entsprechenden GSH zur Auflösung an den Handle Resolver. In OGSI wird, im Gegensatz zu Web-Services, von dem Konzept der Factory und Instanzen, bekannt aus der objekt-orientierten Programmierung, gebrauch gemacht. Wie im vorher gehenden Abschnitt bereits durchklang, kommunizieren Klienten mit Instanzen von Grid- Services. Ein Klient kann mit mehreren Instanzen desselben Services in Verbindung stehen, es kann aber auch sein das auf eine Instanz mehrere Klienten zu greifen. Eine Factory erzeugt die Instanzen von Grid-Services. Daher kann zu jederzeit, in der eine Factory Service verfügbar ist, eine Instanz eines bekannten Services geschaffen werden. Die Factory liefert nach dem die createservice Funktion aufgerufen wurde einen GSH an den Klienten für die neue Instanz. Nicht alle Services müssen von Factorys geschaffen werden, vor allem Services von denen nicht mehrere Instanzen existieren sollen, können ohne Factory verfügbar gemacht werden. 4 2.2.2. porttypes legen wichtige Funktionen fest Jeder Grid-Service muss den GridService porttype implemtieren. Dieser porttype legt wichtige Attribute fest, darunter auch z.b. GSH, GSR und einige weitere. Ein entscheidender Vorteil gegenüber Web-Services wird ebenfalls durch diesen porttype ermöglicht. Es muss das Attribut terminationtime gesetzt werden, dies bedeutet, dass eine Instanz nur eine bestimmte Lebensdauer hat. Man sagt daher auch, ein Grid Service ist transient (flüchtig) im Gegensatz zu Web-Services, die persistent (beständig) sind. Zur Manipulation der Lebensdauer definiert OGSI drei Funktionen 1. Destroy, sofortiges Ende der Lebensdauer, 2. RequestTermination- Before, Verkürzung der Lebensdauer und 3. RequestTerminationAfter, Verlängerung der Lebensdauer. porttypes legen Attribute und Funktionen fest, die ein Service zur Verfügung stellen muss, wenn er den porttype implementiert. Dieses Konzept ist unter Java als Interfaces bekannt, porttypes entstammen der WSDL und sind mit der Version 2.0 von WSDL auch zu Interfaces umbenannt worden. 5 Der Vorteil von Grid-Services ist, dass sie mehr als nur einen porttype implementieren können. Web-Services sind auf einen beschränkt. OGSI definiert mit dem Konzept von porttypes zwei weitere wichtige Elemente für SOAs, ServiceGroups und Notification. - 6 -
2.2.3. ServiceGroups: porttypes zur Umsetzung eines Service Brokers ServiceGroups werden mit Hilfe von drei porttypes umgesetzt und werden verwendet um Sammlungen von GSHs zu ermöglichen, in OGSI als Registries bezeichnet. Dieses Konzept kann und wird dazu verwendet Service Broker im Sinne von ICENI zu realisieren. Den Rahmen für ein Registry bildet der porttype ServiceGroup. Er enthält zwei Service Data Elemente. Der erste heißt Entry Definition mit diesem kann für das Registry festgelegt werden, welche Arten von Services sich registrieren dürfen, z.b. können porttypes festgelegt werden, die jeder Service implementiert haben muss. Das zweite Element heißt Entries und ist der eigentliche Registrierungseintrag eines Services. Neben dem GSH des Services enthält der Entry auch eine Beschreibung des Services in Form eines XML Dokumentes. Auf diese wird bei einer Klienten Anfrage dann zurückgegriffen um zu prüfen ob der Service die gewünschten Eigenschaften hat. Ein weiteres Attribut ist ebenfalls zwingend, eine Referenz zum ServiceGroupEntry porttype. Mit Hilfe von ServiceGroupEntry kann das Registry Gültigkeiten für registrierte Services verwalten, d.h. es kann z.b. festgelegt werden das die Registrierung nach 2 Tagen ausläuft und dann gelöscht wird, es sei den der Service ruft eine Funktion auf, die den Gültigkeitszeitraum verlängert. Der dritte porttype ServiceGroupRegistration legt nur die Funktionen und Attribute fest, die zum Erstellen und Entfernen eines Eintrages im Registry nötig sind. Die Abbildung 2.2. zeigt einige Elemente, wie ein Eintrag eines Services in einem Registry aussehen kann. <entry> <memberservicelocator> <ogsi:handle> http://beispiel.de/ogsa/services/sharedcounter/factory </ogsi:handle> </memberservicelocator> <content> <createserviceextensibilityinfo> <createsinterface>counter</createsinterface> <createsinterface>gridservice</createsinterface> <createsinterface>notificationsource</createsinterface> </createserviceextensibilityinfo> </content> </entry> Der GSH, der den Standort des Services angibt Beschreibung dessen was dieser Service leistet Abbildung 2.2. Beispiel Eintrag in einem Registry - 7 -
2.2.4. Notification Der Notification - Mechanismus wurde eingeführt, damit Grid-Services Klienten über Änderungen an ihrem Zustand informieren können. Technische Vorrausetzung hier für ist, dass der Grid-Service den Notifiction porttype implementiert. Ein Klient kann sich dann beim Service einschreiben um bei einer Zustandsänderung informiert zu werden. Dabei kann festgelegt werden, dass der Klient höchstens alle x Zeiteinheiten informiert wird. Ebenso kann er festlegen, dass er mindestens alle y Zeiteinheiten ein Update über den Zustand erhält. Hat keine Änderung statt gefunden, so sendet der Service dieselben Zustandinformationen erneut. 2.3. Wie OGSI in der ICENI Welt eingesetzt wird Die vier Schritte, die im ersten Abschnitt, als grundlegend für eine SOA erläutert wurden, können mit den im Abschnitt 2.2. vorgestellten Funktionen und Methoden umgesetzt werden. Erzeugung: Für den Grid-Service muss eine Instanz geschaffen werden. Hierfür kann auf eine Factory zurückgegriffen werden. Werbung: Durch ServiceGroups können die Funktionen eines Services Brokers übernommen werden. Jeder Grid-Services registriert sich dann bei einem oder mehreren Registries nach seiner Erzeugung. Dabei verwendet er die durch den porttype ServiceGroupRegistration zur Verfügung gestellten Funktionen. Auffinden: Jedes Registriy ist selber ein Service und implementiert daher den porttype Grid Service. In diesem ist bereits die Funktion findservicedata festgelegt. Durch diese Funktion wird es prinzipiell ermöglicht nach bestimmten Service Data Elementen in einem Registry zu suchen. Meistens stellt ein Registry jedoch komfortablere Funktionen zum Suchen zur Verfügung. Wenn ein passender Service gefunden wird, übergibt das Registry den GSH des Services an den Klienten. Interaktion: Der Klient schickt den GSH an den Handle Resolver und erhält eine GSR, mit Hilfe dieser kann der Klient mit dem Grid-Service kommunizieren. Alle wichtigen Informationen sind im GSR hierfür enthalten. 2.4. Die Zukunft von OGSI OGSI kann man einfach als Erweiterung vom Konzept der Web-Service verstehen. Erweiterungen sind aber keine vollständige Integration in ein bestehendes Konzept. Außerdem hat sich mittlerweile gezeigt, das OGSI einige Schwierigkeiten hat, sich vollständig dem Web-Service Konzept anzupassen. Bestehende Tools für Web-Services arbeiten - 8 -
nicht problemlos mit Grid-Services. Web-Services sind nicht objekt-orientiert, jedoch hat sich OGSI einige Konzepte aus der Objekt-Orientierung abgeschaut und übernommen. Diese Vorwürfe haben dazu geführt, dass im Januar 2004 eine neue Spezifikation, Web Services Resource Framework (WSRF) vorgestellt wurde. Diese soll die OGSI - Spezifikation vollständig ersetzten. WSRF geht dabei völlig in den Spezifikationen der Web-Services auf. Heute, Juni 2005, ist zwischenzeitlich das GT4 veröffentlich worden. Mit dieser Version ist der Schritt der Ablöse von OGSI durch WSRF für das Globus Toolkit vollzogen. Auswirkungen auf Anwendungen, die OGSA umsetzten, soll es nach Möglichkeit nicht geben. WSRF hat alle Interfaces, die auch OGSI hatte, somit hat sich nur die zu Grunde liegende Technologie für OGSA geändert, nicht aber OGSA selber. 3. Einführung in die Basistechnologie Jini 3.1. Was ist Jini? 3.1.1. Geschichtliches Im Januar 1999 wurde von Sun Microsystems die Version 1.0 des Jini Frameworks veröffentlicht 6. Der Ursprung von Jini geht jedoch viel weiter zurück. Die ersten Gedanken an eine Unterstützung von Verteiltem Rechnen finden sich in Oak, eine Programmiersprache, die ein internes Projekt bei Sun Microsystems war 7. Der Öffentlichkeit wurde dieses Projekt erst mit dem Namen Java im Jahre 1995 8 bekannt. Noch während das Projekt nicht öffentlich war, sollten bereits Funktionen für Remote Method Invocation (RMI) bereits gestellt werden. Dieses Vorhaben scheiterte jedoch vorerst. Später wurde Java RMI als Zusatz für Java veröffentlicht. Java RMI ermöglichte die Programmierung von verteilten Softwareanwendungen 9. Nachdem Java RMI Teil der Java Plattform wurde, entstand ein Team, dass das Ziel hatte Verteiltes Rechnen zu vereinfachen. Die Arbeit dieses Teams bekam den Namen Jini. Mittlerweile wurde Version 2.02 von Jini publiziert (Juni 2005). An den Grundsätzen und Zielen für die Jini steht hat sich jedoch nichts geändert. Jini selber ist kein Akronym, sondern ein Eigenname. 3.1.2. Ziele und Versprechungen von Jini Jini will Netzwerke ermöglichen deren Natur von Dynamik geprägt ist, d.h. in einem laufenden Prozess kommen neue Komponenten hinzu und alte werden entfernt. Die nötige menschliche Administration eines solchen Netzwerkes soll dabei soweit wie möglich vereinfacht und reduziert werden. 10-9 -
Das Netz selber ist eine Quelle für Instabilität und Komponenten Ausfälle, Jini will mit seiner Architektur und Diensten zuverlässiges und stabiles Arbeiten ermöglichen. Verteilte Anwendungen sollen einfach zu entwickeln sein. Hierfür spezifiziert Jini Protokolle und die Abstammung aus der Java Familie reduziert den Lernaufwand für einen Entwickler, der Java kennt deutlich. 3.1.3. Verständnis eines Services im Kontext von Jini Sun Microsystems selbst bezeichnet das Konzept des Services als wichtigstes Element der Jini Architektur. Ein Service ist eine Entität die von einer Person, einem Programm oder einem anderem Service genutzt werden kann. 11 Ein Service kann vielfältige Funktion haben, z.b. Berechnungen, Speicherung von Daten, Steuerung einer Hardware-Einheit und ähnliches. Die gesamte Architektur ist dynamisch ausgelegt, daher ist ein Schlüsselelement, die Möglichkeit Services zu jeder Zeit dem Netzwerk hinzuzufügen oder zu entfernen. Services kommunizieren mit Hilfe von Service Protokollen, die in Form von Java Interface geschrieben sind. 3.1.4. Jini Architektur Die Netzwerk Architektur, die Jini zu Grunde liegt, ähnelt stark der SOA im Sinne von Iceni. Netzwerk Service 6 1 2 5 Service Proxy Netzwerk Klient Service Proxy 3 Lookup Service 4 Abbildung 3.1.. Funktionsweise von Jini 12 1.Auffinden: Netzwerk Service findet verfügbare Lookup Services (LUS) 2.Beitreten: Netzwerk Service sendet seine Servicedaten zum LUS 3.Auffinden: Netzwerk Klient findet verfügbare LUS 4.Nachsehen: Netzwerk Klient sendet Anforderung für einen gewünschten Service 5.Empfangen: LUS sendet Informationen über registrierte Services 6.Interagieren: Netzwerk Service und Klient kommunizieren direkt miteinander Für die weitere Betrachtung können die Schritte 1 u. 2 zum Iceni Schritt Werbung, die Schritte 3,4 u. 5 zu Entdeckung und Schritt 6 zu Interaktion zusammengefasst werden. Im folgenden Abschnitt werden nun die Methoden und Funktionen die Jini zur Umsetzung des SOA Gedankens zur Verfügung stellt, allgemein vorgestellt und bewertet. - 10 -
3.2. Implementierung einer SOA mit Hilfe von Jini 3.2.1. Jini und die Verwandtschaft mit Java Im geschichtlichen Abschnitt 3.1.1. ließ es sich bereits vermuten, dass Jini durch die enge Verwandtschaft mit Java auch viele Eigenschaften von Java geerbt hat. Auf jedem Rechner, der mit Jini arbeitet läuft zwangsweise auch die Java Virtual Machine (JVM), alle Jini Klassen werden in der Regel auch auf dieser ausgeführt. Das heißt alle Einstellungen der JVM gelten weitestgehend auch für ein Jini Prozesse. Von besonderer Bedeutung sind zwei Eigenschaften der JVM. Zwei JVMs haben die Möglichkeit Java-Code auszutauschen, d.h. es können sowohl Programmcode als auch Objekte transferiert werden. Ein Service-Proxy (siehe Abbildung 3.1) ist ein Objekt, welches der Netzwerk-Service beim LUS bzw. Service Provider platziert. Dieses Objekt stellt eine Bevollmächtigung dafür da, dass der jeweilige Partner auf den Service zu greifen darf. Alle Sicherheitseinstellungen, die für die JVM aktiv sind, gelten auch für Jini. Z.B. darf fremder Code nur ausgeführt werden, wenn der Rechner auf dem dies geschehen soll, dies auch erlaubt. 3.2.2. Lookup Service Die Zusammenführung von Klient und Service Beide Service Provider und Klient müssen bevor sie miteinander agieren können, mit dem LUS in Verbindung treten. Der LUS hat die Aufgabe Registrierungen von Service Providern entgegen zu nehmen und Klienten den gewünschten Service aufzuzeigen. In jedem Netzwerk, das auf der Jini-Architektur basiert, muss daher mindestens ein Lookup-Service verfügbar sein, da sonst Service Anbieter und Klient keine Möglichkeit haben sich gegenseitig zu finden. Um dieser Aufgabe nach zukommen, führt der LUS eine Liste aller bei ihm registrierten Services. Der LUS ist mit dem UDDI bei Webservices oder dem Name-Server bei DNS vergleichbar. Damit diese Liste nicht voller veralteter, nicht funktionierender Referenzen ist, wie zum Beispiel eine Internetseite, die nur noch Verweise auf nicht mehr existente Seiten hat, wurde der Lease Renewal - Mechanismus entwickelt. D.h. jede Registrierung eines Services hat nur eine bestimmte Gültigkeitsdauer (z.b. 5 Minuten), möchte der Service Anbieter über einen längeren Zeitraum registriert bleiben, so muss dieser die Registrierung in dem vorgegebenem Zeitintervall erneuern. Durch diesen einfachen Mechanismus werden drei wichtige Ziele erreicht 1. Aktualität, 2. Selbst - Reparatur und 3. Selbst Replizierung. 1. Aktualität: Jeder Services der aus dem Netzwerk entfernt wird, sei es bewusst oder durch Fehlfunktion des Netwerkes selber, kann seine Registrierung nicht erneuern und - 11 -
wird somit nach dem festgelegtem Zeitintervall automatisch aus der Liste der verfügbaren Services gestrichen. Die Liste ist stets (unter Berücksichtung des Zeitintervalls) aktuell. 2. Selbst Reperatur: Nach einem Netzwerk-Fehler sendet der LUS eine Hier bin ich Nachricht. Isolierte Services empfangen diese und registrieren sich darauf hin. 3. Selbst Replizierung: In einem Jini-Netzwerk können mehr als ein LUS laufen. Jeder Service kann sich bei beliebig vielen LUS registrieren. Stürzt ein LUS ab, ist immer noch ein LUS vorhanden mit allen Services. Bei einem neuen LUS registrieren sich dann die vorhandenen Services erneut. Service Anbieter und Klienten müssen bevor sie sich registrieren können, erstmal den LUS auffinden. Es stehen zwei Methoden zum Auffinden eines LUS im Jini-Framework zur Verfügung 1. Unicast Discovery und 2. Multicast Diskcovery. 13, diese werden durch das Discovery-Protokoll näher bestimmt. 1. Unicast Discovery: Hierfür muss vor der Registrierung bereits der Standort (z.b. IP- Adresse oder eine URL) dem Service Anbieter bzw. dem Klienten bekannt sein. Der Service sendet einfach einen Registrierungsantrag an den LUS, dieser antwortet dann und die Registrierung kann abgeschlossen werden. 2. Multicast Discovery: Diese Methode wird verwendet, wenn der Standort eines LUS nicht im Vorhinein bekannt ist. Der Service ruft im Netzwerk nach einem LUS. Der Ruf hat einen Parameter Time-to-Live (TTL), der angibt wie viele Gateways passiert werden bevor das Signal erlischt. LUS die das Signal empfangen, antworten entsprechend. Der Service kann Antworten von mehreren LUS erhalten und muss selber entscheiden, bei welchen er sich registrieren möchte. Der LUS ist, wie man es schon dem Namen entnehmen kann, selber nur ein Service, den andere Services verwenden. Es kann sich dabei um einen expliziten Rechner handeln auf dem nur der LUS läuft, oder es können auf einem Rechner alle drei Rollen Service Anbieter, LUS und Klient auftreten. Die Abbildung 3.2. zeigt ein einfaches Interface, welches als Service Proxy verwendet wird. Dieses Interface wird beim LUS als Beschreibung des Services hinterlegt und ein Klient der eine Implementation von sayhello() sucht, bekommt dieses übergeben. public interface Hello extends Remote { String sayhello() throws RemoteException; } Abbildung 3.2. Beispiel Interface - 12 -
3.2.3. Events Der Mechanismus der Events ähnelt stark dem Mechanismus der Notification bei OGSI. Auch hier kann sich ein Klient beim Service registrieren um über Zustandsänderungen informiert zu werden. Jedoch gibt es keine Möglichkeiten Zeitabstände für Aktualisierungen anzugeben. Der Klient muss einen Listener (Java-Konstrukt) einsetzen. An diesen sendet der Service dann, Informationen über Zustandsänderungen, aber auch nur dann wenn sich der Zustand geändert hat. 3.2.4. Wie Jini die ICENI SOA ermöglicht Die Anforderungen die Sun Microsystems mit der Jini Technologie anspricht, liegen sehr nahe an denen von ICENI. Daher sind die vier grundlegenden Schritte auch problemlos mit Jini Abbild bar. Erzeugung: Der Service muss gestartet werden und ein Objekt des Services instanziert werden. Werbung: Mit Hilfe einer Discovery Methode macht der Service Provider einen LUS ausfindig. Durch ein Join-Protokoll, welches hier nicht näher vorgestellt wurde, kann sich der Service bei dem LUS registrieren. Auffinden: Auch ein Klient muss erstmal einen LUS ausfindig machen, auch hier kommt das Discovery Protokoll zum Einsatz. Danach wird eine Anfrage für den gewünschten Service an den LUS gesendet. Der LUS sendet dann den vom Service Provider abgelegten Service Proxy als Referenz an den Klienten. Der Klient kennt nun den Standort des Services. Interaktion: Der Klient hat durch den erhaltenen Service Proxy Kenntnis über die zur Verfügung stehenden Funktionen. Der Klient kann nun einfach diese Funktionen aufrufen. Ob dafür nur Java-Objekte ausgetauscht werden oder sogar Code ist Service abhängig. 4. Bewertung von Jini und OGSI im Kontext von ICENI Mit beiden Technologien, Jini und OGSI, lässt sich die SOA, wie sie von ICENI spezifiziert ist, realisieren. Beide stellen Klassen und Interfaces zur Verfügung, die sich eignen die drei Rollen Service Provider, Service Broker und Service Consumer umzusetzen. Dennoch lassen sich beide Technologien klar differenzieren, da sie von unterschiedlichen Zielen motiviert sind. OGSI, basierend auf Web-Service, ist von der Community des e-businesses über das GGF entstanden. Im Gegensatz dazu ist ICENI und auch Jini mehr auf e-science fokussiert. E-Business zielt wesentlich mehr auf das komfortable und sichere Anbieten von Dienstleis- - 13 -
tungen (Services) ab. Dagegen ist für E-Science vor allem das Verteilte Rechnen entscheidend, d.h. das Ressourcen komfortable verwaltet und zuverlässig zu geteilt werden können. Die Performance, im Sinne von Geschwindigkeit, ist bei Jini wesentlich besser als bei OGSI, dies ist vor allem darin begründet, dass bei Jini direkt Java-Objekte ausgetauscht werden. Bei OGSI werden XML-Dokumente zur Kommunikation verwendet, die erst aufwendig in die passenden Sprachkonstrukte transferiert werden müssen. Die besondere Bedeutung die Jini in die Definition des LUS und die daran angegliederten Protokolle legt, sorgen dafür, dass ein Jini-Netzwerk sehr robust ist und schnell auf hinzugefügte bzw. entfernte Komponenten reagiert. D.h. Einträge in einem LUS werden ständig aktuell gehalten und Klienten Anfragen können fast immer mit gültigen Referenzen beantwortet werden. OGSI ermöglicht auch die Umsetzung von Service-Brokern mit Hilfe der Service Group Elemente. Jedoch liegen die genauen Umsetzungen in der Hand des Entwicklers. So wird z.b. häufig die Gültigkeit von Registry-Einträgen in Tagen vorgenommen, während bei Jini oft nur Minutenabstände gewählt werden. Diese Zeit lässt sich zwar heruntersetzten, aber auch dann verhält sich ein OGSI-Netzwerk nicht so robust wie Jini, z.b. wenn ein Service Broker in ein Netz kommt hat er bei Jini die Here I am Nachricht um sich bekannt zu machen. Bei OGSI gibt es einen solchen Mechanismus nicht explizit. OGSI ist auf Grund der Verwendung von XML Plattform unabhängiger als Jini. Zwar verwenden beide Technologien http als Übertragungsprotokoll, aber an die Implementation der Services und Klienten stellen sich andere Anforderungen. Bei OGSI muss nur mit XML- Dokumenten umgegangen werden können. Die meisten Programmiersprachen unterstützen bereits die Umwandlung von XML in interne Datenstrukturen, mit denen dann gearbeitet wird. Für Jini muss es möglich sein ein Java-Interface in das Programm einzubinden. Mit Java selber ist das kein Problem, allerdings kann es zu Schwierigkeiten kommen ein Java- Interface z.b. in C einzubinden. MIt XML-Dokumenten sind Services auch leichter zu beschreiben, so können Meta-Daten ganz individuell genutzt werden. In den Java-Objekten müssen hierfür bestimmte Attribute, häufig in Form von Arrays, festgelegt werden, was den Handlungsspielraum etwas einschränkt. Das von ICENI genutzte Service Level Agreement, welches fest legt wer wann auf einen Service zugreifen kann, ist mit XML einfach zu ergänzen. Dagegen muss hier für in den Jini-Services erst ein Attribut geschaffen werden, dass diese Bedeutung zugewiesen bekommt. Verteiltes Rechnen findet nicht nur in einem lokal begrenzten Raum statt, sondern im idealen Fall wird das gesamte Netz zu einem Grid. In dieser Umgebung sind häufig Firewalls an zu - 14 -
treffen, die einzelne Bereiche schützen. Firewalls müssen aber, wenn erlaubt, von Services überwunden werden. Viele Firewalls lassen problemlos XML-Dokumente durch, blockieren jedoch Bytecode in dem die Java-Objekte von Jini übertragen werden. Daher ist mit OGSI eine leichtere Interoperationalität gewährleistet. Bei Jini hatte man Sicherheitsbedenken, durch die Möglichkeit des Codetransfers und den bewegten Java-Objekten, sah man Lücken in der Sicherheit. Man befürchtete, dass fremder, bösartiger Code sich auf den Klienten laden konnte und ausgeführt würde. Auch die richtige Authentifizierung von Klienten sah man als nicht vollständig gewährleistet an. Mit der Version 2.0 von Jini, hat man vor allem den Aspekt der Sicherheit im Auge gehabt und deutlich verbessert, z.b. Verschlüsselung und dynamische Sicherheitsmodelle wurden ergänzt. OGSI greift auf bewährte Techniken aus dem Bereich des Internets zurück, z.b. ist der Einsatz von SSL-Verschlüsselung möglich. ICENI hat mit Hilfe von Jini, OGSI und weiteren Technologien eine umfangreiche Grid- Middleware geschaffen. Der Kern ist vor allem aus Geschwindigkeitsaspekten mit Jini umgesetzt worden. Zu vielen verschiedenen weitern Techniken, z.b. OGSI oder JXTA, sind Gateways geschaffen worden. Alle Angebotenen Services werden als IceniServices veröffentlicht. Im Hintergrund handelt es sich dann z.b. um Jini-Services der von einen OGSI Klienten genutzt wird. 14-15 -
Literaturverzeichnis 1 Nathalie Furmento u.a., Implementations of a Service-Oriented-Architecture on Top of Jini, JXTA and OGSI, http://www.lesc.ic.ac.uk/iceni/pdf/axgrids2004_paper.pdf, Januar 2004 2 Borja Sotomayor, The Globus Toolkit 3 Programmer's Tutorial, http://gdp.globus.org/gt3- tutorial/download/progtutorial-pdf_0.4.3.tar.gz, Seite 14ff, 2003 & 2004 3 S. Tuecke u.a, Open Grid Service Infrastructure, http://www.gridforum.org/documents/gfd.15.pdf, Seite 30ff, Juni 2003 4 T. Banks u.a., Open Grid Service Infrastructure Primer, http://www.gridforum.org/documents/gfd.31.pdf, Seite 26ff, August 2004 5 J. Treadwell, OGSA Glossary of Terms, http://www.ggf.org/documents/gfd.44.pdf 6 Sun Microsystems, Jini Specifications and API Archive, http://java.sun.com/products/jini/ 7 Ken Arnold, The Jini Specifications The Second Edition, Addison Wesley, Seite 8, Dezember 2000 8 Sun Microsystems, Java Technology: The Early Years, http://java.sun.com/features/1998/05/birthday.html 9 Sun Microsystems, Java Remote Method Invocation (Java RMI), http://java.sun.com/products/jdk/rmi/index.jsp 10 Robert Flenner, Jini and JavaSpaces Application Development, Sams Publishing, Seiten 2f, Dezember 2001 11 Sun Microsystems, Jini Architecture Specification, http://www.sun.com/software/jini/specs/jini1.1html/jini-spec.html#1001135 12 Sun Microsystems, Jini Network Technology, http://www.sun.com/software/jini/whitepapers/jini-datasheet0601.pdf / Seite 3 13 California Software Laboratories, Jini by Example, http://www.cswl.com/whiteppr/tutorials/jini.html 14 ICENI Research Group, ICENI Contributors Guide, http://www.lesc.ic.ac.uk/iceni/downloads/guide/section6.html - 16 -