Java Web Services - Institut für Wirtschaftsinformatik

Westfälische Wilhelms-Universität Münster
Ausarbeitung im Rahmen des Softwaretechnik Seminars
„Java Web Services“
Jürgen de Braaf
WS 2004/ 2005
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Ch. Lembeck
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1
Einleitung................................................................................................................... 1
1.1
Definition von Web Services............................................................................ 1
1.2
Eigenschaften von Web Services...................................................................... 1
1.3
Apache EXtensible Interaction System (Axis) ................................................. 2
2
Einführendes Beispiel ................................................................................................ 2
3
Die drei Haupttechnologien von Web Services......................................................... 6
3.1
Simple Object Access Protocol (SOAP)........................................................... 7
3.2
Web Service Description Language (WSDL) ................................................ 11
3.3
Universal Description, Discovery, and Integration (UDDI)........................... 13
4
Zusammenfassung ................................................................................................... 16
5
Literaturverzeichnis ................................................................................................. 17
II
Kapitel 1: Einleitung
1 Einleitung
Im Folgenden werden die einzelnen Konzepte von Web Services unter der
Programmiersprache Java vorgestellt. Hierbei wird als SOAP-Implementierung Axis
(Apache EXtensible Interaction System) der Apache Software Foundation eingesetzt,
unter der auch die nachfolgenden Beispielprogramme ausgeführt werden.
1.1 Definition von Web Services
Nach [ChJe03] ist i. w. S. ein Web Service ein Stückchen Geschäftslogik, auf das über
standardisierte Internet Protokolle wie HTTP oder SMTP zugegriffen werden kann und
sich irgendwo im Internet befindet. I. e. S. sieht man jedoch Web Services als
Sammelbegriff neuer Technologien wie SOAP, WSDL, UDDI. Diese neuen
Technologien basieren auf standardisiertem XML und sind nicht Teil eines proprietären
Standards, wie zum Beispiel CGI-Skripte.
1.2 Eigenschaften von Web Services
XML-basiert
Das Einsetzen von XML als Basis soll Web Services von jeglichen Plattformen,
Betriebssystemen und Netzwerkprotokollen unabhängig machen. Dieser Anspruch
unterscheidet Web Services eindeutig von vorherigen Technologien.
Lose gekoppelt
Durch lose Kopplung will man erreichen, dass der Client unabhängig vom Interface
eines Web Service gestaltet werden kann. Ändert sich das Interface mit der Zeit, so soll
der Client weiterhin den Web Service ohne Anpassung nutzen können.
Grobkörnig
Web Services sollen grobkörnige Dienste darstellen, hinter denen viele verschiedene,
einzelne feinkörnige Operationen stehen und Damit möchte man Dienste anbieten, die
auf der Ebene eines gesamten Unternehmens nützlich sind.
Synchrone oder asynchrone Ausführung
Bei synchronen Aufrufen blockiert der Client und wartet auf die Antwort des Dienstes.
Im Gegensatz dazu können Clients bei asynchronen Aufrufen weiterarbeiten und
1
Kapitel 2: Einführendes Beispiel
Ergebnisse zu einem späteren Zeitpunkt abholen. Asynchrone Aufrufe unterstützen
dabei die lose Kopplung von Systemen.
Unterstützung von Remote Procedure Calls (RPCs)
Der Web Service Standard erlaubt das Aufrufen entfernter Prozeduren, Funktionen und
Methoden. Diese geben ihre Eingabe- und Ausgabeparameter bekannt, die wiederum
vom Web Service unterstützt werden müssen. Dabei kann der Web Service die Dienste
selbst bereitstellen oder den eingehenden Aufruf in einen Aufruf einer EJB- oder .NETKomponente übersetzen.
Unterstützung von Dokumentenaustausch
Mithilfe von XML sollen nicht nur Daten, sondern auch komplexe Dokumente
ausgetauscht werden können. Zum Beispiel ist der Austausch einer komplexen
Bedienungsanleitung oder Bildstruktur denkbar.
1.3 Apache EXtensible Interaction System (Axis)
Axis ist eine SOAP-Engine, mit der man Clients, Server und Gateways erstellen kann,
die mittels des Kommunikationsprotokolls SOAP miteinander kommunizieren. Dabei
stellt Axis eine API bereit, die einem viel Arbeit bei der Formulierung von SOAPAnfragen und Antworten abnimmt. Dies erspart einem XML Dokumente von Hand zu
erstellen und zu parsen. Mit der API wird ein stand-alone Server, ein plug-in für den
Tomcat-Server und Tools zum Erstellen von WSDL Dokumenten mitgeliefert.
2 Einführendes Beispiel
Zunächst betrachten wir ein einfaches Beispiel, anhand dessen später die einzelnen
Technologien (SOAP, WSDL, UDDI) vorgestellt werden. Als Beispiel fungiert ein
Dienst, der für eine ausgewählte Aktie den aktuellen Kurs zurückgibt. Der Client
CheckStockClient formuliert eine einfache SOAP-Anfrage mit einem Parameter, der
Wertpapierkennnummer (WKN), an den Web Service MyStockService. Für Testzwecke
vollkommen ausreichend besteht der Dienst aus einer Methode, die beim Aufruf eine
Zufallszahl zurückgibt, die den aktuellen Aktienkurs repräsentiert. Außerdem wird
davon ausgegangen, dass Axis und alle seine Bibliotheken mit Umgebungsvariablen
eingerichtet sind und eine Einbindung in den Tomcat-Server erfolgt ist. Für eine
2
Kapitel 2: Einführendes Beispiel
Installationsbeschreibung wird auf [Axis04] hingewiesen. Als Referenzadresse wird der
lokale Rechner mit der Adresse http://localhost:8080/axis verwendet.
Es folgt der Quelltext des Clients und des Dienstes:
/*
* Dieser Test Client demonstriert eine Web Service Anwendung,
* indem für eine bestimmte Aktie (WKN) und Datum der Schlusskurs
* vom Server zurückgegeben wird.
*/
package seminar.webservices;
// benötigte Klassen werden importiert
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;
import org.apache.axis.utils.Options;
import javax.xml.namespace.QName;
import javax.xml.rpc.ParameterMode;
/**
* Hier folgt die Klasse CheckStockClient, die eine Anfrage
* an den Server stellt.
*/
public class CheckStockClient {
/**
* Die Klasse besteht nur aus einer main Methode
* @param args
*/
public static void main(String [] args) {
try {
// Parameter werden in einem Options Objekt verarbeitet
// und zwischengespeichert
Options options = new Options(args);
String endpointURL = options.getURL();
args = options.getRemainingArgs();
String wkn = args[0];
String datum = args[1];
// erstelle ein neues Service Objekt
Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress( new java.net.URL(endpointURL) );
// die aufzurufende Methode wird ausgewählt
call.setOperationName( new QName("http://webservices.seminar",
"serviceStock") );
// Übergabeparameter und zugehörige Formattypen werden
eingerichtet
call.addParameter( "wkn", XMLType.XSD_STRING, ParameterMode.IN);
// Rückgabewert wird definiert
call.setReturnType(org.apache.axis.encoding.XMLType.XSD_STRING);
// Service wird aufgerufen und das Ergebnis wird gespeichert
double aktienkurs = new Double((String)(call.invoke( new
Object[] { wkn } ))).doubleValue();
3
Kapitel 2: Einführendes Beispiel
// Ausgabe des Aktienkurs
System.out.println("Der Schlusskurs für die Aktie mit der WKN "+
wkn +" lautet: " + aktienkurs);
} catch (Exception e) {
ystem.err.println(e.toString());
}
}
}
Quelltext 1: CheckStockClient.java
/*
* Dieser Test Server demonstriert eine Web Service Anwendung,
* indem für eine bestimmte Aktie (WKN) Kurs
* vom Client abgefragt werden kann.
*/
package seminar.webservices;
/**
* Diese Klasse steht für den Web Service "serviceStock" und wird
* durch den Server bei Anfragen aufgerufen und gibt den gewünschten
* Aktienkurs zurück.
* Für Testzwecke wird eine Zufallszahl zurückgegeben.
*/
public class MyStockService {
// die einzige Methode des Denstes
public String serviceStock(String arg) {
return new Double((double) (java.lang.Math.random() *
double)100)).toString();
}
}
Quelltext 2: MyStockService.java
Nachdem man die Java Klassen kompiliert vorliegen hat, sind folgende Schritte
durchzuführen, um den Dienst schließlich bereitzustellen und eine Testabfrage zu
starten:
1. Seitens Axis erfolgt das Bereitstellen des Dienstes MyStockService mithilfe
eines Web Service Deployment Descriptor (WSDD) im XML Format. Ein
WSDD kann natürlich auch für das Entfernen von Diensten benutzt werden.
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="MyStockService" provider="java:RPC">
<requestFlow>
<handler type="soapmonitor"/>
</requestFlow>
<responseFlow>
<handler type="soapmonitor"/>
</responseFlow>
<parameter name="className"
value="seminar.webservices.MyStockService"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>
Quelltext 3: deploy.wsdd
4
Kapitel 2: Einführendes Beispiel
Dieses XML Dokument deklariert den Namensraum Java und definiert diesen
Dienst als Remote Procedure Call. Als Parameter wird die Klasse des Dienstes
angegeben, die sich im Package seminar.webservices befindet.
Mit dem Aufruf java org.apache.axis.client.AdminClient deploy.wsdd in der
Kommandozeile wird das WSDD Dokument eingeladen und am Axis Server in
das zentrale Diensteverzeichnis server-config.wsdd eingepflegt.
Vorausgesetzt die Klasse liegt in dem Klassenverzeichnis des Axis webapps
Ordners vor, ist der Dienst nun unter der Adresse
http://localhost:8080/axis/services/MyStockService zu erreichen. Eine Liste von
allen registrierten Diensten ist unter http://localhost:8080/axis/services
aufgeführt. Die XML Anweisungen <requestFlow> und <responseFlow>
sind nicht weiter von Bedeutung, da hier nur für Testzwecke standardgemäß der
SOAP-Monitor eingebunden wird, der den SOAP-Austausch mitprotokolliert.
2. Ein Aufruf des Kommandos java seminar.webservices.CheckStockClient mit
dem Argument -lhttp://localhost:8080/axis/services/MyStockService "30392" in
der Kommandozeile ruft den Client mit der Adresse des Dienstes
MyStockService und der WKN 30392 auf und sollte bei fehlerfreier Ausführung
zur folgender Ausgabe führen:
Der Kurs für die Aktie mit der WKN 30392 lautet:
45.741958669707074
(Der Aktienkurswert wird natürlich variieren, da hier eine Zufallszahl verwendet
wird.)
Ein sehr nützliches Hilfsmittel ist hierbei der vorhin erwähnte SOAP-Monitor, der es
ermöglicht, die SOAP-Kommunikation zu verfolgen. In Abbildung 1 sieht man sowohl
die vom Client formulierte SOAP-Anfrage, als auch die Antwort des MyStockService.
In den nächsten Kapiteln wird der Syntax im Einzelnen erläutert.
5
Kapitel 3: Die drei Haupttechnologien von Web Services
Abbildung 1: SOAP-Monitor
3 Die drei Haupttechnologien von Web Services
Aus Abbildung 2 entnimmt man die einfache Interaktion einer Web Service
Anwendung. Zunächst sucht der Client in einer UDDI-Registrierungsstelle mittels
Namen, Bezeichnern, Kategorien oder den von Web Services implementierten
Spezifikationen nach einem Dienst und wählt diesen aus. Dort erhält der Client die
nötigen Information des Web Service in Form eines WSDL Dokuments, um in Kontakt
mit dem Dienst zu treten, indem der Client eine SOAP-Nachricht an den Host abschickt,
auf dem sich der Dienst befindet. Hinter diesem Dienst kann sich eine einfache
Anwendung verbergen, wie ein Fremdsprachenlexikon, eine komplexe Geschäftslogik,
wie das Buchungssystem einer Flugbörse oder der Dienst ist selber wieder nur Teil
einer Sammlung von vielen verschiedenen Diensten. Wichtig hierbei ist jedoch die
Betrachtung, dass jeder Dienst eine abgeschlossene, sich selbst beschreibende,
modulare Einheit darstellt. Exemplarisch werden in Abbildung 2 die Nachrichten über
das HTTP-Protokoll verschickt. SOAP ist jedoch unabgängig vom zugrunde liegenden
Transportprotokoll und kann genauso mit SMTP oder anderen geeigneten Protokollen
kombiniert werden.
6
Kapitel 3: Die drei Haupttechnologien von Web Services
Anwendung
Dienst
HTTP - Anfrage
SOAP Prozessor
SOAP-Client
HTTP - Antwort
Diskrete
Geschäftslogik
WSDL
UDDIRegistrierungsstelle
Abbildung 2: Interaktion mit einem Web Service
3.1 Simple Object Access Protocol (SOAP)
SOAP bildet ohne Zweifel das Rückgrat einer Web Service Anwendung, dessen
Entwicklung erst durch XML ermöglicht wurde. Dabei sieht man SOAP zugleich als
Kommunikationsprotokoll, RPC-Mechanismus und Standard für Interoperabilität an.
Jede SOAP-Nachricht besteht aus einem SOAP-Header und SOAP-Body, die
zusammen in einen SOAP-Envelope zusammengehalten werden (siehe Abbildung 3).
SOAP - Header
SOAP - Block
SOAP - Block
SOAP - Body
SOAP - Block
SOAP - Block
SOAP - Envelope
Abbildung 3: SOAP-Envelope
Der SOAP-Envelope Tag besteht, wie die SOAP-Anfrage aus dem Beispielprogramm
zeigt (Quelltext 4), aus drei obligatorischen Attributen, die den Namensraum und das
Schema angeben. Ein Namensraum in der XML Syntax ist vergleichbar mit der
Definition eines package in Java. In Zeile 3-5 leitet das Schlüsselwort xmlns diese
7
Kapitel 3: Die drei Haupttechnologien von Web Services
Namensraum- bzw. Schemadeklaration ein. Es ist üblich die URL der Organisation
auszuwählen, von der die jeweilige Spezifikation verabschiedet wird. Diese URL muss
nicht zwingend existieren, sondern nur die Eindeutigkeit dieses Strings innerhalb der
Nachricht ist relevant. In Zeile 3 deklarieren wir den Namensraum SOAP-Env für
unseren Envelope und setzen diese Bezeichnung innerhalb des Envelope, Header und
Body Tags ein. Den jeweiligen Namensraum eines Tags können wir somit vor dem
Doppelpunkt eines Tagnamens erkennen. Die Bezeichnung xsi aus Zeile 4 steht für den
Namensraum der XML Schema-Instanz, die in unserem Beispiel in Zeile 11 für die
Attributdefinition xsi:type der wkn verwendet wird und der Namensraum xsd aus
Zeile 5 steht für den XML Schema-Namensraum, hier in Zeile 11 bei einer String
Deklaration xsd:string verwendet.
1
<?xml version="1.0" encoding="UTF-8"?>
2
<SOAP-ENV:Envelope
3
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
4
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
5
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
6
<SOAP-ENV:Header>
7
</SOAP-ENV:Header>
8
<SOAP-ENV:Body>
9
10
11
<ns1:serviceStock xmlns:ns1="http://webservices.seminar">
<wkn xsi:type="xsd:string">30392</wkn>
</ns1:serviceStock>
12
</SOAP-ENV:Body>
13
</SOAP-ENV:Envelope>
Quelltext 4: SOAP-Anfrage
Für den SOAP-Header gibt es nach der SOAP 1.1 und SOAP 1.2 Spezifikationen keine
Konvention über den Inhalt. Dieser Block kann für Anweisungen an den empfangenen
SOAP-Prozessor verwendet werden. Hier kann zum Beispiel die Transaktions-ID
übergeben werden, wenn die dahinter liegende Anwendung einen Transaktionsmanager
einsetzt. Syntaktisch ähneln sich SOAP-Header und SOAP-Body, wobei die
eigentlichen Daten im Body zu finden sind. Das einfache Beispielprogramm aus Kapitel
2 verwendet keine Header Informationen. Im Body in Zeile 10 wird schließlich der
Namensraum ns1 mit der virtuellen Adresse deklariert, die hier mit dem package
Namen der Dienste Klasse korrespondiert und für den Methodenaufruf serviceStock
verwendet wird. Der Methoden Block enthält das Attribut wkn mit der Typdefinition
xsd:string und den Wert “30392“. Damit ist diese SOAP-Anfrage, die einen
8
Kapitel 3: Die drei Haupttechnologien von Web Services
Methodenaufruf beim Diensteempfänger veranlasst, komplett. Erzeugt wird diese
SOAP-Anfrage in der main-Methode der CheckStockClient Java-Klasse. Sie baut das
SOAP-Call Objekt zusammen und ruft den Dienst mit der WKN als Parameter auf und
speichert den Rückgabewert.
1
<?xml version="1.0" encoding="UTF-8"?>
2
<SOAP-ENV:Envelope
3
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
4
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
5
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
9
10
11
12
<SOAP-ENV:Body>
<ns1:serviceStockResponse xmlns:ns1="http://webservices.seminar">
<serviceStockReturn xsi:type="xsd:string">45.741958669707074
</serviceStockReturn>
</ns1:serviceStockResponse>
13
</SOAP-ENV:Body>
14
</SOAP-ENV:Envelope>
Quelltext 5: SOAP-Antwort
Der Dienst wiederum antwortet mit einer SOAP-Nachricht, die sich syntaktisch nicht
von der jeweiligen Anfrage unterscheidet. Nach guter Konvention fügt man dem Namen
der aufgerufenen Methode innerhalb des Body Elements ein „Response“ und dem
Rückgabewert ein „Return“ hinzu, um den Antwortcharakter zu verdeutlichen. Wie
genau letztendlich die Rückgabe benannt ist, lässt sich dem WSDL Dokument des
Dienstes entnehmen.
MIME - Header
SOAP - Envelope
SOAP - Header
SOAP - Block
SOAP - Block
SOAP - Body
SOAP - Block
SOAP - Block
Anhang 1
Anhang 2
Abbildung 4: SOAP mit Anhang
9
Kapitel 3: Die drei Haupttechnologien von Web Services
Möchte man mit XML und SOAP auch Anwendungsdaten, wie Bilddateien, Berichte
im pdf-Format oder auch komplexe CAD-Dateien versenden, besteht die Möglichkeit
das SOAP-Protokoll mit dem MIME-Standard zu kombinieren und wie bei einer eMail
beliebige Anhänge mitzuschicken. Dabei werden die einzelnen Blöcke durch MIMEHeader verbunden, indem jeder Header den Beginn des nächsten Blocks und das Ende
des vorigen markiert. Der erste Block ist der uns bekannte SOAP-Envelope und jeder
Anhang bildet einen darauf folgenden Teil. Um diese so genannten SwA-Nachrichten
(SOAP with Attachments) zu konstruieren und dekonstruieren, greift man auf Axis- und
JavaMail-APIs zurück. Erweitert man die Anfrage aus Kapitel 2 dahingehend, dass man
die Text-Datei Anschrift.txt der SOAP-Nachricht beifügt, so wird ein Referenz Tag
<attachment href=“cid:the-attachment“/> mit der Content-ID des Anhangs dem
SOAP-Element (Quelltext 6) hinzugefügt. Der Inhalt der Anhang Datei erscheint
getrennt durch einen MIME-Header nach dem Schlusstag des SOAP-Envelope mit der
entsprechenden Content-ID, die in der Referenz angeben ist.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope …
<SOAP-ENV:Body>
<ns1:serviceStock xmlns:ns1="http://webservices.seminar">
<wkn xsi:type="xsd:string">30392</wkn>
<attachment href=“cid:the-attachment“/>
</ns1:serviceStock>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Quelltext 6: SOAP-Anfrage mit Anhang
Bisher wurde in dem hier beschriebenen Beispiel stets ein Remote Procedure Call
(RPC) abgesetzt, indem eine Methode am anderen Ende der Leitung aufgerufen wird.
Neben diesem SOAP-Typ, der im Deployment Descriptor (Quelltext 3) auf java:RPC
Provider gesetzt ist, können genauso SOAP-Nachrichten an message services versendet
werden, die keinen expliziten Methodenaufruf erwarten. Der angesprochene Dienst
parst die Nachricht wie jedes gewöhnliche XML Dokument und verarbeitet
anschließend die enthaltenen Daten weiter.
Ferner stellt SOAP einen speziellen Envelope namens Fault-Envelope zur Verfügung.
Dieser SOAP-Fault wird bei einem Fehler während der Verarbeitung einer SOAPNachricht durch den Server an den Client zurückgeschickt. Quelltext 7 listet die
Struktur einer Fehlerbenachrichtung auf. Das erste Kindelement des SOAP-Body
10
Kapitel 3: Die drei Haupttechnologien von Web Services
Elements bildet <SOAP-ENV:Fault>, gefolgt von einem obligatorischen <faultcode>
und <faultstring>. Dabei sind die Elemente <faultactor> und <detail> optional.
Der <faultcode> entspricht einem von sechs Fault-Codes, die in der SOAP 1.1
Spezifiktion benannt sind.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope …
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Test Fault</faultstring>
<faultactor>/axis/services/MyStockService</faultactor>
<detail> … </detail>
<SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Quelltext 7: SOAP-Fault-Nachricht
3.2 Web Service Description Language (WSDL)
WSDL ist ein XML Syntax zur Beschreibung eines Web Service. Es formuliert, was ein
Dienst anbietet, wie man seine Operationen aufruft und wo man ihn schließlich findet.
Vergleichbar ist ein WSDL Dokument mit einer Interface Definition Language (IDL),
wie sie bei CORBA eingesetzt wird. Anders als bei einer herkömmlichen IDL jedoch,
kann WSDL Diente unabhängig vom Nachrichtenformat oder Netzwerkprotokoll
beschreiben, die zum Austausch der Nachrichten verwendet werden. Außerdem besteht
die Möglichkeit, Nachrichten als abstrakte Beschreibungen der auszutauschenden Daten
zu verstehen oder in Form von so genannten Porttypen, abstrakte Sammlungen der
Operationen eines Dienstes zu betrachten. Ein Porttyp kann hierbei auch an ein
konkretes Protokoll und Datenformat gebunden werden.
Da WSDL eine abstrakte Beschreibung der Schnittstelle eines Web Service liefert, kann
man dazu übergehen den Quelltext für die Implementierung automatisch daraus
abzuleiten und zu erzeugen. Genauso vorstellbar ist jedoch auch der umgekehrte Weg,
den Dienst als erstes zu implementieren und anschließend automatisch das WSDL
Dokument erstellen zu lassen. Hierbei wird man durch diverse Tools unterstützt, wie
zum Beispiel unter Axis und Java, wo die Tools WSDL2Java und Java2WSDL die
automatische Erstellung der Klassen bzw. des WSDL Dokuments übernehmen. Eine
11
Kapitel 3: Die drei Haupttechnologien von Web Services
weitere sehr nützliche Funktion von Axis ist die automatische Bereitstellung des WSDL
Dokuments eines Dienstes, indem einfach ein „?wsdl“ an seine Adresse angehängt
wird. Demnach ruft man das WSDL-Dokument des MyStockService aus Kapitel 2 unter
http://localhost:8080/axis/services/MyStockService?wsdl ab und erhält folgendes
Listing im Browser angezeigt:
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions
targetNamespace="http://localhost:8080/axis/services/MyStockService"
xmlns:apachesoap=http://xml.apache.org/xml-soap
xmlns:impl=http://localhost:8080/axis/services/MyStockService
xmlns:intf=http://localhost:8080/axis/services/MyStockService
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:message name="serviceStockResponse">
<wsdl:part name="serviceStockReturn" type="soapenc:string" />
</wsdl:message>
<wsdl:message name="serviceStockRequest">
<wsdl:part name="arg" type="soapenc:string" />
</wsdl:message>
<wsdl:portType name="MyStockService">
<wsdl:operation name="serviceStock" parameterOrder="arg">
<wsdl:input message="impl:serviceStockRequest"
name="serviceStockRequest" />
<wsdl:output message="impl:serviceStockResponse"
name="serviceStockResponse" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="MyStockServiceSoapBinding"
type="impl:MyStockService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="serviceStock">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="serviceStockRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://webservices.seminar" use="encoded" />
</wsdl:input>
<wsdl:output name="serviceStockResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/MyStockService"
use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="MyStockServiceService">
<wsdl:port binding="impl:MyStockServiceSoapBinding"
name="MyStockService">
<wsdlsoap:address
location="http://localhost:8080/axis/services/MyStockService" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Quelltext 8: WSDL Dokument von MyStockService
12
Kapitel 3: Die drei Haupttechnologien von Web Services
Das erste Element <definition> hält das WSDL-Dokument zusammen und beinhaltet
die globalen Deklarationen von Namensräumen, die im gesamten Dokument sichtbar
sein sollen. Das Attribut targetNamespace definiert den Namensraum, den dieses
Dokument erzeugt und ist ein eindeutiger Bezeichner für alle Typen oder abstrakten
Definitionen aus dem Dokument. Dabei muss dieses Attribut auf eine absolute Referenz
zeigen, praktisch ist hier die Adresse des aktuellen Dienstes verwendet. Dem
<definition> Element folgen <import> Elemente (in diesem Beispiel nicht zu sehen),
mit denen man Dokumente einbinden kann auf die Elemente einer Dienstedefinition
verteilt sind. Hiermit möchte man eine Modularisierung und bessere Strukturierung von
WSDL-Dokumenten ermöglichen. Dem folgt das <types> Element um eigene
Datentypen zu definieren. Hier tauschen der Client und der Dienst nur den einfachen
Datentyp String aus und damit entfällt eine eigene Datentypdeklaration. Die
Beschreibung von Datentypen erfolgt mit XML Schema und ermöglicht somit die
Definition von einfachen bis hin zu sehr komplexen Datentypen. Anschließend
formuliert das <message> Element die Daten, die innerhalb des Web Service
ausgetauscht werden. So wird jeweils für die Anfrage und Antwort ein String Datentyp
und Name für das austauschende Argument deklariert. Es folgt das <portType>
Element, dass eine Teilmenge von Operationen beschreibt. Das <operation> Element
stellt eine Operation dar und entspricht hier der einzigen Java Methode, die der Web
Service MyStockService zur Verfügung stellt. Analog zu einer Methodendefinition
werden die eingehenden und ausgehenden Argumente beschrieben. Das <binding>
Element schließlich bildet die abstrakte Definition eines <portType> Elements auf ein
konkretes Protokoll ab. Es verwendet standardisierte Bindungserweiterungen wie
HTTP, SOAP, MIME oder erzeugt eigene und bestimmt wie die Daten codiert werden
sollen. Was jetzt noch fehlt ist die Bindung des Web Service an eine bestimmte URL.
Dies erfolgt in der Regel am Ende eines WSDL-Dokuments mit dem <service>
Element.
3.3 Universal Description, Discovery, and Integration (UDDI)
Bei UDDI handelt es sich um eine standardisierte Methode zum Veröffentlichen und
Auffinden von Informationen über Web Services. Es ist eine Industrie-Initiative, die
sich zum Ziel gemacht hat, ein plattformunabhängiges, offenes Framework zu schaffen,
in
dem
Unternehmen
andere
Unternehmen
aufsuchen
können,
um
13
Kapitel 3: Die drei Haupttechnologien von Web Services
Geschäftstransaktionen durchführen zu können. Die Informationen, die eine UDDIRegistrierungsstelle zur Verfügung stellt, kann man in drei verschiedene Arten
einteilen:
White Pages
Grundlegende Kontaktinformationen über ein Unternehmen, darunter der Name, die
Adresse, Ansprechpartner und eindeutige Bezeichner wie Handelsregisternummer. Mit
diesen Informationen kann ein Web Service anhand der Firma gefunden werden.
Yellow Pages
Informationen, die ein Web Service mit verschiedenen Kategorien beschreiben. Dies
ermöglicht das Auffinden von Diensten anhand seiner Zuordnung wie Rückversicherer,
Maschinenbau etc.
Green Pages
Dort sind technische Informationen gebündelt, die das Verhalten eines Dienstes
beschreiben, die ein Unternehmen betreibt. Hier findet man auch Informationen über
Beziehungen innerhalb einer Gruppe von Web Services und wo die Dienste letztendlich
zu finden sind.
In der Zukunft wird eine Software vielleicht in der Lage sein, einen Dienst dynamisch
und automatisiert finden zu können. Bis dahin wird man jedoch nur durch Fachwissen
und manueller Suchtätigkeit, die ein entsprechender Business-Analyst mitbringt, Web
Services finden und auswählen können. Die Suchtätigkeit mit UDDI ist aus
Anwendersicht vergleichbar mit einer Internet-Suchmaschine für Gechäftsvorgänge.
Diverse Portale wie www.xmethods.net stellen bereits Diensteverzeichnisse zur
Verfügung. Automatisiert dagegen läuft schon jetzt das Bereitstellen und Aktualisieren
von Daten in einer UDDI-Registrierungsstelle ab. Erstellt man einen Web Service, so
sollte das verwendete Toolkit in der Lage sein die UDDI-Registrierungsstelle
automatisiert zu kontaktieren und die Informationen bereitzustellen. Der Aufbau des
UDDI-Projekts sieht eine UDDI Business Registry (UBR) vor, die so genannte Public
Cloud (öffentliche Wolke), ein einziges System, das aus einer Reihe von Knoten
besteht, deren Daten durch Replikation synchronisiert werden. Ein Operatorknoten
sollte somit dieselben Informationen wie alle anderen bereitstellen. Fügt man neue
Informationen zu einem Knoten hinzu, wird er für diese Daten der neue Hauptbesitzer
und nur dort können die Daten aktualisiert und gelöscht werden. Jede Firma kann auch
14
Kapitel 3: Die drei Haupttechnologien von Web Services
einen privaten Operatorknoten betreiben, der nicht zur UBR gehört und nicht mit der
UBR synchronisiert werden muss. Diese privaten Operatorknoten können wiederum mit
anderen privaten Knoten in Kontakt treten und eine private Wolke erzeugen. So können
sich bestimmte Industriegruppen zusammenschließen und eigene Netze schaffen und
ihre UDDI-Knoten ihren Bedürfnissen anpassen.
Java unterstützt den Entwickler mit verschiedenen Arten bei dem Zugriff auf UDDIRegistrierungsstellen. Zum einem kann man sich eine Java-basierte SOAP-API zu
Nutze machen, mit der man SOAP-Nachrichten erzeugt, die UDDI-XML-Dokumente
enthalten. Diese sehr rudimentäre Möglichkeit bringt den Nachtteil mit sich, dass der
Entwickler sehr viel Handarbeit an den Tag legen muss und die Reihenfolge, mit der
eine UDDI-Registrierungsstelle die einzelnen SOAP-Nachrichten empfängt, genau
kennen muss. Eine andere Variante ist das Verwenden einer speziellen Java-basierten
UDDI-Client-API. Diese API bietet bereits spezielle Klassen und Konstrukte an, um
von UDDI unterstützte Datenstrukturen und Nachrichten auszutauschen. Eine noch sich
im frühen Entwicklungsstadium befindliche JAXR-Spezifikation hingegen definiert
eine standardisierte Möglichkeit auf verschiedene Regierungsstellentypen zuzugreifen.
Damit kann man auf einer höheren Abstraktionsschicht auch andere Stellen wie
ebXML-Registry/Repository ansprechen und erreicht eine höhere Portabilität.
Die UDDI-Spezifikation formuliert zwei APIs, die Inquiry-API und die Publishing-API.
Abfragen lassen sich mit der Inquiry-API unverschlüsselt und anonym an eine UDDIStelle abschicken, währen die Publishing-API eine Authentifizierung verlangt, um
Informationen zu erzeugen, zu speichern und zu aktualisieren. Darum sind diese zwei
Dienste unter einer HTTP bzw. einer HTTPS Adresse zu erreichen. Um ein Beispiel für
eine UDDI Stelle zu geben, hier Anfrage-URL und Veröffentlichungs-URL einer
UDDI-Registrierungsstelle von SAP: http://udditest.sap.com/UDDI/api/inquiry und
http://udditest.sap.com/UDDI/api/publish.
Abschließend soll ein Entity-Diagramm (Abbildung 5) einen Überblick über die
wichtigsten Datenstrukturen geben, die als Ein- und Ausgabeparameter von UDDINachrichten dienen:
15
Kapitel 4: Zusammenfassung
<businessEntity>
<publisherAssertion>
grundlegende Informationen eines Unternehmens:
- Name, Kontakt, Beschreibung
- Bezeichner und Kategorien
1
n
n
n
Beziehung zwischen zwei Firmen:
- z.B. referenziert her ein Mutterkonzern
seine Tochterfirma oder zwei Firmen
agieren als Partner
- damit eine Beziehung öffentlich sichtbar wird,
müssen beide Seiten dieses Entity anlegen,
erst dann ist eine Beziehung sozusagen
genehmigt
<businessService>
einzelne, logische Diensteklassifikation:
- Beschreibung einer Menge von Diensten,
die ein Unternehmen anbietet
1
1
<bindingTemplate>
- Zeiger auf technische Beschreibung
- Zugriffspunkt-URL
<tModel>
1
n
abstrakte Beschreibung
- einer Spezifikation
- eines Verhaltens
Abbildung 5: Datenstrukturen einer UDDI-Registrierungsstelle
4 Zusammenfassung
Web Services umfassen die drei Haupttechnologien SOAP, WSDL und UDDI. Mit
SOAP wird ein Kommunikationsprotokoll geschaffen, das eine plattformunabhängige
Interaktion zwischen Client und Diensteanbieter ermöglicht. Es folgt keiner
proprietären Norm und nutzt die Mächtigkeit, die XML bietet und mit der sich einfache
bis zu sehr komplexen Nachrichten formulieren lassen. Ein WSDL-Dokument liefert
eine abstrakte Schnittstellenbeschreibung aus der man entnehmen kann, was der Dienst
macht, wie man ihn nutzt und wo man ihn findet. Um schließlich einen Web Service zu
finden, fragt man bei einer UDDI-Registrierungsstelle nach. Diese bietet entsprechende
Suchmöglichkeiten auf Informationen, die vorher von einem Diensteanbieter entweder
manuell oder automatisiert durch das WS-Service-Toolkit eingepflegt wurden.
Das Thema Web Services hat wie viele andere Informationstechniken einen Hype
durchlebt, der mittlerweile etwas abgekühlt, aber dessen Entwicklung umso aktueller
ist. Nicht zu unrecht bietet die Web Service Technologie viel potential, dessen
Entwicklung am Anfang steht. Im Vergleich zu vorherigen Technologien wie z.B.
CORBA entwickelt sich ein standardisiertes, plattformunabhängiges Interaktions- und
16
Kapitel 5: Literaturverzeichnis
Austauschverfahren, das neue Konzepte wie UDDI-Registrierungsstellen einführt.
UDDI-Registrierungsstellen sollen in Zukunft eine dynamische Interaktion zwischen
Software ermöglichen, die selbständig Dienste suchen und in ihre Infrastruktur
einbinden. Solch ein Ökosystem wird zu einer zunehmenden Verzahnung von
Softwaresystemen und insbesondere im B2B Bereich zu neuen Geschäftsmodellen und transaktionen führen.
5 Literaturverzeichnis
[ChJe03]
David A. Chappell, Tyler Jewell: Java Web Services, O’Reilly, 2003.
[Ray01]
Erik T. Ray: Einführung in XML, O’Reilly, 2001.
[Zi03]
Olaf Zimmermann: Perspectives on Web Services, Springer, 2003.
[Wa04]
Dapeng Wang: Java Web Services mit Apache Axis, Software & Support
Verlag, 2004.
[Axis04]
Apache Software Foundation: Axis Documentation,
http://ws.apache.org/axis/java/index.html.
17