Ob Wörterbuch oder Wetterbericht, immer mehr Dienste stehen im Internet als Webservice bereit. Per Tcl-SOAP binden auch Tcl-Entwickler diese Dienste bequem in ihre Software ein.

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.

Alles drin

Anders als bei CORBA oder Java-RMI sind in der WSDL sowohl die Methoden und Typen als auch die Betriebsparameter eines Dienstes in einer einzelnen Datei definiert. Dieses WSDL-File genügt, um Webservices zu nutzen ohne sich aufwändig um CORBA-Namensdienste oder RMI-Registries zu kümmern.

Passend zum WSDL aus Listing 1 zeigen die Listing 2a und 2b eine XML-Anfrage und -Antwort. Die Anfrage in Listing 2a enthält im »SOAP-ENV:Body«-Element ab Zeile 6 die XML-Struktur, wie sie im WSDL definiert ist. Für die Operation »CtoF« (Zeilen 7 bis 9) gibt es ein Element, das für den Eingabeparameter »temp« ein Unterelement mit dem Eingabewert enthält. Ähnlich ist der Aufbau der Antwort in Listing 2b, die im Unterelement »return« (Zeile 9) das Ergebnis der Umwandlung liefert.

Abbildung 2: Dank Tcl-SOAP ist es leicht, in eigenen Programmen fremde Webservices zu verwenden. Das abgebildete Tool (Listing 5) befragt Amazon, um Daten für ein Literaturverzeichnis zu sammeln.

Innerein bleiben verborgen

Um den genauen Aufbau dieser komplex wirkenden Dokumente brauchen sich Tcl-Programmierer jedoch dank Tcl-SOAP kaum zu kümmern. Für eventuelles Debugging ist es aber hilfreich, die XML-Dateien zu verstehen.

01 <definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
02   xmlns:xs="http://www.w3.org/2001/XMLSchema"
03   xmlns:tns="http://www.borland.com/soapServices/"
04   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
05   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
06   name="ITempConverterservice"
07   targetNamespace="http://www.borland.com/soapServices/">
08 
09   <message name="CtoFRequest">
10     <part name="temp" type="xs:int"/>
11   </message>
12   <message name="CtoFResponse">
13     <part name="return" type="xs:int"/>
14   </message>
15 
16   <portType name="ITempConverter">
17     <operation name="CtoF">
18       <input message="tns:CtoFRequest"/>
19       <output message="tns:CtoFResponse"/>
20     </operation>
21   </portType>
22 
23   <binding name="ITempConverterbinding" type="tns:ITempConverter">
24     <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
25     <operation name="CtoF">
26       <soap:operation soapAction="urn:TempConverterIntf-ITempConverter#CtoF"/>
27       <input>
28         <soap:body use="encoded"
29               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
30               namespace="urn:TempConverterIntf-ITempConverter"/>
31       </input>
32       <output>
33         <soap:body use="encoded"
34               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
35               namespace="urn:TempConverterIntf-ITempConverter"/>
36       </output>
37     </operation>
38   </binding>
39 
40   <service name="ITempConverterservice">
41     <port name="ITempConverterPort" binding="tns:ITempConverterbinding">
42       <soap:address location="http://developerdays.com/cgi-bin/tempconverter.exe/soap/ITempConverter"/>
43     </port>
44   </service>
45 </definitions>

Tcl-SOAP bedient sich der bereits vorhandenen Tcl-Erweiterungen Tcl-XML und Tcl-DOM [10] sowie des HTTP-Moduls aus der Tcllib und ergänzt, was für das SOAP noch notwendig ist. Moderne Linux-Distributionen oder die Tcl-Distribution von Activestate [11] enthalten bereits alle diese Module. Sie stattdessen manuell zu installieren gelingt auch ohne großen Aufwand.

Eingeseift

Die Tcl-SOAP-Erweiterung ist komplett in Tcl geschrieben und braucht folglich keinen Compiler. Soll das Modul für alle Anwender auf dem System bereitstehen, muss es im systemweiten Suchpfad für Tcl-Erweiterungen installiert sein. Dieser Pfad ist schnell ermittelt: »tclsh« aufrufen und »puts $auto_path« eintippen, dann tauchen beispielsweise folgende Verzeichnisse auf:

