D i p l o m a r b e i t

Transkript

1 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Theoretische und Technische Informatik Fachgebiet Rechnerarchitektur D i p l o m a r b e i t zur Erlangung des akademischen Grades Diplominformatiker vorgelegt der Fakultät für Informatik und Automatisierung der Technischen Universität Ilmenau "Konzeption und Realisierung einer Nutzerschnittstelle unter Einbeziehung von Web-Services für die Verwaltung von Nutzerkonten" Bearbeiter: Verantwortlicher Hochschullehrer: Wissenschaftlicher Betreuer: Dirk Behrendt Prof. Dr.-Ing. habil. W. Fengler Dr. Ing. J. Nützel Datum der Ausgabe des Themas: Datum der Abgabe des Themas: Inventarisierungsnummer: I

2 Danksagung An dieser Stelle möchte ich mich bei allen bedanken, die zum Gelingen dieser Arbeit beigetragen haben. Mein besonderer Dank geht an meinen Betreuer Herrn Dr. Ing. Jürgen Nützel, welcher mir die Möglichkeit gab, diese Diplomarbeit anzufertigen und stets beratend zur Seite stand. Ebenso danke ich den verantwortlichen Hochschullehrer Prof. Dr.-Ing. habil. W. Fengler. meine Eltern, die mir mein Studium finanziert und immer die notwendige Unterstützung gegeben haben. meine Freundin Susann, die mir all die Jahre die Kraft gegeben hat, die universitären Anforderungen zu meistern. Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig und nur unter Verwendung der angegebenen Hilfsmittel geschrieben zu haben. Ilmenau, Dirk Behrendt II

3 Thesen (1) Mit Web-Services wurde eine Technologie geschaffen, mit welcher eine plattformunabhängige Interaktion zwischen Systemen durch die Verwendung offener Standards wie HTTP, XML, SOAP, WSDL und UDDI realisierbar ist. (2) Mit WS-Security werden sicherheitsrelevante Funktionalitäten bereitgestellt, welche bislang in der Web-Service Welt vermisst wurden. Somit ist es möglich, Daten auch über mehrere Zwischenstationen verschlüsselt zu übertragen bzw. eine partielle Verschlüsselung für einzelne Empfänger vornehmen zu können. (3) Die gegenwärtig verfügbaren Web-Service Toolkits und Entwicklungsumgebungen bieten den Entwicklern umfangreiche Unterstützung bei der Erstellung und der Nutzung von Web- Services. Für kleinere und mittlere Projekte ist die Verwendung von kostenfreien Toolkits wie Apache Axis völlig ausreichend. (4) Mit dem.net Framework entwickelte Anwendungen sind plattformübergreifend ausführbar. Dazu muss auf dem Zielrechner die.net Laufzeitumgebung installiert sein. (5) Software-Entwickler können in ihrer bevorzugten Programmiersprache Funktionalitäten eines Web-Service nutzen, denn es existieren gegenwärtig für die gängigen Programmiersprachen SOAP-Implementierungen, die für eine Web-Service Nutzung notwendig sind. (6) Viele Menschen empfinden es nicht als Unrecht Kopien von Musik, Software oder Filmen anzufertigen und weiter zu verbreiten. Die Software- und Unterhaltungsindustrie versucht diesen Trend mittels Kopierschutz und Kontrollmechanismen entgegen zuwirken, wodurch jedoch die Verwendung der Produkte stark eingeschränkt wird. Der daraus resultierende Interessenkonflikt zwischen der Software- und Unterhaltungsindustrie und deren Kunden wird durch das Potato-System aufgehoben. III

4 (7) Die konsequente Anwendung des Model-View-Controller Konzeptes (MVC) bei der Softwareentwicklung erhöht die Wartbarkeit und Erweiterbarkeit einer Anwendung. (8) Das MVC-Framework Struts genießt eine hohe Akzeptanz bei den Softwareentwicklern und unterliegt einer ständigen Weiterentwicklung und Verbesserung. Mit dessen Hilfe lassen sich MVC 2-basierte Web-Applikationen entwickeln. (9) Die Nutzung von Testwerkzeugen garantiert die Korrektheit der Implementierung und die Konformität gegenüber den Nutzer-Anforderungen. Ilmenau, Dirk Behrendt IV

5 Inhaltsverzeichnis Abbildungsverzeichnis...VII Tabellenverzeichnis...VII Listingverzeichnis...VIII 1 Einleitung Grundlagen von Web-Services Begriffsklärung Der Stack der Web-Service-Techniken Basistechnologien HTTP (HyperText Transfer Protocol) XML (Extensible Markup Language) SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language) UDDI (Universal Description, Discovery and Integration) Sicherheit und Transaktionalität Sicherheit bei Web-Services mit WS-Security Transaktionalität von Web-Services Anwendungsszenarien Ein Blick in die Zukunft Entwicklungsmöglichkeiten von Web-Services Entwicklung mit Apache Axis Architektur Entwicklung von Web-Services mit Apache Axis Web Service Toolkit (WSTK) von IBM Java Web Services Developer Pack (JWSDP) von Sun Vergleich von WSTK und JWSDP Das.NET Framework Architektur Unterstützte Sprachen ADO.NET (ActiveX Data Objects) Erstellung von Web-Services mit dem.net Framework Sun ONE (Sun Open Net Environment) Zusammenfassung Zugriffsmöglichkeiten auf Web-Services Der Google Web-Service Bereitgestellte Funktionalitäten Clientseitiger Zugriff auf den Google Web-Service C#.NET VB.NET (Visual Basic) Java Serverseitiger Zugriff auf den Google Web-Service JSP (JavaServer Pages) ASP.NET (Active Server Page) PHP (Hypertext Preprocessor) Generierte SOAP-Nachrichten Bewertung des Aufwands und Ausblick SOAP-Implementierungen für Sprachen V

6 5 Das Potato-System Ideen und Konzepte Waren- und Geldkreislauf Architektur Konzeption Zielsetzung und Analyse Das Model-View-Controller-Muster Das klassische MVC-Muster Das MVC 1-Muster Das MVC 2-Muster MVC-Frameworks Ereignisgesteuerte Frameworks Aktionsgesteuerte Frameworks Zusammenfassende Bewertung Das MVC-Framework Struts Die Konfigurationsdateien Der Struts-Controller Internationalisierung Die Struts Tag-Libraries Layout mit Struts-Tiles Der Struts-Validator Alternative Techniken in der View Umgesetzte Funktionalitäten des Jackets Vorgehen beim Erstellen von benutzerdefinierten Actions Verwendung des Validator-Frameworks Verarbeitung eines eingehenden Requests Testwerkzeuge StrutsTestCase Zusammenfassung Implementierung Login in das Potato-System Quellcode der Login Action-Klasse Web-Service Aufruf Layout mit Struts-Tiles Testen mit dem StrutsTestCase-Framework Zusammenfassung Zusammenfassung und Ausblick Anhang Vergleich von JWSDP und WSTK Programmiersprachen für das.net Framework Format der Suchanfragen an den Google Web-Service Format des Suchergebnisses des Google Web-Services Die WSDL-Datei des Google Web-Services Schema für die Erzeugung von Java-Klassen aus WSDL SOAP-Implementierungen für Sprachen Funktionalitäten des Potato-Systems (Web-Service) Screenshot der Login-Seite Testszenarien für die Struts-Applikation (Jacket) Abkürzungen Quellenverzeichnis VI

