Mit WSDL Webdienste dokumentieren

Transkript

1 Mit WSDL Webdienste dokumentieren 86 WSDL-Dokumentsyntax 106 Das WSDL-Dokument des Webdienstes Rechner 110 Zusammenfassung Im vorherigen Kapitel haben Sie erfahren, wie man ein Schema erstellt, um das Format einer SOAP- Nachricht zu beschreiben. Mit XML Schema können Sie das Layout einer Nachricht und den Typ der enthaltenen Daten beschreiben und mit dem daraus resultierenden Schema kann die Nachricht, die der Webserver empfängt, validiert werden. XML Schema allein kann einen Webdienst aber nicht vollständig beschreiben. Angenommen, ich habe den Webdienst Rechner erstellt. Der Webdienst verwendet zwei Methoden, Add und Subtract. Beide Methoden nehmen zwei ganze Zahlen entgegen und geben eine einzelne ganze Zahl als Ergebnis zurück Add gibt die Summe zweier ganzer Zahlen zurück und Subtract gibt die Differenz zwischen zwei Zahlen zurück. Um zu beschreiben, wie ein Client mit meinem Webdienst interagieren kann, definiere ich ein Schema für Nachrichten, die zwischen dem Client und dem Server ausgetauscht werden. Mein Schema enthält eine komplexe Typdefinition für die Anfrage- und Antwortnachricht für die Methoden Add und Subtract. Denken Sie daran, dass das Ziel nicht darin bestehen kann, dass Entwickler nicht über Schemadefinitionen brüten und zu entschlüsseln versuchen, wie mit einem Webdienst interagiert wird. Stattdessen möchte ich meinen Webdienst so beschreiben, dass ein Tool ihn entziffern und einen Proxy im Namen des Clients erzeugen kann. Was muss ein Client außer den Informationen, die vom Schema geliefert werden, wissen, um Methoden aufzurufen, die vom Webdienst Rechner offen gelegt werden? Da der Text einer SOAP-Nachricht alles enthalten kann, was den XML-Code nicht ungültig macht, können einzelne SOAP-Nachrichten kombiniert werden, um eine große Palette von Nachrichtenaustauschmustern zu unterstützen. Die Nachrichtenaustauschmuster für den Webdienst Rechner sind recht einfach, aber eine formale Zuordnung zwischen den Addieren- und Subtrahieren-Anfragenachrichten und ihren zugeordneten Antwortnachrichten sollte jede mögliche Mehrdeutigkeit ausräumen. Eine formale Beschreibung des Nachrichtenmusters ist für komplexere Webdienste sogar noch wichtiger. Einige Webdienste nehmen vielleicht nur eine Anfrage an, senden aber keine entsprechende Antwort zurück an den Client. Andere senden vielleicht nur Nachrichten an den Client. 85

2 Das Schema enthält auch keine Informationen darüber, wie auf den Webdienst zugegriffen wird. Da SOAP protokollunabhängig ist, können Nachrichten zwischen Client und Server auf vielerlei Arten ausgetauscht werden. Woher wissen Sie, ob Sie eine Nachricht über HTTP, SMTP oder ein anderes Transportprotokoll senden sollen? Und woher kennen Sie die Adresse, an die die Nachricht gesendet werden soll? Die Web Service Description Language (WSDL) ist ein XML-basierter Dialekt, der über das Schema gelegt wird, das den Webdienst beschreibt. Ein WSDL-Dokument bietet einem Client die Informationen, die er benötigt, um mit dem Webdienst zu interagieren. WSDL ist erweiterbar und kann verwendet werden, um praktisch jeden Netzwerkdienst zu beschreiben, darunter auch SOAP über HTTP und sogar Protokolle, die nicht XML-basiert sind, wie z.b. DCOM über UDP. In diesem Kapitel erstelle ich das WSDL-Dokument, das den Rechner-Webdienst beschreibt. Nebenbei beschreibe ich die verschiedenen Teile eines WSDL-Dokuments und die Rollen, die sie in der Beschreibung eines Webdienstes spielen. WSDL-Dokumentsyntax WSDL-Dokumente können auf den ersten Blick abschreckend sein. Aber die Syntax eines WSDL- Dokuments ist nicht annähernd so komplex wie die eines XML Schema-Dokuments. Ein WSDL-Dokument besteht aus einer Reihe von Zuordnungen, die auf einem XML Schema-Dokument aufbauen, das einen Webdienst beschreibt. Diese Zuordnungen tragen zur Größe und zur scheinbaren Komplexität eines WSDL-Dokuments bei. Aber wenn Sie erst einmal einen Blick hinter die Fassade geworfen haben, sind WSDL-Dokumente recht einfach. Der Stamm eines WSDL-Dokuments ist das Element definitions. Innerhalb dieses Elements gibt es fünf Typen von Kindelementen: b types: Enthält die Schemadefinition der Nachrichten, die der Dienst senden und empfangen kann. Die gängigste Methode, das Schema darzustellen, ist die Verwendung von XML Schema. b message: Dient als Querverweis, der die Nachricht ihrer Definition innerhalb des Schemas zuordnet. b porttype: Definiert eine Reihe von Schnittstellen, die der Webdienst verwenden kann. Eine Schnittstelle ist einer oder mehreren Nachrichten zugeordnet. b binding: Ordnet die porttype-definition einem bestimmten Protokoll zu. b service: Definiert eine Auflistung verwandter Endpunkte (Ports), die vom Webdienst verwendet werden. Das folgende Diagramm stellt dar, wie die fünf Elemente auf der Schemadefinition aufbauen, um den Webdienst zu beschreiben. Wie Sie sehen, besteht ein WSDL-Dokument aus einer Reihe von Zuordnungen. Die Nachrichtenteile werden z.b. dafür verwendet, einer Datentypdefinition einen Teil des Nachrichteninhalts zuzuordnen. 86 Kapitel 5

