Dienste leisten

Beim Blick auf die verschiedenen Definitionen von Web Services entsteht der Eindruck, bei dieser Technik handele es sich um alten Wein in neuen Schläuchen. Betrachtet man zum Beispiel einen Web Service als ein Programm im Internet, das mit standardisierten Protokollen aufzurufen ist, so zeigt sich, dass ähnliche Verfahren schon lange existieren, etwa CORBA, RMI, (D)COM oder CGI.

Wie kommt es also, dass ein solcher Boom rund um das Thema ausgebrochen ist und sich viele Unternehmen auf die zugehörigen Techniken stürzen? Und was unterscheidet die heutige Definition der Web Services von den oben erwähnten Vorgängern?

Obwohl das Augenmerk des Tutorials auf der Implementierung und Nutzung von Web Services mit Java sowie den damit verbundenen Schwierigkeiten liegt, vorab ein paar Worte zu diesen Fragen. Wer sich tiefergehend mit Web Services beschäftigen möchte, sei auf die Literatur verwiesen [1, 2, 6, 7, 8].

Web Services: Anfänge und Neuzeit

Während sich durch CORBA, RMI oder (D)COM in vielen Fällen verteilte Applikationen erstellen ließen, behandelten sie häufig nur Teilaspekte der Kommunikation. So gewährleisten sie zum Beispiel nicht in allen Fällen eine vollständige Unabhängigkeit von Plattform und Programmiersprache. Auch werden häufig nur Remote Procedure Calls unterstützt, nicht aber ein auf Dokumenten basierender Ansatz. Schließlich sind die verwendeten Übertragungsprotokolle nicht immer völlig unabhängig vom jeweiligen Verfahren.

Web Services der Neuzeit sind so konzipiert, dass sie ein Höchstmaß an Interoperabilität bieten. Als Marketing-Beispiel dafür dient häufig die reibungslose Kommunikation der beiden Kontrahenten .NET und Java. Dies gelingt unter anderem durch das Verpacken von Daten in XML. Zum Transport über das Netz setzen Web Services auf standardisierte Protokolle wie HTTP oder SMTP. Neben Remote Procedure Calls, also Aufrufen entfernter Methoden und Funktionen, verarbeiten Web Services dokumenten-basierte Nachrichten.

Da die Definition des Dienstes und seine Umsetzung klar getrennt sind, lassen sich Softwaresysteme lose koppeln. Zusätzliche Unterstützung dafür bieten asynchrone Kommunikationsverfahren.

Service-orientierte Architekturen

Web Services liegt eine Service-Oriented Architecture (SOA) zugrunde. Dieses Entwurfsmuster kommt zum Einsatz, wenn es um die lose Anbindung beziehungsweise Integration einer Applikation geht [5]. SOA ist ein Modell, in dem drei verschiedene Rollen drei unterschiedliche Interaktionen auf einem Web Service durchführen. Bei den Rollen handelt es sich um

• den Service Provider,
• die Service Registry und
• den Service Requestor.

Service Provider nennt man den Besitzer beziehungsweise Anbieter eines Dienstes. Handelt es sich um einen Web Service, verfügt er über eine XML-basierte Beschreibung und eine Implementierung in einer Programmiersprache. Die Art des Zugriffs, also das verwendete Protokoll, bleibt dem Provider überlassen. Da sich aber als Quasistandard SOAP (Simple Object Access Protocol) über HTTP etabliert hat, nutzen alle im Tutorial gezeigten Beispiele diese Protokollkombination. Im Sinne einer Client/Server-Beziehung kann der Provider als die Serverseite gelten.

Am ehesten lässt sich die Service Registry als eine Art Gelbe Seiten für Web Services beschreiben, in denen ein Service Provider Informationen über sich und seine Dienste hinterlegt. Daneben beinhaltet sie Daten zum Aufruf eines Services und zu seiner Verwendung. Durch die Suche und Klassifizierung von Web Services vermag der potenzielle Nutzer zusätzlich Dienste zu bewerten, untereinander zu vergleichen und bei Bedarf dynamisch zu binden.

Eigentlicher Nutzer des Dienstes ist der Service Requestor. Es kann sich bei ihm sowohl um eine Person handeln, die via Browser einen Service findet und nutzt, als auch um ein Stück Software, etwa einen anderen Web Service, der dies automatisch erledigt. In einer Client/Server-Beziehung stellt der Service Requestor den Client dar.