7 Abbildungsverzeichnis Abbildung 2.1: Service Orientierte Architektur (SOA) [W3Ca02]... 5 Abbildung 2.2: Der Web-Service-Stack [Web02]... 6 Abbildung 2.3: Die SOAP-Nachrichtenstruktur [Sne02] Abbildung 2.4: Komplexer Web-Service Reiseorganisation [Sta02] Abbildung 3.1: Axis im Web-Container [Bay03] Abbildung 3.2: Die Komponenten von JAX-RPC [Wan03] Abbildung 3.3: Bestandteile des JWSDP [Hol02] Abbildung 3.4: Die Architektur des.net Frameworks [NET2] Abbildung 3.5: Die Sun ONE Plattform [SunONE] Abbildung 4.1: C#.NET Zugriff auf den Google Web-Service Abbildung 4.2: JSP-Zugriff auf den Google Web-Service (1) Abbildung 4.3: JSP-Zugriff auf den Google Web-Service (2) Abbildung 5.1: Ablaufende Prozesse beim Dateikauf [NueB03] Abbildung 5.2: Zugrunde liegendes Preismodell [Potato] Abbildung 5.3: Die Architektur des Potato-Systems in Anlehnung an [Fri03] Abbildung 6.1: Das Wasserfallmodell [Balz00] Abbildung 6.2: Das klassische MVC-Muster [Gam96] Abbildung 6.3: Das MVC 1-Muster in Anlehnung an [Cav02] Abbildung 6.4: Das MVC 2-Muster in Anlehnung an [Cav02] Abbildung 6.5: Die wichtigsten Klassen des Action-Packages in Anlehnung an [Garn] Abbildung 6.6: Die Aufgaben der Konfigurationsdatei struts-config.xml Abbildung 6.7: Layout mit dem Tiles-Framework [HaiA03] Abbildung 6.8: Sequenzdiagramm für die Verarbeitung eines eingehenden Requests in Anlehnung an [Garn] Abbildung 6.9: Das StrutsTestCase Framework Abbildung 9.1: Screenshot der Login-Seite Tabellenverzeichnis Tabelle 6.1: Einordnung der Struts Action-Klassen Tabelle 9.1: Vergleich von JWSDP und WSTK (Featurematrix) [Hais02] Tabelle 9.2: Vergleich von JWSDP und WSTK (Entwicklungsprozess) [Hais02] Tabelle 9.3: Programmiersprachen für das.net Framework (1) [NET3] Tabelle 9.4: Programmiersprachen für das.net Framework (2) [NET3] Tabelle 9.5: Format der Suchanfragen an den Google Web-Service [Google] Tabelle 9.6: Format des Suchergebnisses des Google Web-Service [Google] Tabelle 9.7: Schema für die Erzeugung von Java-Klassen aus WSDL [Axis] Tabelle 9.8: SOAP-Implementierungen für Sprachen (1) [Xmethods] Tabelle 9.9: SOAP-Implementierungen für Sprachen (2) [Xmethods] Tabelle 9.10: Funktionalitäten des Potato-Systems (Web-Service) [Fri03] VII

8 Listingverzeichnis Listing 2.1: Kunden XML-Dokument... 7 Listing 2.2: DTD zum Kunden XML-Dokument... 8 Listing 2.3: XML-Schema zum Kunden XML-Dokument... 9 Listing 2.4: Eine SOAP-Nachricht Listing 2.5: Datenverschlüsselung mit XML Encryption Listing 3.1: Bereitzustellendes Java-Interface Listing 3.2: Struktur einer.asmx -Datei Listing 4.1: Codefragment für den Zugriff auf den Google Web-Service mit C#.NET Listing 4.2: Codefragment für den Zugriff auf den Google Web-Service mit VB.NET Listing 4.3: Codefragment für den Zugriff auf den Google Web-Service mit Java Listing 4.4: Codefragment für den Zugriff auf den Google Web-Service mit JSP Listing 4.5: Codefragment für den Zugriff auf den Google Web-Service mit ASP.NET Listing 4.6: Codefragment den Zugriff auf den Google Web-Service mit PHP Listing 4.7: SOAP-Request (Rechtschreibeanfrage) des Clients an den Google Web-Service Listing 4.8: SOAP-Response des Google Web-Service auf die Rechtschreibenfrage des Clients. 47 Listing 6.1: Struktur einer Action-Klasse Listing 6.2: Ausschnitt aus der Konfigurationsdatei struts-config.xml Listing 6.3: Ausschnitt aus der Datei validation.xml Listing 7.1: Implementierung der Login Action-Klasse Listing 7.2: Vorbereitung des Web-Service Aufrufs Listing 7.3: Web-Service Aufruf für das Login in das Potato-System Listing 7.4: Fragment der Datei tilesdefinitions.xml Listing 7.5: Anwendung der HTML Tag-Library in der Datei login_body.jsp Listing 9.1: Die WSDL-Datei des Google Web-Services VIII

9 1 Einleitung Immer mehr Menschen nutzen das Internet, um digitale Güter wie MP3, Software oder Filme untereinander zu tauschen. Dabei empfinden es viele Nutzer nicht als Unrecht, Kopien von diesen digitalen Gütern anzufertigen und weiter zu verbreiten. Dadurch entstehen der Software- und Unterhaltungsindustrie große Verluste. Kopierschutz und Kontrollmechanismen sollen die illegale Verbreitung von digitalen Gütern erschweren, wodurch jedoch die Verwendung der Produkte stark eingeschränkt wird. Industrie und Kunden stehen sich also mit entgegengesetzten Interessen gegenüber. Diese beiden Interessengruppen werden durch das Potato-System wieder zusammengeführt. Das Potato-System ist ein Handelsplatz für digitale Güter, insbesondere MP3-Dateien. Die Nutzer werden am Umsatz beteiligt, indem sie zu Vertriebspartnern werden. Die Funktionalitäten des Potato-Systems werden als Web-Service bereitgestellt, wobei sich so genannte Jackets dieser bedienen. Das können zum Beispiel Web-Applikationen sein. Ziel dieser Diplomarbeit ist die Konzeption und Realisierung einer Nutzerschnittstelle unter Einbeziehung des Web-Services, welcher vom Potato-System bereitgestellt wird. Es ist eine Web-Applikation zu entwickeln, welche die Funktionalitäten des angesprochenen Web- Services nutzt. Über kein anderes Konzept wurde in den letzten Monaten in Fachzeitschriften mehr diskutiert als über Web-Services. Dabei erhält man oftmals den Eindruck, dass das Web-Service Konzept die Softwareentwicklung revolutionieren würde. Aber was genau steckt hinter der Web-Service Technologie? Wie kann man Web-Services erstellen? Wie kann man Funktionalitäten eines Web-Services in seinen Anwendungen nutzen und welche Möglichkeiten gibt es, den Entwickler bei der Erstellung und Nutzung von Web-Services zu unterstützen? Auf diese Fragen soll im theoretischen Teil dieser Diplomarbeit eine Antwort gegeben werden, um die daraus gewonnenen Erkenntnisse im praktischen Teil anzuwenden. Im Kapitel 2 werden die Grundlagen von Web-Services besprochen. Dies beinhaltet eine Begriffsdefinition, die Einführung in das Architekturkonzept und die Vorstellung der zugrunde liegenden Basistechnologien. In diesem Zusammenhang wird ebenfalls besprochen werden, wie man die Sicherheit bei Web-Services gewährleisten kann. Mögliche Anwendungsbereiche für Web-Services runden dieses Kapitel ab. 1