3 Dienst (Service) Port Port... Bindung (Binding) Operation Speicherort (URI) Anschlusstyp (PortType) Operation Operation... Protokoll (SOAP etc.) Nachricht (Message) Part Part... Aktion (Methodenaufruf etc.) einfacher Typ (simpletype) Typen (Types) komplexer Typ (complextype)... Inhalt Abbildung 5.1 Das Element definitions Das Stammelement in einem WSDL-Dokument, das Element definitions, dient im Großen und Ganzen dem gleichen Zweck wie das Element schema in einem XML Schema-Dokument. Es enthält Kindelemente, die einen bestimmten Dienst definieren. Ähnlich wie ein XML Schema-Dokument kann ein WSDL-Dokument seinen eigenen Namespace definieren, indem es dem Element definitions das Attribut targetnamespace hinzufügt. Die einzige Beschränkung besteht darin, dass der Wert des Attributs targetnamespace keinen relativen URL enthalten kann. Der WSDL-Namespace erlaubt es Ihnen, Verweise auf Entitäten, die in einem WSDL-Dokument definiert sind, voll zu qualifizieren. Zum Beispiel wird auf eine Nachrichtendefinition durch eine port- Type-Definition verwiesen. Weiter unten in diesem Kapitel verweise ich auf Entitäten, die in einem anderen WSDL-Namespace definiert sind, um die Schnittstellenvererbung zu vereinfachen. Das folgende WSDL-Fragment definiert das Element definitions für den Webdienst Rechner: <?xmlversion="1.0"encoding="utf-8"?> <definitionstargetnamespace=" xmlns:tns="  Mit WSDL Webdienste dokumentieren 87

4 Dieses WSDL-Dokument enthält ein definitions-element. Innerhalb des Zielnamespaces ist der Zielnamespace auf gesetzt. Dann wird ein Verweis auf den Zielnamespace gemacht, wobei ihm das Präfix tns: zugewiesen wird. Dieses Präfix wird in dem Dokument verwendet, um Verweise auf Entitäten, die in dem Dokument definiert sind, voll zu qualifizieren. Danach wird der WSDL-Namespace auf den Standardnamespace gesetzt. Das Element definitions definiert die Grenzen eines bestimmten Namensbereichs (name scope). Mit Elementen, die in einem WSDL-Dokument deklariert sind, werden Entitäten wie Anschlüsse und Nachrichten definiert. Diesen Entitäten wird mit dem Attribut name ein Name zugewiesen. Alle name-attribute innerhalb eines Namensbereichs müssen eindeutig sein. Wenn ein WSDL-Dokument z.b. einen Anschluss namens Foo enthält, kann es keinen anderen Anschluss oder eine Nachricht namens Foo enthalten. Es mag nicht immer praktisch sein, eine eindeutigen voll qualifizierten URI für einen Namespace zu definieren z.b. an einem frühen Punkt im Entwicklungszyklus oder wenn Sie einige experimentelle Webdienste erstellen möchten. In diesen Fällen können Sie nutzen, einen speziellen URI, der nach der Konvention verwendet wird, um Namespaces zu definieren, die nicht eindeutig identifiziert werden müssen. Das Element types Das Element types enthält Schemainformationen, auf die in dem WSDL-Dokument verwiesen wird. Das Standardtypensystem, das von WSDL unterstützt wird, ist XML Schema. Wenn mit XML Schema die Typen definiert werden, die im Element types enthalten sind, dann erscheint das Element schema als ein unmittelbares Kindelement. Sie können andere Typensysteme als Erweiterung verwenden. Wenn Sie andere Typensysteme verwenden, kann unter dem Element types ein Erweiterbarkeitselement erscheinen. Der Name des Elements sollte das verwendete Typensystem identifizieren. In diesem Kapitel beschränke ich meine Erörterung auf XML Schema, da es das dominierende Typensystem in WSDL-Dokumenten ist, und zwar auch in denen für Webdienste, die auf der.net-plattform entwickelt wurden. Der Webdienst Rechner wird zwei Methoden im RPC-Stil verwenden: Add und Subtract. Die Nachrichten werden ähnlich codiert, wie ich es Ihnen im Kapitel 4 gezeigt habe. Der einzige Unterschied ist, dass das Schema in ein WSDL-Dokument eingebettet sein wird, wie Sie hier sehen: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:xsd=" xmlns:s=" <types> <schema attributeformdefault="qualified" elementformdefault="qualified" xmlns=" targetnamespace=" <! Definitionen für die Add- und Subtract-SOAP-Nachrichten --> <element name="add"> <complextype> <all> <element name="x" type="int"/> <element name="y" type="int"/> </all> 88 Kapitel 5

5 </complextype> </element> <element name="addresult"> <complextype> <all> <element name="result" type="int"/> </all> </complextype> </element> <element name="subtract"> <complextype> <all> <element name="x" type="int"/> <element name="y" type="int"/> </all> </complextype> </element> <element name="subtractresult"> <complextype> <all> <element name="result" type="int"/> </all> </complextype> </element>  <element name="calculatefault"> <complextype> <all> <element name="x" type="int"/> <element name="y" type="int"/> <element name="description" type="string"/> </all> </complextype> </element> </schema> </types>  Innerhalb des Elements types gibt es Schemadefinitionen für die Methoden Add und Subtract, die den Verweis auf den Namespace des Schemas verwenden, der im Element definitions weiter oben im Dokument erscheint. WSDL ist nicht auf die Beschreibung von XML-basierten Serialisierungsformaten beschränkt. Sie können damit Dienste beschreiben, die andere Formate verwenden, darunter auch binäre. Mit WSDL können Sie z.b einen Dienst beschreiben, der über DCOM verwendet wird. In diesem Fall können Sie trotzdem XML Schema verwenden, um die Daten zu beschreiben, die über die Leitung gesendet werden. Die WSDL-Spezifikation gibt dafür die folgenden Empfehlungen: b Beschreiben Sie die Daten mit Elementen, nicht mit Attributen. Zum Beispiel sollte jeder Parameter in seinem eigenen Element codiert sein, ähnlich wie in SOAP-Encoding. Mit WSDL Webdienste dokumentieren 89

