Fachbereich Informatik

Transkript

1 Diplomarbeit Web Services zur automatischen Softwareverteilung Kristian Mihajloski Juni 2004 Betreuer: Prof. Dr. Paul Müller Dipl. Inform. Markus Hillenbrand Fachbereich Informatik AG Integrierte Kommunikationssysteme Universität Kaiserslautern Postfach Kaiserslautern

2 Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kaiserslautern, (Kristian Mihajloski)

3

4 Abstract Durch die zunehmende Vernetzung von Rechnern entstehen immer größere und komplexere Netzwerke. Die Rechner können dabei unterschiedliche Ausprägungen bzgl. eingesetzter Hard- und auch Software haben. Auf Notebooks und Desktop-Computern werden z.b. völlig andere Prozessorarchitekturen und Betriebssysteme eingesetzt als auf PDAs oder Handys. Gemeinsam ist jedoch allen Rechnern eines: Sie benötigen Software, die auf ihren Rechnern lauffähig ist und dem Endbenutzer zur Verfügung gestellt werden kann. Gerade in großen Netzwerken ist es hilfreich, wenn die Verteilung und Installation dieser Software von zentraler Stelle und vollautomatisch erfolgen kann. Die Software ist dabei im Netz gelagert und wird bei Bedarf vom Benutzer angefordert. Der Download, die Installation und der Start der Software geschieht dabei im Idealfall vollautomatisch, sodass der Benutzer sofort mit der Software arbeiten kann. In einer heterogen Systemumgebung stellt die Realisierung einer solchen Softwareverteilung natürlich besondere Anforderungen, da hier gewährleistet werden muss, dass für den Rechner des anfragenden Benutzers auch die richtige Software geliefert wird. Die vorliegende Arbeit beschäftigt sich mit dieser Problematik und zeigt ein Konzept, das, basierend auf der Web Services- Technologie, ein auch in heterogenen Systemumgebungen einsetzbares Softwareverteilungssystem realisiert.

5

6 Inhaltsverzeichnis Inhaltsverzeichnis Kapitel 1: Einleitung... 8 Kapitel 2: Verteilte Anwendungen Historische Entwicklung Service-orientierte Architekturen Verteilte Objektarchitekturen Stub und Skeleton Common Object Request Broker Architecture (CORBA) Distributed Component Object Model (DCOM) Java Remote Method Invocation (Java RMI) Web Services Zusammenfassung Kapitel 3: Automatische Softwareverteilung Einführung Unterstützende Technologien Java Webstart / JNLP Microsoft Windows Installer (MSI) Grid Application Definition Language (GADL) Open Software Description (OSD) Kommerzielle Softwareverteilungssysteme Zusammenfassung Kapitel 4: Modellierung eines Web Service zur automatischen Softwareverteilung Modellbildung Datentypen Client_Descriptor Software_Descriptor Global_Software_Descriptor Download_Descriptor Downloadfile WSDL-Datei (Schnittstelle) Service-Komponente... 76

7 Inhaltsverzeichnis Software-Management Bearbeitung von Softwareanfragen Softwareübertragung Clientsoftware Zusammenfassung...83 Kapitel 5: Implementierungsaspekte...84 Kapitel 6: Zusammenfassung und Ausblick...92 Kapitel 7: Anhang XML-Schemata Client_Schema.xsd Software_Schema.xsd Global_Software_Schema.xsd Download_Schema.xsd XML-(Beispiel)-Instanzen Software_Descriptor.sds Global_Software_Descriptor.xml getdownload_descriptor.xml getdownload_descriptorresponse.xml getpacked_file.xml getpacked_fileresponse.xml Literaturverzeichnis Abbildungsverzeichnis...116

8 8 Einleitung Kapitel 1: Einleitung Die Vernetzung von Computern gewinnt in der heutigen Zeit immer mehr an Bedeutung. Das Internet wird täglich von Millionen Menschen genutzt. Auch Intranets, wie sie z.b. in Unternehmen eingesetzt werden, sind bei der Abwicklung der täglichen Geschäftsprozesse nicht mehr wegzudenken. Die dabei entstehenden Netzwerke werden immer komplexer. Verschiedene Topologien und Transportprotokolle kommen zum Einsatz, und immer mehr Rechner mit unterschiedlicher Hardware werden miteinander verbunden. Die Wartung und Pflege solcher heterogenen Systemlandschaften ist sehr aufwendig und geht in der Regel mit hohen Kosten einher. Besonders problematisch ist dabei die Installation von Software auf den einzelnen Clients. Bei kleineren Unternehmen übernimmt diese Arbeit ein Administrator, der vor Ort auf jedem einzelnen Client die benötigte Software installiert. Bei großen Unternehmen, die Netzwerke mit mehreren tausend Clients umfassen, ist dieser Lösungsansatz nicht vertretbar. Die Kosten für die eingesetzten Arbeitsstunden würden explodieren. Abgesehen davon müssen die Mitarbeiter während der Installationsphase ihre Arbeit unterbrechen. Aus diesem Grund ist es sinnvoll, solche Vorgänge automatisch und von zentraler Stelle aus zu steuern. Die zu installierende Software liegt im Netz gelagert und wird bei Bedarf von den Clients herunter geladen und installiert. Das Herunterladen und auch die Installation laufen im Idealfall vollautomatisch ab, sodass der Benutzer nur den Installationsprozess abwarten muss und direkt danach mit der Benutzung der gewünschten Software beginnen kann. Dieser Ansatz ist im Grunde genommen nicht neu, es existiert schon eine große Zahl kommerzieller Softwareverteilungssysteme, die diesen umsetzen. Sie haben aber alle einen großen Nachteil: Sie sind nicht vollständig plattformunabhängig. Sie haben Vorgaben bezüglich der eingesetzten Hardware, Programmiersprache und des Betriebssystems und funktionieren somit nur auf speziellen Rechnern. Gerade in den oben erwähnten heterogenen Systemlandschaften geht dabei die Flexibilität verloren. Ein Client ist heutzutage nicht mehr zwingend ein Desktop-Computer, es kann sich z.b. auch um ein Notebook, Handy oder PDA handeln, und diese setzen teilweise völlig andere Hard- und Software ein. Die begrenzte Plattformunabhängigkeit rührt zum großen Teil von den eingesetzten Schnittstellen der einzelnen Softwareverteilungssysteme her. Damit die Kommunikation zwischen Softwarelieferant und Softwareempfänger funktioniert und die Daten übertragen werden können, muss eine Schnittstelle angegeben werden. Zur Beschreibung dieser Schnittstellen werden entweder herstellereigene oder andere Spezifikationen verwendet, die auf bestimmte Programmiersprachen, Betriebssysteme, Transportprotokolle oder Hardware ausgelegt sind und somit die Unabhängigkeit einschränken.

