Neue Produktivität durch Web-Services RPC, WSDL und SOAP

Transkript

1 Neue Produktivität durch Web-Services RPC, WSDL und SOAP Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester 2003/04 Universität Jena vorgelegt von Hendrik Jander Thomas Puhl Februar 2004

2

3 Zusammenfassung Die unter dem Schlagwort Web-Service zusammengefassten Technologien stellen eine Alternative zu bisher bekannten Ansätzen zur verteilten Programmierung dar. Interoperabilität ist ein wichtiges Kriterium bei der Realisierung verteilter Systeme, Web-Services versprechen diese durch die Nutzung von XML-basierten Standards und etablierten Internettransporttechnologien zu erhöhen. Die Tatsache, daß große Softwarekonzerne wie Microsoft oder Sun ihre Produktstrategien auf Web-Services ausrichten, verdeutlicht die Bedeutung, die dieses Thema zukünftig in der IT-Industrie spielen kann. Die vorliegende Arbeit konzentriert sich dabei, nach einem Überblick über die Grundlagen, auf die Kernstandards SOAP, WSDL und UDDI, da diese das Grundgerüst der Web-Servicearchitektur darstellen. Beispiele zur Implementierung von Web-Services mit Java und Microsofts C# geben Einblick in die praktische Arbeit mit dieser Technologie. 1

4 Inhaltsverzeichnis 1 Einleitung 3 2 Verteilte Systeme RPC Remote Procedure Call Existierende Middlewaretechnologien Web-Services SOAP Simple Object Access Protocol Aufbau einer SOAP-Nachricht Nachrichtenverarbeitung Kommunikationsmuster von SOAP SOAP-RPC Transport von SOAP-Nachrichten WSDL Web-Service Description Language Struktur eines WSDL-Dokuments WSDL Kommunikationsmuster Binding UDDI Universal Description, Discovery and Integration Datenstrukturen Informationsarten Nutzung von UDDI Zusammenwirken von SOAP, WSDL und UDDI Anwendungsszenarien Existierende Implementierungen Microsoft.NET Programmierung eines Web-Services Programmierung eines Web-Service Clients Sun ONE Programmierung eines Web-Services Programmierung eines Web-Service Clients Zusammenfassung und Ausblick 43 A Glossar 44 B Internetadressen 45 C Abkürzungen und Akronyme 45 Literaturverzeichnis 47 Index 48 2

5 1 Einleitung Der Entwurf und die Realisierung verteilter Systeme ist ein wichtiges Teilgebiet der praktischen Informatik. In dieser Arbeit sollen Web-Services als Möglichkeit zur Implementierung verteilter Systeme näher untersucht werden. Das zweite Kapitel der vorliegenden Arbeit betrachtet dazu die charakteristischen Eigenschaften verteilter Systeme und ihre Implikationen für den Entwurf selbiger. Desweiteren wird das Schema des entfernten Prozeduraufrufs als elementares Prinzip der Applikationskommunikation in einem Netzwerk vorgestellt. Abschließend wird in diesem Kapitel ein kurzer Überblick über die existierenden Technologien zur Unterstützung verteilter Programmierung gegeben. Im dritten Kapitel wird zuerst einen Überblick über den aktuellen Stand der Entwicklung von Web-Services gegeben. Anschließend werden die wichtigsten Standards, namentlich SOAP, WSDL und UDDI, im Detail vorgestellt und ihr Zusammenwirken beim Entwurf von Web-Serviceanwendungen verdeutlicht. Abschließend wird ein kurzer Überblick über die möglichen Anwendungsszenarien von Web-Services gegebenen. Die konkrete Implementierung von Web-Services mit den zwei wichtigsten aktuell verfügbaren Entwicklungsplattformen nämlich Microsoft.NET und Sun ONE wird im vierten Kapitel überblicksartig dargestellt. Kapitel fünf faßt schließlich die Ergebnisse der Arbeit zusammen und gibt einen Ausblick über künftig zu erwartende Entwicklungen. 2 Verteilte Systeme Der Einsatz verteilter Systeme wird vor allem durch den Wunsch bzw. der Nowendigkeit einer gemeinsamen und somit effizienten Ressourcennutzung motiviert. Ein verteiltes System zeichnet sich durch eine lose Kopplung der einzelnen, unter Umständen heterogenen Systemkomponenten aus. Mehrere, evtl. räumlich verteilte, System-Rechner werden dabei durch ein Kommunikationsnetz (z. B. Internet) verbunden. Ein verteiltes System weist außerdem eine gewisse Dynamik auf, da sich zur Laufzeit Komponenten hinzufügen bzw. entfernen lassen. Über das Kommunikationsnetz versenden die Komponenten untereinander Nachrichten. Der Datenaustausch mittels Nachrichten ist notwendig, da den einzelnen Komponenten kein gemeinsamer Speicher zur Verfügung steht, über den die Kommunikation abgewickelt werden kann. Durch die lose Kopplung der Systemkomponenten ist die Laufzeit der versendeten Nachrichten durch das Netz allerdings nicht vorhersagbar. Außerdem gibt es keine Garantie, daß die Sendereihenfolge der Empfangsreihenfolge der Nachrichten entspricht, was z. B. durch unterschiedliche Versandwege durch das Kommunikationsnetz verursacht werden kann. Die Uhrensynchronisation der einzelnen Komponenten kann ebenfalls nur durch einen Nachrichtenaustausch erfolgen, wodurch diese aufgrund der unbekannten Nachrichtenlaufzeit nur approximativ erfolgen kann. 3