• /usr/local/lib/tcl8.5
• /usr/local/lib
• /usr/local/lib/tcllib1.7
• /usr/local/lib/tklib0.2

Beim Starten sucht Tcl in jedem dieser Directories nach Erweiterungenen. Ein sinnvolles Plätzchen für Tcl-SOAP wäre »/usr/local/lib/tclsoap1.6.7«, dann haben alle Benutzer Zugriff. Wer das nicht will oder dort keine Schreibrechte hat, wählt eine beliebige Stelle und erweitert den Suchpfad. Hierzu genügen folgende Zeilen am Anfang jedes Skripts, das Tcl-SOAP verwenden will:

lappend auto_path /home/cz/lib/tclsoap
package require SOAP

Bei einigen Linux-Distributionen ist die Tcl-XML-Version zu neu für die neueste Tcl-SOAP-Version. Wer die Fehlermeldung »require dom package greater than 1.6« erhält, obwohl Tcl-DOM 3.0 installiert ist, findet bei den Quellen für diesen Artikel [14] ein gepatchtes Tcl-SOAP.

01 <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
02   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
03   xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
04   xmlns:xsd="http://www.w3.org/1999/XMLSchema"
05   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
06     <SOAP-ENV:Body>
07       <ns:CtoF xmlns:ns="http://www.borland.com/soapServices">
08         <temp xsi:type="xsd:int">100</temp>
09       </ns:CtoF>
10     </SOAP-ENV:Body>
11 </SOAP-ENV:Envelope>

01 <SOAP-ENV:Envelope .... >
02   <SOAP-ENV:Body>
03     <NS1:CtoFResponse xmlns:NS1="urn:TempConverterIntf-ITempConverter"
04                       SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
05       <return xsi:type="xsd:int">212</return>
06     </NS1:CtoFResponse>
07   </SOAP-ENV:Body>
08 </SOAP-ENV:Envelope>

01 # Initialisierung
02 lappend auto_path tclsoap1.6.7
03 package require xml
04 package require dom
05 package require SOAP
06 
07 # Abfrage definieren...
08 SOAP::create CtoF 
09     -uri "http://www.borland.com/soapServices" 
10     -proxy "http://developerdays.com/cgi-bin/tempconverter.exe/soap/ITempConverter" 
11     -params {"temp" "int"} 
12 
13 # ... und ausführen
14 for {set c -40} {$c <= 100} {incr c 20} {
15     puts "$c°C = [CtoF $c]°F"
16 }
17 
18 # Anzeige: letzter Aufruf und Antwort
19 puts stderr "nAnfrage"
20 puts stderr [SOAP::dump -request CtoF]
21 
22 puts stderr " nAntwort"
23 puts stderr [SOAP::dump -reply CtoF]

100° Fahrenheit

Das erste Beispielprogramm in Listing 3 nutzt den einfachen Webservice aus der WSDL-Datei in Listing 1. Er rechnet Temperaturangaben von Grad Celsius in Grad Fahrenheit um. In Tcl-SOAP erzeugt der Programmierer mit dem Kommando »SOAP::create« ein eigenes Tcl-Kommando, das zu der Operation passt, die in WSDL beschriebenen ist. Aus der WSDL-Datei übernimmt er den Namen der Operation »CtoF« (Listing 1, Zeile 17) als Namen des Tcl-Befehls (Listing 3, Zeile 8), aus »targetnamespace« (1, Zeile 7) wird der »uri«-Parameter (3, Zeile 9) und die »location« (1, Zeile 42) wird zum »proxy«-Parameter (3, Zeile 10).

Die gewünschte Struktur für die Eingabe besteht aus einer Liste mit dem Namen und Typ der Variablen, in diesem Beispiel (Listing 3, Zeile 11) genügt ein Integer-Parameter namens »temp«.

Neues Kommando

Das neue Tcl-Kommando »CtoF« verwandelt – wie in Zeile 15 gezeigt – beliebige Temperaturen von Grad Celsius in Grad Fahrenheit. Der Anwender braucht sich nicht um die passenden XML-Strukturen zu kümmern, seine Eingaben schreibt er hinter das Kommando in Form einer für Tcl üblichen Liste. Gleiches gilt für die Ausgabe, sie enthält in diesem Fall nur den berechneten Wert.