6 b Beschreiben Sie nur Daten, die in Bezug zu der Nachricht stehen und die nicht spezifisch für die Leitungscodierung sind. Zum Beispiel sollten die Parameter, die an ein Remote-COM-Objekt übergeben werden, in dem Schema beschrieben werden. Der DCOM-Objektbezeichner (DCOM object identifier, OID) besteht aber aus leitungs-protokoll-spezifischen Daten, die das Objekt identifizieren und nicht im Schema beschrieben werden sollten. b Arraytypen sollten von dem komplexen Typ Array abgeleitet werden, der im SOAP Encoding- Schema definiert ist. Nach der Konvention sollte der Name des Typs der Typ der Elemente im Array sein, mit dem Präfix ArrayOf. b Parameter, die Daten jeden Typs enthalten können, sollten von einem Element des Typs xsd:any- Type definiert werden. Das Element message Das Element message bietet eine allgemeine Abstraktion für Nachrichten, die zwischen dem Client und dem Server übergeben werden. Da Sie in einem WSDL-Dokument mehrere Schemadefinitionsformate verwenden können, ist eine allgemeine Methode notwendig, um die Nachrichten zu identifizieren. Das Element message bietet diese allgemeine Ebene der Abstraktion, auf die in anderen Teilen des WSDL-Dokuments verwiesen wird. In einem WSDL-Dokument können mehrere message-elemente erscheinen und häufig ist das auch der Fall. Dabei gibt es ein Element für jede Nachricht, die zwischen dem Client und dem Server übermittelt wird. Jede Nachricht enthält ein oder mehrere part-elemente, die Inhaltsstücke der Nachricht beschreiben. Ein Beispiel für einen Teil ist der Text einer SOAP-Nachricht oder ein Parameter, der in der Anfragezeichenfolge enthalten ist, ein Parameter, der im Text einer SOAP-Nachricht codiert ist, oder der gesamte Text einer SOAP-Nachricht. Jedes part-element enthält Attribute, die type- und element-definitionen assoziieren, die im Element types gefunden werden. Da Teile abstrakte Inhaltsdefinitionen sind, muss man die Bindungsinformationen untersuchen, um die Bedeutung der Teile zu ermitteln. Zwei Attribute, die im Element part erscheinen können, sind die Attribute element und type. Das Attribut element verweist auf eine Elementdefinition in einem Schema und das Attribut type auf eine Typdefinition in einem Schema. Da der Webdienst Rechner zwei Methoden mit jeweils einer Anfrage- und Antwortnachricht enthält und da eine Fehlernachricht definiert wurde, wird das WSDL-Dokument fünf message-elemente enthalten: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:s=" xmlns:xsd="  <message name="addmsgin"> <part name="parameters" element="s:add"/> <message name="addmsgout"> <part name="parameters" element="s:subtractresult"/> 90 Kapitel 5

7 <message name="subtractmsgin"> <part name="parameters" element="s:add"/> <message name="subtractmsgout"> <part name="parameters" element="s:subtractresult"/> <message name="calculatefaultmsg"> <part name="fault" element="s:calculatefault"/>  Ich habe ein Element message für die Anfrage- und Antwortnachricht der Methoden Add und Subtract erstellt. Stattdessen hätte ich auch für jeden Parameter ein Element part angeben können. Zum Beispiel hätte die Nachricht AddMsgIn so geschrieben werden können: <message name="addmsgin"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:int"/> Die Parameter x und y sind in ihrem eigenen Teil der Nachricht enthalten. Die Protokollbindung hat viel Einfluss darauf, wie Nachrichten dargestellt werden. Wenn ich weiter unten in diesem Kapitel die Bindung bespreche, werde ich jeden Parameter, der in einer HTTP-Anfragezeichenfolge enthalten ist, als seinen eigenen Nachrichtenteil darstellen. Da jeder Teil als abstrakte Definition eines Datenstücks dienen kann, kann eine Nachricht aus mehreren Datenstücken aus mehreren Quellen bestehen. Obwohl es nicht empfehlenswert ist, könnten Sie eine Nachricht beschreiben, in der einige der Parameter im SOAP-Text und andere in der Anfragezeichenfolge codiert wurden. Das Element porttype Das Element porttype enthält eine Reihe von abstrakten Operationen, um die Arten der Korrespondenz darzustellen, die zwischen dem Client und dem Server auftreten können. Bei Webdiensten im RPC-Stil kann man sich porttype als Schnittstellendefinition vorstellen, in der jede Methode als Operation definiert werden kann. Ein Anschlusstyp (port type) besteht aus einer Reihe von operation-elementen, die eine bestimmte Aktion definieren. Die operation-elemente bestehen aus den Nachrichten, die im WSDL-Dokument definiert sind. WSDL definiert vier so genannte Operationsarten: b Request-Response: Kommunikation im RPC-Stil, bei der der Client eine Anfrage stellt und der Server eine entsprechende Antwort herausgibt. b One-way: Kommunikation im Dokumentenstil, bei der der Client eine Nachricht sendet, aber keine Antwort vom Server erhält, die das Ergebnis der verarbeiteten Nachricht anzeigt. b Solicit-Response: Das Gegenteil der Request-Response-Operation. Der Server sendet eine Anfrage und der Client sendet eine Antwort zurück. b Notification: Das Gegenteil der One-way-Operation. Der Server sendet eine Dokumentstilkommunikation an den Client. Mit WSDL Webdienste dokumentieren 91

8 Eine Operation besteht aus einer Teilmenge von input-, output- und fault-elementen. Die Art der Elemente und die Reihenfolge der Elemente innerhalb der Operation bestimmen den Typ der Operation. One-way definiert z.b. eine Eingabenachricht und Request-Response eine Eingabe- und eine Ausgabenachricht. Die Operationstypen Solicit-Response und Notification sind das Gegenteil von Request-Response bzw. One-way. Die Operation Solicit-Response listet die Ausgabenachricht und dann die Eingabenachricht auf und die Operation Notification enthält eine Ausgabenachricht statt einer Eingabenachricht. Die Tabelle 5.1 listet für jeden Operationstyp den Typ und die Reihenfolge der Nachrichten auf. Operationstyp input output fault Request-Response 1 2 3* One-Way 1 Solicit-Response 2 1 3* Notification 1 Tabelle 5.1: Nachrichtenreihenfolge für die Operationstypen * Die fault-nachricht ist optional. In einer Operation können beliebig viele fault-nachrichten erscheinen. Operationen, zu denen eine Zwei-Wege-Kommunikation gehört, können optional eine oder mehrere Fehlernachrichten angeben. Wie Methodendefinitionen in Java, so erlauben es auch die Fehlernachrichten, den Typ der Ausnahmen zu deklarieren, die von der Serveranwendung verursacht werden können. Die Liste der möglichen Fehler sollte aber keine Fehler enthalten, die vom zugrunde liegenden Transportprotokoll spezifiziert werden. Sie sollten z.b. nicht den HTTP 500-Fehler im WSDL- Dokument darstellen müssen. Die Namen der Elemente input, output und fault haben einen Standardwert, wenn kein anderer Wert angegeben wurde. Für die Operationstypen One-way und Notification ist der Standardname der Name des operation-elements, in dem sie enthalten sind. Für den Operationstyp Request-Response ist der Name für die Elemente input und output standardmäßig der Name der Operation mit einem am Ende angehängten Request oder Response. Bei Solicit-Response ist der Name des Elements output standardmäßig der Name der Operation mit einem am Ende angehängten Solicit oder Response. Da in einer Operation mehrere fault-elemente definiert sein können, gibt es keinen Standardnamen für das Element fault. Daher muss jedes fault-element in seinem operation-elternelement eindeutig benannt werden. Hier sehen Sie die porttype-definition für den Webdienst Rechner: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:xsd="  <porttype name="rechnerporttype"> <operation name="add"> <input message="tns:addmsgin"/> <output message="tns:addmsgout"/> 92 Kapitel 5