6 Die einzelnen Komponenten eines Systems können unabhängig voneinander versagen oder ausfallen. In einem eng gekoppelten System führt der Ausfall einer Komponente (z. B. dem Speicher oder der CPU) praktisch in jedem Fall zu einem Gesamtausfall des Systems. In verteilten Systemen muß der Ausfall einer Komponente dagegen nicht zwangsläufig einen Totalausfall nach sich ziehen. Es gibt aber andere Szenarien, die bei lose gekoppelten Systemen beachtet werden müssen. Es werden drei Arten von Fehlfunktionen einer Komponente unterschieden. Ein Failstop tritt auf, wenn eine Komponente hält bzw. in einem Zustand verharrt und die anderen Systemkomponenten dies beobachten und ggf. entsprechend reagieren können. Analog dazu gibt es den Crash, mit dem Unterschied, daß die Systemkomponenten das Fehlverhalten des defekten Rechners nicht beobachten können. Falls ein Rechner ein beliebiges, inkonsistentes Verhalten aufweist und unterschiedliche Antworten zu unterschiedlichen Zeiten oder an unterschiedliche Anfrager sendet, spricht man von einem Byzantine Failure. Die Isolation und die daraus resultierende Unabhängigkeit der einzelnen Systemkomponenten ermöglichen aber auch die Konstruktion eines fehlertoleranten Systems. Die Fehlertoleranz ermöglicht zum einen das Erkennen und zum anderen das Maskieren und Kompensieren von Fehlern. Sie läßt sich durch Redundanz erreichen, indem bestimmte Teile des Systems repliziert werden. Durch die Unabhängigkeit der Komponenten steigt aber auch die Unsicherheit bei deren Interaktion. D. h. daß der Absender einer Nachricht nichts über den Zustand des Empfängers weiß, bis dieser eine Antwort sendet. Der Empfänger könnte z. B. nicht erreichbar sein oder noch an der Antwort arbeiten. Genauso könnte die Anfrage den Empfänger nicht erreicht haben oder die Antwort kann verloren gegangen sein. Aufgrund dieser Unsicherheiten werden für die Kommunikation häufig Time-Outs verwendet, welche die Operation abrechen, wenn nach einem bestimmten Zeitintervall keine Antwort vom Empfänger eingetroffen ist. Die eigentliche Kommunikation zwischen den einzelnen Komponenten sollte für den Nutzer einer Anwendung möglichst transparent erfolgen. Für diesen Zweck wurde der Remote Procedure Call entwickelt, der den Nachrichtenaustausch über das Kommunikationsnetzwerk kapselt. 2.1 RPC Remote Procedure Call Ein Remote Procedure Call bezeichnet den Aufruf einer Prozedur, die auf einem entfernten Rechner ausgeführt wird. Der Aufruf erfolgt dabei über ein Netzwerk (z. B. Intra- oder Internet), mit dem der aufrufende und der aufgerufene Rechner verbunden sein müssen. Dem RPC liegt das Client/Server-Prinzip zugrunde. Die Kommunikation zwischen dem Client und dem Server kann dabei als ein Request/Response-Paar aufgefaßt werden. Der Client sendet eine Anfrage (Request) an den Server und blockiert die Weiterverarbeitung bis dieser eine Antwort (Response) gesendet hat 1. Der eigentliche Austausch der Nachrichten wird dabei vom unterliegen- 1 Die Blockierung der Verabeitung kann natürlich auch durch ein Time-Out beendet werden, wenn der Server nicht erreichbar ist. 4

7 den Betriebssystem oder einer Laufzeitumgebung durchgeführt. Dazu wird ein sogenannter Stub verwendet, der die Schnittstelle/Signatur der entfernten Prozedur abbildet und lokal zur Verfügung stellt. Die Aufgabe eines Stubs ist es, die Aufrufparameter in eine Nachricht zu verpacken, deren Übertragung an den Server durch das Betriebssystem bzw. die Laufzeitumgebung zu veranlassen und die Rückgabewerte aus der Antwortnachricht an das Programm zurückzugeben. Aus Sicht einer Anwendung bzw. deren Entwickler verhält sich der Stub genauso wie eine einfache lokale Prozedur. Die gesamte Kommunikation geschieht transparent. Der Ablauf eines entfernten Aufrufs erfolgt dabei über das in Abbildung 1 dargestellte Schema. Ein Programm ruft den Stub einer entfernten Prozedur auf. Client Server Client prozess Server prozess Stub Anfrage Antwort Skeleton Betriebssystem/ Laufzeitumgebung Betriebssystem/ Laufzeitumgebung Abbildung 1: Schema eines Remote Procedure Calls. Dieser erzeugt aus allen Parametern eine Nachricht, die durch das Transportnetz an den Server gesendet wird. Auf der Serverseite wird diese durch das unterliegende Betriebssystem bzw. die Laufzeitumgebung entgegengenommen und an den entsprechenden Skeleton den serverseitigen Stub weitergeleitet. Dieser liest die Parameter aus und führt die Prozedur in einem neuen Prozeß auf dem Server aus. Die Rückgabewerte der Prozedur werden anschließend wieder in eine Nachricht verpackt, die an den Client gesendet wird. Die Nachricht wird vom Client empfangen, entpackt und die Werte werden an das lokale Programm übergeben, welches anschließend die Abarbeitung fortsetzt. Allerdings bringt die Kommunikation von Prozessen über ein Netzwerk auch einige Probleme mit sich. Der Client und der Server können in verschiedenen Programmiersprachen implementiert worden sein und auf unterschiedlichen Plattformen 2 laufen. Diese können unterschiedliche Datendarstellungen benutzen, was ggf. eine Umkonvertierung der Daten notwendig macht. Für diese Konvertierungen sind der Stub und der Skeleton verantwortlich. Sie wandeln alle zu übertragenden Parameter in ein für den Nachrichtenversand festgelegtes Format um (Marshalling). Nach Erhalt ein Nachricht extrahieren sie daraus die ent- 2 Das schließt sowohl Betriebssysteme, als auch Hardwareplattformen ein. 5

8 haltenen Werte und wandeln sie in ein für die Plattform/Programmiersprache lesbares Format um (Unmarshalling). Ein anderes Problem ist die Frage, wie Parameter übergeben werden können und müssen. Ein Call-by-Value Parameter stellt dabei kein Problem dar, da eine Kopie des eigentlichen Wertes verwendet wird. Ein Prozeduraufruf der Call-by-Reference Parameter enthält, läßt sich allerdings nicht ohne weiteres in ein verteiltes System übertragen, da Zeiger auf lokale Speicheradressen nur auf einem Rechner Bedeutung haben. In Regel wird diesem Problem mit Serialisierung und Kopieren der Strukturen begegnet. 2.2 Existierende Middlewaretechnologien Als Middleware bezeichnet man im Allgemeinen eine Kombination aus Laufzeitumgebungen und Standards welche verteilte Programmierung unterstützen und dabei die Heterogenität und Verteilung für die nutzenden Anwendungen transparent halten. Middlewaretechnologien unterstützen die Interaktion von Softwarekomponenten über ein Netzwerk, sie gewährleisten dabei Eigenschaften wie Orts- und Verteilungstransparenz. Im Laufe der Jahre wurden zahlreiche Ansätze zur Unterstüzung verteilter Programmierung entwickelt. Die bekanntesten Middlewaretechnologien sind CORBA, RMI sowie DCOM. Ein wichtiger Unterschied ist dabei, daß es sich bei CORBA um eine Spezifikation handelt, deren Bestandteile von diversen Herstellern implementiert wurden, während es sich bei Java-RMI und DCOM um herstellergebundene Implementierungen einer Middlewarelösung handelt. Die Common Object Request Broker Archtitecture (CORBA) ist ein von der Object Management Group (OMG) entwickelter plattformunabhängiger Standard zur Unterstüzung verteilter, objektorientierter Programmierung dessen Bestandteile von diversen Herstellern implementiert wurde. Die Remote Method Invocation (RMI) ist die Java spezifische Variante eines verteilten Objektsystems. Das Distributed Component Object Model(DCOM) ist Microsofts Standard zur Implementierung verteilter OO-Systeme und ermöglicht es COM- Komponenten, über ein Netzwerk zu interagieren. Neben der Transparenz der Netzwerkkommunikation versuchen alle genannten Middlewarelösungen die Heterogenität der Plattformen in einem Netzwerk zu verbergen und somit Interoperabilität zu gewährleisten. Bei Java-RMI ist dies implizit durch den Interpreteransatz der Java-Technologie gewährleistet. Für DCOM existieren außer für die Windows-Plattform noch Implementatierungen für Unix und Apple Plattformen, so daß auch diese Plattformen in ein DCOM-System eingebunden werden können. CORBA-Implementierungen existieren für alle gängigen Plattformen. Zusätzlich können CORBA-Komponenten in Programmiersprachen wie C, C++, Java, COBOL, Smalltalk und Ada entwickelt werden. Die Kommunikationstransparenz in einem verteilten System wird durch Stubs und Skeletons (siehe Abschnitt 2.1) gewährleistet, welche aus den Schnittstellenbeschreibungen der Serverdienste generiert werden können. Die Schnittstellendefinitionen können dabei je nach verwendeter Middlewaretechnologie 6