10 Kapitel 1 / Einleitung Das Kapitel 3 beschäftigt sich mit den Entwicklungsmöglichkeiten von Web-Services. Es werden Toolkits und Entwicklungsumgebungen vorgestellt, welche die Arbeit mit Web- Services erleichtern. Im Fokus dieser Diplomarbeit steht zwar die Nutzung von Web- Services, dennoch soll in diesem Kapitel beleuchtet werden, wie man Web-Services erstellt und welche Unterstützung die vorgestellten Toolkits und Entwicklungsumgebungen hierfür bieten. Kapitel 4 untersucht die Zugriffsmöglichkeiten auf Web-Services. Es wird dargelegt, wie man die Funktionalitäten eines Web-Services in Client- und Serverseitigen Anwendungen nutzen kann und welche Schritte dafür notwendig sind. Dies wird am Beispiel des Google Web- Service getan werden. Die Ideen und Konzepte sowie die Architektur des Potato-Systems werden in Kapitel 5 vorgestellt. Kapitel 6 beschreibt den konzeptionellen Teil dieser Diplomarbeit. Ziel ist die Entwicklung einer Web-Applikation, welche den Web-Service des Potao-Systems in Anspruch nimmt. Es werden die Anforderungen an die Nutzerschnittstelle erläutert und Möglichkeiten aufgezeigt, wie diese Anforderungen erfüllt werden können. Abschließend werden die Konzepte und Strategien dargelegt, welche für die Umsetzung der Anforderungen notwendig sind. Das 7. Kapitel demonstriert beispielhaft, wie eine konkrete Funktionalität der Nutzerschnittstelle unter Verwendung der in Kapitel 6 erarbeiteten Konzepte implementiert wurde. Den Abschluss dieser Diplomarbeit bildet eine Zusammenfassung und Ausblick im Kapitel 8. 2

11 2 Grundlagen von Web-Services In diesem Kapitel sollen die Grundlagen von Web-Services besprochen werden. Nach einer Begriffsklärung wird in die zugrunde liegende Schichten-Architektur eingeführt, um in Anschluss daran die verwendeten Basisarchitekturen zu erläutern. Sicherheitsfragen und Anwendungsmöglichkeiten werden ebenso erörtert. 2.1 Begriffsklärung Der Begriff Web-Service ist zum Schlagwort in den letzten Jahren geworden. Allerdings fällt auf, dass keine einheitliche Definition dieses Begriffs und des mit ihm verbundenen Paradigmas existiert. [Sne02] vermittelt eine kurze Beschreibung: Ein Web-Service ist eine über ein Netzwerk zugängliche Schnittstelle zu Anwendungsfunktionen, die mit Hilfe von Standardtechniken des Internets realisiert wird. Wenn also eine Anwendung mit Hilfe einer Kombination von standardisierten Protokollen wie HTTP (HyperText Transfer Protocol), XML (Extensible Markup Language), SMTP (Simple Mail Transfer Protocol) oder Jabber über ein Netzwerk angesprochen werden kann, handelt es sich um einen Web-Service. Folgende Definition nimmt das W3C (World Wide Web Consortium) [W3Ca02] vor: A Web service is a software system identified by a URI (Uniform Resource Identifier), whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols. Diese Eigenschaften sind nichts Neues, sondern stellen eher eine Weiterentwicklung von Prinzipien dar, an welchen sich das Internet seit Jahren orientiert hat. Betrachtet man einen Web-Service als ein Programm im Internet, das mit standardisierten Protokollen aufzurufen ist, so zeigt sich, dass ähnliche Verfahren schon lange existieren. Während sich durch CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation) oder (D)COM ((Distributed) Component Object Model) verteilte Applikationen erstellen lassen, behandeln sie häufig nur Teilaspekte der Kommunikation. Plattformunabhängigkeit kann durch RMI erreicht werden, jedoch benötigt man eine Java-Implementation. Der 3

12 Kapitel 2 / Grundlagen von Web-Services Standard CORBA ist unabhängig von einer Programmiersprache, setzt jedoch die Existenz eines speziellen Moduls voraus. Der ORB (Object Request Broker) kann nicht von jeder Plattform bereitgestellt werden. COM ist an Windows-Umgebungen gebunden. Bisherige Verteilungstechnologien gewährleisten also nicht in allen Fällen eine vollständige Unabhängigkeit von Plattform oder Programmiersprache. Dieser Unzulänglichkeit soll die Web-Service-Technologie entgegenwirken. Das Web-Service-Modell beruht auf der Interaktion dreier Rollen. - Dienstanbieter (service provider) - Dienstbenutzer (service requestor) - Dienstverzeichnis (service registry) Ein Dienstanbieter stellt eine Plattform zur Verfügung, welche über ein Netzwerk Zugriff auf den Dienst ermöglicht. Der Dienstbenutzer sucht und ruft den durch den Dienstanbieter angebotenen Dienst auf. Diese Rolle kann sowohl von einem Browser und dem dahinter stehenden Nutzer, als auch von einem Programm, wie zum Beispiel einem weiteren Web-Service übernommen werden. Das Dienstverzeichnis ist eine über das Internet durchsuchbare Datenbank, in welcher der Dienstanbieter Dienstbeschreibungen für seinen Web-Service bereitstellt. Das Durchsuchen der Datenbank kann zur Laufzeit (dynamic binding) oder zur Entwicklungszeit des Dienstbenutzers (static binding) erfolgen. Beim static binding ist das Dienstverzeichnis nicht zwingend notwendig, denn der Dienstanbieter kann die Dienstbeschreibung dem Dienstbenutzer direkt zugänglich machen (z. B. per FTP (File Transfer Protocol), ). Die dynamische Integration von Diensten bezeichnet man auch als Just-in-time-Integration. Die Interaktion der Rollen kann durch drei Operationen beschrieben werden. - interagieren (interact) - finden (find) - veröffentlichen (publish) Damit auf einen Web-Service zugegriffen werden kann, muss seine Beschreibung veröffentlicht werden. Der Dienstbenutzer sucht (und findet) einen Web-Service und erhält dessen Beschreibung. 4