9 <fault message="tns:calculatefaultmsg" name="calculatefault"/> <operation name="subtract"> <input message="tns:subtractmsgin"/> <output message="tns:subtractmsgout"/> <fault message="tns:calculatefaultmsg" name="calculatefault"/> </porttype>  Dieser Abschnitt des Rechner-WSDL-Dokuments definiert den porttype mit dem Namen Rechner- PortType. Es enthält zwei Request-Response-Operationen, Add und Subtract. Da die Operationen den Typ Request-Response haben, definieren sie beide eine Eingabe- und eine Ausgabenachricht. Beide Operationen enthalten ebenfalls ein fault-element mit dem Namen CalculateFault. Operationen im RPC-Stil können optional das Attribut parameterorder verwenden, um die Reihenfolge der erwarteten Parameter anzugeben. Dieses Attribut hat den Typ nmtokens und enthält eine Liste der Parameternamen. Da SOAP eine klare Methode angibt, um Parameter zu serialisieren, und da die Namen und Reihenfolge der Parameter mit XML Schema beschrieben werden können, wird dieses Attribut nicht häufig verwendet. Einige Dienste, die mit WSDL beschrieben wurden, können überladene Methoden unterstützten, d.h. Methoden, die zwar denselben Namen, aber unterschiedliche Parametersätze haben. Daher können in einer porttype-definition mehrere operation-elemente den gleichen Namen haben, aber unterschiedliche Nachrichten angeben. In diesem Fall müssen die unterschiedlichen operation-elemente durch die Kombination aus dem Operationsnamen und den Namen der input-, output- und fault- Elemente identifiziert werden. Daher stellen die Standardnamen für die input-, output- und fault- Elemente möglicherweise nicht sicher, dass operation-element mit dem gleichen Namen eindeutig identifiziert werden können. Das Element binding Das Element binding enthält Bindungsdefinitionen für die Bindung eines Protokolls wie z.b. SOAP an einen bestimmten bindingtype. Die binding-definitionen geben Einzelheiten zur Nachrichtenformatierung und zum Protokoll an. Die Bindungsinformation gibt z.b. an, ob Sie auf RPC-ähnliche Art auf eine Instanz eines porttype zugreifen können. Die binding-definitionen geben auch die Anzahl von Netzwerkkommunikationen an, die erforderlich sind, um eine bestimmte Aktion durchzuführen. Ein SOAP-RPC-Aufruf über HTTP kann z.b. einen HTTP-Kommunikationsaustausch umfassen, während der gleiche Aufruf über SMTP zwei getrennte SMTP-Kommunikationsaustausche umfasst. Die Bindung wird mit der Verwendung von Erweiterungselementen erreicht. Jedes Protokoll hat seinen eigenen Satz von Erweiterungselementen, um die Einzelheiten des Protokolls und des Formatierens der Nachricht anzugeben. Für ein bestimmtes Protokoll werden häufig Erweiterungselemente verwendet, um die einzelnen Aktionen innerhalb einer Operation und die Operation mit Protokollbindungsinformationen zu ergänzen. Manchmal werden Erweiterungselemente auf der porttype- Ebene selbst verwendet. Das folgende vereinfachte WSDL-Dokument zeigt die Bindung für den Webdienst Rechner. Es enthält außerdem Platzhalter für Erweiterbarkeitselemente, um zu zeigen, wo sie in Bezug auf das ent- Mit WSDL Webdienste dokumentieren 93

10 haltende binding-element platziert werden können. (Ich werde die Erweiterbarkeitselemente, die von der WSDL-Spezifikation definiert werden, weiter unten in diesem Kapitel erläutern.) <?xml version="1.0" encoding="utf-8"?> <definitions xmlns:ext="   <binding name="rechnerbindung" type="tns:rechnerporttype> <ext:einextelement/> <operation name="add"> <ext:einextelement/> <ext:einextelement/> <output> <ext:einextelement/> </output> <ext:einextelement/> <operation name="subtract"> <ext:einextelement/> <ext:einextelement/> <output> <ext:einextelement/> </output> <ext:einextelement/> </binding>  Das Element binding wird über das Attribut type einem bestimmten porttype-element zugeordnet. In dem vorherigen WSDL-Dokument habe ich die Bindung RechnerBindung mit dem Anschlusstyp RechnerPortType assoziiert. Im Element binding habe ich zwei operation-elemente erzeugt, um sie mit denen in Übereinstimmung zu bringen, die im Element porttype definiert sind. Jedes operation-element muss entsprechende input-, output- und fault-elemente habe, die im Element porttype definiert sind. Außerdem müssen die Namen des Elements operation und seiner input-, output- und fault-kindelemente exakt mit den Namen ihrer Gegenstücke übereinstimmen, die in dem entsprechenden porttype-element definiert sind. 94 Kapitel 5