9 entweder in einer speziellen Beschreibungssprache oder in einer Programmiersprache abgefasst werden. Bei CORBA werden diese Schnittstellendefinitionen in der CORBA Interface Definition Language (CORBA IDL) definiert. interface Vector { Vector add(in Vector x, in Vector y); int size(in Vector x); }; Listing 1: Beispiel einer CORBA-IDL Interface Definition DCOM nutzt die auf der Distributed Computing Environement IDL basierende DCOM IDL. Java RMI definiert keine gesonderte Schnittstellenbeschreibungssprache, sondern erlaubt die Definition der Schnittstellen in der Java Programmiersprache. Die verteilte Objektkommunikation ist dem RPC zwar schematisch ähnlich, um Ortstransparenz zu gewährleisten, muß die Adressierung beziehungsweise die Lokalität der Objekte im Netzwerk jedoch von einer zusätzlichen Komponente verwaltet werden. Ein weiterer wichtiger Unterschied zwischen entfernten Prozeduraufrufen und entfernten Objektaufrufen, stellt die Tatsache dar, daß Objekte an Methoden als Referenzen übergeben werden können. Zur Realisierung dieser Eigenschaften, verwendet man Serverkomponenten, die Mechanismen bereitstellen, um Objekte zu finden. Dies wird in der Regel durch eine tabellarische Zuordnung von Objektrefrenzen und URLs realisiert. Für CORBA realisiert diese und andere Eigenschaften der Object Request Broker (ORB) und stellt somit die Kommunikationsschnittstelle für CORBA Serverobjekte dar. Bei einer CORBA-Kommunikation handelt es sich also immer um eine ORB zu ORB Verbindung. Bei Java-RMI wird diese Rolle von der sogenannten RMI-Registry übernommen. Diese ist ein Serverprogramm, das auf jedem Rechner der verteilte Objekte beherbergt laufen muß. Für DCOM wird die Aufgabe der Objektverwaltung vom Betriebssystem realisiert. Eine wichtige Gemeinsamkeit der genannten Middlewaretechnologien stellt die Tatsache dar, daß sie binäre Protokolle zur Übertragung der auszutauschenden Nachrichten definieren. Im Falle von CORBA heisst dieses Protokoll Internet Inter ORB Protocol (IIOP). Java-RMI verwendet Java Sockets und TCP/IP zur Kommunikation. DCOM ist in der Lage verschiedene Protokolle für den Transport der Nachrichten zu verwenden, so z. B. TCP/IP, UDP, IPX/SPX, NetBIOS and AppleTalk. 3 Web-Services Als Web-Service bezeichnet man im Allgemeinen eine Softwarekomponente, die ihre Funktionalität über Standardinternetprotokolle zur Verfügung stellt. Dieser Lösungsansatz zur Realisierung eines verteilten Systems ist historisch aus den Erfahrungen und Protokollen des verteilten Programmierens gewachsen. Die Nutzung etablierter und standardisierter Internetstandards für Transport und 7

10 Datenstrukturierung stellt dabei die Interoperabilität bei der Kommunikation zwischen Softwarekomponenten sicher. Die Entwicklung der eingesetzten Standards wird vom W3C und anderen Standardisierungsgremien geleitet, wobei die Aufgabe hauptsächlich in der Definition und Pflege bereits etablierter Standards der Web-Servicearchitektur besteht. Die Web-Servicearchitektur des W3C ist dabei kein fest vorgegebener Rahmen, sondern definiert lediglich die minimalen Anforderungen welche eine Softwarekomponente erfüllen muß, um als Web-Service zu gelten. Trotz der Offenheit der Web-Servicearchitektur haben sich die Beschreibunsstandards Simple Object Access Protocoll (SOAP), Web-Service Description Language (WSDL) und Universal Description, Discovery and Integration (UDDI) als Kern dieser Architektur etabliert. Diese Standards basieren auf XML und XML-Schema, so daß XML-fähige Applikationen Dokumente welche auf diesen Standards beruhen verarbeiten können. Zusammen mit der Nutzung von etablierten Netzwerkübertragungsprotokollen ergeben sich somit gute Kommunikationseigenschaften. Mit SOAP steht dabei eine Beschreibungssprache zur strukturierten Datenübertragung zur Verfügung. Es wird heute hauptsächlich zur strukturierten Beschreibung von Nachrichten und ihren Parametern eingesetzt. WSDL ist ein plattformunabhängiger Standard zur Beschreibung der Schnittstellen von Softwarekomponenten. UDDI ist ein Beschreibungsstandard zur Kategorisierung und Beschreibung von Einträgen in einem Verzeichnissystem für Dienste im Allgemeinen. UDDI erlaubt es dabei neben allgemeinen Informationen zur veröffentlichenden Institution, technische Daten zur Beschreibung der angebotenen Dienste zu publizieren. Diese drei Standards werden in den folgenden Abschnitten eingehend behandelt. Abbildung 2 illustriert die Gesamtkonzeption der Web-Servicearchitektur, das prinzipiell offen und erweiterbar ist. Die Komponenten Sicherheit (Security), Kommunikation (Communications) und Verwaltung (Management) sind flexible Bestandteile der Web-Servicearchitektur, d. h. es ist nicht vorgeschrieben welche Standards zur Realisierung dieser Aspekte zu benutzen sind. Ein Web-Service kann also z. B. durch unterschiedliche Transportprotokolle realisert werden. Den Kern der Architektur bilden die zentral dargestellten Komponenten zum Nachrichtenaustausch (Messages), zur Schnittstellenbeschreibung von Services (Descriptions) und zur Komposition von Services zu komplexen Geschäftsprozessen (Processes). Aus der Abbildung ist ersichtlich, daß die genannten Komponenten auf XML und XML-Schema basieren, was eine plattformübergreifende Nutzbarkeit garantiert. Die vom W3C definierte Web-Servicearchitektur soll in erster Linie die Interoperabilität der angebotenen Dienste sicherstellen. Details zur Implementierung oder zu Transport und Strukturierung der Daten werden dabei bewußt nicht definiert. Die Unterstützung des Nachrichtenaustausches von Softwarekomponenten über Netzwerke charakterisieren Web-Services als Middleware für verteilte Systeme. Wichtigste Eigenschaften von Web-Services sind dabei ihre lose Kopplung, ihre Programmierbarkeit über selbstbeschreibende Schnittstellen, sowie Orts- und Protokolltransparenz. 8