Die Tcl-SOAP-Erweiterung sorgt bequemerweise für die Umwandlung der Ein- und Ausgabewerte aus der XML-Struktur in Tcl-Listen. Um diesen Schritt besser zu verstehen, schreiben die Zeilen 20 und 23 mit »SOAP::dump« die letzte Abfrage und Antwort als XML-Struktur auf die Standardausgabe. Die Ausgabe findet sich in den Listings 2a und 2b.

Verschachtelt

Für die Praxis relevanter als ein einfaches Rechenexempel sind Abfragen großer Datenbanken, wie sie Google oder Amazon pflegen. Die Firmen betreiben zusätzlich zu ihrer Webseite auch einen Webservice. Im Gegensatz zu dem einfachen Dienst aus Listing 1 nutzen sie häufig komplexe Datenstrukturen für Anfrage und Antwort. Listing 4 zeigt einen kurzen Ausschnitt aus der WSDL-Datei für Amazon.

Die Anfrage enthält ein »ItemSearch«-Element (Zeilen 1 bis 10) mit den drei Werten »SubscriptionId« (Zeile 4), »Validate« und »Request«. Die ersten beiden Elemente sind vom Typ »string«, das dritte ist ein »ItemSearchRequest«. Dieser komplexe Typ ist in den Zeilen 12 bis 21 definiert und enthält mehrere Strings. Solche geschachtelten Strukturen sind etwas kniffliger zu benutzen, das Beispiel in Listing 5 zeigt, wie es geht.

Der »SOAP::create«-Aufruf erwartet komplexe Strukturen in Listenform. Zeile 19 enthält Name-Typ-Paarungen. Das Format der Unterstrukturen legen »rcpvar::typedef«-Kommandos (Zeilen 10 bis 14) fest. Für »ItemSearchRequest« aus dem WSDL nutzt das Beispiel den Typ »ItemSearchRequestT« (Zeile 14) und gibt ihn bei der »params«-Option an (Zeile 19).

Struktur in der Liste

Tcl-SOAP muss die Eingabelisten bei jeder Anfrage WSDL-entsprechend schachteln. Passend dazu definiert Zeile 23 eine Liste für diese geschachtelte Anfrage, Zeile 24 verwendet sie wie einen normalen Parameter.

Die Antwort von Amazon besteht wieder aus einem XML-Dokument mit zwei bis drei geschachtelten Elementen, Tcl-SOAP erzeugt entsprechend geschachtelte Tcl-Listen. Die Prozedur namens »schlüsselwort« (Zeilen 22 bis 34) extrahiert aus dieser Antwort ab Zeile 26 dann die IDs für die gefundenen Bücher. Die Download-Dateien für dieses Federlesen [14] enthalten Listing 5 in einer ergänzten Fassung, die Amazons Buchkatalog nach Büchern mit dem Schlüsselwort »Tcl/Tk« durchforstet und das Ergebnis ausgibt (siehe Abbildung 2).

01 <xs:element name="ItemSearch">
02   <xs:complexType>
03     <xs:sequence>
04       <xs:element name="SubscriptionId" type="xs:string" minOccurs="0"/>
05       <xs:element name="Validate" type="xs:string" minOccurs="0"/>
06       <xs:element name="Request" type="tns:ItemSearchRequest" minOccurs="0" maxOccurs="unbounded"/>
07       <!-- gekürzt -->
08     </xs:sequence>
09   </xs:complexType>
10 </xs:element>
11 
12 <xs:complexType name="ItemSearchRequest">
13   <xs:sequence>
14     <xs:element name="Author" type="xs:string" minOccurs="0"/>
15     <xs:element name="Keywords" type="xs:string" minOccurs="0"/>
16     <xs:element name="ResponseGroup" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
17     <xs:element name="SearchIndex" type="xs:string" minOccurs="0"/>
18     <xs:element name="Title" type="xs:string" minOccurs="0"/>
19     <!-- gekürzt -->
20   </xs:sequence>
21 </xs:complexType>