Kennt der Service Requestor den anbietenden Provider und die Details des Aufrufs, kann er den Web Service ohne Zugriff auf die Service Registry nutzen.

Zwischen den drei Rollen gibt es drei Interaktionen:

• Veröffentlichen,
• Finden,
• Binden.

Beim Veröffentlichen übergibt der Service Provider Informationen über sich und den angebotenen Dienst an eine Service Registry.

Dienste im Web suchen

Ist ein Dienst registriert, können ihn interessierte Service Requestors finden. Dazu senden sie eine XML-Abfrage an die Registry. Sie spezifiziert den gewünschten Dienst durch verschiedene Suchkriterien. Dazu können neben der Einordnung des Dienstes in eine bestimmte Kategorie Aspekte wie die Qualität oder die vom Service Provider unterstützten Protokolle gehören.

Obwohl hier der Begriff ‘Qualität eines Service’ (QoS) auftaucht, sollte man sich bewusst sein, dass sich derlei bei einer Dienstleistung nicht einfach quantifizieren lässt. Auf diesen Aspekt geht der dritte Teil des Tutorials ein.

Binden ist die dritte und letzte Interaktion zwischen den verschiedenen Rollen innerhalb des SOA-Modells. Dadurch kommt die eigentliche Client/Server-Beziehung zustande. Es sei betont, dass sich innerhalb der Registry zwar die Beschreibung eines Dienstes sowie eine Anleitung für seinen Aufruf befinden, nicht aber er selbst. Dieser ist stets beim Service Provider zu finden.

Auch beim Binden eines Service können verschiedene Mechanismen zum Zuge kommen. Neben dem einfachen statischen Binden kann zum Beispiel der Client dynamisch zur Laufzeit einen Proxy generieren, der die notwendigen Informationen durch die Servicebeschreibung erhält.

Drei beherrschende Techniken

Obwohl immer wieder die Flexibilität von Web Services hinsichtlich der zu verwendenden Protokolle betont wird, haben sich drei Basistechniken herauskristallisiert:

• Simple Object Access Protocol (SOAP),
• Web Service Description Language (WSDL),
• Universial Description, Discovery and Integration (UDDI).

SOAP spezifiziert eine Verpackung für den Transport von XML-Dokumenten über Internet-Protokolle wie HTTP, SMTP oder FTP. Aktueller Stand ist die Version 1.1, der Nachfolger bereits als Working Draft beim W3C zu besichtigen. WSDL basiert ebenfalls auf XML und beschreibt die Schnittstelle eines Web Service, insbesondere die Ein- und Ausgabeparameter sowie die zu verwendenden Protokolle. UDDI bildet die Grundlage der Service Registries; es dient der strukturierten Beschreibung von Unternehmen, deren Beziehungen untereinander, ihrer Dienste sowie weiterer Metadaten.

Während der drei Teile des Tutorials entwickelt sich ein einfaches Beispiel zu einer komplexen Applikation mit mehreren Web Services. Seine Quellen sind auf dem iX-Listingsserver in einem Paket erhältlich, zu dem Anleitungen zur Installation und zum Einsatz in einem README gehören.

Erste praktische Schritte

Ausgangspunkt ist folgendes Szenario: Der Geschäftsführer des kleinen und erfolgreichen Unternehmens my-NetService.com bittet seinen Entwicklungsleiter, den aktuellen Web-Auftritt mit möglichst wenig Aufwand attraktiver zu gestalten. Da das Unternehmen ohnehin schon genügend zu tun hat, soll jemand anders die eigentliche Dienstleistung erbringen. Die Website von my-NetService.com wird lediglich als Vermittler des Dienstes fungieren und sich somit über lange Sicht zu einem Serviceportal entwickeln.

Weil immer mehr Kunden aus dem Ausland die bisher nur in Deutsch verfügbaren Webseiten aufrufen, liegt es nahe, als erstes einen Übersetzungsdienst zu implementieren. Nach einer Marktanalyse stellt der Entwicklungsleiter fest, dass solche Dienste in den verschiedenen Formaten und unter Verwendung unterschiedlicher Protokolle verfügbar sind. Zudem bieten viele von ihnen neben einer proprietären Lösung eine via HTTP zugängliche Web-Service-Schnittstelle.