13 Kapitel 2 / Grundlagen von Web-Services Der Dienstbenutzer ruft einen Dienst auf und interagiert mit diesen. Die beschriebenen Zusammenhänge sind in der Abbildung 2.1 nachzuvollziehen. Die zugrunde liegende Basisarchitektur bezeichnet man auch als Service orientierte Architektur (SOA - Service Oriented Architecture). Dienstverzeichnis Dienstbeschreibung veröffentlichen finden Dienst Dienstanbieter Dienstbeschreibung Dienstbenutzer interagieren binden Abbildung 2.1: Service Orientierte Architektur (SOA) [W3Ca02] 2.2 Der Stack der Web-Service-Techniken Die unterste Schicht des Web-Service-Stacks nimmt die Netzwerkschicht ein. Web-Services müssen in einem Netzwerk verfügbar sein, um von anderen Programmen aufgerufen werden zu können. Web-Services, die über das Internet zugreifbar sein sollen, müssen Standard Internet-Protokolle verwenden. Als Transportprotokoll wird meist HTTP eingesetzt. Aber auch jedes andere Transportprotokoll wie FTP oder SMTP ist je nach Anwendungsgebiet einsetzbar. Die zweite Schicht des Web-Service-Stacks ist die Nachrichtenschicht. In ihr findet der XML-basierte Nachrichtenaustausch statt. SOAP definiert einen auf XML basierenden Umschlag (envelope), in welchem jede Art von Daten übertragen werden können. Zusätzlich dazu sind RPC-Aufrufe (Remote Procedure Call) übermittelbar. Damit ist der Aufruf eines Web-Services über standardisierte XML-Nachrichten möglich. 5

14 Kapitel 2 / Grundlagen von Web-Services Die Dienstbeschreibungsschicht bildet die dritte Schicht des Stacks. Sie besteht aus einer Sammlung von Dokumenten, die den Web-Service beschreiben. Standardmäßig wird dafür WSDL als XML-basierte Dienstbeschreibungssprache verwendet. Ein WSDL-Dokument beschreibt das Interface und die Implementierung eines Web-Service und enthält alle nötigen Informationen für dessen Benutzung. Die vierte Schicht setzt auf den Kern-Stack (Netzwerkschicht, Nachrichtenschicht Dienstbeschreibungsschicht) auf, welcher jeder Web-Service implementieren muss und wird als Service-Registrierungsschicht bezeichnet. In ihr sind die Prozesse Veröffentlichung (Service-Publication) und Entdeckung (Service-Discovery) von Bedeutung. Die einfachste Form der Veröffentlichung ist ohne Verwendung einer Service-Registry. Hierbei werden die WSDL-Dokumente direkt vom Dienstanbieter an den Dienstbenutzer gesendet. Die Entdeckung besteht dann einfach aus dem Laden der WSDL-Datei. Eine andere Möglichkeit bietet UDDI (Universal Description, Discovery and Integration) als Service-Registry. Darin werden typischerweise nicht nur die WSDL-Dokumente abgespeichert, sondern weiterhin ausführliche Beschreibungen des Dienstanbieters. Die Säulen Management, Quality of Service (QoS) und Sicherheit bezeichnen Anforderungen, welche in jeder horizontalen Schicht gefordert sind. Abbildung 2.2 gibt eine zusammenfassende Darstellung über den Stack der Web-Service- Techniken. UDDI Service-Registrierungsschicht WSDL XML, SOAP Dientsbeschreibungsschicht Nachrichtenschicht Management Quality of Service Sicherheit HTTP, SSL, FTP, SMTP, etc. Netzwerkschicht Abbildung 2.2: Der Web-Service-Stack [Web02] 6

15 Kapitel 2 / Grundlagen von Web-Services 2.3 Basistechnologien HTTP (HyperText Transfer Protocol) Das HTTP-Protokoll wurde ursprünglich zur Übermittlung von HTML-Seiten (HyperText Markup Language) entwickelt und basiert auf dem Client-Server-Prinzip. Es werden eine Reihe von Methoden (z. B. GET oder POST) für die Übertragung von Daten spezifiziert. Weiterhin stehen Status-Codes zum Anzeigen von Fehlern oder Warnmeldungen zur Verfügung. Eine HTTP-Verbindung ist zustandslos, der Server führt also keine Aufrufhistorie. HTTP-Nachrichten sind durch die Kodierung im ASCII-Format (American Standard Code for Information Interchange) für den Menschen lesbar. Weitere Informationen sind unter [HTTP] abrufbar XML (Extensible Markup Language) XML ist ein Projekt des W3C-Konsortiums [W3C], welches seit 1996 entwickelt wird und stellt eine universelle Sprache zum Austausch, zum Retrieval und zur Verwaltung von Daten dar. Ein XML-Element besteht aus einem Anfangs-Tag und einem End-Tag, den so genannten semantischen Tags. Tags sind eine Art Marke und sagen etwas über die Bedeutung der Zeichenkette aus, die von ihnen eingeschlossen wird. Ein XML-Dokument ist ein XML-Element, das verschachtelte XML-Elemente enthalten kann. In Listing 2.1 ist ein einfaches Kunden XML-Dokument abgebildet. <Kunden> <Kunde id="12345"> <Name>Mustermann, Karl</Name> <Firma>Mustermann GmbH</Firma> <Telefon> </Telefon> <Fax> </Fax> <Kreditkartennummer> </Kreditkartennummer> <Adresse> <Strasse>Musterstrasse 1</Strasse> <Stadt>Ilmenau</Stadt> <PLZ>98693</PLZ> <Land>BRD</Land> </Adresse> </Kunde>... </Kunden> Listing 2.1: Kunden XML-Dokument 7