11 Das Element service Ein Dienst ist eine Gruppe verwandter Anschlüsse und wird durch das Element service definiert. Ein Anschluss ist ein bestimmter Endpunkt für den Webdienst, auf den durch eine einzelne Adresse verwiesen wird. Anschlüsse, die in einem bestimmten Dienst definiert sind, sind rechtwinklig. Zum Beispiel kann die Ausgabe eines Anschlusses nicht als Eingabe eines anderen dienen. Hier sehen Sie eine vereinfachte Dienstdefinition für den Webdienst Rechner. Das Dokument enthält Platzhalter für Erweiterbarkeitselemente, um zu zeigen, wo sie in Bezug auf das enthaltende service- Element platziert werden können: <?xml version="1.0" encoding="utf-8"?> <definitions xmlns:ext="   <service name="rechnerdienst"> <ext:einextelement/> <port name="rechnerport" binding="tns:rechnerbindung"> <ext:einextelement/> </port> </service>  Mit dem Element service wird eine Reihe verwandter Anschlüsse zusammengruppiert. Das vorangegangene WSDL-Dokument definiert einen Dienst mit dem Namen RechnerDienst. Er enthält einen Anschluss namens RechnerPort. RechnerPort wird mit dem Bindungselement RechnerBindung assoziiert. Ein Anschluss enthält ein Erweiterungselement, das die Adresse liefert, an dem er sich befindet. Wenn Sie mehr als eine Adresse angeben müssen, müssen Sie einen Anschluss für jede Adresse erzeugen. Wenn Sie in einem Webdienst mehrere Anschlüsse desselben Anschlusstyps definieren (und möglicherweise mit unterschiedlichen Adressen), sollten diese als Alternativen angesehen werden. Die Anschlüsse sollten zwar das gleiche Verhalten bieten, dies aber über unterschiedliche Transportprotokolle machen. Der Client kann durch die Anschlüsse iterieren, um eine kompatible Bindung mit einem geeigneten porttype und Protokoll zu finden. Erweiterbarkeitselemente Erweiterbarkeitselemente werden verwendet, um bestimmte Technologien darzustellen. Mit Erweiterbarkeitselementen können Sie z.b. die Schemasprache angeben, die im Element types verwendet wird. Das Schema für eine bestimmte Reihe von Erweiterbarkeitselementen muss in einem anderen Namespace als WSDL definiert sein. Die Definition der Elemente selbst kann das Attribut wsdl:required enthalten, das einen Booleschen Wert angibt. Wenn das Attribut required in einer Elementdefinition auf true gesetzt ist, muss eine Bindung, die auf die bestimmte Reihe von Erweiterbarkeitselementen verweist, auch dieses Elemente umfassen. Mit WSDL Webdienste dokumentieren 95

12 Meistens werden Erweiterbarkeitselemente verwendet, um Bindungsinformationen anzugeben. Die WSDL-Spezifikation definiert Sätze von Erweiterungselementen für die Bindung an SOAP, HTTP GET; HTTP POST und MIME. Die Spezifikation definiert aber die Bindung nur für zwei der vier Operationstypen, für One-way und Request-Response. Wir wollen uns nun die drei Bindungen ansehen, die von der.net-plattform unterstützt werden: SOAP, HTTP GET und HTTP POST. SOAP-Erweiterungen Die SOAP-Erweiterungen bieten eine Reihe von Elementen für die Bindung eines Anschlusstyps an eine SOAP-Nachricht, die über ein bestimmtes Transportprotokoll gesendet wird. Zum Beispiel gibt man mit SOAP-Erweiterungselementen an, wo sich die einzelnen Teile in der SOAP-Nachricht befinden. Sie werden außerdem verwendet, um das Transportprotokoll anzuzeigen, mit dem die SOAP- Nachricht gesendet wird. SOAP-Erweiterungselemente sind im Namespace enthalten. Nach der Konvention, die ich im Rest dieses Kapitels verwende, werden Verweise auf den Namespace dem Kurznamen soap: zugeordnet. binding-elementbindung Erweiterbarkeitselemente, die dem Element binding hinzugefügt wurden, geben Informationen darüber, wie die Parameter in der SOAP-Nachricht codiert sind. Erweiterbarkeitselemente werden zu den bind-, operation-, input-, output- und fault-nachrichten hinzugefügt. Sie liefern Informationen über das Transportprotokoll, mit dem die SOAP-Nachricht gesendet wird, und darüber, wie die Daten im SOAP-Umschlag codiert sind. Der primäre Zweck des Elements soap:binding besteht darin, zu signalisieren, dass die SOAP-Bindung auf eine bestimmte Bindungsdefinition angewendet wird. Daher müssen alle binding-elemente, die die SOAP-spezifische Bindung enthalten, auch das Element soap:binding enthalten. Mit dem soap:binding-element kann außerdem der Stil der Nachricht und das Transportprotokoll angegeben werden, mit dem die SOAP-Nachricht versendet werden wird. Der folgende Teil des WSDL-Dokuments des Rechner-Webdienstes zeigt die Verwendung des soap:binding-elements: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:soap="  <binding name="rechnerbindung" type="tns:rechnerporttype"> <soap:binding style="document" transport="  </binding>  Das Element soap:binding kann das Attribut transport enthalten, um ein Transportprotokoll anzugeben. Das Attribut transport muss einen URI enthalten, der das Transportprotokoll eindeutig identifi- 96 Kapitel 5

13 ziert. Der einzige URI, der in der Spezifikation definiert ist, ist für das HTTP-Transportprotokoll: Da das soap:binding-element auf die gesamte Bindungsdefinition angewendet wird, wird es auch auf alle Operationen angewendet, auf die von der Bindungsdefinition verwiesen wird. Der Stil der Nachricht wird vom Attribut style angegeben. Der Wert ist entweder rpc oder document. Wenn der Stil auf rpc gesetzt ist, stellt jeder Teil in der Operation einen Parameter dar. Die Parameter müssen im Text der SOAP-Nachricht strukturähnlich codiert sein, wie es von der SOAP-Spezifikation vorgeschrieben wird. Der Name des Elements operation muss mit dem Namen des Elements übereinstimmen, das die Parameter in der SOAP-Nachricht enthält. Wenn der Stil auf document gesetzt ist, erscheinen die Nachrichtenteile direkt im Text der SOAP-Nachricht. Wie Sie in Kürze sehen werden, kann der Nachrichtenstil auch auf der Operationsebene gesetzt werden. Da das Attribut style, das auf der Operationsebene definiert wird, Vorrang hat, bestimmt das Setzen des Attributs style innerhalb des Elements soap:binding den Nachrichtenstil nicht; es setzt nur den Standardwert. Wenn das Attribut style nicht gesetzt ist, wird der Standardwert document verwendet. Das Element soap:operation bietet Bindungsinformationen für die Operation als Ganzes. Sie können damit sowohl den Dokumentstil als auch den SOAPAction-HTTP-Headerwert für HTTP-Bindungen angeben. Der folgende Abschnitt des WSDL-Dokuments des Rechner-Webdienstes zeigt die Verwendung des Elements soap:binding: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:soap="  <binding name="rechnerbindung" type="tns:rechnerporttype"> <soap:binding style="document" transport=" <operation name="add"> <soap:operation soapaction= <soap:body use="literal"/> <output> <soap:body use="literal"/> </output> <soap:fault name="calculatefault" use="literal"/> <operation name="subtract"> <soap:operation soapaction= <soap:body use="literal"/> <output> <soap:body use="literal"/> </output> Mit WSDL Webdienste dokumentieren 97