Da der gesamte Web-Auftritt des Unternehmens auf Java-Servlets und JSPs fußt, soll die Anbindung fremder Web Services ebenfalls Java benutzen. Um sich hier nicht auf das Angebot eines speziellen Herstellers festzulegen, sondern erstmal Erfahrungen mit der neuen Technik zu sammeln, entscheidet sich der Entwicklungsleiter für Suns frei verfügbares Web Service Development Pack.

AltaVista erledigt die Arbeit

Bei der Analyse der anfallenden Aufgaben stellt sich schnell heraus, dass die einzige Unbekannte im Projekt die Web-Service-Technik selbst ist. Um deren Risiken zu minimieren, soll im ersten Schritt ein einfaches Standalone-Servlet namens TranslationServlet entstehen, das einen Web Service aufruft und dessen Antwort entgegennimmt. Zur Realisierung sollen lediglich die Hilfsmittel des WSDP und keine weiteren APIs oder Tools von Drittanbietern zum Einsatz kommen. Um die Benutzung des Servlets komfortabler zu gestalten, ist zusätzlich eine Java Server Page zu implementieren, die das Eingeben eines zu übersetzenden Wortes erlaubt und das TranslationServlet aufruft. Die eigentliche Übersetzungsarbeit soll AltaVistas Übersetzungsdienst ‘Babelfish’ erledigen.

Für einen Abdruck ist das komplette Servlet zu lang. Es ist im Quell-Paket des Tutorials auf dem iX-Listingserver zu finden, und seine wesentlichen Teile erläutert der folgende Text. Listing 1 zeigt die vom Servlet erzeugte SOAP-Nachricht. Als Basis für die Implementierung dient die JAXM-API (Java API für XML Messaging).

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope 
        xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-env:Body>
      <m:BabelFish xmlns:m="urn:xmethodsBabelFish">
      <translationmode>de_en</translationmode>
      <sourcedata>Wissen</sourcedata>
      </m:BabelFish>
   </soap-env:Body>
</soap-env:Envelope>

Eine spätere zweite Variante dieses Web Services auf Basis der JAX-RPC-API wird zeigen, dass die hier gewählte Lösung etwas zu komplex für die Aufgabe ist. Während man mit dem JAX-RPC-API viele der Quellen automatisch generieren kann, müssen Entwickler sie bei der JAXM-Variante selber schreiben. Am Anfang steht aber absichtlich die JAXM-Implementierung, um die Zusammenhänge zwischen dem Aufruf eines Web Service und den zugehörigen Java-Klassen zu verdeutlichen.

Um die einzelnen Schritte innerhalb der doGet-Methode des TranslationServlets verstehen zu können, muss man den Aufbau einer SOAP-Nachricht betrachten: Sie verfügt über einen Part, in dem befindet sich wiederum der Envelope, der die eigentliche Nachricht umschließt, bestehend aus einem optionalen Header und dem Body. Neben dem SOAP-Part kann eine SOAP-Nachricht textuelle und binäre Anhänge beherbergen.

Verbinden, füllen, extrahieren

Um eine SOAP-Nachricht verschicken und im Anschluss eine Antwort empfangen zu können, muss man eine Verbindung aufbauen. Sie kann direkt zum Anbieter des Web Service oder zu einem so genannten Messaging Provider gehen (mehr zu den Vor- und Nachteilen der beiden Varianten bringt einer der nächsten Teile des Tutorials). Für das aktuelle Beispiel reicht eine direkte Verbindung aus. Das Servlet führt folgende Schritte aus:

1. Verbindung aufbauen;

2. SOAP-Nachricht erzeugen;

3. Nachricht mit Inhalt füllen;

4. Nachricht versenden;

5. Inhalt aus der Antwort extrahieren.

Der Aufbau der SOAPConnection folgt dem Factory-Pattern:

SOAPConnectionFactory soapConnectionFactory
       = SOAPConnectionFactory.newInstance();
connection = soapConnectionFactory.createConnection();

Auch zum Erzeugen der Nachricht dient dieses Entwurfsmuster:

MessageFactory messageFactory = MessageFactory.newInstance();
SOAPMessage message           =  messageFactory.createMessage();