9 Einleitung 9 Die sich nun stellende Frage ist folgende: Existiert eine Technologie, welche es ermöglicht, ein plattformunabhängiges Softwareverteilungssystem umzusetzen und wenn ja, wie? In der vorliegenden Diplomarbeit wird gezeigt, dass die Web Services-Technologie dazu sehr gut geeignet ist. Web Services setzen auf Service-orientierten Architekturen auf, die auf die Umsetzung von plattformunabhängigen Schnittstellen ausgelegt sind. Mit ihnen lassen sich verteilte Anwendungen besonders flexibel implementieren. In Kapitel 2 soll zunächst die historische Entwicklung von verteilten Anwendungen wiedergegeben werden; dabei wird den Service-orientierten Architekturen ein eigener Abschnitt gewidmet. Anschließend werden verschiedene Technologien untersucht, mit denen sich Service-orientierte Architekturen umsetzen lassen. Es wird gezeigt, dass Web Services zu den wenigen gehören, die es ermöglichen, vollkommen plattformunabhängige Schnittstellen zu beschreiben [Gis01-2]. Im dritten Kapitel erfolgt die erste Annäherung an die Umsetzung eines plattformunabhängigen und automatischen Softwareverteilungssystems. Zunächst werden verschiedene Beschreibungssprachen beleuchtet, die zur Realisierung eines automatischen Softwareverteilungsdienstes eingesetzt werden können. Danach werden einige schon auf dem Markt erhältliche Softwareverteilungssysteme vorgestellt. Die einzelnen Stärken und Schwächen aller Ansätze werden aufgearbeitet, als Ergebnis bleibt: Die Technologien bieten viel Positives, das aufgegriffen werden kann, keine aber realisiert ein Softwareverteilungssystem wie es Ziel dieser Diplomarbeit ist. In Kapitel 4 wird deshalb ein komplett neues Softwareverteilungssystem, basierend auf der Web Services-Technologie, ausgearbeitet. Bei der sehr detailliert zu beschreibenden Modellbildung wird auf die drei Hauptparteien eines Softwareverteilungsprozesses, den Web Service (Schnittstelle), den Softwareanbieter (Service-Komponente) und den Softwareempfänger (Clientsoftware) eingegangen. Das fünfte Kapitel widmet sich schließlich diversen Implementierungsaspekten. Verschiedene Implementierungsmöglichkeiten und die damit einhergehenden Probleme werden erläutert. Das abschließend zusammenfassende Kapitel gibt einen Ausblick auf mögliche Erweiterungen und Einsatzgebiete dieses Softwareverteilungssystems.

10 10 Verteilte Anwendungen Kapitel 2: Verteilte Anwendungen In diesem Kapitel wird zunächst die historische Entwicklung von verteilten Anwendungen angesprochen. Die Service-orientierten Architekturen sind für diese Diplomarbeit von besonderem Interesse und werden deshalb in einem gesonderten Abschnitt behandelt. Darauf aufbauend werden einige bestimmte Technologien vorgestellt, mit denen sich Service-orientierte Architekturen implementieren lassen. Vor- und Nachteile werden jeweils aufgearbeitet und als Entscheidungsgrundlage hinsichtlich der Brauchbarkeit bei der Realisierung eines automatischen Softwareverteilungssystems verwendet. 2.1 Historische Entwicklung Mitte der 80er Jahre war der Einsatz von zentralisierten Großrechnern weit verbreitet. Sie wurden in Multi-User-Betrieben eingesetzt, in denen die Benutzer über lokale oder entfernte Terminals auf die dort laufenden Programme zugreifen konnten. Durch zwei grundlegende Entwicklungen ist dieser Ansatz immer mehr zurückgedrängt worden. Zum einen durch die - dank Weiterentwicklungen von Mikrochips und Speicherchips - immer preiswerter und leistungsfähiger werdenden Arbeitsplatzrechner und zum anderen durch die zunehmende Vernetzung über Übertragungsmedien wie Kabel und Funk. Rechnerverbundsysteme sind entstanden, in denen autonome Rechner mit einem Kommunikationssystem (Rechnernetz) verbunden waren. In einem nächsten Schritt wurde die Existenz mehrerer autonomer Rechner für den Benutzer transparent gemacht, d.h. der Benutzer führt ein Programm aus und weiß nicht, ob für dessen Abarbeitung nur lokale Ressourcen oder auch Ressourcen von anderen Rechnern verwendet werden. Dieser Ansatz entspricht dem heute weit verbreiteten Begriff der verteilten Systeme. Es gibt unterschiedliche Definitionen für verteilte Systeme, aus technischer Sicht ist die Definition von Tanenbaum [Tan03] anzuführen: Ein verteiltes System ist ein System, das auf einer Menge von Rechnern ausgeführt wird, die nicht über einen gemeinsamen Speicher verfügen, und das sich dem Benutzer wie ein einzelner Rechner darstellt. Die Softwareentwicklung musste sich dieser neuen Situation stellen und Anwendungen entwickeln, die über mehrere Rechner bzw. Prozessoren hinweg lauffähig waren. Durch die Verteilung von Daten und Algorithmen ergaben sich neue softwaretechnische Probleme, für deren Behebung neue Konzepte entwickelt werden mussten. Ein Hauptproblem hierbei war, dass eine laufende Anwendung jetzt auf Daten zugreifen musste, die sich auf entfernten Rechnern befanden. Dafür wurden die so genannten Remote Procedure Calls (RPCs) entwickelt. Der Distributed Computing Environment (DCE)-

