Spezifikation von Webservices mittels WSDL
Fallstricke frühzeitig erkennen und vermeiden
von Dr. rer. nat. Christoph Hartmann
Webservices
Webservices ermöglichen die Bereit-stellung von plattformunabhängigen, ver-
teilten Diensten. Sie bilden damit die Basis für serviceorientierte Architekturen (SOA). Die dadurch angestrebte lose Koppelung der Einzelkomponenten erlaubt es, die Systemlandschaft kontinuierlich an neue Bedürfnisse anzupassen – z. B., indem neue Komponenten bestehende Dienste nutzen, neue Dienste eingeführt, Kommunikationspfade verändert und ver-altete Komponenten ausgetauscht wer-
den. Damit solche Änderungen isoliert von anderen Komponenten durch-
geführt werden können, ist es von zentraler Bedeutung, dass die Schnittstellen der Webservices unabhängig von ihrer konkreten Implementierung spezifiziert werden (eine gute Übersicht bieten Zimmermann et al.1).
WSDL
Bei der Spezifikation von Webservices kommt typischerweise die Web Services Definition Language (oder auch Web Services Development Language, IBM), kurz WSDL2,3, zum Einsatz. Diese Spezifikationssprache für Webservices basiert auf dem XML-Format. Sie wird vom World Wide Web Consortium (kurz: W3C) spezifiziert, das auch Formate wie XML, PNG oder HTML definiert und weiterentwickelt.
Mittels WSDL lassen sich folgende Eigenschaften einer Webservice-Schnittstelle beschreiben:
- die Definitionen der Ein- und Ausgabemethoden
- die Datenstrukturen der Ein- und Ausgabe
- das zu verwendende Kommunikationsprotokoll
- das Antwortverhalten der Kommunikationspartner
- die Adressen, mit denen die Dienste assoziiert sind
Sobald die WSDL eines Anbieters von Webservices (Service Provider) festgelegt ist, ist sie damit gemeinsamer Ausgangspunkt sowohl für die Ent-wicklung des Webservice selbst als auch für die Entwicklung von Nutzern des Dienstes (Service Consumer, Clients).
Programmierschnittstellen wie Apache CXF oder das .NET Framework bieten die Möglichkeit, Programmcode automatisch aus der WSDL zu generieren. Er dient dann als Basis für die weitere Entwicklung von Applikationen. Auch für die Modellierung von Geschäftsprozessen mittels BPEL (Business Process Execution Language) ist eine Modellierung der Schnittstellen mit WSDL nötig.
Kommunikationsstil und Nachrichtenformat
WSDL ist jedoch leider nicht gleich WSDL. Im Bindungsabschnitt der WSDL werden die Protokolle und Formate spezifiziert, mittels derer Nachrichten des Dienstes ausgetauscht werden können. Er legt fest, wie auf einen vorher definierten Dienst zugegriffen werden kann. Hier werden auch die Attribute „style“ und „use“ definiert. Das Attribut „style“ legt den Inhalt der SOAP-Nachricht fest und kann zwei Werte annehmen: „rpc“ falls die SOAP-Nachricht einem Remote Procedure Call entspricht, oder „document“ falls die Nachricht ein beliebiges XML-Dokument enthält. Das Attribut „use“ ist von „style“ unabhängig und kann die Werte „encoded“ oder „literal“ annehmen (die Kombination document/encoded hat keine praktische Relevanz).
Im „encoded“-Stil wird auf externe Regeln, die SOAP-Codierung, verwiesen, die die Übersetzung von Typen der Programmiersprache in SOAP-Typen festlegen. Der „literal“-Stil dagegen erzwingt, dass jeder Teil der SOAP-Nachricht eine Definition aus dem WSDL-Schema referenziert, was hier eine Abhängigkeit von externen Schemata vermeidet. Für eine detaillierte Übersicht über die Attributkombinationen und ihre Vor- und Nachteile soll hier auf einen Übersichtsartikel von R. Butek4 verwiesen werden.
Fallstricke
Erst nach der Festlegung der WSDL kann die Entwicklung von Clients beginnen. Eine nachträgliche Änderung der WSDL, z. B. eine Änderung der oben beschriebenen Attribute, kann drastische Mehraufwände bei der Entwicklung verursachen, da sie
auch eine Anpassung des Programmcodes aller Clients verlangt. Zudem wird oftmals
der aus der WSDL generierte Code nicht strikt von der sonstigen Programmlogik getrennt. Es ist daher lohnenswert, die Eigenschaften einer WSDL zu analysieren, ggf. zu modifizieren und an die Bedürfnisse der zu unterstützenden Geschäfts-
prozesse anzupassen, bevor sie zur Schnittstellendefinition verwendet wird.
Gerade ältere Systeme verwenden die Attributkombination rpc/encoded, die nicht konform mit der Spezifikation WS-I () Basic Profile ist. Damit sind solche WSDLs inkompatibel mit heute üblicherweise verwendeten Programmbibliotheken, die auf dieser Spezifikation aufbauen, wie z. B. JAX-WS 2.0 (Java API for XML – Web Services), die auch in moderne Entwicklungsumgebungen integriert sind. Möchte ein Entwickler einen solchen Webservice nutzen, muss er speziell für diesen auf veraltete Programmbibliotheken zurückgreifen, z. B. Apache Axis 1.x. Ein Testprogramm für WSDL-WS-I-Compliance kann über die Homepage der Web Service Interoperability Organization bezogen werden5.
Auch bestimmen die Attribute „type“ und „use“ das Format der zu übertragenden XML-Nachrichten. Im Fall der Kombination rpc/encoded werden Typinformationen der Parameter unnötigerweise mit- übertragen (die WSDL ist ja Sender und Empfänger bekannt). Dies vergrößert die Gesamtlänge der XML-Nachricht mit einem nicht zu vernachlässigenden Einfluss auf die Performance des Web- Service6:
Zum einen steigt das Lastaufkommen im Netzwerk, zum anderen müssen die SOAP-Nachrichten wegen ihrer Größe in mehrere TCP-Pakete fragmentiert werden (1460 Bytes Nutzlast im Ethernet für TCP/IP, abzgl. des Overheads für HTTP und SOAP).
Diese Einzelnachrichten müssen an-schließend am Empfänger wieder zu-
sammengesetzt werden. Die Kommuni-kation wird damit insgesamt anfälliger für Verzögerungen durch Paketverluste, die in verschiedenen Szenarien auftreten können, z. B. durch Überlast oder mobile Clients. Bei der Modellierung einer Webservice-Schnittstelle kann mittels Prototypen für Service Provider/Clients der Netzverkehr simuliert werden.
Das Lastverhalten des Webservice und eine mögliche Fragmentierung der SOAP-Nachrichten können so durch eine Analyse des Netzverkehrs, z. B. mit dem Hochleistungs-Tracer caplon, bestimmt werden.
Fazit
Die WSDL spielt eine zentrale Rolle bei der Spezifikation von Webservices. Von ihrer korrekten und mit der WS-I konformen Formulierung hängen die Leistungsfähigkeit und die Zukunfts-sicherheit einer Webservice-Schnittstelle ab. Unter Umständen kann sich auch die Reimplementierung einer bestehenden rpc/encoded-Schnittstelle lohnen, der hier entstehende Aufwand einer Neuformulierung der WSDL, einschließlich der Weiterentwicklung von Service Provider und bereits existierenden Clients, sollte dem zukünftig zu erwartenden Mehraufwand bei der Entwicklung von Clients gegenübergestellt werden.