Ein wenig komplizierter als diese ersten beiden trivialen Schritte gestaltet sich das Füllen der Nachricht mit Inhalt. Für jeden der oben aufgezählten Nachrichtenteile bietet die JAXM-API eigene Klassen. Beispielsweise repräsentiert SOAPMessage die SOAP-Nachricht, und SOAPEnvelope bildet den Umschlag ab. Der eigentlich zu füllende Teil (Body) gehört zum Envelope, der wiederum im SOAP-Part enthalten ist. Deshalb muss der Programmierer sich Schritt für Schritt zum Body vorarbeiten - ein direkter Zugriff ist nicht möglich.

SOAPPart     soapPart =   message.getSOAPPart();
SOAPEnvelope envelope =   soapPart.getEnvelope();
SOAPHeader   header   =   envelope.getHeader();
SOAPBody     body     =   envelope.getBody();

Nachdem der Body zugänglich ist, kann man ihn mit Inhalt füllen. Dazu ist ein Element für die aufzurufende Web-Service-Methode BabelFish unter Verwendung dreier Konstanten zu erzeugen:

SOAP_METHOD_NAME    = "BabelFish"
NS_REQUEST_PREFIX   = "m" 
NS_REQUEST_URI      = "urn:xmethodsBabelFish"

Name bodyName       = 
  envelope.createName(SOAP_METHOD_NAME, NS_REQUEST_PREFIX, NS_REQUEST_URI);
SOAPBodyElement babelFishMethod =  body.addBodyElement(bodyName);

createName(elementName, nameSpacePrefix, nameSpaceURI) legt das XML-Element elementName an, dem der Namespace-Prefix nameSpacePrefix zugeordnet wird, der wiederum eindeutig mit dem Namespace nameSpaceURI verbunden ist. Im Anschluss daran fügt die Methode addBodyElement() das eben erzeugte Element zum Body hinzu.

Als Resultat bekommt man folgendes SOAP-Fragment innerhalb des Body:

<m:BabelFish xmlns:m="urn:xmethodsBabelFish">
...
</m:BabelFish>

SOAP-Parameter übergeben

Laut Beschreibung benötigt der Babelfish-Web-Service die Parameter translationmode und sourcedata. Die SOAP-Spezifikation verlangt, diese innerhalb des Body-Elements zu platzieren:

Name translationModeName =      
    envelope.createName (SOAP_IN_PARAM_TRANSLATION_MODE);
SOAPElement translationModeParam = 
    babelFishMethod.addChildElement (translationModeName);
    translationModeParam.addTextNode (translateFromTo);
Name sourceDataName = envelope.createName (SOAP_IN_PARAM_SOURCE_DATA);
SOAPElement sourceDataParam =    
    babelFishMethod.addChildElement (sourceDataName);
sourceDataParam.addTextNode(textToTranslate);

Dies verläuft analog: Erst den jeweiligen Knoten erzeugen, dann im Body-Element ‘Babelfish’ platzieren. Die Werte der beiden ‘Parameterknoten’ setzt man mit addTextNode(paramValue). Durch das Hinzufügen dieser beiden Parameter kommen zum Aufruf des Web Service innerhalb des SOAP-Body zwei Elemente hinzu, was ihn vervollständigt:

<m:BabelFish xmlns:m="urn:xmethodsBabelFish">
    <translationmode>de_en</translationmode>
    <sourcedata>...</sourcedata>
  </m:BabelFish>

Es fehlen noch das Versenden der SOAP-Nachricht sowie das Empfangen und Auswerten der Antwort. Vor dem Versenden ist zunächst der Endpunkt zu bestimmen, an den sie gerichtet ist. Dies geschieht im Beispiel mit der Konstanten

ENDPOINT_URL = 
  "http://services.xmethods.net:80/perl/soaplite.cgi";

Die notwendigen Informationen über diese URL erhält man in der Regel durch eine öffentliche Beschreibung des Web Service oder durch den Anbieter direkt. Schließlich geht die Nachricht über die zu Beginn aufgebaute SOAP-Verbindung auf die Reise.

URLEndpoint endpoint = 
  new URLEndpoint(ENDPOINT_URL);
SOAPMessage soapResponse = 
  connection.call(message, endpoint);