16 Kapitel 2 / Grundlagen von Web-Services Eine Dokumententyp-Definition (DTD) enthält Normen für den Inhalt und Aufbau von XML- Dokumenten. In ihr wird also festgelegt, wie ein Dokument auszusehen hat. In Listing 2.2 ist die zum Kunden XML-Dokument gehörige DTD. <?xml version="1.0"?> <!DOCTYPE Kunden [ <!ELEMENT Kunde (Kunde)* > <!-- XML-Dokument beginnt mit einem Kunde Element (beliebig viele) --> <!ELEMENT Kunde (Name, Firma, Telefon+, Fax*, Adresse)> <!-- "*" heißt beliebig oft, "+" heißt mind. einmal --> <!ELEMENT Name (#PCDATA)> <!ELEMENT Firma (#PCDATA)> <!ELEMENT Telefon (#PCDATA)> <!ELEMENT Fax (#PCDATA)> <!ELEMENT Adresse (Strasse, Stadt, PLZ, Land)> <!ELEMENT Strasse (#PCDATA)> <!ELEMENT Stadt (#PCDATA)> <!ELEMENT PLZ (#PCDATA)> <!ELEMENT Land (#PCDATA)> <!ATTLIST Kunde id CDATA #REQUIRED> <!-- unbedingte Angabe --> ]> Listing 2.2: DTD zum Kunden XML-Dokument Eine weitere Möglichkeit die Struktur eines XML-Dokumentes zu definieren, bietet sich mit dem XML-Schema, welches die DTDs mittelfristig ablösen wird. Die Gründe für diesen Wechsel sind in den folgenden Punkten aufgezeigt. Nachteile von DTDs: - Datentypen sind begrenzt (keine Möglichkeit Datum, Währung,... genau darzustellen) - verwenden keine XML-Syntax - besitzen komplexen Erweiterungsmechanismus - unterstützen keine Namensräume Vorteile von XML-Schema: - mehr Datentypen (Datum, Integer...) - Nutzung selbst erstellter Datentypen - Vererbung deklarierter Objekte - Verwendung von Namensräumen DTDs sind zwar nicht so mächtig wie das XML-Schema, jedoch einfacher zu erlernen. Es wurden bereits viele Erfahrungen damit gesammelt und werden auch weiterhin zum Einsatz 8

17 Kapitel 2 / Grundlagen von Web-Services kommen. Im folgenden Listing 2.3 ist das zum Kunden XML-Dokument zugehörige XML- Schema. <schema xmlns=" <element name="kunden" type="kundentyp"/> <complextype name="kundentyp"> <element name="kunde" type= "KundeTyp" maxoccurs="*"/> </complextype> <complextype name="kundetyp"> <element name="name" type="string"/> <element name="firma" type="string"/> <element name="telefon" type="string" maxoccurs="*"/> <element name="fax" type="string" minoccurs="0"/> <element name="adresse" type="adressetyp"/> <attribute name="id" type="string" minoccurs="1"/> </complextype> <complextype name="adressetype"> <element name="strasse" type="string"/> <element name="stadt" type="string"/> <element name="plz" type="string"/> <element name="land" type="landtyp"/> </complextype> <simpletype name="landtyp" base="string"> <enumeration value="brd"/> <enumeration value="usa"/> <enumeration value="nl"/> <!-- Weitere Staaten hier eintragen --> </simpletype> </schema> Listing 2.3: XML-Schema zum Kunden XML-Dokument Falls ein Dokument im Sinne der DTD bzw. des XML-Schemas korrekt ausgezeichnet wurde, so ist es gültig oder valid. Ein XML-Dokument kann auch ohne DTD bzw. XML-Schema auskommen und wohlgeformt sein, wenn es definierten syntaktischen Anforderungen genügt SOAP (Simple Object Access Protocol) SOAP ist eine Anwendung der XML-Spezifikation. Eine sehr flexible Möglichkeit zur Kommunikation zwischen Anwendungen stellt der XML-Nachrichtenaustausch dar, welcher die Grundlage für SOAP bildet. Da XML an keine spezielle Anwendung, Betriebsystemumgebung oder Programmiersprache gebunden ist, können XML-Nachrichten in allen Umgebungen verwendet werden. RPC (Remote Procedure Call) ist die Grundlage für verteiltes Rechnen und EDI (Electronic Document Interchange) findet bei automatisierten geschäftlichen Transaktionen Anwendung. RPC, also der Aufruf einer Methode eines Programms und EDI sind mit SOAP verwandt. 9

18 Kapitel 2 / Grundlagen von Web-Services Eine SOAP-Nachricht besteht aus einem Umschlag (envelope), welcher optional einen Header und danach zwingend einen Body enthält. Der Header enthält Informationsblöcke, welche sich auf die Nachrichtenverarbeitung beziehen. Diese beinhalten Angaben zum Routing und zur Auslieferung, Aussagen über die Authentifizierung oder Autorisierung und Transaktionskontexte. Der Body enthält die eigentliche Nachricht für die Auslieferung und Verarbeitung. Die XML-Syntax für die Formulierung einer SOAP-Nachricht stützt sich auf den Namensraum Dieser Bezeichner weist auf ein XML-Schema, welches die Struktur einer SOAP-Nachricht definiert. In Abbildung 2.3 ist die SOAP-Nachrichtensstruktur verdeutlicht. SOAP-Umschlag SOAP-Header Headerblock Headerblock SOAP-Body Nachrichten-Body Abbildung 2.3: Die SOAP-Nachrichtenstruktur [Sne02] Das folgende Listing 2.4 beinhaltet alle Kernkomponenten eines SOAP-Umschlages. Zu sehen ist eine Nachricht im RPC-Stil. Man stelle sich vor, dass eine Anwendung eine Funktion anbietet, die einen Aktienkurs liefert. 10

19 Kapitel 2 / Grundlagen von Web-Services <soapenv:envelope xmlns:soapenv=" <soapenv:header> <tr:transaction xmlns:tr="soap-transaction" soapenv:mustunderstand="true"> <transactionid>1234<transactionid> </tr:transaction> </soapenv:header> <soapenv:body> <q:getquote xmlns:q="urn:quoteservice" soapenv:encodingstyle=" <symbol xsi:type="xsd:string">ibm</symbol> </q:getquote> </soapenv:body> </soapenv:envelope> Listing 2.4: Eine SOAP-Nachricht Der oberste Container <soapenv:envelope> enthält die SOAP-Nachricht. Der optionale Header <soapenv:header> beinhaltet zusätzliche Informationsblöcke, hier eine Transaktions-ID und das Attribut mustunderstand. Wenn das Flag mustunderstand = true in einen bestimmten Block (hier der Header) gesetzt ist, muss die gesamte Nachricht vom Empfänger zurückgewiesen werden, falls dieser den Block nicht versteht und zwar unabhängig davon, ob der Rest der Nachricht (hier der Body) verarbeitet werden kann oder nicht. Dadurch wird sichergestellt, dass der Empfänger Transaktionen versteht. Jedes Envelope-Element muss genau ein Body-Element enthalten. Das Body-Element kann so viele Kind-Knoten beinhalten, wie benötigt werden. Darüber hinaus kann es jeden gültigen, wohlgeformten XML-Code aufnehmen, der durch einen Namensraum qualifiziert ist und keinerlei Verarbeitungsanweisungen und Verweise auf DTDs enthält. Die gleichen Restriktionen sind für das Header-Element einzuhalten, welches nur einmal vorkommen darf und mehrere Headerblöcke enthalten kann. Der Codierungsstil für eine bestimmte Menge von XML-Elementen wird durch die Angabe des Attributes encodingstyle festgelegt. Es kann an jeder Stelle des Dokumentes auftreten und gilt für alle untergeordneten Kinder des Elements. Der Codierungsstil legt fest, wie Anwendungen auf verschiedenen Plattformen Informationen miteinander austauschen. Treten Fehler bei der Verarbeitung von SOAP-Nachrichten auf, so wird ein besonderer Nachrichtentyp generiert, so genannte SOAP-Faults, welche den aufgetretenen Fehler näher spezifizieren. 11

20 Kapitel 2 / Grundlagen von Web-Services WSDL (Web Service Description Language) Der Standard für die Beschreibung von Web-Services ist WSDL. Dadurch kann ein Web- Service darüber informieren, welche Funktionalitäten er anbietet und wie diese zu nutzen sind. Die Struktur eines WSDL-Dokuments entspricht der Syntax des XML-Schemas (siehe Kapitel 2.3.2). Mehr Informationen über den Aufbau und Funktionsweise einer WSDL- Beschreibung können aus der Diplomarbeit von Gabriele Frings [Fri03] entnommen werden UDDI (Universal Description, Discovery and Integration) WSDL stellt den Dienstbenutzer Informationen zur Verfügung (ähnlich den Gelben Seiten), welche für die Interaktion mit dem Web-Service notwendig sind. Das UDDI-Projekt ist eine Initiative der Industrie, ein durchsuchbares Register von Diensten und ihren Beschreibungen zu definieren. Somit ist es Konsumenten möglich, Dienste entdecken zu können. UDDI ist nicht die einzigste Möglichkeit Dienste zu entdecken. IBM [IBM] und Microsoft [Microsoft] haben WS-Inspection (Web-Service Inspection Language) vorgeschlagen, eine auf XML basierende Sprache, welche ein Verzeichnis aller Web-Services unter einer bestimmten URL (Uniform Resource Locator) bereitstellt. Für tiefergreifende Informationen soll wiederum auf [Fri03] verwiesen werden. 2.4 Sicherheit und Transaktionalität Die Entwicklung der Web-Service Technologie schreitet rasch voran, dennoch blieb das Thema Sicherheit für lange Zeit ungeklärt. Fehlende Sicherheitsstandards wurden in der Vergangenheit immer wieder als Aufschiebegrund für den Beginn von Web-Service Projekten genannt. Folgende Fragen müssen betrachtet werden: [Pop02] - Wie können Sicherheit, Erreichbarkeit von Diensten und Performance gewährleistet werden? - Wie verhalten sich (kooperierende) Dienste? - Welche Sicherheitsrisiken werden bei Aufruf eines Web-Services eingegangen? 12

21 Kapitel 2 / Grundlagen von Web-Services Sicherheit bei Web-Services mit WS-Security Beim Einsatz von Web-Services entstehen neue Anforderungen, die mit gewöhnlichen Firewalls nicht erfüllbar sind. Die Zugriffsbeschränkung auf gewisse Operationen ist mit einer Firewall auf Netzwerkebene nicht erreichbar. Alle vom Web-Service bereitgestellten Methoden sind für jedermann zugänglich. Die XML- bzw. SOAP-Fähigkeit von Firewall- Produkten könnte dieses Problem lösen, denn es wäre eine Filterung eingehender SOAP- Requests möglich. Weit verbreiteter ist jedoch die Problemlösung auf Anwendungsebene. Neben der reinen Zugriffsbeschränkung, muss die Vertraulichkeit von SOAP-Nachrichten durch Verschlüsselung garantiert werden können. Die Sicherstellung der Datenintegrität, also die Gewährleistung, dass eine Nachricht auf dem Weg vom Sender zum Empfänger nicht verändert wird, ist ebenso eine wichtige Anforderung. WS-Security [WSSecurity] definiert einige Erweiterungen des SOAP-Protokolls, mit deren Hilfe die Standards XML-Encryption [XMLEncryption] und XML-Signature [XMLSignature] im Zusammenspiel mit SOAP-Nachrichten genutzt werden können. Um diese Technologien verstehen zu können, ist ein Grundwissen über kryptographische Verfahren erforderlich. Dieses soll im Folgenden aufgefrischt werden. Bei der Verschlüsselung von Daten unterscheidet man zwischen symmetrischen und asymmetrischen Verfahren. Symmetrischer Verfahren Absender und Empfänger einer Nachricht verwenden denselben Schlüssel, um die Nachricht ver- bzw. entschlüsseln zu können. Der Vorteil liegt in der Geschwindigkeit und Effizienz. Der gemeinsame Schlüssel muss jedoch zunächst auf einem sicheren Weg vereinbart bzw. übermittelt werden. Ebenso muss für jeweils zwei Kommunikationspartner ein solcher Schlüssel existieren. Bei 15 Kommunikationspartnern wären dies bereits 105 Schlüssel. Asymmetrische Verfahren Jeder Kommunikationspartner besitzt einen öffentlichen (public key) und einen privaten Schlüssel (private key). Der private Schlüssel wird geheim gehalten, während der öffentliche Schlüssel allen Kommunikationspartnern gezielt zugeführt wird. Somit sind für 15 solcher Kommunikationspartner nur 30 Schlüssel notwendig. Eine Nachricht, die mit einem öffentlichen Schlüssel einer Person chiffriert wurde, kann nur mit dem zugehörigen privaten Schlüssel wieder zurückverwandelt werden und umgekehrt. 13

22 Kapitel 2 / Grundlagen von Web-Services Die Herleitung des einen Schlüssels aus dem anderen ist mit unrealistischem Aufwand an Hardware und Rechenleistung verbunden. Ein erfolgreicher Angriff würde viel Zeit in Anspruch nehmen. Digitale Zertifikate wie X.509 betätigen die Zugehörigkeit eines öffentlichen Schlüssels zu einer Person. Somit kann die Erzeugung von gefälschten Schlüsselpaaren und das in Umlauf bringen von ungültigen öffentlichen Schlüsseln unter falschem Namen verhindert werden. Häufig werden asymmetrische Verfahren auch dazu verwendet, um auf sichere Art und Weise einen symmetrischen Schlüssel für die weitere Kommunikation zu übertragen. (z. B. SSL (Secure Socket Layer)). Die Verwaltung öffentlicher Schlüssel kann mit hohem Aufwand verbunden sein. Digitale Signaturen sind ein bekanntes Einsatzgebiet von asymmetrischen Verfahren. Damit kann die Datenintegrität und die Authentizität der Kommunikationspartner garantiert werden. Diese erhöhte Sicherheit resultiert in einer schlechten Performance, da die zu signierenden Nachrichten beliebig groß werden können. Deshalb wird in der Regel nur ein so genanntes Message Digest signiert. Dies ist eine Art Checksumme, welche mittels einer Hash-Funktion aus der zu signierenden Nachricht berechnet wird. Das Fälschen eines Message Digest ist nur extrem schwer möglich, denn kleinste Änderungen an einer bestehenden Nachricht bewirken deutliche Abweichungen in der Checksumme. Die Identität von Clients nimmt eine Schlüsselrolle in Web-Service-Anwendungen ein, vor allem bei der Verknüpfung mehrerer Web-Services zu komplexen Workflows. Einfache Web- Services realisieren eine Autorisierung meist über Benutzername und Passwort. Diese Vorgehensweise ist jedoch untragbar beim Zusammenspiel mehrerer Web-Services unterschiedlicher Anbieter. Daher existieren bereits Ansätze wie Microsofts Passport oder das Liberty Alliance Projekt, um den Single Sign-on zu etablieren (siehe auch [Fri03]). XML-Encryption Grundsätzlich kann eine Verschlüsselung auf der Transportschicht oder auf der Anwendungsschicht vorgenommen werden. Wenn eine SOAP-Nachricht nicht einen einzigen Web-Service als Empfänger hat, sondern die Nachricht erst über mehrere Zwischenstationen zum endgültigen Empfänger gelangt, so liegt in der Verschlüsselung auf der Transportschicht (meist SSL/HTTPs (HTTP secure)) ein Sicherheitsrisiko. Denn es kann unter Umständen möglich sein, dass Teile einer Nachricht für einzelne Zwischenstationen nicht sichtbar sein dürfen. Um eine partielle Verschlüsselung erreichen zu können, muss auf der Anwendungsschicht eingegriffen werden. Mit XML-Encryption kann eine granulare 14

23 Kapitel 2 / Grundlagen von Web-Services Verschlüsselung vorgenommen werden. So kann zum Beispiel das komplette XML- Dokument, einzelne Elemente oder nur die Inhalte eines Elements verschlüsselt werden. Das XML-Dokument in Listing 2.5 verschlüsselt die Kreditkartennummer des Kunden XML- Dokumentes (siehe Listing 2.1). Ein mit XML-Encryption verschlüsseltes Element enthält anstelle der verschlüsselten Anteile ein Element namens <EncryptedData>. Dessen Attribute beinhalten Informationen über den Namensraum sowie über die Granularität der Verschlüsselung. Darin verschachtelt befinden sich die Elemente <EncryptionMethod>, welche den Verschlüsselungsalgorithmus spezifiziert und <CipherData>, welches die verschlüsselten Daten enthält. Verschlüsselt man ein komplettes XML-Dokument, so geht dessen Struktur verloren. Verschlüsselt man hingegen nur einzelne Elemente eines Dokumentes, könnte die Sicherheit darunter leiden. Der Einsatz von XML-Encryption bedeutet immer eine Erhöhung der Komplexität und ein Performanceverlust. <Kunden> <Kunde id="12345"> <Name>Mustermann, Karl</Name> <Firma>Mustermann GmbH</Firma> <Telefon> </Telefon> <Fax> </Fax> <EncryptedData xmlns=" type=" <EncryptionMethod algorithm=" <CipherData> <CipherValue>A84H8D38PC</CipherValue> </CipherData> </EncryptedData> <Adresse> <Strasse>Musterstrasse 1</Strasse> <Stadt>Ilmenau</Stadt> <PLZ>98693</PLZ> <Land>BRD</Land> </Adresse> </Kunde>... </Kunden> Listing 2.5: Datenverschlüsselung mit XML Encryption 15

24 Kapitel 2 / Grundlagen von Web-Services XML-Signature Da die Reihenfolge von Elementen in einem XML-Dokument beliebig sein kann und Parser häufig Formatierungen vornehmen, gibt es für eine und dasselbe XML-Dokument unendlich viele Repräsentationen. Die Errechnung des Message Digest würde für jede Repräsentation zu einem anderen Ergebnis führen. Eine Lösung dieses Problem bietet Canonical-XML [CanXML]. Mit diesem Standard werden XML-Dokumente in eine kanonische Darstellung überführt. Weitere Spezifikationen sind vorgesehen. Mit Hilfe von WS-Policy [WSPolicy] können in Kopplung mit WS-Trust [WSTrust] Vertrauensverhältnisse bezüglich Authentifizierung und Autorisierung zwischen mehreren Kommunikationspartnern definiert und verwendet werden. WS-Privacy erlaubt es Sendern und Empfängern zu spezifizieren, welche Anforderungen sie an ihre Kommunikationspartner stellen und welche sie selbst erfüllen. Mit WS-Security [WSSecurity] werden sicherheitsrelevante Funktionalitäten bereitgestellt, welche bislang in der Web-Service Welt vermisst wurden. Somit ist es möglich, Daten auch über mehrere Zwischenstationen verschlüsselt zu übertragen bzw. eine partielle Verschlüsselung für einzelne Empfänger vornehmen zu können. Eine Datenintegrität kann mit Hilfe von digitalen Signaturen gewährleistet werden Transaktionalität von Web-Services Einen wichtigen Aspekt bei der Gewährleistung von Transaktionalität, bildet die Verfolgbarkeit und Definierbarkeit des Zustandes eines Requests. Einen wichtigen Ansatz hierfür bildet der Standard XAML (Transaction Authority Markup Language), welcher von namhaften Firmen initiiert wurde. Es werden eine Reihe von XML-Nachrichtenformaten und Interaktionsmodellen definiert, mit denen bekannte Transaktionsoperationen (commit, undo, retry, ) realisierbar sind. Ziel ist die Bereitstellung von TP-Monitoren (Transaction Processing Monitors), um Transaktionalität bei Web-Services umzusetzen. Aufrufern von Diensten werden Transactions-IDs zugewiesen, woraufhin die bekannten Transaktionsoperationen benutzt werden können. Die Gewährleistung der Transaktionalität nach dem XAML-Prinzip, kann in drei Phasen vorgenommen werden. (1) Prüfung der Verfügbarkeit eines Dienstes (2) Nutzung des (verfügbaren Dienstes) und Zuweisung einer Transaktionskennung (SessionID) (3) Ausführung von Transaktionsoperationen 16

25 Kapitel 2 / Grundlagen von Web-Services 2.5 Anwendungsszenarien Bei der EAI (Enterprise Application Integration) werden mehrere Geschäftsanwendungen innerhalb eines Intranets mittels einer zentralen Komponente miteinander verbunden. Für die Kommunikation der zentralen Komponente kann eine Web-Service-Schnittstelle verwendet werden. Weiterhin kann das EAI-System die bereits integrierten Anwendungen nach außen hin wiederum über eine Web-Service-Schnittstelle zugänglich machen. B2B (Business to Business) fördert die Integration von firmeninternen Anwendungen mit denen von Partnerunternehmen. Die Kommunikation mit fremden Anwendungen stellt hohe Anforderungen an Sicherheit und Kontrolle. Ein Beispiel für ein B2B-Szenario ist in Abbildung 2.4 zu sehen. Der Web-Service Reiseorganisation bedient sich zahlreicher anderer Web-Services. Web-Service Hotelbuchung Web-Service Mietwagen UDDI & SOAP UDDI, WSDL & SOAP Client (Browser) Web-Service Wetterbericht SOAP Web-Service Reiseorganisation SOAP SOAP Web-Service Veranstaltungskalender Abbildung 2.4: Komplexer Web-Service Reiseorganisation [Sta02] Das B2C (Business to Customer) Szenario zeichnet sich durch die Nutzung von Web-Services durch Anwendungen von Kunden aus. Ein populäres Beispiel ist die Nutzung des Google Web-Service. Im Kapitel 4 wird demonstriert, wie man Funktionalitäten dieses Web-Services in seiner Anwendung nutzen kann. 17

26 Kapitel 2 / Grundlagen von Web-Services 2.6 Ein Blick in die Zukunft Die Web-Service Technologie erfüllt die hohe Anforderung der Interoperabilität. Somit ist eine plattform- und programmiersprachenunabhängige Interaktion von Systemen möglich geworden. Eine Eigenschaft, welche herkömmliche Verteilungstechnologien nicht erfüllen konnte. Die Popularität und Bekanntheit von Web-Services steigt ständig. Jedoch werden Web-Services bestehende Infrastrukturen nicht ersetzen. Vielmehr helfen sie, bestehende Techniken zu integrieren. Immer mehr Firmen bedienen sich an diesem Konzept. Web- Services sind für die Kommunikation zwischen Unternehmen interessant, die ansonsten aufgrund inkompatibler Systeme am Geschäft gehindert würden. Deshalb existiert ein sehr großes Potenzial für Web-Services im B2B Umfeld. Die Standardisierung schreitet immer weiter voran. Innerhalb des letzten Jahres hat sich sehr viel auf diesem Gebiet getan. Web- Services sind unverzichtbar in der modernen Softwareentwicklung geworden. 18

27 Kapitel 3 / Entwicklungsmöglichkeiten von Web-Services 3 Entwicklungsmöglichkeiten von Web-Services In diesem Kapitel sollen Toolkits und Entwicklungsumgebungen vorgestellt werden, welche die Erstellung von Web-Services unterstützen. Es kann dabei nur ein kleiner Ausschnitt existierender Umgebungen und Toolkits beleuchtet werden. Toolkits dienen der automatischen Unterstützung von Methoden und Verfahren zum Zwecke der Softwareerstellung. [Balz00] Unter einer Software-Entwicklungsumgebung versteht man die Gesamtheit von aufeinander abgestimmten, untereinander kompatiblen, gemeinsam zu benutzenden und wesentliche Teile des Entwicklungsprozesses abdeckenden Methoden und Werkzeugen zur Software-Entwicklung. [GI] Besondere Aufmerksamkeit soll dem Toolkit Axis (Apache extensible Interaction System) [Axis] gewidmet werden. Beispielhaft werden die Schritte erläutert, welche zur Entwicklung eines Web-Service notwendig sind. Ebenso wird das.net Framework einen größeren Umfang in diesem Kapitel einnehmen, da Microsoft [Microsoft] mit dieser Technologie völlig neue Wege beschreitet. Auch für das.net Framework [NET] soll dargelegt werden, wie Web-Services zu erstellen sind. 3.1 Entwicklung mit Apache Axis Architektur Axis ist ein Nachfolgeprojekt der Apache SOAP-Implementierung, die aus dem IBM [IBM] Projekt SOAP4J [SOAP4J] hervorging. Es stellt eine typische Webanwendung dar, welche in einem Servlet-konformen Web-Container wie zum Beispiel Tomcat [Tomcat] installiert werden kann. Sie beinhaltet drei Servlets für die Laufzeit, die Administration und für das Verfolgen von SOAP-Aufrufen (siehe Abbildung 3.1). Module gliedern Axis in Teilsysteme, welche verschiedene Aufgaben übernehmen, wie zum Beispiel den Transport von Nachrichten, die Administration oder den Aufruf von Service-Implementierungen. Die Aufteilungen der Aufgaben in Module in Verbindung mit Konfigurationsdateien, ermöglicht eine Erweiterung ohne Änderungen an Axis vornehmen zu müssen. Nachrichten durchlaufen in Form eines MessageContext einzelne Subsysteme. Der MessageContext ist eine Struktur, die Referenzen auf die Request- und Response-Nachricht sowie auf eine Reihe von Attributen beinhaltet. Der Zugriff auf den Request, die Response und weitere Eigenschaften erfolgt in den Handlern über den MessageContext. Mehrere Handler können in einer Kette zusammengefasst werden. Die Verarbeitung von Anfragen erfolgt über Filterketten, die sich 19

28 Kapitel 3 / Entwicklungsmöglichkeiten von Web-Services aus Handlern zusammensetzen. Bei der alltäglichen Anwendungsentwicklung ist es nicht notwendig selbst Handler zu erstellen. Web-Container Internet Axis Web Anwendung Action Servlet Web-Service Web-Service Web-Service Admin Servlet SOAP Monitor Servlet Abbildung 3.1: Axis im Web-Container [Bay03] Die Kommunikation mit Web-Services erfolgt über den Austausch von XML-Nachrichten. Das Ziel von JAX-RPC (Java API for XML-based Remote Procedure Call) [JAXRPC] ist es, die Komplexität des XML-Nachrichtenaustausches zu kapseln und ein für viele Entwickler vertrautes RPC-Paradigma anzubieten. Axis bedient sich dieser Technologie. Aus einem WSDL-Dokument kann automatisch ein Stub generiert werden, welcher einen Java-Aufruf zu einem SOAP-Request umwandelt. Dieser wird mittels der JAX-RPC-Laufzeitumgebung über HTTP an den Server gesendet. Aus dem SOAP-Umschlag (siehe Kapitel 2.3.3) werden wiederum die Java-Objekte rekonstruiert, die dann als Parameter an die Implementierungs- Klasse übergeben werden. Das Ergebnis des Aufrufs nimmt denselben Weg in umgekehrter Richtung zum Client. Dieser Ablauf ist in Abbildung 3.2 veranschaulicht. 20

29 Kapitel 3 / Entwicklungsmöglichkeiten von Web-Services Client Server JAX-RPC Stub JAX-RPC-Skeleton JAX-RPC-Rintime JAX-RPC-Runtime Transport Transport Abbildung 3.2: Die Komponenten von JAX-RPC [Wan03] Ein wichtiger Bestandteil der JAX-RPC-Spezifikation ist die Definition der Mapping-Regeln zwischen WSDL und Java, damit die Umwandlung von Java-Objekten in XML und umgekehrt erfolgen kann. Die Einhaltung dieser Mapping-Regeln ist für die Sicherstellung der Interoperabilität von Web-Services unverzichtbar. WSDL verwendet als Typsystem XML-Schema, welches eine Menge von einfachen Datentypen vordefiniert. Es hat also ein Mapping von Java-Datentypen auf die XML-Schema Datentypen zu erfolgen. Auch komplexe Datentypen sind mit dem XML-Schema definierbar. Eine Auflistung der Mappings einfacher Datentypen nimmt [Wan03] vor Entwicklung von Web-Services mit Apache Axis Bei der Entwicklung von Web-Services kann zwischen zwei Vorgehensweisen unterschieden werden. Bei der WSDL-zentrierten (top down) Vorgehensweise wird zuerst das WSDL- Dokument erstellt. Aufgrund der damit verbundenen Komplexität und des Aufwands, ist dies jedoch nicht zu empfehlen. Bei der Java-zentrierten (bottom up) Vorgehensweise wird die Schnittstelle zuerst in Java implementiert. Im Folgenden wird aufgezeigt, wie man mit Hilfe von Apache Axis Web-Services implementieren und veröffentlichen kann. (1) Bereitstellung eines Java-Interfaces Es ist ein Interface zu implementieren, welches von der Klasse java.rmi.remote zu erben hat. Darin werden Methodenrümpfe bereitgestellt, die RemoteExceptions zu erzeugen haben. In Listing 3.1 ist das entsprechende Interface zu sehen. 21

30 Kapitel 3 / Entwicklungsmöglichkeiten von Web-Services import java.rmi.remote; import java.rmi.remoteexception; public interface YourInterface extends Remote { } public void yourmethod() throws RemoteException; Listing 3.1: Bereitzustellendes Java-Interface (2) Erzeugung von WSDL Mit Hilfe der programmierten Interface-Klasse kann ein WSDL-Dokument erzeugt werden, welches die Schnittstelleninformationen enthält. Dazu dient das in Axis integrierte Tool java2wsdl. In Ergebnis des folgenden Aufrufs erhält man eine WSDL-Datei. java org.apache.axis.wsdl.java2wsdl -o YourFile.wsdl -l" -n "urn:yourservice" p "yourservice" "urn:yourservice" YourInterface es werden folgende Parameter übergeben: -o spezifiziert den Namen der WSDL- Datei -l spezifiziert die URL, unter welcher der Web-Service erreichbar sein soll -n bezeichnet den Ziel-Namensraum der WSDL-Datei -p bezeichnet das Mapping eines Packages auf einen Namensraum das implementierte Interface (3) Erzeugung von Hilfslassen aus der WSDL-Datei Mittels des folgenden Aufrufs werden Klassen und Dateien erzeugt, welche zum Teil auf Clientseite für einen erfolgreichen Aufruf des Web-Service benötigt werden. Ebenso müssen diese zum Teil dem Webserver bekannt gemacht werden, auf dem der Web-Service veröffentlicht werden soll. java org.apache.axis.wsdl.wsdl2java -o./out -s -S true YourFile.wsdl es werden folgende Parameter übergeben: -o das Ausgabeverzeichnis -s Erzeugung serverseitiger Bestandteile -S Verwendung serverseitiger Anteile in der Datei deploy.wsdd 22