11 Verteilte Anwendungen 11 Standard [Schill97] gehörte zu den ersten Standards, die auf RPC-Mechanismen basierten. Er wurde von der Open Software Foundation (OSF), der heutigen Open Group, verabschiedet. In diesem Standard ist u. a. die Übertragung von numerischen Daten geregelt. Er stellt im UNIX-Umfeld eine Schlüsseltechnologie dar. Seit der Etablierung der objektorientierten Programmiersprachen Mitte der 90er Jahre wurde DCE immer mehr verdrängt. Objektorientierte Programmierung und darauf aufbauend komponentenbasierte Programmierung sind immer mehr in den Vordergrund getreten und gehören heute zum Standard der Softwareentwicklung. Zur Umsetzung von verteilten Anwendungen stehen verschiedene verteilte Objektarchitekturen zur Verfügung. Zu den bekanntesten Modellen gehören Common Object Request Broker Architecture (CORBA) [OMG04], Distributed Component Object Model (DCOM) [HorKirt97] und Java Remote Method Invocation (Java RMI) [SunRMI]. Sie liefern die nötige Funktionalität, um entfernte Methodenaufrufe (RPC) auszuführen, wobei hier nun auf verteilte Objekte bzw. verteilte Komponenten zugegriffen wird. Als letzte und für diese Ausarbeitung wichtigste Ausprägung von verteilten Systemen sind noch die Service-orientierten Architekturen (SOA) zu erwähnen, die im Bereich der Softwareentwicklung einen immer bedeutenderen Platz einnehmen. 2.2 Service-orientierte Architekturen Service-orientierte Architekturen (SOA) [Col04] stellen kein neues Konzept dar: Schon im Jahre 1999 wollte Hewlett-Packard (HP) mit e-speak eine Plattform für das Web schaffen, deren Implementierung das Konzept der SOAs zugrunde lag. Aufgrund eines schlechten Marketings konnte sich e-speak nicht auf dem Markt etablieren [Gis01-1], der Gedanke einer Service-orientierten Architektur jedoch war geboren. Im Februar 2001 meldete sich HP mit einer verbesserten Softwarestrategie zurück, in der die Kommunikation zwischen verteilten Softwarekomponenten mit dem Transportprotokoll SOAP umgesetzt wurde. SOAP ist ein Basisstandard der Web Services-Technologie, die in diesem Kapitel noch ausführlich behandelt wird. Während HP mit SOAP ein Transportprotokoll einsetzte, das durch offenen und unabhängigen Standard hervorsticht, wurde die Schnittstelle weiterhin mit einer proprietären Beschreibungssprache umgesetzt. Erst die beiden Unternehmen IBM und Microsoft erkannten, wie das volle Potenzial der Service-orientierten Architekturen ausgeschöpft werden kann: Eine SOA muss mit komplett offenen und unabhängigen Standards implementiert werden. Wie in den nachfolgenden Kapiteln zu sehen sein wird, ist dieses Konzept im Gegensatz zu anderen verteilten Systemen erst seit der Einführung der Web Services zufrieden stellend umgesetzt. Hinsichtlich Service-orientierter Architekturen gibt es eine Menge von unterschiedlichen Definitionen, dieses Kapitel bezieht sich auf die Beschreibungen, die auf der Homepage von IBM zu finden sind. Sie gehören zu den aktuellsten und sind am ehesten dem aktuellen Trend der Web Services- Technologie angepasst. Service-orientierte Architekturen sind danach gekennzeichnet durch verteilte

12 12 Verteilte Anwendungen Komponenten, deren Daten und Funktionalität mittels Services (Dienste) zur Verfügung gestellt werden. Ein Service kapselt die interne Struktur und bietet nach außen eine klar definierte Schnittstelle, die die Funktionalität dieses Services beschreibt. Services werden zentral bereitgestellt und können über das Netzwerk angesprochen werden. Eine entscheidende Eigenschaft von Serviceorientierten Architekturen ist die lose Koppelung. Die Modellierung der Schnittstellen muss also so erfolgen, dass keine Festlegungen bzgl. konkreter Implementierung und eingesetztem Kommunikationsprotokoll getroffen werden. Konkret bedeutet dies, ein Service muss ein möglichst neutrales, plattform- und programmiersprachenunabhängiges Protokoll unterstützen. Dadurch vermindert sich die Abhängigkeit der einzelnen Services voneinander und auch zwischen den Services und den Anwendungen. Der entscheidende Vorteil hierbei ist, dass Services, die in eine Anwendung integriert sind, leichter ausgetauscht werden können (Wiederverwendbarkeit). Die lose Kopplung wird typischerweise durch eine synchrone nachrichtenbasierte Kommunikation realisiert, wobei die Kommunikation im einfachsten Fall aus einem einfachen Datenaustausch besteht, aber auch ein komplexes Gebilde von Interaktionen darstellen kann. In einer Service-orientierten Architektur werden drei Rollen identifiziert (Abbildung 1): der Service Provider, der Service Requestor sowie der Service Broker. Diese interagieren miteinander und führen dabei die Aktionen publizieren, suchen und binden aus. Service Broker suchen publizieren Service Requestor binden Service Provider Abbildung 1: Service-orientierte Architektur Service Provider Der Service Provider ist der Anbieter eines Dienstes. Er ist letztendlich verantwortlich für das Implementieren und das Hosting des Services. Er kann den Dienst durch verschiedene Möglichkeiten dem

13 Verteilte Anwendungen 13 Service Requestor anbieten. In den meisten Fällen werden die Service-Beschreibungen bei einem Service Broker publiziert, und dieser kümmert sich um deren Verwaltung. Service Requestor Der Service Requestor nimmt den Service in Anspruch (binden). Falls Schnittstelle und Adresse des Services nicht schon bekannt sind, muss er zunächst durch Abfrage beim Service Broker die für das Binden notwendigen Informationen in Erfahrung bringen. Anhand dieser Informationen weiß der Service Requestor, wie der Dienst zu nutzen ist. Danach kann er den Service durch das Versenden von Requests in Anspruch nehmen. Beim Service Requestor kann es sich sowohl um eine natürliche Person als auch um eine Softwarekomponente handeln. Service Broker Der Service Broker ist der Vermittler zwischen Service Provider und Service Requestor. Die Aufgabe des Brokers wird oft von einer zentralen Registry erfüllt. Hierbei handelt es sich um zentrale Verzeichnisse, in die Service Provider die benötigten Informationen über sich sowie die von ihnen zur Verfügung gestellten Dienste eintragen können. Daten über die Art und Weise des Aufrufs wie auch die Verwendung werden ebenso eingetragen. Durch die Möglichkeit der Klassifizierung der Dienste und der Suche innerhalb der Register kann der Nutzer die verschiedenen Dienste bewerten und miteinander vergleichen. Hat er einen geeigneten Dienst gefunden, kann er diesen dynamisch binden. Der Nutzen von Service-orientierten Architekturen ist direkt greifbar: Durch den Ansatz der Wiederverwendbarkeit lässt sich Software flexibler entwickeln. Gerade bei der zunehmenden Vernetzung der Computerwelt und dem damit steigenden Einsatz von verteilten Anwendungen stellt dies einen wesentlichen Vorteil dar. Neue Anwendungen können aus bereits existierenden Diensten zusammengesetzt werden. Es ist auch möglich, laufende Anwendungen durch den Austausch einzelner Services zu modifizieren, zu erweitern oder zu optimieren. Das Anpassungsrisiko aufgrund externer Einflüsse wird somit verringert, außerdem lassen sich Anwendungen viel schneller und kostengünstiger entwickeln. Service-orientierte Architekturen eignen sich auch ausgezeichnet für ein Bottom-Up-Vorgehen, bei dem Funktionalität und Anwendungen nach und nach in kleinen, übersichtlichen Projekten entwickelt werden. Dies senkt die Risiken eines Scheiterns von Projekten erheblich und zwar sowohl für Neuentwicklungen als auch für Neustrukturierungen der unternehmensinternen Informationstechnologie.