Dass die URL an einen CGI-Aufruf erinnert, ist kein Zufall - CGI-Anwendungen können durchaus Web Services implementieren. Entscheidend ist, dass sie SOAP-Requests akzeptieren und SOAP-Antworten erzeugen.

Als Antwort trudelt eine neue SOAP-Nachricht ein, die die definierten Rückgabewerte beinhaltet (s. Listing 2). Bleibt noch, die Ausgabeparameter aus ihr zu extrahieren.

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope 
      xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
      SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
      xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"    
      xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
     <namesp1:BabelFishResponse xmlns:namesp1="urn:xmethodsBabelFish">
        <return xsi:type="xsd:string">knowledge</return>
     </namesp1:BabelFishResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Antwort lesen und verstehen

Da es sich beim SOAP-Request um einen Remote Procedure Call (RPC) handelt, ist die Struktur der Rückgabe durch die SOAP-Spezifikation vorgegeben: Das erste Kindelement des SOAP-Body muss die Antwort enthalten. Der Name dieses XML-Elements ist frei wählbar, er sollte allerdings laut Konvention aus dem Namen der aufgerufenen Methode und dem Wort ‘Response’ bestehen. Hier heißt dieses Element deshalb:

<namesp1:BabelFishResponse .... >
  ... 
</namesp1:BabelFishResponse >

Innerhalb des ersten Kindelements der Antwort wiederum steht der Rückgabe-Wert des RPC, bei Babelfish schlicht

<return ...>  ... </return>

Sollte der RPC über weitere Ausgabeparameter verfügen, so folgen diese im Anschluss in der Reihenfolge ihrer ursprünglichen Definition.

Da das Extrahieren der Rückgabewerte eines RPC-Aufrufs immer nach dem gleichen Muster verläuft, die Java-XML-APIs aber dafür keine Klassen zur Verfügung stellen, enthält das Web Service Tutorial die Klasse de.ix.wstutorial.util.soap.SOAPRPCResponse, deren Anwendung so aussieht:

String returnString = null;
...
/* SOAP Message versenden und SOAP Response erhalten */ 
SOAPMessage soapResponse = connection.call(message, endpoint);
/* SOAP RPC Response extrahieren */
SOAPRPCResponse soapRpcResponse =    
  SOAPRPCResponse.getSOAPRPCResponse (soapResponse);
/* Return Wert aus dem SOAP RPC Response Element extrahieren */
if (soapRpcResponse != null) {
  SOAPElement returnElement = 
    soapRpcResponse.getReturnElement();
  returnString = returnElement.getValue();
}
...

Jeder macht mal Fehler

Betrachtet man die einzelnen Schritte für den Aufruf eines Web Service, zeigen sich zahlreiche Fehlermöglichkeiten. Wurde zum Beispiel der Methodenname falsch geschrieben oder fehlt ein Parameter im SOAP-Body, liefert der Server automatisch eine Fehlernachricht wie in Listing 3 zurück.

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope 
...
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode xsi:type="xsd:string">SOAP-ENV:Server</faultcode>
         <faultstring xsi:type="xsd:string">
            Could not translate. Either the service cannot handle your input, 
            your connection to the babelfish site may be down or the site itself 
            may be expiencing difficulties
         </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Für das Verarbeiten solcher Fehler stellt die JAXM-API das Interface SOAPFault zur Verfügung, das über den SOAPBody erreichbar ist. Das folgende Listing zeigt beispielhaft die Behandlung einer Fehlernachricht:

/* Message senden */
SOAPMessage soapResponse = 
     connection.call(message, endpoint);
/* Body extrahieren */
...
/* Test auf Fehler */
if (responseSOAPBody.hasFault()) {
  SOAPFault soapFault =  responseSOAPBody.getFault();
  /* Fehler-Details extrahieren */
  String faultActor  = soapFault.getFaultActor();
  String faultCode   = soapFault.getFaultCode();
  String faultString = soapFault.getFaultString();
  ...
} else {
  /* Bearbeitung der korrekten Antwort */
  ...
}

Fremde Hilfe: TCP-Monitor

Bei der Bearbeitung von Requests und Responses kann es hilfreich sein, die hin und her reisenden Nachrichten im Klartext zu sehen, denn häufig sind kleine Vertipper Ursache für Fehler. Hilfe dafür bietet der TCP-Monitor aus dem Web-Services-Projekt ‘Axis’ der Apache-Group [4]. Er befindet sich als axis.jar im Package org.apache.axis.utils und kann mit