11 Security Base Technologies: XML, DTD, Schema Processes Discovery, Aggregation, Choreography... Descriptions Web Service Description (WSDL) Messages SOAP Extensions Reliability, Correlation, Transactions,... Management SOAP Communications HTTP, SMTP, FTP,... Abbildung 2: Konzept der Web-Servicearchitektur. 3.1 SOAP Simple Object Access Protocol Das Simple Object Access Protocol bietet ein standardisiertes, XML-basiertes Protokoll zum Verpacken von Nachrichten, die zwischen Applikationen ausgetauscht werden. Es bietet einen Mechanismus zum Austausch typisierter Daten in einem dezentralen, verteilten Umfeld und läßt sich leicht mit verschiedenen Übertragungsprotokollen nutzen. Die Grundidee ist, daß zwei Anwendungen Informationen übertragen können, ohne daß auf das Betriebssystem, die Programmiersprache oder andere technische Implementierungsdetails Rücksicht genommen werden muß. Für diesen Informationsaustausch wird dabei nichts weiter benötigt als eine Nachricht, die so codiert ist, daß beide Anwendungen sie verstehen können. Eine versendete Nachricht kann dabei jede beliebige Information enthalten: eine Suchanfrage an eine Suchmaschine oder ein Warenhaus, die Suche oder Buchung eines Fluges oder einer Zugfahrt, die Abfrage eines Aktienkurses, eine Warenbestellung etc. Ursprünglich begann Microsoft 1998 mit der Entwicklung von SOAP. Später beteiligten sich andere Firmen wie IBM und SAP an der Standardisierung. Seit September 2000 wird die Weiterentwicklung des Standards durch eine Arbeitsgruppe des W3C koordiniert, wodurch Offenheit und Herstellerunabhängigkeit gewährleistet ist. Die aktuelle Version ist SOAP 1.2 ([SOAP Pt. 1] und [SOAP Pt. 2]) Aufbau einer SOAP-Nachricht Eine SOAP-Nachricht besteht aus einem XML-Dokument, in dem ein SOAP- Envelope, ein SOAP-Header und ein SOAP-Body definiert werden. Abbildung 3 zeigt die allgemeine Struktur einer SOAP-Nachricht. 9

12 Envelope Header Header Block Body Fault Abbildung 3: Struktur einer SOAP-Nachricht. Das Envelope-Element ist das Wurzelelement des Dokuments und beinhaltet ein optionales Header- und ein erforderliches Body-Element. Das Header-Element bietet einen Erweiterungsmechanismus, der es erlaubt, Informationen in einer Nachricht zu transportieren, die nicht direkt mit dem Nachrichteninhalt verknüpft sind. Der Header kann jeden gültigen, wohlgeformten XML-Code enthalten, der durch einen Namensraum qualifiziert ist. Die direkten Unterelemente des Headers werden Headerblocks genannt. Die genaue Funktion und Verarbeitung der Header-Elemente wird in Abschnitt behandelt. Das Body-Element ist in jeder Nachricht zwingend erforderlich. Der Body kann analog zum Header jeden gültigen, wohlgeformten und namensraumqualifizierten XML-Code enthalten, welcher die eigentliche Nachricht an den Empfänger, d. h. eine SOAP-Applikation, darstellt. Das folgende Beispiel zeigt den Envelope einer SOAP-Nachricht mit zwei Headerblöcken, die jeweils durch ihre eigenen Namensräume (ns1 und ns2) spezifiziert werden. Die eigentliche Nachricht wird im Body im message-element übertragen. Dieses wird durch den Namensraum xyz gekennzeichnet. <SOAP:Envelope xmlns:soap=" <SOAP:Header> <ns1:headerblock1 xmlns:ns1=" </ns1:headerblock1> <ns2:headerblock2 xmlns:ns2=" </ns2:headerblock2> </SOAP:Header> <SOAP:Body> <xyz:message xmlns:xyz=" </xyz:message> </SOAP:Body> 10

13 </SOAP:Envelope> Fehlerbehandlung Listing 2: Struktur eines SOAP-Envelopes. Die SOAP-Spezifikation bietet einen Mechanismus auf Fehler, die bei der Verarbeitung einer Nachricht auftreten, zu reagieren und den Absender der fehlerhaften Nachricht darüber zu informieren. Die auftretenden Fehler werden als SOAP-Faults bezeichnet. Die Beschreibung eines Fehlers muß in einem Fault-Element übertragen werden, welches in den Body einer Nachricht eingebettet wird. Die innere Struktur des Fault-Elements wird in Abbildung 4 gezeigt. Es enthält die erforderli- Fault Code Value Subcode Reason Text Detail Abbildung 4: Struktur eines SOAP-Faults. chen Code- und Reason- und das optionale Detail-Element. Das Code-Element enthält ein Value-Element, welches die Art eines Fehlers angibt. Die SOAP-Spezifikation definiert feste Fehlercodes, die in diesem Value- Element verwendet werden müssen. Das optionale Subcode-Element kann genutzt werden, um die Fehlerangabe genauer zu spezifizieren. Es ist hierarchisch definiert und enthält wiederum ein erforderliches Value- und ein optionales Subcode-Element. In den eingeschachtelten Value-Elementen lassen sich applikationsspezifische Fehlercodes übermitteln. Reason wird verwendet um eine für den Nutzer verständliche Fehlermeldung anzugeben. Ein Reason-Element enthält ein oder mehr Text-Elemente, die durch verschiedene lang-attribute 3 unterschieden werden. Auf diese Weise lassen sich die Fehlermeldungen in verschiedenen Sprachen übertragen. Das folgende Beispiel zeigt einen SOAP-Fault, in dem eine Fehlermeldungen für den us-amerikanischen (en-us) und eine für den deutschen (de-de) Raum angegeben wurden. 3 von language (engl.) = Sprache 11