14 14 Verteilte Anwendungen 2.3 Verteilte Objektarchitekturen Durch die Einführung der objektorientierten Programmierung hat sich die Softwareentwicklung drastisch verändert. Die Objektorientierung ist zur Strukturierung von komplexen Software-Projekten sehr gut geeignet und bringt eine Menge von Vorteilen mit sich. Im Hinblick auf die Umsetzung von Service-orientierten Architekturen sind die wichtigsten Vorzüge folgende: die Trennung von Schnittstelle und Implementierung sowie die Wiederverwendbarkeit von Objekten. Um auf diese Objekte auch in verteilten Umgebungen zugreifen zu können, werden verteilte Objektarchitekturen benötigt. Die Grundidee hierbei ist, das RPC-Konzept für Objekte zu realisieren. Anwendungen bestehen dabei aus interoperablen Objektkomponenten, die auch über das Netzwerk verteilt sein können. Die Verteilungsaspekte sind für die Anwendung selbst aber nicht sichtbar. Das Ziel besteht also darin, Objekte miteinander interagieren zu lassen, und zwar über verschiedene Programmiersprachen hinweg, zwischen unterschiedlichen Betriebssystem- und Hardwareplattformen sowie über Rechnerknoten mithilfe verschiedener Netzwerkprotokolle. Auf den ersten Blick scheinen die Eigenschaften von verteilten Objektarchitekturen sehr gut geeignet zu sein, um Service-orientierte Architekturen umzusetzen. Eine Untersuchung der drei am weitesten verbreiteten Konzepte DCOM, Java RMI und CORBA wird jedoch zeigen, dass sich mit ihnen zwar Service-orientierte Architekturen implementieren lassen, sie alle aber auch gewisse Nachteile bei der Umsetzung derselben mit sich bringen. Da die verteilten Objektarchitekturen beim Zugriff auf verteilte Objekte das gleiche Grundprinzip verwenden, soll letzteres im folgenden Kapitel zunächst einmal gesondert beleuchtet werden Stub und Skeleton Der Zugriff auf verteilte Objekte erfolgt über den Aufruf von öffentlichen Methoden, die von den einzelnen Objekten zur Verfügung gestellt werden. Im Mittelpunkt stehen dabei die so genannten Stubs und Skeletons [Gis01-2]. Diese werden benötigt, um von der eigentlichen Datenübertragung und Nutzung eines entfernten Objektes (Serverobjekt) zu abstrahieren. Das verteilte Objekt selbst wird durch eine öffentliche Schnittstelle beschrieben, in der die zur Verfügung stehenden Methoden, die Eingabe- und Ausgabeparameter sowie der Rückgabewert spezifiziert sind. Auf Clientseite wird das Stub-Objekt anhand dieser Schnittstelle implementiert. Es fungiert als lokales Vertreter-Objekt, welches das Serverobjekt repräsentiert und den Aufruf der Methoden abwickelt. Bei einem Methodenaufruf nimmt das Stub-Objekt mit demjenigen Skeleton-Objekt Kontakt auf, welches die Verbindung zum Serverobjekt realisiert. In Abbildung 2 sind die einzelnen Schritte abgebildet, die beim Zugriff auf ein verteiltes Objekt durchlaufen werden:

15 Verteilte Anwendungen 15 Client Server 1 2 skeleton 5 stub 4 3 server object object bus Abbildung 2: Stub und Skeleton Im ersten Schritt ruft die Clientanwendung die Objektmethode des Stub-Objektes auf. Dieses kodiert den Aufruf bzw. die Aufrufparameter als Botschaft und schickt sie zum Server (2). Dieser Vorgang wird auch als Marshalling bezeichnet. Dabei werden die Aufrufparameter so umgewandelt (serialisiert), dass sie über das Netz verschickt werden können. Auf Serverseite ist nun das Skeleton- Objekt für die Dekodierung der Botschaft (Unmarshalling) zuständig. Nach erfolgreicher Dekodierung ruft dieses auch die entsprechende Methode des Serverobjektes auf (3). Im nächsten Schritt wird das Ergebnis des Methodenaufrufs an das Stub-Ojekt zurückgeschickt und dieses liefert letztendlich das Resultat an die Clientanwendung Common Object Request Broker Architecture (CORBA) Die Common Object Request Broker Architecture (CORBA) [OMG04] ist eine von der Object Management Group (OMG) definierte Basisarchitektur für die Entwicklung verteilter objektorientierter Anwendungen. Die OMG ist ein herstellerunabhängiges Konsortium, das inzwischen aus über 700 Mitgliedern (z.b. IBM, DEC, HP, Sun Microsystems) besteht. Die Zielsetzung des heute weltweit größten Softwarekonsortiums bestand von Anfang an darin, eine geeignete Infrastruktur bereitzustellen, um die problemlose Interaktion von Softwareobjekten selbst in heterogenen Umgebungen zu gewährleisten. Der Begriff heterogen beschränkt sich dabei nicht nur auf unterschiedliche Netztechnologien und Betriebssysteme, sondern umfasst ebenfalls die bunte Palette der verschiedenen Programmiersprachen. Ein derartiges Vorhaben kann nicht ungeplant und unkoordiniert erfolgen, aus diesem Grund hat das Konsortium die Referenzarchitektur Object Management Architecture (OMA) definiert. Zentraler Bestandteil dieser Referenzarchitektur ist der Object Request Broker (ORB). Er

16 16 Verteilte Anwendungen steuert die Kommunikation zwischen Client und Server und gehört zu den wichtigsten Komponenten der OMA. Demnach wurde dieser auch als erster spezifiziert und legte den Grundstein zur Namensgebung der Common Object Request Broker Architecture (CORBA). In Abbildung 3 ist die Struktur eines CORBA Object Request Brokers zu sehen: Client Object- Interface Repository implementation Implementation Repository Dynamic Invocation Client IDL Stub ORB Interface Static Skeleton Dynamic Skeleton Object Adapter Object Request Broker Core Abbildung 3: Bestandteile eines ORBs Damit der ORB mit Objekten umgehen kann, müssen diese in einer eindeutigen Sprache beschrieben sein. Zu diesem Zweck hat die OMG die Interface Definition Language (IDL) entwickelt. Sämtliche Objekte, die für den ORB benutzbar sein sollen, müssen mit Hilfe der IDL beschrieben werden. Ein CORBA-Objekt besteht dabei aus zwei Komponenten, zum einen aus der IDL-Schnittstelle und zum anderen aus der konkreten Implementierung. Der Client kann nur jene Methoden aufrufen, die in der IDL-Schnittstelle beschrieben werden. Sie bilden für ihn die einzige Möglichkeit, auf ein Objekt und seine Daten zuzugreifen. Durch die Trennung von Schnittstelle und Implementierung (Kapselung) bleibt dem Client die Programmiersprache, mit der das Objekt implementiert wurde, verborgen. Damit ist es möglich, eine Objektimplementierung gegen eine andere Implementierung des gleichen Objektes auszutauschen, ohne dass dadurch der Client bei der Benutzung dieser Objekte beeinträchtigt wird. Außerdem unterstützt CORBA dadurch die Wiederverwendbarkeit von Objekten: Bereits entwickelte Objekte können in neuen Applikationen eingesetzt werden. Der Einsatz von IDL bringt natürlich nicht nur die Sprachunabhängigkeit auf Serverseite, sondern auch auf Clientseite mit sich. Diese Sprachunabhängigkeit ermöglicht es einem Entwickler, jedes Objekt in der Sprache zu implementieren, die sich dafür am besten eignet. Selbst bestehende Applikationen können mit Hilfe von CORBA benutzt werden, indem man entsprechende Schnittstellen für die Applikation durch IDL beschreibt. Um die Kommunikation über den ORB zu ermöglichen, wird ein IDL-Compiler verwendet. Auf Clientseite wird mit ihm der IDL Stub generiert, der das Bindeglied zum ORB ist. Auf der Serverseite