14 <soap:fault name="calculatefault" use="literal"/> </binding>  Wie ich bereits weiter oben erwähnt habe, kann das Attribut style entweder auf rpc oder auf document gesetzt werden, um den Stil der Nachricht anzuzeigen. Das Attribut soapaction gibt den Wert des SOAPAction-Headers an. Das Attribut soapaction ist erforderlich, wenn HTTP das Transportprotokoll ist. Der Wert kann ausgelassen werden, wenn der HTTP-Anfrage-URL die Intention der Nachricht adäquat beschreibt. Der Client sollte den Wert des Attributs soapaction unverändert übergeben, wenn die Nachricht an den Webdienst gesendet wird. Wenn das Protokoll nicht HTTP ist, kann das Attribut soapaction ausgelassen werden. Das Element soap:body gibt an, wie Teile der Nachricht im SOAP-Nachrichtentext codiert sind. Mit diesem Element wird angegeben, welche Teile einer Nachricht im SOAP-Nachrichtentext erscheinen. Mit ihm kann auch der Codierungstyp deklariert werden, mit dem Teile im Nachrichtentext serialisiert sind. Sie können optional die Liste der Teile angeben, die im Text der SOAP-Nachricht gefunden werden können. Das Attribut parts kann eine Liste benannter Token enthalten, wobei jeder Token der Name eines Teils ist, der im SOAP-Text enthalten ist. Wenn das Attribut parts nicht angegeben ist, wird angenommen, dass alle Teile, die von der Nachricht definiert werden, im SOAP-Textkörper enthalten sind. Das Attribut parts sollte z.b. dann verwendet werden, wenn eine HTTP-Nachricht eine Multipart-Nachricht enthält, die neben einem MIME-Anhang eine SOAP-Nachricht enthält. Ein Teil der Nachricht, der im SOAP-Textkörper nicht enthalten wäre, wäre der Anhang selbst. Manchmal kann ein Schema allein die Art, in der Daten serialisiert werden, nicht adäquat darstellen. SOAP Encoding definiert z.b. mehrere Möglichkeiten, wie ein Array serialisiert werden kann: das gesamte Array, ein Teilarray oder ein dünn besetztes Array. (Mehr Informationen finden Sie in Kapitel 3.) Das Attribut use ist erforderlich und muss entweder literal oder encoded sein. Der Wert literal bedeutet, dass Teile im SOAP-Textkörper dem Schema entsprechen müssen. Der Teil innerhalb der Nachrichtendefinition muss entweder mit dem Attribut type oder mit element auf das Schema verweisen. Wenn Teile im Textkörper mit einer bestimmten Methode der Codierung serialisiert werden sollen, sollte der Wert des Attributs use encoded sein. Jeder Teil der Nachricht, der im SOAP-Textkörper codiert ist, muss mit dem Attribut type auf einen abstrakten Typ verweisen. Ein Teil, der z.b. ein SOAP- Array enthält, würde auf den SOAP-Typ Array verweisen. Wenn der Codierungsstil verschiedene Arten der Datencodierung unterstützt (wie z.b. der SOAP-Typ Array), muss der Dienst alle diese Variationen unterstützten. Wenn Teile einer Nachricht auf einer abstrakten Typdefinition statt auf einem konkreten Format basieren, das von einer Schemadefinition angegeben wird, sollte auf den Codierungsstil verwiesen werden. Der Codierungsstil wird von dem Attribut wsdl:encodingstyle angegeben und kann eine durch Leerstellen getrennte Liste von URIs enthalten (ähnlich dem Attribut encodingstyle, das von SOAP definiert wird). Wenn für einen Nachrichtenteil das Attribut encodingstyle angegeben ist und das use-attribut auf literal gesetzt wurde, dient der encodingstyle als Hinweis darauf, wie die Daten codiert sind. Das ist 98 Kapitel 5

15 nützlich, wenn Sie nur eine Variation eines bestimmten SOAP-codierten Datentyps akzeptieren möchten. Ein Webdienst könnte z.b. nur SOAP-Arrays akzeptieren, die vollständig serialisiert sind. service-elementbindung Das einzige SOAP-Erweiterungselement, das im Element service angegeben ist, ist soap:address. Es ist in der Anschlussdefinition enthalten und wird verwendet, um den URI eines Endpunktes oder Anschlusses anzugeben, an dem der Webdienst erreicht werden kann. <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:soap="  <service name="rechnerdienst"> <port name="rechnerport" binding="tns:rechnerbindung"> <soap:address location=" </port> </service> Die Dienstdefinition legt fest, dass der Webdienst Rechner unter erreicht werden kann. Wenn die Adresse nicht durch einen URI angegeben werden kann, kann das Element soap:address mit einem benutzerdefinierten address-element platziert werden, das den Ort ordentlich angibt. HTTP GET/POST-Erweiterungen Manchmal ist es wünschenswert, einen Webdienst aufzurufen, indem die Parameter als Name-/Wert- Paare mit dem gleichen Mechanismus übergeben werden wie eine Übermittlung in der Standard- HTML-Form. Parameter können über die Anfragezeichenfolge oder ein Form-POST übergeben werden. Das macht es einem Client manchmal einfacher, einen Webdienst aufzurufen, ohne eine wohlgeformte SOAP-Nachricht erzeugen zu müssen. Die HTTP GET/POST-Erweiterungen bieten eine Reihe von Elementen für die Bindung von Anschlusstypen an das SOAP-Protokoll. Mit SOAP-Erweiterungselementen wird z.b. angegeben, wo sich die einzelnen Teile in der SOAP-Nachricht befinden. Mit ihnen wird außerdem das Transportprotokoll angegeben, mit dem die SOAP-Nachricht versendet wird. In diesem Abschnitt erzeuge ich zwei zusätzliche Bindungen für den Webdienst Rechner, eine für HTTP GET und eine für HTTP POST. Da ich viel Freiheit darin habe, wie ich die Bindung angebe, erstelle ich Bindungen, die sehr stark dem ähneln, wie sich Webdienste verhalten, die auf der.net- Plattform erstellt wurden. Insbesondere akzeptieren Webdienste, die mit der.net-plattform entwickelt wurden, Standard-Name-/Wert-Paare, die URL-codiert sind und entweder an die Anfragezeichenfolge angehängt sind oder über POST mit dem Text der HTTP-Anfragenachricht versendet werden. Wenn Ergebnisse zurückgegeben werden, werden sie als einfaches XML-Dokument im Textkörper der HTTP-Antwortnachricht übergeben. Mit WSDL Webdienste dokumentieren 99