14 <SOAP:Envelope xmlns:soap=" <SOAP:Body> <SOAP:Fault> <SOAP:Code>...</SOAP:Code> <SOAP:Reason> <SOAP:Text xml:lang="en-us"> Missing parameter</soap:text> <SOAP:Text xml:lang="de-de"> Fehlender Parameter</SOAP:Text> </SOAP:Reason> <SOAP:Detail>...</SOAP:Detail> </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> Listing 3: SOAP-Fault mit mehrsprachiger Fehlermeldung. Der Inhalt eines Detail-Elements ist applikationsabhängig und wird durch einen eigenen Namesraum identifiziert. Darin lassen sich weitere applikationsspezifische Details zum aufgetretenen Fehler hinterlegen. SOAP unterscheidet zwischen dem Erzeugen eines Faults und der Übertragung des Faults an den Absender einer Nachricht, damit dieser von der Information Gebrauch machen kann. Die Möglichkeit den Absender über den Fehler zu informieren hängt von der Methode ab, mit der die Nachricht transportiert wird. Mögliche Transportmechanismen und die damit verbundene Möglichkeit, den Absender über Fehler zu informieren, werden in Abschnitt behandelt. Nachrichtencodierung Applikationen, die mit SOAP-Nachrichten arbeiten, müssen allerdings nicht nur in der Lage sein, den generellen Aufbau einer Nachricht zu verstehen, sondern sie müssen auch die darin enthaltenen Informationen und Werte richtig interpretieren können. Für diesen Zweck definiert die SOAP-Spezifikation Codierungsstile (Encoding Styles). Ein Codierungsstil ist eine Menge von Regeln, die exakt festlegen, wie die zu übertragenden Datentypen einer Nachricht in einer allgemein verbindlichen Weise zu codieren sind. SOAP definiert einen Standardcodierungsstil. Dieser wird durch die URI eindeutig bestimmt. Die Benutzung dieses Stils ist jedoch nur optional, denn SOAP gestattet die Nutzung eines beliebigen applikationsspezifischen Codierungsstils für die Codierung der Daten einer Nachricht. Für diesen Zweck wurde das encodingstyle-attribut eingeführt, das in jedem Headerblock und jedem Unterelement der Body und Detail-Elemente verwendet werden kann. Jedes Element kann durch dieses Attribut einen Codierungsstil definieren, der für alle seine Unterelemente gilt. Ein eingeschachteltes Element kann die Codierungsstilvorschrift eines übergeordneten Elementes überschreiben, indem es einen eigenen Stil in seinem encodingstyle-attribut definiert. 12

15 Dieser gibt dann die Codierung aller Unterelemente des besagten Elementes an. <SOAP:Envelope xmlns:soap=" <SOAP:Body> <ns:message xmlns:ns=" SOAP:encodingStyle= " <part1> <subpart1>...</subpart1> </part1> <part2 SOAP:encodingStyle= " </part2> <part3>...</part3> </ns:message> </SOAP:Body> </SOAP:Envelope> Listing 4: SOAP-Nachricht mit applikationsspezifischen Codierungsstil. Im Beispiel wird für das message-element im SOAP-Body der Codierungsstil definiert, der somit für die Elemente part1, subpart1, part3 und deren Unterelemente gilt. Das Element part2 überschreibt diesen Stil mit dem SOAP-Standardcodierungsstil, indem es ein eigenes encodingstyle-attribut spezifiziert Nachrichtenverarbeitung Die Verarbeitung einer SOAP-Nachricht erfolgt auch wenn es sich dabei eigentlich um eine einfache Einwegübertragung von einem Absender zu einem bestimmten Empfänger handelt durch eine Schritt-für-Schritt -Versendung entlang eines sogenannten Nachrichtenpfades (Message Path). Auf diesem Pfad können verschiedene Zwischenverarbeitungsstellen durchlaufen werden, welche Absender "initial sender" Empfänger "ultimate receiver" "intermediary" "intermediary" Abbildung 5: Nachrichtenpfad einer SOAP-Nachricht. 13

16 als SOAP-Nodes bezeichnet werden. Wie aus Abbildung 5 ersichtlich wird, gibt es drei Arten von SOAP-Nodes. Der Absender der Nachricht wird als initial sender bezeichnet. Er ist der erste Knoten auf dem Nachrichtenpfad, der die Nachricht erzeugt und auf den Weg schickt. Der Empfänger der Nachricht und damit letzte Knoten auf dem Pfad ist der ultimate receiver. Zwischen dem Anfangs- und Endknoten des Nachrichtenpfades können beliebig viele weitere Knoten liegen, welche intermediary genannt werden. Es ist jedoch nicht erforderlich, daß ein oder mehr intermediary vorhanden sind. Ein zwischengeschalteter intermediary-knoten entspricht einem Web-Service, der zwischen initial sender und ultimate receiver im Nachrichtenpfad liegt und der Transaktion zwischen diesen beiden zusätzliche Funktionalitäten hinzufügt. Eine solche Funktion könnte z. B. ein Service zur Authentifikation der Kommunikationspartner oder zur Abwicklung der Bezahlung des genutzen Dienstes sein. Alle auf dem Nachrichtenpfad vorhandenen Knoten, erhalten nacheinander die versendete Nachricht, worauf sie diese verarbeiten und ggf. verändern können. Anschliessend wird die bearbeitete Nachricht an den nächsten Knoten im Pfad versandt. Da die Konstruktion des Nachrichtenpfades nicht in der SOAP-Spezifikation definiert wird, gibt es keine offizielle Standardmethode zur Angabe des Pfades. Es existieren aber verschiedene SOAP-Erweiterungen, die diese Lücke füllen. Eine davon ist WS-Routing 4 von Microsoft. Für die Verarbeitung der SOAP-Nachricht durch die einzelnen Knoten werden der Header und die darin enthaltenen Headerblocks verwendet. Die Headerblöcke einer Nachricht können durch jeden Knoten untersucht, verändert und gelöscht werden. Außerdem können Knoten einer Nachricht neue Headerblöcke hinzufügen. Die Nachricht, die der Empfänger erhält, kann sich also von der ursprünglich gesendeten Nachricht unterscheiden. Des weiteren kann ein Knoten auch einen Fault erzeugen und an den Absender schicken, falls bei der Verarbeitung ein Fehler auftritt. In diesem Fall kann es passieren, daß der eigentliche Empfänger die Nachricht nie erhält, da der Fehler schon bei einem vorhergehenden Knoten auftrat. a)<soap:envelope xmlns:soap=" <SOAP:Header> <ns1:firstblock xmlns:ns1=" </ns1:firstblock> <ns2:secondblock xmlns:ns2=" </ns2:secondblock> </SOAP:Header> <SOAP:Body>...</SOAP:Body> </SOAP:Envelope>

