Die Dienste der Großen sind gefährlich und lohnen der Mühe nicht, die sie kosten. – Gotthold E. Lessing Es ist der Erfolg, der die großen Männer macht. – Napoleon Bonaparte

Kapitel 20 Web Services

Es scheint ein ungeschriebenes Gesetz in der IT-Branche zu sein, dass es jedes Jahr ein Hype-Thema gibt. In den letzten Jahren waren das so wohlklingende Begriffe wie »Multimedia«, »WAP« oder »XML«. Auch die Zyklen, die die entsprechenden Technologien durchlaufen, ähneln sich. Zunächst wird das Thema hochgejubelt, und jeder Wanderprediger preist die neue technische Wunderwelt. Bremser, die unangenehme Fragen der Art »Wo ist der Nutzen für die breite Masse?« oder »Wo sind die Praxisanwendungen?« stellen, werden niederdiskutiert. Im schlimmsten Fall ist sogar ein neues »Wort des Jahres« geboren.¹  Dabei ist es egal, ob es sich um eine Programmiersprache, eine Technik oder ein Betriebssystem handelt; das Muster ist immer dasselbe. Nun gut, die lauten Stimmen bekommen nach und nach prominenten Widerspruch. Mehr und mehr zuvor fanatische Verteidiger rücken von ihrer Einstellung ab, einige sehen ihre vorschnelle Begeisterung für ein noch unreifes Thema ein, andere handeln so wider besseres Wissen, um ihre Pfründe zu retten. Nach und nach ebbt der Hype ab, und die IT-Welt kehrt wieder zur Normalität zurück.

Sobald sich der Nebel jedoch gelichtet hat, fangen einige kluge Köpfe an, das Konzept noch einmal zu betrachten, entwerfen Lösungen, stellen Machbarkeitsstudien an und entwickeln die Technologie weiter. Oftmals wird dann erneut versucht, die Technik einer breiteren Masse zugänglich und schmackhaft zu machen. Und manchmal klappt das sogar. Das beste Beispiel hierfür ist XML. Jeder, der vor ein paar Jahren etwas auf sich hielt, war ein selbst ernannter XML-Experte. Erfolgreich durchgeführte Projekte konnte jedoch fast niemand vorweisen. Heutzutage ist XML überall zu finden, das Format ist schon etabliert und weiter auf dem Vormarsch. Und die Moral von der Geschicht´ – respektive von dieser längeren Kapiteleinleitung: Springen Sie nicht auf jeden Zug auf, der gerade vorbeifährt!

Aber: Sehen Sie ihn sich zunächst einmal an – es könnte ja sein, dass Sie später noch einsteigen möchten.

Dieses Kapitel behandelt ein Thema, das seit Längerem ebenfalls ziemlich hochgejubelt wird, sich aber beständig hält und damit gute Zukunftsaussichten hat – Web Services. Sie sehen, worum es sich hierbei überhaupt handelt und wie Sie mit JavaScript auf solche Web Services zugreifen können. Betrachten Sie Web Services vor allem mit AJAX und JSON im Hinterkopf, welche manchmal die bessere (und ebenfalls gehypte) Wahl sind.

20.1 Was sind Web Services? 

Was aber ist nun so ein Web Service? Nun, Web Services gibt es eigentlich schon seit mehreren Jahren. In letzter Zeit jedoch ist das Thema sehr populär geworden. Ein Grund dafür ist die Firma Microsoft beziehungsweise ihre .NET-Strategie, denn ein Teil dieser Strategie sind auch Web Services. Das Thema .NET hat derart weite Kreise gezogen, dass mittlerweile sogar an Open-Source-Implementierungen gearbeitet wird. Wir wollen in diesem doch sehr plattformneutralen Buch die Anti-Microsoft-Fraktion nicht über Gebühr strapazieren, weswegen wir .NET größtenteils außen vor lassen (und an den Stellen, an denen wir es trotzdem behandeln, begründen wir das ausführlich).

20.1.1 Verteiltes Arbeiten 

Aber zurück zum Thema Web Services: Eines der wichtigen Schlagwörter heißt »Distributed Computing« oder »verteilte Anwendungen«. Es geht darum, Teile einer Anwendung auch auf anderen Rechnern laufen zu lassen. Dazu gab es früher schon Ansätze, beispielsweise DCOM (Distributed Component Object Model). Die zunehmende Verbreitung des Internets hat jedoch dazu geführt, dass nach neuen Möglichkeiten gesucht wurde, verteilte Anwendungen zu organisieren – am besten unter Verwendung von Internetprotokollen.