17 Verteilte Anwendungen 17 wird die Verbindung vom ORB zur Objektimplementierung durch das generierte IDL Skeleton bereitgestellt. Da es bei der Kommunikation zwischen Client und Server zum Einsatz von unterschiedlichen ORBs kommen kann, hat die OMG mehrere ORB-to-ORB Protokolle spezifiziert. Das wichtigste unter ihnen ist das General Inter-ORB Protocol (GIOP). Es enthält sämtliche generellen Spezifikationen, die ein Inter-ORB Protokoll erfüllen muss und wurde so entwickelt, dass die Spezifikationen mit jedem zuverlässigen Netzwerkprotokoll implementiert werden können. Eine oft verwendete Implementierung ist dabei das Internet Inter-ORB Protocol (IIOP), das auf TCP/IP aufsetzt. Damit eine ORB-to-ORB-Kommunikation zustande kommen kann, muss der lokale ORB wissen, wie er ein Objekt lokalisieren kann. Hierfür wurden die Objektreferenzen eingeführt. Jedes Objekt in einer CORBA Umgebung hat seine eigene Objektreferenz. Diese wird vom ORB des jeweiligen Objektes erzeugt und bleibt für das Objekt bestehen, bis es explizit gelöscht wird. Ein Client benutzt nun diese Referenzen, um die Methoden des entsprechenden Objektes aufzurufen. Für das Generieren und Auffinden der Objekte ist der Object Adapter zuständig. Der Object Adapter sucht das Objekt im Implementation Repository. Hier sind alle Objektimplementationen registriert und alle Informationen darüber zu finden, wie und wo man die Objekte aufrufen kann. Die bereits geschilderte Realisierung der ORB-to-ORB-Kommunikation ist es letztlich, die die Interoperabilität von CORBA realisiert und somit noch flexibler macht. Die bisher erarbeiteten Vorteile von CORBA seien nochmals genannt: Sprachunabhängigkeit, Wiederverwendbarkeit und Interoperabilität. Da es eine Vielzahl von Plattformen gibt, auf denen ein CORBA-ORB implementiert und lauffähig ist, ist auch die Plattformunabhängigkeit noch hinzuzuzählen. Als weiterer Vorteil lässt sich die Herstellerunabhängigkeit nennen, sodass CORBA hinsichtlich seiner Voraussetzungen als ideal für die Umsetzung von Serviceorientierten Architekturen erscheint. Doch auch bei dieser Architektur lassen sich einige Kritikpunkte anmerken. An erster Stelle hierbei steht die immense Komplexität, die CORBA mit sich bringt. Die Spezifikation umfasst mehr als 1100 Seiten, auf denen alles sehr genau beschrieben ist. Sie ist aber auch sehr schwer zu erlernen und schreckt Neulinge eher ab. Auch Unternehmen müssen sich genau überlegen, ob sie ein Projekt mit CORBA umsetzen wollen, da damit ein hoher Aufwand und große Kosten verbunden sind. Ein weiterer Nachteil besteht darin, dass sich nicht alle Hersteller bei ihren Implementierung strikt an die Spezifikation halten. Gerade bei der Kommunikation zwischen gewachsenen CORBA Strukturen kommt es oft zu Schwierigkeiten, wenn die ORB Implementierungen verschiedener Hersteller untereinander nicht kompatibel sind. Weiterhin müssen die Kosten berücksichtigt werden, die entstehen, wenn die ORB-Implementierung nicht selbst vorgenommen werden soll. Der Kauf einer fertigen ORB-Implementierung eines anderen Herstellers ist in der Regel mit hohen Lizenzgebühren verbunden. Als ein letztes Problem seien noch die Kommunikationsprotokolle erwähnt. Wenn z.b. für den Aufruf eines verteilten Objektes das Internet Inter-ORB Protocol (IIOP) verwendet wird, kann es

18 18 Verteilte Anwendungen zu Problemen kommen, falls auf der Serverseite eine TCP/IP-Firewall installiert ist. Die verteilte Kommunikation über Netzwerkgrenzen hinweg wird somit erschwert. Diesen Nachteil bringen auch die nachfolgend beschriebenen Modelle DCOM und Java RMI mit sich Distributed Component Object Model (DCOM) DCOM (Distributed COM) [HorKirt97] wurde von Microsoft entwickelt und erweitert dessen Komponenten-Objekt-Modell COM. Während COM einen Protokoll-Standard definiert, der die Kommunikation von Objekten innerhalb eines Prozesses oder zwischen verschiedenen Prozessen auf dem gleichen Rechnerknoten beschreibt, ermöglicht DCOM die Kommunikation dieser Objekte über verschiedene Rechner hinweg. DCOM wurde im September 1996 erstmals in Windows-NT integriert und ist seitdem fester Bestandteil aller Windows-Plattformen. Mit der Einführung von Windows 2000 wurde die erste Weiterentwicklung von DCOM eingeführt: COM+. COM+ soll den Umgang mit den komplizierten COM-Komponenten erleichtern und bietet zusätzliche Dienste an. In der aktuell von Microsoft auf dem Markt befindlichen.net-plattform ist COM+ in der Version 2.0 integriert, wobei dieses Komponentenmodell einem völlig neuen Ansatz zu Grunde liegt und mit dem älteren COM+ kaum etwas gemeinsam hat. Die wichtigsten Komponenten einer DCOM-Architektur sind in Abbildung 4 zu sehen: Client COM Runtime COM Runtime Component Security Provider DCE RPC Security Provider DCE RPC Protocol Stack Protocol Stack DCOM networkprotocol Abbildung 4: DCOM-Architektur