17 b)<soap:envelope xmlns:soap=" <SOAP:Header> <ns2:secondblock xmlns:ns2=" </ns2:secondblock> <xyz:thirdblock xmlns:xyz=" </xyz:thirdblock> </SOAP:Header> <SOAP:Body>...</SOAP:Body> </SOAP:Envelope> Listing 5: Nachricht vor (a) und nach (b) Verarbeitung in einem Knoten. Das Beispiel zeigt die Veränderung der Header-Informationen einer SOAP- Nachricht durch die Verarbeitung in einem SOAP-Node. Vor der Verarbeitung (a) enthält der Header die zwei Blöcke firstblock und secondblock welche durch ihre spezifischen Namensräume (ns1 und ns2) beschrieben werden. Während der Verabeitung im Knoten wird der Block firstblock entfernt und ein der neue Block thirdblock kommt hinzu. secondblock bleibt dabei unverändert. Das Ergebnis dieser Verarbeitung ist in (b) zu sehen. Auf diese Weise lassen sich Informationen, die für nachfolgende Knoten irrelevant sind, entfernen und neue bzw. veränderte Informationen, an die nächsten Knoten weitergeben. Ein intermediary der die Bezahlung eines genutzten Service abwickelt, könnte so z. B. einen neuen Header einfügen, der dem Empfänger signalisiert, daß die Bezahlung erfolgt und der gewünschte Dienst auszuführen ist. Rolle eines Headers Die tatsächliche Verarbeitung eines Headerblocks durch einen Knoten hängt von der Rolle (role) ab, die ihm zugewiesen wird. Diese wird durch das optionale role-attribute in der Headerblock-Definition bestimmt. Jeder Knoten, der die Rolle eines Headerblocks unterstützt, kann diesen verarbeiten. Ein Knoten kann dabei mehrere Rollen unterstützen. Die SOAP-Spezifikation definiert die drei Standardrollen none, next und ultimatereceiver. Darüber hinaus lassen sich beliebige anwendungsspezifische Rollen erstellen, die von den entsprechenden Knoten verstanden werden müssen. <SOAP:Envelope xmlns:soap=" <SOAP:Header> <ns1:firstblock xmlns:ns1=" SOAP:role= " 15

18 </ns1:firstblock> <ns2:secondblock xmlns:ns2=" SOAP:role=" </ns2:secondblock> <ns3:thirdblock xmlns:ns3=" </ns3:thirdblock> </SOAP:Header> <SOAP:Body>...</SOAP:Body> </SOAP:Envelope> Listing 6: SOAP-Header mit verschiedenen Rollen. Das Beispiel zeigt eine SOAP-Nachricht mit drei Headerblocks. Der erste Block firstblock definiert die Rolle next. Diese ist die einzige Rolle, die von jedem SOAP-Knoten verstanden werden muß. Die Annahme dabei ist, daß ein durch next ausgezeichneter Headerblock durch den nächsten Knoten untersucht und verarbeitet wird. Der Block wird also in der Nachricht an den nächsten Knoten weiter versendet. Der zweite Headerblock secondblock hat die selbstdefinierte Rolle die z. B. von einem Knoten verarbeitet werden kann, der gesendete Nachrichten protokolliert. Dem dritten Headerblock thirdblock wurde keine Rolle zugewiesen, wodurch er die Standardrolle ultimatereceiver spielt. Er ist also für den eigentlichen Empfänger der Nachricht bestimmt. Der Body einer Nachricht besitzt ebenfalls kein role-attribut, da er immer an den ultimate receiver adressiert ist. Ein Headerblock, der die Rolle none besitzt, sollte überhaupt nicht durch einen Knoten untersucht werden. Die einzige Ausnahme dafür ist, wenn der Block durch einen anderen Block referenziert wird, welcher durch einen Knoten verarbeitet wird. Erforderliche Header Nachdem ein Knoten anhand des role-attributes alle Headerblöcke identifiziert hat, die durch ihn verarbeitet werden können, bestimmt das ebenfalls optionale Attribut mustunderstand, wie weiter zu verfahren ist. Falls das mustunderstand-attribute auf "true" gesetzt ist, muß ein Knoten, der eine Rolle unterstützt, den Headerblock entsprechend seiner Spezifikation verarbeiten. Dazu ist es notwendig, daß der Knoten diesen Block auch versteht. Auf diese Weise lassen sich Blöcke definieren, deren Verarbeitung zwingend erforderlich ist. Falls ein Knoten einen erforderlichen Block nicht versteht bzw. nicht verarbeiten kann, muß er einen Fault erzeugen, wodurch die Weiterverarbeitung der Nachricht beendet und die Nachricht nicht an den nächsten Knoten im Nachrichtenpfad weitergeleitet wird. Analog zum role-attribut ist auch kein mustunderstand-attribut für den Body einer SOAP-Nachricht definiert. Es wird allerdings gefordert, daß der 16

19 ultimate receiver den Body versteht und verarbeiten kann. Ist dies nicht der Fall, müßte ebenfalls ein Fault erzeugt werden. <SOAP:Envelope xmlns:soap=" <SOAP:Header> <ns1:firstblock xmlns:ns1=" SOAP:role= " </ns1:firstblock> <ns2:secondblock xmlns:ns2=" SOAP:role=" SOAP:mustUnderstand="true">... </ns2:secondblock> <ns3:thirdblock xmlns:ns3=" </ns3:thirdblock> </SOAP:Header> <SOAP:Body>...</SOAP:Body> </SOAP:Envelope> Listing 7: SOAP-Header mit erforderlichen Headerblöcken. Im gegebenen Beispiel ist der Headerblock secondblock als mustunderstand gekennzeichnet. Ein Knoten, der die Rolle unterstützt, muß diesen Block also verarbeiten. Der Empfänger der Nachricht kann neben dem Body, den er verarbeiten muß den Headerblock thirdblock verarbeiten, da dieser das mustunderstand- Attribut nicht definiert. Des weiteren kann er ebenfalls den ersten Block first- Block verarbeiten, da dieser die Rolle next hat, aber ebenfalls kein mustunderstand fordert. Headerweiterleitung SOAP definiert ein weiteres optionales Attribut für Headerblöcke, welches angibt, ob ein Headerblock an den nächsten Knoten weitergeleitet werden muß, wenn es nicht vom bearbeitenden Knoten selbst verarbeitet wird. Diese Angabe wird mit dem relay-attribut gemacht. Es ist zu beachten, daß SOAP fordert, daß ein Headerblock, der von einem Knoten verarbeitet wird, aus der Nachricht entfernt werden muß 5. Blöcke, die zwar von einem Knoten verarbeitet werden könnten, aber nicht verarbeitet werden, müssen standardmäßig ebenfalls aus der Nachricht entfernt werden. Ein Headerblock, dessen relay-attribut "true" ist, muß weitergeleitet werden, falls der Knoten ihn zwar versteht, ihn aber nicht selbst verarbeitet. 5 Es steht allerdings frei den Block anschliessend wieder (verändert oder in seiner ursprünglichen Form) in die Nachricht einzufügen. 17