16 Ehe ich die Bindungsinformationen angebe, muss ich eine zusätzliche Elementdeklaration erstellen, um den Wert der Rückgabeparameter zu speichern. Da einzelne Parameter als einzelne Teile einer Nachricht dargestellt werden müssen, muss ich außerdem einige neue Nachrichtendefinitionen für die Methoden Add und Subtract erstellen, in denen jeder Parameter in seinem eigenen Nachrichtenteil enthalten ist. Hier sehen Sie die Ergänzungen: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:s=" xmlns:xsd=" xmlns:http=" xmlns:mime="  <types> <schema attributeformdefault="qualified" elementformdefault="qualified" xmlns=" targetnamespace=" <! Allgemeines Ergebniselement für HTTP GET/POST-Bindung --> <element name="result" type="int"/> </schema> </types>   <message name="addhttpmsgin"> <part name="x" type="xsd:string"/> <part name="y" type="xsd:string"/> <message name="addhttpmsgout"> <part name="result" element="s:result"/> <message name="subtracthttpmsgin"> <part name="x" element="xsd:string"/> <part name="y" element="xsd:string"/> <message name="subtracthttpmsgout"> <part name="result" element="s:result"/>  Dieses WSDL-Dokument definiert unter dem Namen Result ein neues Element des Typs int, mit dem das Ergebnis der Methoden Add und Subtract gespeichert wird, das an den Client zurückgegeben wird. Auf dieses Element wird durch zwei neue, ausgehende Nachrichten verwiesen: eine für jede Methode. Das Dokument definiert außerdem zwei neue eingehende Nachrichten für die Methoden Add und Subtract. Die ausgehenden Nachrichten definieren einzelne Teile für jeden Parameter. Da die Namen-/Wert-Paare, die die Parameter enthalten, nicht stark typisiert sind, ist der Typ jeden Teils als string definiert. 100 Kapitel 5

17 HTTP GET/POST-Erweiterungselemente sind im Namespace http/ enthalten. Die Konvention für den Rest dieses Kapitels besteht darin, Verweise auf den Namespace mit dem Kurznamen http: zuzuordnen. Gelegentlich verwenden HTTP GET/POST-Bindungen die MIME-Erweiterungselemente. Sie sind im Namespace definiert und auf sie wird mit dem Kurznamen mime: verwiesen. binding-elementbindung Erweiterbarkeitselemente, die zum Element binding hinzugefügt werden, bieten Informationen darüber, wie die Parameter in der HTTP-Nachricht codiert sind. Erweiterbarkeitselemente werden zu den bind-, operation-, input-, output- und fault-nachrichten hinzugefügt. Das Element gibt an, ob die Parameter mit dem URL oder im Textkörper der HTTP-Anfrage übergeben werden: Das»Verb«des wird entweder auf GET oder POST gesetzt. Das folgende WSDL-Dokument zeigt die Verwendung des Elements innerhalb der Definition des Webdienstes Rechner: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:http="  <binding name="rechnerhttpgetbindung" type="tns:rechnerporttype"/> < verb="get"/>  </binding>  Das Element gibt die relative Adresse für jede Operation an. Jede input- und output- Nachricht wird mit einem Erweiterungselement ergänzt, das die Methode anzeigt, mit der die Parameter codiert werden, die an den Webdienst übergeben werden. Die drei kommenden Szenarien für die Codierung von Parametern zeigen die URL-Codierung von Parametern in der Anfragezeichenfolge, die Nicht-Standardcodierung innerhalb des URLs und die URL-Codierung der Parameter im Textkörper der Sendung. Parameter können an einen Webdienst über einen URL übergeben werden, der in der Anfragezeichenfolge codiert ist. Die URL-Codierung gibt an, dass ein? an das Ende des URL angehängt wird, gefolgt von einem durch ein = getrenntes Name-/Wert-Paar. Wenn mehrere Name-/Wert-Paare an den URL angehängt werden, werden sie durch ein & voneinander getrennt. Die Methode Add kann z.b. folgendermaßen aufgerufen werden: In diesem Fall würde das Element input in der Bindung für eine bestimmte Operation mit einem ergänzt. Hier sehen Sie die daraus resultierende HTTP GET-Bindungsdefinition für den Webdienst Rechner: Mit WSDL Webdienste dokumentieren 101

18 <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:http="  <binding name="rechnerhttpgetbindung" type="tns:rechnerporttype"/> < verb="get"/> <operation name="add"> < location="/add"/> < <output> <mime:mimexml part="body"/> </output> <mime:mimexml part="fault"/> <operation name="subtract"> < location="/subtract"/> < <output> <mime:mimexml part="body"/> </output> <mime:mimexml part="fault"/> </binding>  Parameter können auch innerhalb des URL auf eine nicht standardmäßige Art codiert werden. In diesem Fall enthält das Attribut location des Elements Informationen darüber, wie die Parameter codiert sind. Die Parameter für die Methode Add könnten z.b. so im URL codiert werden: Die Parameter 2 und 3 wurden in der Pfadinformationen des URL codiert, wo die Parameter durch plus begrenzt wurden. Das daraus resultierende Element würde in den Bindungsdefinitionen wie folgt erscheinen: < location="add/(x)plus(y)"/> 102 Kapitel 5