19 Verteilte Anwendungen 19 Die Kommunikation zwischen den verteilten Objekten wird von der COM-Laufzeitumgebung übernommen, diese ist fest in die Windows-Plattform integriert. Die Schnittstellenbeschreibung erfolgt dabei mit der Microsoft Interface Definition Language (MIDL). Sie ermöglicht, wie IDL bei CORBA, auf Client- und auf Serverseite den Einsatz einer beliebigen Programmiersprache. Aus einer MIDL- Schnittstelle werden die nötigen Stubs und Skeletons automatisch generiert. Der Zugriff auf die verteilten Objekte erfolgt dann über eine objektorientierte Erweiterung des DCE-RPC-Mechanismus (ORPC), wobei sich die dafür nötigen Adressangaben in COM-Komponenten befinden, welche von der Windows-Registry verwaltet werden. Schon nach dieser kurzen Beschreibung von DCOM wird im Hinblick auf die Umsetzung von Service-orientierten Architekturen ein großer Nachteil offensichtlich. DCOM ist stark an die Windows-Plattformen gebunden und bietet somit keine Plattform- und Herstellerunabhängigkeit. Wenn eine verteilte Anwendung in einem Windows-Netzwerk implementiert werden soll, gehört DCOM aufgrund der Standardintegration in den einzelnen Windows-Plattformen sicherlich zur ersten Wahl. Sollen jedoch auch andere Betriebssysteme unterstützt werden, ist dies nur teilweise oder überhaupt nicht möglich. Es gibt zwar Portierungen von DCOM und COM+ auf andere Plattformen, wie z.b. Unix oder Linux, diese sind aber aufgrund der hohen Integration in die Windows-Plattformen nur mit eingeschränktem Funktionsumfang möglich Java Remote Method Invocation (Java RMI) Java Remote Method Invocation (Java RMI) [SunRMI] wurde von Sun Microsystems entwickelt und hat sehr viele Ähnlichkeiten mit CORBA. Ein entscheidender Unterschied aber besteht in der Festlegung auf die Programmiersprache Java. Während bei CORBA und auch bei DCOM eine separate Schnittstellen-Beschreibungssprache erlernt und eingesetzt werden muss, basiert hier alles auf Java. Mit Java RMI lassen sich somit verteilte Java-basierte Anwendungen entwickeln. Da hier auf Client- und auf Serverseite die gleiche Programmiersprache eingesetzt wird, fällt das Mapping zwischen den einzelnen Datentypen verschiedener Programmiersprachen weg. Grundvoraussetzung für die Kommunikation über Rechnergrenzen hinweg ist die Java Virtual Machine (JVM). Sie ist vergleichbar mit dem Object Request Broker (ORB) von CORBA und ermöglicht den Methodenaufruf auf verteilte Java-Objekte. Die Java Virtual Machine ist auf sehr vielen Plattformen erhältlich. Die zur Entwicklung benötigte RMI-Klassenbibliothek gehört zum Umfang aller Java Distributionen, von der Java 2 Micro Edition bis hin zur Java 2 Enterprise Edition. Auch die Distributionen sind für viele Plattformen erhältlich, sodass diese Technologie als plattformunabhängig eingestuft werden kann. Für die Datenübertragung der verteilten Java-Objekte wird der Mechanismus der Objektserialisierung verwendet. Die Java-Objekte werden in einen (binären) seriellen Datenstrom umgewandelt und über das Netz verschickt, auf der Empfängerseite wird dieser wiederhergestellt. Als Transportprotokoll kommt dabei das Java Remote Method Protocol (JRMP) zum Einsatz. Das Auffinden von verteilten

20 20 Verteilte Anwendungen Java-Objekten erfolgt über die RMI-Registry, hierbei handelt es sich um einen einfachen Nameserver, der Referenzen auf die einzelnen Objekte verwaltet. Java RMI bringt prinzipiell die gleichen Vorteile mit sich wie CORBA. Der entscheidende Unterschied und ein in unserem Zusammenhang gravierender Nachteil ist die Sprachabhängigkeit. Das in dieser Diplomarbeit angestrebte Ziel, ein Softwareverteilungssystem in einer stark heterogenen Systemumgebung zu realisieren, schließt auch ein, dass Clients auftreten können, für die es keine lauffähige Java Virtual Machine gibt und die somit von Java RMI nicht unterstützt werden können. 2.4 Web Services Während CORBA, Java RMI und auch DCOM grundsätzlich dafür geeignet sind, Service-orientierte Architekturen zu implementieren, sind bei allen auch bestimmte Mängel festzustellen. Jede dieser verteilten Objektarchitekturen hat Restriktionen in Bezug auf die unterstützten Betriebssysteme, Programmiersprachen sowie Übertragungsprotokolle und kann somit keine vollkommene Unabhängigkeit garantieren. Hier kommt nun die neue Web Services-Technologie [Chris01, Gis01, Quan03, CurDuf02] ins Spiel, mit ihr lässt sich die Idee der Service-orientierten Architekturen am besten umsetzen. Technisch gesehen bieten Web Services zunächst einmal nichts fundamental Neues, größtenteils kommen bekannte und etablierte Konzepte zum Einsatz, die auch bei den verteilten Objektarchitekturen verwendet werden. Auch hier werden Remote Procedure Calls mit automatischer Code-Generierung für Stubs und Skeletons eingesetzt. Ihr entscheidender und gleichzeitig trivialer Unterschied zu den verteilten Objektarchitekturen ist die Einfachheit. Web Services basieren auf weithin akzeptieren und offenen Standards und ermöglichen damit ein Höchstmaß an Interoperabilität. Absolut im Mittelpunkt steht dabei der Einsatz der Extensible Markup Language (XML) [Yer04] als Basisformat. XML wird zum einen als Datenformat zur Kommunikation eingesetzt und zum anderen dient es als Basis für alle im Bereich Web Services entwickelten Standards. Bei der Nachrichtenübertragung ergibt sich dadurch der wesentliche Vorteil, dass die Nachrichten sehr einfach durch zusätzliche Komponenten oder Werkzeuge weiterverarbeitet werden können, da XML generisch und flexibel ist und nicht von speziellen Programmiersprachen abhängt. Bei den verteilten Objektarchitekturen werden die Daten dagegen im Binärformat verschickt, das sich nur schwer weiterverarbeiten lässt. Ein weiterer großer Vorteil von XML besteht in seiner Herstellerunabhängigkeit, XML ist ein offener und kostenloser Standard, der vom Standardisierungsgremium World Wide Web Consortium (W3C) gepflegt wird. Dank XML erhält die Web Services-Technologie auch ihre umfassende Unabhängigkeit von konkreten Programmiersprachen. Voraussetzung ist nur ein Mapping zwischen der Programmiersprache und XML, das zumeist direkt von den Entwicklungsumgebungen der einzelnen Programmiersprachen zur Verfügung gestellt wird. Die Programmiersprachenunab-