20 <SOAP:Envelope xmlns:soap=" <SOAP:Header> <ns2:secondblock xmlns:ns2=" SOAP:role=" SOAP:relay="true">... </ns2:secondblock> </SOAP:Header> <SOAP:Body>...</SOAP:Body> </SOAP:Envelope> Listing 8: SOAP-Header mit Angaben zur Weiterleitung. Der Headerblock secondblock muß durch einen Knoten an den nächsten weitergeleitet werden, falls dieser ihn nicht unterstützt bzw. ihn nicht selbst verarbeitet. Sollte der Knoten den Block aber verarbeiten, muß er ihn entsprechend der Spezifikation aus der Nachricht entfernen. Die folgende Tabelle faßt zusammen, wie ein SOAP-Node Headerblöcke mit den gegebenen Rollen weiterleitet. Rolle Headerblock Name Unterstützt Verarbeitet Weitergeleitet next Ja Ja Nein* Nein Nein** benutzerdefiniert Ja Ja Nein* Nein Nein** Nein Ja ultimatereceiver Ja Ja Nein none Nein Ja * außer erneut eingefügt ** außer relay="true" Kommunikationsmuster von SOAP Ein Kommunikationsmuster (MEP Message Exchange Pattern) ist eine Schablone, die angibt wie der Nachrichtenaustausch zwischen SOAP-Knoten abläuft. Es handelt sich dabei um eine Art Spezifikation, die den gesamten Ablauf der Kommunikation beschreibt. Diese Spezifikation beschreibt neben dem Namen, der das Muster identifiziert den gesamten Lebenszyklus der Interaktion der Kommunikationspartner. Desweiteren beschreibt sie die Beziehungen der während des Lebenszyklus ausgetauschten Nachrichten zueinander (z. B. wird eine Antwort erst nach einer Anfrage gesendet und nicht umgekehrt) und definiert das Ende der Interaktion für den regulären und den irregulären Fall. Die SOAP-Spezifikation definiert verschiedene Kommunikationsmuster, die für den SOAP-Nachrichtenaustausch genutzt werden können. Zwei davon sind das Request/Response- und das Response-Muster. 18

21 Request/Response Das Request/Response-Muster beschreibt die Interaktion, in der auf eine Anfrage in Form einer SOAP-Nachricht (Request) eine weitere SOAP-Nachricht als Antwort (Response) an den Absender der Anfrage gesendet wird. Falls bei dieser Interaktion keine Fehler auftreten, besteht das Muster also aus exakt zwei SOAP-Nachrichten. Im Normalfall wird die Anfrage-Nachricht an den Empfänger gesendet. Nach der erfolgreichen Bearbeitung der Anfrage sendet dieser eine Antwort- Nachricht an den eigentlichen Absender zurück. Mögliche Fehler können beim Request/Response-Muster während der Übertragung oder während der Verarbeitung der Anfrage auftreten. Diese Fehler können entweder von keinem, einem oder beiden beteiligten SOAP-Knoten behandelt werden. Während einer Kommunikation im Request/Response-Muster bezieht sich eine Antwort immer auf die vorher gesendete Anfrage. Es gibt keine Aussagen über die Beziehungen mehrerer verschiedener Anfragen bzw. Antworten zueinander. Response Das Response-Muster entspricht im Grunde dem Request/Response-Muster. Der einzige Unterschied ist, daß die Anfrage nicht in Form einer SOAP-Nachricht gesendet wird. Der Empfänger der Anfrage muß diese in einer anderen Form entgegen nehmen (können). Die Antwort auf die gesendete Anfrage wird als SOAP-Nachricht an den Absender der Anfrage gesendet. Das Muster besteht also ebenfalls aus zwei Nachrichten, von denen allerdings nur eine eine SOAP- Nachricht ist. Die Fehlerquellen und die Beziehung der Anfrage und der Antwort ergeben sich daraus analog zum Request/Response-Muster. Es ist allerdings zu beachten, daß für die Anfrage kein Nachrichtenpfad (siehe Abschnitt auf S. 13) nutzbar ist, da sie keinen SOAP-Envelope verwendet, in dem die entsprechenden Header definiert werden können. SOAP ermöglicht die Definition mehr oder wenig beliebiger (oder vielmehr realisierbarer) Kommunikationsmuster. Denkbar wären zum Beispiel eine Anfrage, die zwei (zeitversetzte) Antworten zur Folge hat, oder eine andauernde Folge von (ebenfalls zeitversetzten) Antworten auf eine Anfrage, die erst endet, wenn eine zweite Anfrage gesendet wird SOAP-RPC Ein Designziel von SOAP war, die Funktionalität von RPC mit der Flexibilität von XML zu kombinieren. Aus diesem Grund definiert die SOAP-Spezifikation ein einheitliches Format für den Aufruf und die Antwort eines RPC. Um eine Methode an einem SOAP-Knoten via SOAP-RPC aufrufen zu können, benötigt man die Adresse, an dem der Knoten auffindbar ist, den Namen der aufzurufenden Methode und die Bezeichner und Typen aller Ein- und Ausgabeparameter, sowie des Rückgabewertes, dieser Methode. 19

22 Das folgende Beispiel zeigt einen einfachen SOAP-RPC-Aufruf der dospellingsuggestion-methode der Google Web-Service API. <SOAP:Envelope xmlns:soap=" <SOAP:Body> <ns:dospellingsuggestion xmlns:ns="urn:googlesearch"> <key> </key> <phrase>britney speers</phrase> </ns:dospellingsuggestion> </SOAP:Body> </SOAP:Envelope> Listing 9: Aufruf der dospellingsuggesion-methode von Google. Das Beispiel zeigt, daß der RPC direkt im SOAP-Body transportiert wird. Er wird als XML-Konstrukt definiert, dessen Wurzelelement der Name der Methode selbst ist, in diesem Fall dospellingsuggesion. Die Methode erwartet zwei Eingabeparameter 6, die in den Elementen key und phrase übermittelt werden. Als Antwort auf eine Anfrage wird wiederum eine SOAP-Nachricht gesendet, die den Rückgabewert der Methode enthält. Diese enthält im Body wieder ein XML-Konstrukt, dessen Wurzelelement nach Konvention aus dem Namen der Methode zzgl. dem Zusatz "Response" besteht 7. In diesem Element befinden sich die Rückgabewerte. Das Beispiel zeigt die Antwort-Nachricht auf die vorher gezeigte Anfrage für eine Rechtschreibkorrektur der Google API. <SOAP:Envelope xmlns:soap=" <SOAP:Body> <ns:dospellingsuggestionresponse xmlns:ns="urn:googlesearch"> <return>britney spears</return> </ns:dospellingsuggestionresponse> </SOAP:Body> </SOAP:Envelope> Listing 10: Antwort vom Google dospellingsuggesion-dienst. Falls während der Verarbeitung des RPC ein Fehler auftritt, wird ein entsprechender SOAP-Fault erzeugt und an den Absender der Nachricht gesendet Transport von SOAP-Nachrichten Als standardisiertes Protokoll zum Verpacken von Nachrichten setzt SOAP auf die Netzwerk- und Transportschichten auf. Es ist also irrelevant, welche Transportmechanismen für den eigentlichen Versand verwendet werden, wodurch SOAP sehr flexibel bzgl. der Art und dem Ort des Einsatzes ist. 6 Der Parameter key erwartet den Authentifizierungsschlüssel des Nutzers des Web-Services. phrase gibt den Begriff an, für den der Rechtschreibvorschlag gemacht werden soll. 7 Diese Namenskonvention ist sozusagen ein ungeschriebenes Gesetz. Allerdings ist es nicht zwingend notwendig sich daran zu halten. 20

