SOAP-Webservices mit Tcl nutzen

In den unendlichen Weiten des Internets entsteht eine neue Generation von Onlinediensten, die für automatisierte Abfragen optimiert sind. Mit standardisierten Methoden greifen eigene Programme auf Wörterbücher oder die aktuellen Wetterdaten zu. Anders als herkömmliche Webseiten sind diese Dienste jedoch nicht über einen Browser zu nutzen (Abbildung 1). Eigene Webservice-Clients zu entwickeln ist dank standardisierten Protokolls und guter Bibliotheken recht einfach - auch und gerade unter Tcl. Für den Entwickler sind die Dienste kaum schwerer zu verwenden als einfache lokale Bibliotheksfunktionen.

Webservice-Client und -Server kommunizieren meist über SOAP (Simple Object Access Protocol, [1]). Das Protokoll basiert auf einer Entwicklung von Dave Winner und Microsoft und wurde im Jahr 2000 vom W3C (World Wide Web Consortium) standardisiert. Während vergleichbare Techniken wie CORBA (Common Object Request Broker Architecture) oder Java-RMI (Remote Method Invocation) binäre Datenübertragungsprotokolle verwenden, war die Idee hinter SOAP eher simpel. Die Anfrage an den Server und seine Antwort kodiert SOAP als XML-Textdokument, das es per HTTP transportiert.

Transport per HTTP

Der Vorteil: Das HTTP-Protokoll und das Verarbeiten von XML-Dokumenten sind bewährte Techniken. Da die Daten wie normale Webseiten wirken, überqueren sie mühelos fast jede Firewall. Andererseits braucht das geschwätzige XML (öffnende und schließende Tags, jede einzelne Stelle eines Zahlenwerts per Ascii-Zeichen dargestellt) deutlich mehr Bandbreite als ein binäres Format und es ist aufwändiger zu parsen. Aber beim Debugging glänzt XML, da der Inhalt für Menschen recht verständlich aussieht. Wegen seiner Einfachheit ist SOAP bei Entwicklern recht beliebt.

Damit sich Client und Server verstehen, muss beiden der Aufbau der XML-Anfragen und -Antworten bekannt sein. Für deren Definition ist ein weiteres XML-Dokument zuständig, diesmal in der Web Services Description Language (WSDL). Seit Anfang 2001 ist die Spezifikation beim W3C verfügbar [2], inzwischen liegt der Entwurf für die Version 1.2 vor. Mit Kenntnis der WSDL-Datei kann der Client ein passendes XML-Dokument für seine Anfrage erzeugen und er kennt den Aufbau der Antwort.

Webservice Description Language

WSDL-Dokumente beschreiben die Kommunikationsmethoden (mit deren Anfragen und Antworten) sowie die Serveradresse eines Webservice. Das gekürzte Beispiel in Listing 1 stammt von der Entwicklerseite Developer Days [9]. Es spezifiziert eine Methode zur Umwandlung von Grad-Celsius-Temperaturen in Grad Fahrenheit.

Der erste Teil einer WSDL-Datei legt die Datenstrukturen (Types) fest sowie Anfrage- und Antwortformate (Messages) und die Methoden (Operation). Für die Beschreibung der Types und Messages greift WSDL auf XML-Schema-Typen zurück, die primitive Typen wie Strings, Zahlen oder einen Datumstyp bereits enthalten. Benutzerdefinierte Strukturen definiert sie wie in XML-Schema. Derartiges ist in Listing 1 nicht enthalten, da sowohl die Anfrage »CtoFRequest« (Zeile 9) als auch die Antwort »CtoFResponse« (Zeile 12) mit Integerzahlen auskommen. Erst ein Ausschnitt aus dem später vorgestellten Amazon-WSDL (Listing 4) braucht neue XML-Strukturen, wie sie aus XML-Schema bekannt sind.

Ab Zeile 16 definiert Listing 1 den Anschlusspunkt »portType name="ITempConverter"«, er enthält ab Zeile 17 einzig die Operation »CtoF«. Als Anfrage und Antwort sind die Messages »CtoFRequest« und »CtoFResponse« erlaubt (Zeilen 18 und 19), ihre Definition steckt in den Zeilen 9 bis 14. Für den Fehlerfall könnte das WSDL noch ein »fault«-Element als Antwort spezifizieren.

Der zweite Teil der Datei beschreibt ab Zeile 23 den Serverdienst mitsamt Adresse und Protokolleinzelheiten. Das »soap:binding«-Element in Zeile 24 bestimmt HTTP als Transportprotokoll - SOAP würde ebenso per E-Mail oder FTP funktionieren. In den Zeilen 28 und 33 definiert ein »soap:body«-Element das Encoding der ausgetauschten Nachrichten. Das »service«-Element (Zeile 40) enthält als letztes dann die URL des Dienstes.

Abbildung 1: Den Versuch, per Browser auf ihn zuzugreifen, quittiert der Temperaturumwandlungs-Webservice von Developer Days mit dieser Fehlermeldung. Er erwartet eine XML-kodierte SOAP-Anfrage, die aber kein Browser sendet.