21 Verteilte Anwendungen 21 hängigkeit ist auch gleichzeitig ein erster Beitrag zur Realisierung der losen Kopplung zwischen den einzelnen Komponenten. Mit XML wird die Schnittstelle beschrieben und dabei von der konkreten Implementierung abstrahiert. Auch die Kommunikationsanbindung muss die lose Kopplung unterstützen. Hier bedient man sich einer recht einfachen Lösung und verwendet das täglich von Millionen Menschen genutzte World Wide Web als Transportmedium. Auch wenn Web Services theoretisch mit beliebigen Transportprotokollen umgesetzt werden können, wird in der Praxis fast ausschließlich das Hypertext Transfer Protocol (HTTP) [Fiel99] eingesetzt. HTTP wird heutzutage fast von allen Rechnern unterstützt und erfordert somit keine Installation spezieller Datenverbindungen, wie das z.b. bei CORBA mit IIOP der Fall ist. Probleme mit Firewalls sind dadurch auch behoben, denn der HTTP-Port ist in der Regel geöffnet und somit die Kommunikation nicht behindert. Obwohl immer wieder die Flexibilität von Web Services hinsichtlich der zu verwendenden Protokolle und Techniken betont wird, haben sich vier Basisstandards herauskristallisiert: Datentypen: XML-Schemata Nachrichtenformat: SOAP Web Service Description Language (WSDL) Universal Description, Discovery and Integration (UDDI). Darüber hinaus gibt es noch eine Menge von weiteren Standards, die diese grundlegenden Web Services-Standards erweitern. Für die vorliegende Arbeit sind dabei die Standards rund um das Thema Sicherheit von Interesse. Alle genannten Standards sollen im Folgenden kurz vorgestellt werden. Datentypen: XML-Schemata Um die Struktur eines XML-Domkumentes zu definieren, stehen zwei Techniken zur Verfügung: Document Type Definition (DTD) und XML-Schema [Fall01, Thom01, BirMal01]. XML-Schema stellt den neueren Ansatz dar und hat eine Reihe von Vorteilen. Es nutzt selbst XML-Syntax und lässt sich somit mit denselben Werkzeugen verarbeiten wie XML-Dokumente. Außerdem können mit XML- Schemata neben einfachen auch komplexe Datentypen beschrieben werden. Gerade bei modernen Programmiersprachen werden solche häufig eingesetzt. Ein weiterer Vorteil ist die Unterstützung der Modularisierung, die für die Realisierung von großen und verteilten Projekten von Interesse ist. Sie wird über das Konzept der so genannten Namespaces realisiert. Im Kontext von Web Services werden XML-Schemas hauptsächlich für zwei Bereiche eingesetzt. Zum einen für die Beschreibung der einzelnen Standards wie SOAP und WSDL und zum anderen für die Definition der Ein- und Ausgabeparameter der angebotenen Web Service Methoden.

22 22 Verteilte Anwendungen Nachrichtenformat: SOAP SOAP [Gud03] spezifiziert das Nachrichtenformat in der Web Services-Technologie. Es ermöglicht den Informationsaustausch mit entfernten Services und basiert dabei auf XML als Datenaustauschformat. Eine SOAP-Nachricht ist dabei ein XML-Dokument, das aus drei Teilen besteht: dem SOAP- Envelope, dem SOAP-Header und dem SOAP-Body. Während der SOAP-Header optional ist, müssen die beiden Elemente Envelope und Body in jeder SOAP-Nachricht vorhanden sein. Im SOAP-Body ist der eigentliche Inhalt der Nachrichten kodiert. Der SOAP-Header enthält dagegen zusätzliche Informationen, die von weiterführenden Standards genutzt werden können, um zusätzliche Funktionalität in den SOAP-basierten Nachrichtenaustausch zu integrieren. Zur Datenübertragung selbst ist SOAP an kein festes Transportprotokoll gebunden, theoretisch kann ein beliebiges Transportprotokoll eingesetzt werden. In der Praxis setzt sich aber vor allem HTTP durch. In einem Schichtenmodell ist SOAP direkt über der Kommunikationsschicht anzusiedeln. Wenn in einer Anwendung eine Web Service- Methode aufgerufen wird, dann werden die Daten zunächst aus dem Programmiersprachenformat in das SOAP-Format überführt und dann mit dem eingesetzten Transportprotokoll verschickt. Auf Empfängerseite wird das SOAP-Format wieder in das dort verwendete Programmiersprachenformat überführt. Diese Schritte werden von den Stubs und Skeletons realisiert, die auf Client- und Serverseite mit entsprechenden Werkzeugen automatisch generiert werden. Schnittstellenbeschreibung: WSDL WSDL [Chris01] steht für Web Services Description Language und dient der Beschreibung der Schnittstellen von Web Services. Wie bei SOAP werden diese auch hier im XML-Format formuliert. Eine WSDL-Datei besteht dabei aus mehreren Tags, mit denen die zentralen Elemente eines Web Service beschrieben werden. Zu ihnen gehören Informationen über die angebotenen Dienste (Methoden) und deren Eingabe- und Ausgabeparameter, Informationen über das jeweils verwendete Transportprotokoll und Angaben darüber, wo der Service zu finden ist. Für die Beschreibung der Datentypen der einzelnen Parameter scheint sich immer mehr der schon eingeführte Standard XML- Schema zu etablieren, auch wenn WSDL diesbezüglich offen ist und auch die Verwendung beliebiger anderer Beschreibungssprachen für die Datentypen erlaubt. Genauso offen ist WSDL bei der Angabe des Transportprotokolls, es muss nicht zwingend SOAP sein, auch wenn es bis dato das meistgenutzte ist. Zurzeit werden zwei verschiedene Ansätze unterschieden, um eine WSDL-Datei zu erstellen [LiMa04]. Zum einen der Top-Down-Ansatz, bei dem zuerst die WSDL-Datei geschrieben wird, daraus automatisch der Stub- und Skeleton-Code generiert und anschließend deren Funktionalität implementiert wird. Zum anderen der Bottom-Up-Ansatz, bei dem der Web Service zuerst in einer konkreten Programmiersprache implementiert wird, und daraus durch den Einsatz eines Werkzeugs