19 Die einzelnen Nachrichtenteile, die in Klammern eingeschlossen sind, werden in ihrer jeweiligen Position im relativen URL angezeigt. In diesem Fall würde das Element input innerhalb der Bindung für eine bestimmte Operation durch das Element ergänzt. Die dritte und letzte hier beschriebene Methode der Parametercodierung ist die Einbettung der URLcodierten Parameter in den Textkörper der HTTP-Anfragenachricht (HTTP POST). Die Parameter würden z.b. im Textkörper der HTTP-Anfrage wie folgt codiert: Add="x=2&y=3" In diesem Fall kann das Element input mit dem MIME-Typ application/x-www-form-urlencoded beschrieben werden. Daher würde das Element operation durch das Element mime:content ergänzt. Die daraus resultierende HTTP POST-Bindungsdefinition für den Webdienst Rechner sieht folgendermaßen aus: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" xmlns:tns=" xmlns:http="  <binding name="rechnerhttppostbindung" type="tns:rechnerporttype"/> < verb="post"/> <operation name="addn"> < location="/add"/> <mime:content type="application/x-www-form-urlencoded"/> <output> <mime:mimexml part="body"/> </output> <soap:fault name="calculatefault" use="literal"/> <operation name="subtract"> < location="/subtract"/> <mime:content type="application/x-www-form-urlencoded"/> <output> <mime:mimexml part="body"/> </output> <soap:fault name="calculatefault" use="literal"/> </binding>  Mit WSDL Webdienste dokumentieren 103

20 Das Attribut type enthält einen gültigen MIME-Typ, mit dem der Inhaltstyp angegeben wird, der im Textkörper der HTTP-Nachricht enthalten ist. Der Inhalt der HTTP-Nachricht kann mit einem Platzhalter auch als Mitglied einer Familie von MIME-Typen gekennzeichnet werden. Hier sehen Sie einige Beispiele:  <mime:content type="text/*"/>  <mime:content type="text/*"/> <mime:content/> Das Element mime:content kann auch ein part-attribut enthalten, mit dem angegeben wird, welcher Teil im Textkörper der HTTP-Nachricht enthalten ist. Wenn die Nachricht den MIME-Typ multipart/related hat, kann sie eine Auflistung von MIME-formatierten Teilen enthalten. Eine Multipart-Nachricht kann z.b. eine SOAP-Nachricht (text/xml) zusammen mit einem JPEG-Bild (image/jpeg) enthalten. Eine Multipart-Nachricht kann in der Bindungsdefinition mit dem Element mime:multipartrelated dargestellt werden. Das Element mime:multipartrelated enthält eine Auflistung von mime:part-elementen. Jedes mime:part-element stellt einen bestimmten MIME-formatierten Teil dar, wobei sein Typ mit dem Element mime:content deklariert wird. Das folgende Beispiel zeigt, wie eine Multipartnachricht, die eine SOAP-Nachricht und ein JPEG- Bild enthält, in einem WSDL-Dokument dargestellt wird: <mime:multipartrelated> <mime:part> <soap:body use="literal" part="xycoordinates"/> </mime:part> <mime:part> <mime:content type="image/jpeg" part="graph"/> </mime:part> </mime:multipartrelated> Beachten Sie, dass Sie mit dem Element soap:body anzeigen können, dass ein bestimmter MIME-Teil eine SOAP-Nachricht enthält. Es wird angenommen, dass der Nachrichtenteil den MIME-Typ text/ xml hat und in einem gültigen SOAP-Umschlag enthalten ist. Wenn der MIME-Nachrichtenteil XML enthält, aber nicht SOAP-kompatibel ist, können Sie das Element mime:mimexml verwenden. Das assoziierte part-element definiert das XML-Stammelement statt des Textkörpers einer SOAP-Nachricht. Dieses Element wird in ASP.NET ausgiebig verwendet, da die HTTP GET/POST-Version eines Webdienstes das Ergebnis mit nicht-soap-kompatiblem XML-Code zurückgibt. service-elementbindung Das einzige HTTP-Erweiterungselement, das im Element service angegeben wird, ist Wie sein SOAP-Gegenstück ist es in der Anschlussdefinition enthalten und wird verwendet, um den URI anzugeben, unter dem der Webdienst erreicht werden kann. Hier sehen Sie die Dienstdefinition für den Rechner-Webdienst: <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace=" 104 Kapitel 5

21 xmlns:tns=" xmlns:soap="  <service name="rechnerdienst"> <port name="rechnerhttpgetport" binding="tns:rechnerhttpgetbindung"> < location=" </port> <port name="rechnerhttppostport" binding="tns:rechnerhttppostbinding"> < location=" </port> </service> Dieses WSDL-Dokument definiert zwei Anschlüsse, einen für HTTP GET und einen anderen für HTTP POST. Beide Anschlüsse können über erreicht werden. Das Element import Wie XML Schema-Dokumente können auch WSDL-Dokumente andere Dokumente importieren. Daher können Sie die gleiche Ebene der Modularität erreichen, die Sie mit XML Schema-Dokumenten erreichen können. Da ein WSDL-Dokument recht schnell recht groß werden kann, kann das Aufspalten des Dokuments in einige kleinere Dokumente dabei helfen, das Dokument leichter verständlich und möglicherweise leichter pflegbar zu machen. Eine gängige Methode, eine einzelne Dienstdefinition in mehrere WSDL-Dokumente zu teilen, besteht darin, Protokollbindungsinformationen in ein separates Dokument zu setzen. Das ermöglicht es Ihnen, die Schnittstellendefinitionen einmal zu schreiben und sie dann in ein WSDL-Dokument zu importieren, das die besonderen Protokolle definiert, die von einer bestimmten Instanz des Webdienstes unterstützt werden. Im Gegensatz zu seinem XML Schema-Gegenstück muss das Element import sowohl das Attribut namespace als auch das Attribut location enthalten. Stellen Sie sich vor, ich hätte das WSDL-Dokument für den Rechner-Webdienst in drei Teile geteilt. Ich hätte die Schemadefinitionen in Rechner.xsd gesetzt, die Schnittstellendefinitionen in i_rechner.wsdl und das Protokoll in Rechner.wsdl. Rechner.wsdl dient als das WSDL-Dokument für den Webdienst, indem es die anderen beiden Dokumente importiert. Hier sehen Sie Rechner.wsdl: <definitions  <import namespace=" location="  <import namespace=" location=" <! Gibt zum Schluss die protokollspezifischen Bindungsinformationen an. --> Mit WSDL Webdienste dokumentieren 105