01 package require dom
02 package require SOAP
03 package require XMLRPC
04 package require rpcvar
05 
06 set validate false
07 set SubscriptionId "Zugangsschlüssel"
08 
09 # Typdefinition für die geschachtelte Struktur
10 rpcvar::typedef {
11     ResponseGroup stringValue
12     Keywords      stringValue
13     SearchIndex   stringValue
14 } ItemSearchRequestT
15 
16 # Erzeugt Kommando
17 SOAP::create ItemSearch -uri http://webservices.amazon.com/AWSECommerceService/2005-07-26 
18     -proxy http://webservices.amazon.de/onca/soap?Service=AWSECommerceService 
19     -params {SubscriptionId stringValue Validate stringValue Request ItemSearchRequestT}
20 
21 # Gibt eine Liste mit IDs für eine Suche nach Schlüsselwort
22 proc schlüsselwort {schlüssel} {
23     set itemSearchRequest [list ResponseGroup ItemIds Keywords $schlüssel SearchIndex Books]
24     set antwort [ItemSearch $::SubscriptionId $::validate $itemSearchRequest]
25 
26     set Items [lindex $antwort 8]
27     set retval {}
28     foreach {var value}  $Items {
29         if {[string match Item $var]} {
30             lappend retval [lindex $value 1]
31         }
32     }
33     return $retval
34 }

Abbildung 3: Mit Ramdebugger hat Tcl-Guru Dennis LaBelle ein Tool entwickelt, das Fehler in Tcl- und C/C++-Programme aufspürt. Tcl-Skripte (hier Listing 5) instrumentiert der Debugger, bevor er sie ausführt.

Tcl-SOAP ist auch bei so komplexen Webdiensten wie Amazon verblüffend einfach. Die Antwort auf eine Suche liefert gut strukturierte Ergebnisse, die sich leicht in Tcl-Code auswerten lassen. Die größte Hürde für Programmierer ist, dass sie selbst die Dienst-Spezifikation in der WSDL-Datei verstehen und in Tcl umsetzen müssen. Leider fehlt noch ein Werkzeug, das aus der WSDL-Datei automatisch passenden Tcl-Code erzeugt. Die Entwickler arbeiten aber schon an einem solchen Tool. (fjl)

Das Neueste

Linus Torvalds äußert sich selten über Anwendungen im Userland, aber vor kurzem schrieb er in der GIT-Mailingliste: “I have to say, with tcl/tk, ‚google’ + ‚random typing’ can make you appear to know what the hell you’re doing.” (Ich muss zugeben, dass es mit Tcl/Tk genügt, Google zu befragen und ein bisschen zu tippen, um den Eindruck zu erwecken, dass man genau wisse, was man tut.) Das schnelle Entwickeln funktionsfähiger Anwendungen stößt offenbar auch bei gestandenen C-Programmierern wie Torvalds auf Zustimmung. Neben dem unvermeidlichen Google haben Tcl-Programmierer die Wahl zwischen vielen praktischen Helfern, zum Beispiel den Debugger Ramdebugger (Abbildung 3, [15]) und die grafische Entwicklungsumgebung Tkpro-E (Abbildungen 4a und 4b, [16]). Hinter Letzterer steckt Dennis LaBelle, der mit seinem Skript-Wrapper Freewrap [17] bekannt wurde. Die Entwicklungsumgebung konzentriert sich auf das Entwerfen von Oberflächen, was durch den eingebauten GUI-Builder ziemlich schnell geht. Ramdebugger ist ein grafischer Entwanzer für Tcl-Skripte und C-Programme. Abbildung 4a: Die Entwicklungsumgebung Tkpro-E bringt einen bequemen GUI-Builder für Tcl/Tk-Oberflächen mit. Viele kleine und große Helfer Sind alle (bekannten) Fehler beseitigt, hilft Tk-CVS [18] beim Einchecken in einen CVS-Server (Concurrent Versions System). Das Tool besticht mit einer enormen Funktionalität, mit der sich auch in großen Verzeichnissen und Branch-Strukturen schnell navigieren lässt. Tk-CVS übertrifft locker den CVS-Support von IDEs wie Netbeans oder Eclipse. Wer sich eher für den Inhalt seiner Festplatte interessiert, sollte einen Blick auf Xapian [19] investieren. Diese C++-Bibliothek indiziert und durchsucht Dateisysteme. Eine Tcl-Erweiterung gehört zum Lieferumfang – damit steht einer konkurrenzfähigen Desktopsuche [20] mit Tcl nichts im Weg. Abbildung 4b: Zum GUI-Builder in Tkpro-E gehört ein umfassender Properties-Editor für die Eigenschaften der Widgets.