23 Verteilte Anwendungen 23 aus der Entwicklungsumgebung die Stubs, Skeletons und die WSDL-Datei generiert werden. Der Bottom-Up-Ansatz wird häufig in Unternehmen eingesetzt, in dem unterschiedliche, veraltete und inkompatible Anwendungen laufen, die miteinander verbunden werden sollen. Ein Web Service wird dieser Infrastruktur aufgesetzt und ermöglicht die Kommunikation zwischen den einzelnen Anwendungen. Da der Entwickler des Web Service und der Clientsoftware die darauf zugreift in der Regel derselbe ist, kann dieser überall die gleichen Werkzeuge einsetzen bzw. diese aufeinander abstimmen, um die WSDL-Datei und die jeweiligen Stubs zu generieren. Dadurch entgeht der Entwickler möglichen Kompatibilitätsproblemen und kann den Web Service bequem und schnell in seiner favorisierten Programmiersprache implementieren. Anders sieht es dagegen aus, wenn der Web Service von Service Requestoren genutzt werden soll, deren Clientsoftware von anderen Entwicklern implementiert wird und in einer anderen Umgebung abläuft. Der Bottom-Up-Ansatz kann hier nicht verwendet werden. Wenn der Entwickler zuerst den Code implementiert und dann mit einem Werkzeug die WSDL-Datei automatisch generieren lässt, und der Entwickler der Clientsoftware für die Generierung der Stubs ein anderes Werkzeug einsetzt, kann es unter Umständen sein, dass dieses Werkzeug die WSDL-Datei nicht richtig interpretieren kann. Der Grund dafür sind die noch teilweise unausgereiften Werkzeuge, die in manchen Fällen plattformspezifische oder zweideutige Angaben in den WSDL-Dateien generieren, was dem Grundgedanken der Web Service- Technologie völlig widerspricht. Um diesen Kompatibilitätsproblemen zu entgehen wird in solchen Fällen der Top-Down-Ansatz vorgezogen. Die WSDL-Datei wird von Hand und gemäß der WSDL- Spezifikation geschrieben, sodass jedes Werkzeug daraus die Stubs generieren kann. Registrierung und Suche: UDDI Der Universal Description, Discovery and Integration Dienst (UDDI) [Bell02] ist ein Verzeichnisdienst, der Web Services und ihre Schnittstellen registriert und damit das dynamische Finden und Aufrufen von Web Services ermöglicht. Bei einer solchen Registrierung können detaillierte Informationen über den Service angegeben werden. Obwohl UDDI von Beginn an als Bestandteil von Web-Services-Technologie angesehen wurde, hat dieser Standard bis heute nicht die gleiche Akzeptanz und Relevanz erreichen können wie SOAP und WSDL. Die Gründe hierfür sind mannigfaltig; es wird an dieser Stelle auf die Literatur verwiesen: [Quan03]. Anhand von Abbildung 5 sollen an dieser Stelle die eben beschriebenen Standards veranschaulicht und logisch zusammengeführt werden. Dabei wird auch Bezug auf die Service-orientierten Architekturen genommen und gezeigt, wie deren Umsetzung hiermit erfolgt. Zwei Phasen sind dabei zu unterscheiden, zunächst die Entwicklungsphase und anschließend die Nutzungsphase. Bezüglich der Entwicklungsphase wird gezeigt, wie und wo Software implementiert werden muss, damit ein

24 24 Verteilte Anwendungen Web Service angeboten und genutzt werden kann. Bezüglich der Nutzungsphase wird ausgeführt, wie ein angebotener Web Service in Anspruch genommen werden kann. Service Requestor Service Provider Client-Programm Stub Skeleton Server-Programm Programmcode Methode X Input XML SOAP generieren SOAP Request Methode X SOAP verarbeiten Methode X (Input, Output) Methode X (Input, Output) SOAP verarbeiten Output XML SOAP Reply SOAP generieren Implementierung der Funktionalität Code Generierung WSDL-Beschreibung Service Broker Abbildung 5: Web Service - Szenario 1. Entwicklungsphase: Um einen Web Service anbieten zu können, muss dieser zunächst einmal implementiert werden. Im Kontext der Service-orientierten Architekturen ist dafür der Service Provider zuständig. Die Implementierung kann dieser dabei mit einer beliebigen Programmiersprache umsetzen. Um seinen Web Service für andere zugänglich zu machen, werden die WSDL-Datei und die Skeletons benötigt. In den meisten Fällen bietet die Entwicklungsumgebung dafür ein Werkzeug an, das diese automatisch generiert. Die WSDL-Datei beschreibt dabei den kompletten Dienst, den dieser Web Service zur Verfügung stellt. Die Datei selbst ist nicht an den Speicherort der implementierten Objekte gebunden und kann an einer beliebigen Stelle publiziert werden. Ein Service Broker wäre dafür ein geeigneter Anlaufpunkt, dieser könnte z.b. durch den Einsatz einer UDDI- Registry die Verwaltung und Veröffentlichung des Web Service durchführen. Bleibt der Service Requestor: Auch er braucht zunächst einmal eine passende Software, um auf den Web Service zugreifen zu können. Dieser sucht zunächst beim Service Broker nach der entsprechenden WSDL- Datei. Mit dieser Datei kann er die Stubs generieren lassen, die zur Kommunikation mit den Skeletons auf der Seite des Service Providers nötig sind. Auch dieser Schritt erfolgt automatisch durch den Einsatz eines Werkzeugs der eingesetzten Programmiersprache, wobei diese natürlich

25 Verteilte Anwendungen 25 nicht mit der auf Service Provider Seite identisch sein muss. Die Entwicklungsphase ist damit abgeschlossen, der Service Requestor kann den Dienst nun nutzen. 2. Nutzungsphase: Wenn der Service Requestor aus seinem laufenden Programm eine Methode des Web Service in Anspruch nehmen will, muss der Methodenaufruf zunächst an das zuständige Stub-Objekt übergeben werden. Das Stub-Objekt überführt die erhaltenen Daten aus ihrem Programmiersprachenformat in das XML-Format. Die Struktur der XML-Daten muss dabei mit demjenigen XML-Schema in der WSDL-Datei valide sein, das die einzelnen Datentypen definiert. Anschließend wird mit den Daten eine SOAP-Nachricht generiert. Diese ermöglicht es, die Methode aufzurufen und das Ergebnis an das Programm zurückzuliefern. Im ersten Schritt führt das Stub- Objekt einen SOAP-Request beim zuständigen Skeleton-Objekt auf der Seite des Service Providers durch. Das Skeleton-Objekt verarbeitet die SOAP-Nachricht und veranlasst den Methodenaufruf beim entsprechenden Objekt, in dem die Funktionalität der Methode implementiert ist. Im zweiten Schritt wird das Ergebnis wiederum in eine SOAP-Nachricht gepackt und über ein SOAP-Reply an das Stub-Objekt zurückgegeben. Dieses verarbeitet die SOAP-Nachricht und gibt das Ergebnis an das Programm zurück. Nach der Erläuterung der Basisstandards und der Erklärung der Entwicklungs- und Nutzungsphase eines Web Service, wird im Folgenden noch kurz auf den Aspekt der Sicherheit eingegangen. Bei einem Softwareverteilungsdienst ist die Sicherheit in zweifacher Hinsicht interessant. Der Softwarelieferant kann teure Software gelagert haben, die er natürlich nur dem Softwareempfänger ausliefern darf, der dafür autorisiert ist und ggf. dafür bezahlt hat. Der Softwareempfänger auf der anderen Seite möchte natürlich sicher gehen, dass der Softwarelieferant auch wirklich der ist, für den er sich ausgibt, da er ihm für die Realisierung einer automatischen Softwareverteilung vertrauliche Daten preisgeben muss. Neben der Gefahr der Datenspionage eines Dritten, könnte dieser auch anstatt der gewünschten Software einen Virus schicken und den kompletten Rechner unbrauchbar machen. Es gibt eine Menge von Standards, die die Sicherheit einer Web Service-Umgebung erhöhen können. Eine kurze Übersicht darüber soll der folgende Abschnitt liefern. Sicherheit Die Realisierung des Sicherheitsaspektes in einer Web Services-Umgebung ist ein entscheidender Faktor für die zukünftige Bedeutung dieser Technologie. Von Anfang an hatte sie mit dem Problem zu kämpfen, dass sie als nicht sicher eingestuft wurde. Zweifel an der Sicherheit gehört zu den Hauptgründen, warum Unternehmen mit der Einführung von Web Services zögern. Eine Studie von