java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort]

gestartet und konfiguriert werden. Beim Aufruf nicht angegebene Parameter lassen sich später in der grafischen Konsole setzen. Der TCP-Monitor klemmt sich zwischen den Service Requestor und den Service Provider und ist so in der Lage, ein- und ausgehende Nachrichten zu protokollieren. Die zugehörige Konsole gibt nach passender Konfiguration die gewünschten Informationen aus (s. Abb. 3). Neben der eigentlichen SOAP-Nachricht zeigt sie alle protokollspezifischen Informationen (etwa HTTP-Header) an.

Bei zwischengeschaltetem Monitor sind Änderungen am ursprünglichen Web-Service-Aufruf erforderlich. Schließlich darf dieser nicht mehr direkt an den Service Provider, sondern muss an den TCP-Monitor gehen, etwa in dem man die Endpoint URL (siehe oben)

final static private String ENDPOINT_URL = 
  "http://services.xmethods.net:80/perl/soaplite.cgi";

ändert:

final static private String ENDPOINT_URL = 
  "http://localhost:8070/perl/soaplite.cgi";

Eine elegantere Lösung wäre das Auslagern dieser Informationen in eine Property-Datei oder einen Servlet-Parameter im Deployment Descriptor. Folgendes ist in der Konfiguration des TCP-Monitors bei geänderter Endpoint URL einzutragen:

Listen Port              = 8070 
Target Hostname     = services.xmethods.net
Target Port              = 80

WSDP statt Framework

Vergleicht man den beschriebenen Ablauf mit dem Aufwand bei Verwendung eines SOAP-Frameworks, so ist durchaus die Frage nach dem ‘warum’ gerechtfertigt. Der Hauptgrund für die Entscheidung pro WSDP und contra Frameworks liegt vor allem darin, dass Letzteren derzeit eine gemeinsame Basis fehlt. Während Sun jetzt erst mit der Spezifikation von APIs für Web Services beginnt, bestehen die meisten Frameworks schon deutlich länger - und sind deshalb proprietäre Lösungen.

Zwar bieten sie in der Regel einen deutlichen Mehrwert gegenüber dem WSDP, nutzen aber meistens einen völlig anderen Ansatz, als ihn die jüngst erschienen XML-APIs des WSDP verwenden. In der Vergangenheit setzten sich meistens die Vorgaben von Sun durch, sodass Frameworks und Tools in Zukunft ebenfalls die hier benutzten APIs verwenden dürften. Außerdem spricht für den Einsatz des WSDP statt eines Frameworks, dass der erhöhte Arbeitsaufwand das Verständnis für die neue Technik fördert.

Um allerdings nicht bei jedem neuen Beispiel unnötig viel Aufwand entstehen zu lassen, führt der nächste Teil des Tutorials eine kleine Bibliothek ein, die basierend auf den WSDP-Bibliotheken einige Hilfsklassen für die Arbeit mit SOAP mitbringt.

Literatur

[1] Sun Web Service Home Page: java.sun.com/webservices/

[2] W3C Web Service Activity: www.w3.org/2002/ws/

[3] xMethods: www.xmethods.com

[4] Apache Axis Home Page: xml.apache.org/axis/

[5] IBM Web Service Architect Paper: www-106.ibm.com/developerworks/webservices/library/ws-arc1/

[6] Java Web Services; D. A. Chappell, T. Jewell; O’Reilly; Sebastopol 2002; ISBN 0-596-00269-6

[7] Building Web Services with Java; S. Graham et al.; Sams Publishing 2001; ISBN 0-672-32181-5

[8] Professional XML Web Services; Z. Zaev et. al.; Wrox Press; Birmingham 2001; ISBN 1-86100-509-1

[9] Michael Marr; Java-Programmierung; Fleissige Ameise; Ant: Make-Alternative für Java; iX 2/2001, S. 56

[10] Peter Roßbach; Apache und Java; Web-Catering; Tomcat 3.2.1: Servlet- und JSP-Referenzimplementierung; iX 2/2001, S. 48

[11] Stefan Edlich; B2B-Standardisierung; Weiß, Gelb, Grün; UDDI: Geschäftsdaten bereitstellen und nutzen; iX 2/2001, S. 133