SOAP mit Axis

Ein Akronym als Programmname wählen liegt seit langem im Trend und so spielte dieses Motiv bei der Namensfindung von SOAP ([1] und [2]) wohl auch eine Rolle: Die Abkürzung steht für Simple Object Access Protocol. Mittlerweile gilt das XML-basierte Protokoll beim Einsatz von XML-RPC (XML Remote Procedure Call) als Standardlösung. Das Projekt Axis ermöglicht dem Webserver Apache die Verwendung von Webservices mit Hilfe von SOAP.

RPC, CORBA, RMI & Co.

Remote Procedure Call (RPC) funktioniert immer gleich: Programm A möchte eine Funktion (Methode, Unterprogramm) eines Programms B aufrufen. B hat einen eigenen Adressraum und befindet sich möglicherweise auf einem entfernten Rechner. Ein so genann- ter Stub simuliert für das Programm A die Funktion des entfernten Pro- gramms.

Der Stub übernimmt die Argumente, wandelt sie in ein Transportformat um - dieser Vorgang heißt Serialisierung - und schickt sie über eine Netzwerkverbindung ans Programm B.

Die Stubs haben also die Aufgabe, die Funktionsargumente korrekt zu serialisieren, eine Netzwerkverbindung zu öffnen und die Daten übers Netz zu verschicken. Dann empfangen sie das Ergebnis des Funktionsaufrufs und wandeln es wieder in einen Wert oder ein Objekt um (Deserialisierung). Der RPC-Programmierer muss sich also nicht um diese technischen Details kümmern, er braucht nur ein sprachenspezifisches Werkzeug, das den Stub generiert.

Die RPC-Implementationen unterscheiden sich durch die verwendeten Programmiersprachen und Transportprotokolle. CORBA[3] zum Beispiel unterstützt verschiedene Sprachen, benutzt aber ausschließlich ein Binärprotokoll. Unter Java findet häufig RMI[4] Verwendung; es kommuniziert zwar über Plattformgrenzen hinweg, ist jedoch stets auf genau diese Programmiersprache angewiesen.

SOAP geht einen Schritt weiter: Dank zahlreicher Stub-Generatoren ist es weitgehend sprachunabhängig. Zur Serialisierung verwendet SOAP XML, so ist es auch in puncto Protokoll nicht wählerisch. Typischerweise benutzt man es über HTTP, aber da es sich bei XML lediglich um Text handelt, sind auch SMTP, Messenger-Protokolle und andere Übertragungswege denkbar.

Bei der Performance bietet SOAP keine überragende Leistung, aber es zielt auch auf einen anderen Verwendungszweck als RMI oder CORBA. Als textbasiertes Übertragungsprotokoll hat es keine Probleme mit Firewalls oder Proxies und eignet sich deshalb dazu, beliebige Funktionen im Internet bereitzustellen, also Webservices.

SOAP-Protokoll und Webservices

SOAP wurde nicht speziell für RPC entworfen, Abbildung 1 zeigt den grundsätzlichen Aufbau einer SOAP-Meldung. Der SOAP-Envelope enthält optional SOAP-Header-Einträge und dazu zwingend einen SOAP-Body. Letzterer enthält die so genannte Nutzlast der Nachricht, also die eigentlichen Daten, in einem applikationsspezfischen Format. Die Header steuern die Verarbeitung und sind ebenfalls applikationsspezifisch, aber unabhängig von der Nutzlast. Listing 1 zeigt ein Beispiel.

Im eingangs beschriebenen Szenario - Programm A ruft eine Methode des Programms B auf - ist der Stub für die formale Implementation der Methode verantwortlich. Dazu definiert man zuerst die Methode, um aus dieser Definition den Stub zu generieren.

CORBA verwendet dazu eine eigene Sprache, die Interface Definition Language (IDL,[3]). Ein IDL-Compiler erzeugt den Stub, je nach Implementation in C, C++, Java, Python oder einer anderen Sprache. Das Java-basierte RMI braucht keine eigene Sprache zu diesem Zweck, hier reicht ein geeignetes Interface, das der RMI-Compiler anschließend übersetzt[4].

Webservices unterscheiden sich von klassischen Webformularen hauptsächlich durch die Möglichkeit, sie aus anderen Programmen direkt ansprechen zu können. Denn im Gegensatz zu den Formularen ist ein Webservice mit der Webservice Definition Language (WSDL,[5]) formal beschrieben.

Die WSDL entspricht der IDL von CORBA oder im Falle von RMI den Java-Interfaces, sie generiert die Client-Stubs. WSDLs schreibt man aber selten selbst, meist erledigt das ein Anwendungssystem, das auch die Webservices erstellt. Die Implementation der Service-Seite erfolgt dann mit den Mitteln des Anwendungssystems, die des Clients in einer beliebigen Programmiersprache.

Um einen Webservice zu beschreiben, verwendet die WSDL sechs Elemente: »Types«, »Messages«, »PortTypes«, »Bindings«, »Ports« und »Services«. Die »Types« beschreiben Datentypen, aus denen sich die »Messages« zusammensetzen, also die Basis der Kommunikation. Ein »PortType« gibt die abstrakte Beschreibung einer Operation wieder und verwendet Ein- und Ausgabe-Messages. Das »Binding« verknüpft diese Beschreibung mit einem Protokoll, meist SOAP - die W3C-Definition nennt alternativ HTTP GET/POST und MIME. Ein »Port« stellt die Zuordnung eines Bindings an eine Adresse (URI) dar, also die kleinste tatsächlich nutzbare Einheit. Mehrere Ports bilden zusammen einen »Service«, der allerdings lediglich aus einer logischen Klammer besteht.

Abbildung 1: Eine SOAP-Nachricht besteht aus einem optionalen Header und dem Body.

01 <?xml version='1.0' ?>
02 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
03  <env:Header>
04   <m:reservation xmlns:m="http://travelcompany.example.org/reservation"
05           env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
06            env:mustUnderstand="true">
07    <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
08    <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
09   </m:reservation>
10   <n:passenger xmlns:n="http://mycompany.example.com/employees"
11           env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
12            env:mustUnderstand="true">
13    <n:name>ke Jógvan ¯yvind</n:name>
14   </n:passenger>
15  </env:Header>
16  <env:Body>
17   <p:itinerary
18     xmlns:p="http://travelcompany.example.org/reservation/travel">
19    <p:departure>
20      <p:departing>New York</p:departing>
21      <p:arriving>Los Angeles</p:arriving>
22      <p:departureDate>2001-12-14</p:departureDate>
23      <p:departureTime>late afternoon</p:departureTime>
24      <p:seatPreference>aisle</p:seatPreference>
25    </p:departure>
26    <p:return>
27      <p:departing>Los Angeles</p:departing>
28      <p:arriving>New York</p:arriving>
29      <p:departureDate>2001-12-20</p:departureDate>
30      <p:departureTime>mid-morning</p:departureTime>
31      <p:seatPreference/>
32    </p:return>
33   </p:itinerary>
34   <q:lodging
35    xmlns:q="http://travelcompany.example.org/reservation/hotels">
36    <q:preference>none</q:preference>
37   </q:lodging>
38  </env:Body>
39 </env:Envelope>