WSDL (Web Service Description Language) ist eine XML-Sprache zur Beschreibung von Web Services. Dabei beschreibt WSDL Web Services auf zwei Ebenen: abstrakt und konkret. Hierzu wird die Darstellung der Funktionalität, die ein Web Service anbietet, getrennt von den technischen Details, wie ein Dienst zur Verfügung gestellt.
So lässt sich mithilfe von WSDL definieren, welche Methoden bei der Server-Komponente vom Client ausgeführt werden können, welche Parameter dabei übergeben werden müssen und was für einen Rückgabewert diese einzelnen Methoden liefern.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 (in Planung) |
Verzeichnisdienste für Web Services / UDDI |
|
Teil 6 (in Planung) |
Web Services und Sicherheit |
WSDL als W3C-Standard
Die Besonderheit eines WSDL-Dokuments ist die Angabe unter welcher Adresse (URL) der Web Service zu finden ist. Diese Information wird über eine Service Registry zur Verfügung gestellt, sodass IP-Adressänderungen nicht mehr allen Clients mitgeteilt werden müssen.
WSDL entstand auf Initiative der Unternehmen IBM, Microsoft und Ariba. Mittlerweile wurde die Technologie vom W3C standardisiert. Am 15. März 2001 veröffentlichte das World Wide Web Consortium die Web Services Description Language Version 1.1 als technical Note (http://www.w3.org/TR/wsdl.html).
Bereits seit dem 6. Januar 2006 ist die Version 2 in einem Draft-Dokument für die Sprachdefinition (core language, http://www.w3.org/TR/wsdl20/) und die Nachrichten-Muster (message patterns, http://www.w3.org/TR/wsdl20-adjuncts/) verfügbar. Wer sich übrigens den Anschein des echten WSDL-Profis geben will, spricht WSDL am besten wie im Englischen „wiz-dull“ aus.
Aufbau eines WSDL-Dokumentes
Um die Definition einer in WSDL spezifizierten Schnittstelle zu verstehen, sind gute XML-Kenntnisse notwendig. Das Grundprinzip aber lässt sich einfach skizzieren. Eine WSDL-Beschreibung ist hierarchisch aufgebaut und enthält mehrere Komponenten. Die wichtigsten sind die XML-Elemente <types>, <messages>, <porttype>, <binding> und <service>.
Die einzelnen Elemente sind einander hierarchisch zugeordnet. Die ersten drei Abschnitte (<types>, <message>, <portType>) nennt man den „abstrakten“ Teil, und die beiden letzten (<binding>, <service>) den „konkreten“ Teil einer WSDL-Beschreibung.
Im abstrakten Teil werden unabhängig von einem Protokoll oder Service die Operationen und verwendeten Datentypen beschrieben. Im konkreten Teil ist aufgeführt, über welche URI (Uniform Resource Identifier) und Protokolle ein Web Service erreicht werden kann und wie die Daten serialisiert und kodiert werden.
Das folgende Listing zeigt den strukturellen Aufbau noch einmal in explizitem XML-Code:
<definitions>
<types>
… hier werden die verwendeten Datentypen beschrieben
</types>
<message name=”KontoAnfrage”>
… hier werden die Parameter einer Nachricht beschrieben
</message>
<message name=”KontoAuskunft”> ... </message> …
<portType name=”KontoZugriffsPort”>
<operation name=”KontoZugriff”>
<input message=”KontoAnfrage” />
<output message=”KontoAuskunft” />
</operation> …
</portType> ...
<binding name=”KontoAuskunftSoap”> ... </binding>
<service name=”KontoAuskunftsService”> ... </service>
</definitions>
WSDL-Dokumentenstruktur: Die Elemente und ihre Beziehungen
Wir beschreiben nun detaillierter, aus welchen Elementen ein WSDL-Dokument besteht; dabei werden nur die wichtigsten berücksichtigt.
WSDL-Elemente: Das Element „<types>“
Das <types>-Element enthält jene Datentypen, die später in den Nachrichten (<message>) verwendet werden. Es bietet die Möglichkeit, all die Datentypen zu definieren, die nicht vom XML-Schema-Standard erfasst werden.
Das folgende, leicht modifizierte Beispiel stammt aus dem Buch von W. Dostal: „Serviceorientierte Architekturen mit Web Services“. Bei dem Beispiel handelt es sich um einen Web Service, der es ermöglicht, nach Büchern in einem Buchkatalog zu suchen. Um die Suche durchzuführen, stellt der Nutzer des Web Service eine Anfrage mit den Suchbegriffen, zum Beispiel Titel und Autor oder einem Stichwort. Die Anfrage wird dann vom Web Service bearbeitet und mit einer Trefferliste beantwortet, die den Suchkriterien entsprechende Bücher beinhaltet.
In dem Beispiel werden im Abschnitt <types> die zum Datenaustausch mit dem Web Service notwendigen Datentypen definiert. Hierfür wird der XML-Schema-Standard des W3Cs verwendet. Die in diesem Abschnitt definierten Datentypen können dann im WSDL-Dokument verwendet werden, um die Eingabe- und Ausgabeparameter des Web Service darzustellen.
<types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/buch/suche.xsd"
xmlns="http://www.example.com/buch/suche.wsdl">
<xs:element name="buchSuchen" type="AnfrageTyp"/>
<xs:element name="buchTreffer" type="AntwortTyp"/>
<xs:element name="eingabeUngueltigFehler"
type="xs:string"/>
<xs:complexType name="BuchTyp">
<xs:sequence>
<xs:element name="Autor" type="xs:string"/>
<xs:element name="Titel" type="xs:string"/>
<xs:element name="ISBN" type="xs:string"/>
<xs:element name="Preis" type="xs:double"/>
<xs:element name="Stichwort" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnfrageTyp">
<xs:sequence>
<xs:element name="Buch" type="BuchTyp"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AntwortTyp">
<xs:sequence>
<xs:element name="Buch" type="BuchTyp"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</types>
In dem Listing werden die drei Typen „buchSuchen“, „buchTreffer“ und „eingabeUngueltigFehler“ definiert. „buchSuchen“ wird verwendet, um die Suchkriterien aufzunehmen, „buchTreffer“ stellt die Trefferliste dar, die der Benutzer als Ausgabe erhält. „eingabeUngueltigFehler“ legt die Nachricht fest, die im Falle eines Fehlers an den Nutzer gesendet wird.
„buchSuchen“ und „buchTreffer“ nutzen den Datentyp „BuchTyp“. Er wird nicht nur zur Angabe der Suchkriterien verwendet, sondern auch für die Elemente der Trefferliste.
Das Element „<interface>“
Die WSDL-Komponente <interface> beschreibt eine Menge von Nachrichten, die ein Service senden oder empfangen kann. Sie enthält typischerweise eine Menge von Operationen, die „Interface Operations“, über die ein Aufrufer mit einem Web Service interagiert.
Das folgende Listing definiert das Interface-Element für das obige Beispiel:
<interface name="sucheInterface">
<fault name="eUAusnahme" element="bsns:eingabeUngueltig"/>
<operation name="opSuchen"
pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="bsns:buchSuchen"/>
<output messageLabel="Out" element="bsns:buchTreffer"/>
<outfault ref="tns: eUAusnahme" messagelabel ="Out" />
</operation>
</interface>
Im Beispiel besitzt das Interface des Web Service eine einzige Operation: „opSuchen“. Die Operation verwendet als Message Exchange Pattern „in-out“. Als Eingabe wird hierfür der im Abschnitt <types> definierte Typ „buchSuchen“ verwendet. Die Ausgabe des Dienstes nutzt den Typ „buchTreffer“.
Sollte ein Fehler auftreten, wird dieser über „eUAusnahme“ abgefangen. Er gibt Informationen über den aufgetretenen Fehler zurück.
Das Element „<binding>“
Der Abschnitt <binding> beschreibt, wie ein Web Service mit dem Client kommuniziert, also: welches Transportprotokoll (z. B. SOAP und HTTP) verwendet werden soll und wie die Daten der einzelnen Operationen kodiert werden sollen. Für jedes unterstützte Transportprotokoll gibt es ein eigenes <binding>-Element.
Eine <binding>-Komponente kann hierbei eine gesamte Schnittstelle mit all ihren Operationen und darüber hinaus einzelne Operationen dieser Schnittstelle sowie auch Fehler näher beschreiben.
Das folgende Listing zeigt ein passendes <binding>-Element für das Buchbeispiel.
<binding name="sucheSOAPBinding"
interface="tns:suchelnterface"
type=http://www.w3.org/2004/08/wsdl/soap12
wsoap:protocol="http://www.w3.org/.../bindings/HTTP">
<operation ref="tns:opSuchen"
wsoap:mep="http://www.w3.org/.../mep/request-response"/>
<fault ref="tns:eUAusnahme" wsoap:code="soap:Sender"/>
</binding>
Das Listing spezifiziert das vom Web Service zu verwendende Protokoll SOAP. Zudem wird auf die Operation „opSuchen“ Bezug genommen, um das oben abstrakt eingeführte Message Exchange Pattern konkret anzugeben. „fault“ legt fest, wann ein Fehler auftreten soll, im Beispiel wird ein SOAP-Fehlercode angegeben, der den Fehler auslösen soll.
Die Element „<service>“ und „<documentation>“
Zuletzt wird definiert, wo der Web Service erreicht werden kann. Hierbei müssen konkrete Adressen angegeben werden. Mit dem Element <service> lässt sich für jedes Interface eines Dienstes eine Menge von <endpoints> angeben. <endpoints> sind Zugangspunkte, über die sich der Dienst erreichen lässt.
<service name="sucheService" interface="tns:sucheInterface">
<endpoint name="sucheEP"
binding="tns:sucheSOAPBinding"
address="http://www.example.com/buch/suche"/>
</service>
In dem Beispiel-Listing wird festgelegt, dass der Bücher-Suchdienst unter der Adresse http://www.example.com/buch/suche erreicht werden kann.
Schlussendlich enthält der Abschnitt <documentation> eine Textbeschreibung des Dienstes. Dem Anbieter des Dienstes steht es hier frei, weitere Angaben zur Nutzung des Service und seiner Schnittstellen zu machen. Zudem kann man hier Ansprechpartner nennen, zu denen im Bedarfsfall Kontakt aufgenommen werden kann.
<documentation>
Dies ist die Beschreibung des Buch-Suche Web Service.
Bei Problemen wenden Sie sich bitte an support@example.com
</documentation>
Weitere Elemente
Es gibt noch weitere WSDL-Elemente, auf die wir hier nur kurz verweisen wollen.
Das Element „<import>“
Das <import>-Element ist für die Einbindung von externen WSDL-Ressourcen zuständig. Da XML für verteilte Umgebungen entwickelt wurde, kann sich ein XML-Dokument aus vielen Dokumententeilen zusammensetzen, die auch an verschiedenen Orten abgelegt sein können. Dies ist sinnvoll, wenn der zu beschreibende Web Service mit bereits existierenden Services zusammenarbeitet. Wenn sich einer dieser Services ändert, muss nur ein Einzelteil der gesamten Servicebeschreibung geändert werden.
Das Element „<portType>“
Im Abschnitt <portType> werden Operationen beschrieben. Eine Operation (<operation>) besteht aus bis zu zwei Nachrichten. Soll eine Antwort an den Sender zurückgesendet werden, so wird die eingehende Nachricht (<input>) mit einer ausgehenden Nachricht (<output>) zu einer Operation zusammengefasst. Es werden natürlich nur die im Abschnitt <message> beschriebenen Nachrichten verwendet. Mehrere Operationen bilden schließlich einen Port-Typ. Eine WSDL-Beschreibung kann mehrere <portType>-Elemente enthalten.
Das Element „<message>“
In einem <message>-Element werden die Nachrichten beschrieben, die zwischen Client und Server gesendet werden. Ein <message>-Element enthält die Parameter, die in den Nachrichten übergeben werden. Nachdem im <message>-Element spezifiziert wird, welche Nachrichten zwischen Client und Server fließen, lassen sich mithilfe des <portType>-Elements die am Web Service aufrufbaren Methoden definieren.
Fazit
WSDL stellt ein XML-Vokabular zur Beschreibung von Schnittstellen sowie deren Operationen und Diensten dar. Die technische Beschreibung eines Dienstes – etwa die genaue Netzwerkadresse, das Nachrichtenformat oder Übertragungsprotokoll – wird dabei von der abstrakten Beschreibung der Funktionalität eines Dienstes getrennt. Dies ermöglicht eine wieder verwendbare, modulare Schnittstellendeskription, die sich in mehrere WSDL-Dokumente aufteilen lässt.
Für die Entwicklung von WSDL-Dokumenten stehen verschiedene Tools bereit wie etwa die Eclipse Web Tools Platform (WTP). Sie beinhalten Funktionen wie Wizards zum Erzeugen von WSDL-Dokumenten. Das WTP-Projekt besteht aus Quelltexteditoren für HTML, Javascript, CSS, JSP, SQL, WSDL und andere Sprachen sowie aus einem grafischen Editor für XSD und WSDL. (ala)
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 (in Planung) |
Verzeichnisdienste für Web Services / UDDI |
|
Teil 6 (in Planung) |
Web Services und Sicherheit |