Mit Hilfe von Web Services können einzelne Webapplikationen miteinander kommunizieren. Das Trägerprotokoll ist http, denn dieses Protokoll ist bereits überall im Internet in irgendeiner Form implementiert. Als weitere Technik kommt XML (eXtensible Markup Language) zum Einsatz. Die Daten bei Web Services werden im XML-Format übergeben, denn es bietet eine standardisierte Möglichkeit, Daten zu speichern.

Die einzelnen Daten, die bei einem Web Service hin- und hergeschickt werden, sind im SOAP-Format gespeichert. SOAP stand einst für »Simple Object Access Protocol«, ist jedoch weder simpel noch hat es etwas mit Objektzugriff zu tun, und ein Protokoll im eigentlichen Sinne des Begriffs ist es auch nicht. Deswegen steht SOAP mittlerweile nur noch für ... SOAP. Aber zurück zum Thema: SOAP ist eine Vorschrift, die angibt, wie die einzelnen Daten verpackt werden müssen. Als Beschreibungssprache innerhalb einer SOAP-Nachricht wird übrigens – wen wundert's – XML eingesetzt.

Sie müssen sich das Vorgehen folgendermaßen vorstellen: Angenommen, Sie benötigen eine Information, beispielsweise die aktuelle Uhrzeit (atomgenau), den Börsenkurs einer Firma oder darüber, ob es von dem JavaScript-Buch bereits eine neue Auflage gibt. Sie schicken dann eine SOAP-Nachricht an einen Web Service und rufen dort die gewünschte Funktionalität ab. Der Web Service antwortet auch (mehr oder weniger) prompt und schickt Ihnen das Ergebnis zurück, ebenfalls per SOAP.

In diesem Kapitel werden wir als durchgängiges Beispiel etwas Einfacheres verwenden. Wir überprüfen per Web Service, ob eine Zahl eine Primzahl ist oder nicht. Sie sehen später, warum wir ausgerechnet dieses Beispiel ausgewählt haben.

20.1.2 WSDL 

Ein Web Service erwartet gewisse Parameter, die an ihn übergeben werden (im Primzahltest beispielsweise die Zahl, die überprüft werden soll). Außerdem ist der Rückgabewert eines Web Service ebenfalls von einem bestimmten Wert. Damit ein Programm oder ein Skript, das auf einen Web Service zugreifen will, weiß, welche Parameter erwartet werden und welche zurückgeliefert werden, muss es eine Art von Beschreibung des Dienstes geben. Diese wird in WSDL zurückgeliefert. Das Kürzel WSDL steht für »Web Services Description Language« und gibt (natürlich als XML) eine Beschreibung des Web Service zurück. Hier sehen Sie einen Auszug aus einer Beschreibung für den (momentan noch nicht vorhandenen) Primzahlen-Web-Service:

<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:s="http://www.w3.org/2001/XMLSchema" 
xmlns:s0="http://tempuri.org/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" 
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
   <types>
      <s:schema elementFormDefault="qualified"
         targetNamespace="http://tempuri.org/">
         <s:element name="istPrimzahl">
            <s:complexType>
               <s:sequence>
                  <s:element minOccurs="1" maxOccurs="1"
                              name="zahl" type="s:int" />
               </s:sequence>
            </s:complexType>
         </s:element>
         <s:element name="istPrimzahlResponse">
            <s:complexType>
               <s:sequence>
                  <s:element minOccurs="1" maxOccurs="1"
                     name="istPrimzahlResult"
                     type="s:boolean" />
               </s:sequence>
            </s:complexType>
         </s:element>
         <s:element name="boolean" type="s:boolean" />
     </s:schema>
  </types>
</definitions>

Diese Beschreibung sagt unter anderem aus, dass es einen Dienst namens istPrimzahl gibt.

<s:element name="istPrimzahl">

Es wird genau ein Parameter erwartet, der vom Typ int (für Integer) ist:

<s:element minOccurs="1" maxOccurs="1" name="zahl" type="s:int" />

Der Rückgabewert des Dienstes ist ein boolescher Wert:

<s:element name="istPrimzahlResponse">
   <s:complexType>
      <s:sequence>
         <s:element minOccurs="1" maxOccurs="1"
            name="istPrimzahlResult" type="s:boolean" />
      </s:sequence>
   </s:complexType>