23 SOAP über HTTP Die gebräuchlichste Form des Austausches von SOAP-Nachrichten ist die Übertragung über HTTP. Der HTTP GET Mechanismus kann dabei für das Response- Verfahren genutzt werden. HTTP POST bietet sich für das Request/Responseund das SOAP-RPC-Verfahren an. Es gibt aber noch weitere Vorteile, die HTTP als Übertragungsprotokoll mit sich bringt. Es ist weltweit verbreitet und verfügbar. HTTP-Server sind weit entwickelt und unter großen Lasten nutzbar. Desweiteren lassen sich existierende Sicherheitskonzepte, wie z. B. Authentication oder SSL in HTTPS, für den SOAP-Nachrichtenaustausch nutzen. Aufgrund dieser Vorteile und der hohen Nutzbarkeit ist der Transport über HTTP der einzige, der direkt in der SOAP-Spezifikation standardisiert wird. Es existieren zwei Möglichkeiten eine Anfrage an einen Web-Service über HTTP zu stellen. Für das Response-Verfahren läßt sich ein einfaches HTTP GET verwenden, welches die URI des Dienstes mit eventuell vorhandenen Parametern enthält. Das folgende Beispiel enthält ein Beispiel für eine Anfrage an den dospellingsuggesion-dienst von Google 8. Das Accept-Feld signalisiert dem Server dabei, daß der Client als Antwort eine SOAP-Nachricht erwartet. GET /search/beta2/dospellingsuggestion?key=&phrase= HTTP 1.1 Host: api.google.com Accept: application/soap+xml Listing 11: Anfrage mit HTTP GET. Das Request/Response- und das SOAP-RPC-Verfahren können durch HTTP POST realisiert werden. Die SOAP-Nachricht wird dafür in den HTTP-Request eingekapselt. Die Abbildung zeigt einen Ausschnitt einer Anfrage an den Google dospellingsuggesion-dienst mittels HTTP POST. POST /search/beta2 HTTP/1.1 Host: api.google.com Content-Type: application/soap+xml; charset="utf-8" Content-Length:??? SOAPAction: "urn:googlesearch#dospellingsuggestion" <?xml version="1.0"?> <SOAP:Envelope xmlns:soap=" </SOAP:Envelope> Listing 12: Anfrage mit HTTP POST Der HTTP-Header SOAPAction verweist darauf, daß die Anfrage einen SOAP- Request darstellt. Sein Wert ist beliebig, ist aber eigentlich dafür gedacht, dem 8 Diese Anfrage würde im wahren Leben nicht funktionieren, da der Google-Dienst nicht via HTTP GET ansprechbar ist. Statt dessen erhält man eine freundliche (HTML-)Nachricht, doch bitte HTTP POST zu verwenden. 21

24 HTTP-Server mitzuteilen, welche Operation der Web-Service-Client aufrufen möchte, noch bevor der SOAP-Envelope gelesen wurde. Auf diese Weise lassen sich ungültige bzw. inakzeptable Anfragen sofort herausfiltern. Der SOAP-Response des Servers wird analog in den HTTP-Response eingebettet. Dem Server stehen für die Antwort zusätzlich die HTTP-Statuscodes zur Verfügung. Die Abbildung zeigt die Antwort auf eine erfolgreiche Anfrage mit dem Statuscode 200 OK. HTTP/ OK Content-Type: application/soap+xml; charset="utf-8" Content-Length:??? <?xml version="1.0"?> <SOAP:Envelope xmlns:soap=" </SOAP:Envelope> Listing 13: Antwort des Web-Service. In Falle eines Fehlers bei der Verarbeitung einer Anfrage fordert die SOAP- Spezifikation, daß der HTTP-Response den Statuscode 500 Internal Server Error zusammen mit dem entsprechenden SOAP-Fault enthält. HTTP/ Internal Server Error Content-Type: application/soap+xml; charset="utf-8" Content-Length:??? <?xml version="1.0"?> <SOAP:Envelope xmlns:soap=" <SOAP:Body> <SOAP:Fault>... </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> SOAP über SMTP Listing 14: Fehlermeldung eines Web-Services. Die Nutzung von SMTP als Übertragungsprotokoll ermöglicht einen asynchronen Datenaustausch von SOAP-Nachrichten. Diese lassen sich z. B. als Text oder Anhang einer versenden. Die Abbildung zeigt eine SOAP-Nachricht, die als Text einer versendet wird. From: To: Subject: Serve Me 22

25 Date: Thu, 05 Feb :00:00 GMT Message-Id: Content-Type: application/soap+xml <?xml version="1.0"?> <SOAP:Envelope xmlns:soap=" </SOAP:Envelope> Listing 15: Versand einer SOAP-Nachricht als . Bei dieser Form der Nachrichtenübermittlung ist zu beachten, daß keine Garantie für die Übertragung der Nachricht gegeben ist. SMTP bietet zwar Mechanismen zur Benachrichtigung über den Erfolg bzw. Mißerfolg einer Übertragung, diese werden aber in einer separaten an den Absender der Nachricht versendet. Die Benachrichtigung erfolgt also auf dem SMTP- und nicht auf dem SOAP-Level. Die Client-Applikation bzw. der Nutzer muß eine solche Benachrichtigung selbst der gesendeten Nachricht zuordnen können. Die gleiche Zuordnung ist notwendig, wenn eine Antwort auf eine Nachricht in einer neuen empfangen wird. Der Versand von SOAP-Nachrichten über SMTP empfiehlt sich demzufolge hauptsächlich für Einweg -Nachrichten, die keine Antwort erwarten. Weitere Protokolle Es ist eine Vielzahl von Szenarien denkbar, in denen sich SOAP zur Nachrichtenübertragung verwenden läßt. Als Beispiel für die hohe Flexibilität von SOAP sei auf die SOAP::Lite Bibliothek 9 für Perl verwiesen, welche die Protokolle HTTP, HTTPS, FTP, TCP, SMTP, POP3, MQSeries und Jabber unterstützt. 3.2 WSDL Web-Service Description Language Jeder Web-Service läßt sich als Objekt verstehen, das verschiedene Methoden zur Verfügung stellt, auf die zugegriffen werden kann. Um diese Zugriffe zu ermöglichen und zu automatisieren, ist eine standardisierte Beschreibung der Schnittstelle zum Web-Service notwendig. Hierfür wird die Web-Service Description Language verwendet. WSDL ist eine XML-basierte Sprache zur Beschreibung von Web-Services. Sie beschreibt die Methodenschnittstelle des Web-Services, nicht aber den Web- Service selbst. Neben der Methodenspezifikation beinhaltet sie auch technische Daten, wie die eigentliche Lage des Dienstes und an welche Transportprotokolle er gebunden ist. Die Weiterentwicklung von WSDL wird durch das W3C kooridiniert. WSDL liegt aktuell in der Version 2.0 vor und gliedert sich in drei Teile. Die Core Language ([WSDL Pt. 1]) mit allen wesentlichen Strukturierungselementen,