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.net- Komponente ü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 SOAP- Anfragen 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
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
Anwendung Dienst SOAP-Client HTTP - Anfrage HTTP - Antwort SOAP - Prozessor Diskrete Geschäftslogik WSDL UDDI- Registrierungsstelle 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
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 <ns1:servicestock xmlns:ns1="http://webservices.seminar"> 10 <wkn xsi:type="xsd:string">30392</wkn> 11 </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
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 <SOAP-ENV:Body> 10 <ns1:servicestockresponse xmlns:ns1="http://webservices.seminar"> 11 <servicestockreturn xsi:type="xsd:string">45.741958669707074 </servicestockreturn> 12 </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
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 MIME- Header 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 SOAP- Nachricht durch den Server an den Client zurückgeschickt. Quelltext 7 listet die Struktur einer Fehlerbenachrichtung auf. Das erste Kindelement des SOAP-Body 10
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
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
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
Geschäftstransaktionen durchführen zu können. Die Informationen, die eine UDDI- Registrierungsstelle 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
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 UDDI- Registrierungsstellen. 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 UDDI- Stelle 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 UDDI- Nachrichten dienen: 15
Kapitel 4: Zusammenfassung <businessentity> grundlegende Informationen eines Unternehmens: - Name, Kontakt, Beschreibung - Bezeichner und Kategorien <businessservice> einzelne, logische Diensteklassifikation: - Beschreibung einer Menge von Diensten, die ein Unternehmen anbietet n n 1 n <publisherassertion> 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 1 <bindingtemplate> - Zeiger auf technische Beschreibung - Zugriffspunkt-URL 1 1 n <tmodel> 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] [Axis04] Dapeng Wang: Java Web Services mit Apache Axis, Software & Support Verlag, 2004. Apache Software Foundation: Axis Documentation, http://ws.apache.org/axis/java/index.html. 17