</s:element>

20.1.3 Web Services aufrufen 

Es gibt mehrere Möglichkeiten, einen Web Service aufzurufen. SOAP haben wir ja bereits zuvor erwähnt. Hier folgt eine etwas ausführlichere Schilderung.

Bei der Verwendung von SOAP muss eine HTTP-Anforderung an den Web Service übermittelt werden. Eine HTTP-Anforderung besteht aus einem HTTP-Header und (optional) dem eigentlichen Inhalt. Zwischen dem Header und dem Inhalt ist immer eine Leerzeile.

Der HTTP-Header einer SOAP-Web-Service-Anforderung sieht etwa folgendermaßen aus:

POST /Primzahlen HTTP/1.1
Host: servername
Content-Type: text/xml; charset=utf-8
Content-Length: 349
SOAPAction: "http://servername/Primzahlen/istPrimzahl"

Darauf folgen eine Leerzeile und dann der eigentliche Inhalt. Dort wird zunächst ein <soap:Envelope>-Element erstellt. Dieses dient als »Umschlag« (die deutsche Übersetzung des englischen envelope) für die eigentliche SOAP-Nachricht. Die Daten selbst stehen innerhalb des Elements <soap:Body>. Da der Web Service istPrimzahl heißt, wird ein Element <istPrimzahl> verwendet. Dort wird der Parameter angegeben. Der Name des Parameters ist zahl, also heißt das entsprechende Element <zahl>.

Wenn Sie das alles zusammenfassen, erhalten Sie als Inhalt der HTTP-Anforderung Folgendes:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <istPrimzahl xmlns="http://servername/">
         <zahl>1021</zahl>
      </istPrimzahl>
   </soap:Body>
</soap:Envelope>

Alternativ ist es möglich, den Aufruf eines Web Service per GET oder POST zu realisieren. Der Grund ist naheliegend. SOAP hat unbestritten Vorteile. In vielen Umgebungen sind jedoch GET und POST bereits implementiert, beispielsweise im Webbrowser. Insbesondere GET ist sehr einfach zu erreichen, indem die notwendigen Daten einfach per URL angegeben werden. Der (noch fiktive) Primzahl-Web-Service könnte also wie folgt aufgerufen werden:

http://servername/Primzahlen/istPrimzahl?zahl=1021

Wie Sie in dem WSDL-Ausschnitt des vorigen Absatzes sehen können, hat der Parameter, der an den Web Service übergeben wird, den Namen zahl. Obiger Aufruf würde also den Web Service veranlassen zu überprüfen, ob 1021 eine Primzahl ist oder nicht.

Die HTTP-Anforderung würde hierbei folgendermaßen aussehen:

GET /Primzahlen/istPrimzahl?zahl=1021 HTTP/1.1
Host: servername

Wenn Sie POST verwenden, sieht Ihre HTTP-Anforderung in etwa wie folgt aus:

POST /Primzahlen/istPrimzahl HTTP/1.1
Host: servername
Content-Type: application/x-www-form-urlencoded
Content-Length: 9

zahl=1021

Der Parameter wird also als Name-Wert-Paar im Inhalt der HTTP-Anforderung übermittelt; zwischen dem HTTP-Header und dem HTTP-Inhalt steht eine Leerzeile als Trennzeichen.

Wie die Antwort des Web Service aussieht, hängt von der verwendeten Aufrufmethode, also SOAP, GET oder POST ab. Bei den beiden letzteren Möglichkeiten, GET oder POST, ist die Antwort ein einfaches XML-Dokument, das den Rückgabewert enthält:

<?xml version="1.0" encoding="utf-8"?>
<boolean xmlns="http://servername/">true</boolean>

Bei SOAP sieht das schon anders aus; hier ist auch der Rückgabewert vollständig SOAP, also inklusive <soap:Envelope> und <soap:Body>:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <istPrimzahlResponse xmlns="http://servername/">
         <istPrimzahlResult>true</istPrimzahlResult>
      </istPrimzahlResponse>
   </soap:Body>
</soap:Envelope>

Sie sehen also, wie Sie nun serverseitig Web Services implementieren können. Die SOAP-Implementierung ist hierbei die aufwändigste, aber für komplexere Web Services die flexibelste. Die Erstellung von GET- und POST-Web-Services geht etwas schneller von der Hand.