Seminar: Praktischee Informatik. Web Services. Norman Thomas. Matrikelnummer: November 2003

Transkript

1 Seminar: Praktischee Informatik Web Services Norman Thomas Matrikelnummer: November 2003

2 Inhaltsverzeichnis 1 Einführung Was sind Web Services? Warum Web Services? Beispiel-Szenario Lösungssuche & -methoden Stellung von Web Services SOAP Wozu SOAP? Struktur von SOAP SOAP-Envelope SOAP-Header SOAP-Body SOAP und Datentypen Einfache Datentypen Arrays Strukturen Array von Strukturen WSDL Wozu WSDL? Struktur von WSDL definitions types message porttype binding service Alternativen zu WSDL UDDI Wozu UDDI? Struktur von UDDI business entity business service ii

3 Inhaltsverzeichnis Inhaltsverzeichnis binding template tmodel publisher assertion Benutzung von UDDI Publizieren von Einträgen Abfragen von Einträgen Alternative zu UDDI WSIL iii

4 1 Einführung 1.1 Was sind Web Services? Unter Web Service versteht man eine im Internet veröffentlichte Software, die ihren Dienst anbietet und mittels Standardschnittstellen angesprochen wird. Web Services eröffnen eine neue Ebene der Internetnutzung. Bisher wurde das Internet für s und Webseiten genutzt, um z.b. Produkte zu verkaufen oder Nachrichten zu veröffentlichen oder für Bilder-Galerien. Nun jedoch wird es auch möglich Dienste im Internet anzubieten und das plattform- wie auch programmiersprachenunabhängig. Solche Dienste gibts es schon wie z.b. der Übersetzungsservice von Babelfish. Dies ist jedoch eine sehr knappe Definition der Web Services. Es gibt viele Ansichten zu Web Services. Wenn man die Schnittmenge der Definitionen nimmt, dann ist das Ergebnis obige Beschreibung. Noch genauer kann man zu Web Services sagen, dass die besagten standartisierten Schnittstellen auf XML basieren, denn der Datenaustausch läuft über SOAP (Simple Object Access Protocol) [Seite 4, Kapitel 2] und die Beschreibung eines Web Service erfolgt mit WSDL (Web Service Description Language) [Seite 9, Kapitel 3]. 1.2 Warum Web Services? Um die Daseinsberechtigung von Web Services zu verstehen ist es von Vorteil ein Beispielszenario durchzuspielen und mit dessen Hilfe zu analysieren welche Möglichkeiten es zur Problemlösung gibt und wo sich dort Web Services eingliedern. Nachdem dann die Auswahlmöglichkeiten gefunden sind, werden kurz die Alternativen beschrieben. In den darauffolgenden Kapiteln werden Web Services und die zugrundeliegenden Protokolle erläutert bis dann im letzten Kapitel die Vor- und Nachteile von Web Services abgewägt werden Beispiel-Szenario Ein international agierendes Unternehmen habe eine Software entwickelt, die es ermöglicht weltweit auf einen zentralen Projektverwaltungsserver zuzugreifen. Diese Software ist vor allem für Unternehmen von Nutzen, deren Mitarbeiter oft in verschiedene Länder reisen aber dennoch Ihre Projektdaten mit dem zentralen Server ihres Unternehmens ständig abgleichen und aktualisieren müssen. Ggf. geben sie neue Daten ein. Dieses Unternehmen bietet ihre Software anderen Firmen an, indem es für jede Firma einen eigenen Bereich zur Verfügung stellt mit dazu passendem Login. Dieses vir- 1

5 1.2. WARUM WEB SERVICES? KAPITEL 1. EINFÜHRUNG tuelle Büro soll über Standardfähigkeiten wie Kalender, Kontaktverwaltung, ein Nachrichtensystem, Aufgabenverwalung, eine Notizfunktion (z.b. Pinnwand) usw. verfügen. Die komplette Software ist per Browser zu bedienen. Nun bemängelt jedoch ein Kunde, dass er diese Software nicht nur per Browser benutzen will, sondern sie auch in seine eigene Software integrieren will. Was tun? Lösungssuche & -methoden Aufgabe ist es also nicht nur ein webbasiertes Interface anzubieten, sondern auch eine Schnittstelle, über die eine beliebige Software mit der Verwaltungs-Software umgehen kann, um z.b. Daten einzugeben, zu löschen, usw. Zu aller erst bietet es sich an, nichts an seiner Software zu ändern, und dem Kunden vorzuschlagen, doch einfach die HTML-Seite des Browsers zu parsen und Eingaben von deren eigener Software vorzunehmen. Mit anderen Worten: die fremde Software soll den Benutzer vor dem Browser simulieren. Dies hört sich u.u. einfacher an als es ist, denn in Wirklichkeit ist dies eine sehr komplexe Angelegenheit, HTML-Seite zu parsen, um Daten auszulesen und Eingabefelder zu erkennen, um entsprechende Daten zu lesen der zu schreiben. Noch viel schlimmer ist ein anderer Nachteil des Parsers. Der Parser trennt für den Benutzer die Nutzdaten von den vielen Gestaltungs-Tags des HTML-Codes. Andert sich mal das Layout der Seite, muss sofort ein entsprechender Parser geschrieben werden, der den neuen Aufbau der Seite verarbeiten kann, sprich: Bei jeder Layoutänderung muss man einen neuen Parser entwickeln. Und selbst wenn man den neuen Parser freiwillig schreibt besteht das weiterhin Problem, dass die alten Parser die Seite auf keinen Fall mehr korrekt auswerten können und deswegen die Kunden gezwungen sind den Parser sofort auszutauschen. Deswegen muss möglichst eine andere Lösung als der Parser und der simulierte Anwender her. Wenn man aber dennoch sich darauf einigen sollte die Webseite der Software nie wieder layouttechnisch zu ändern besteht immernoch das Problem, dass sobald die Software um weitere Dienste erweitert wird, das wieder im Parser umgesetzt werden muss. Ein weiterer Lösungsansatz ist die Verwendung von RMI, DCOM und CORBA. Alle haben Ihre Vor- und Nachteile. Das Problem ist immerwieder, dass die Kunden viele verschiedene Plattformen und Programmiersprachen verwenden. Während ein Kunde Visual Basic und Windows verwendet, benutzt der nächste C/C++ und Linux, und der Mac-User benutzt vielleicht C und Java. Dann taucht vielleicht noch ein Kunde auf, der UNIX und Python benutzt. Spätestens jetzt bemerkt man wie vielfältig die Kombinationsmöglichkeiten sind. Schlimmer noch ist dass diese Kombinationen wirklich auftauchen. Betrachtet man RMI (Remote Method Invocation), so hat man schnell begriffen, dass diese Lösung nur auf Java spezialisiert ist und somit sofort aus der Kandidatenliste gestrichen werden muss. Wenn man nun DCOM (Distributed Component Object Model) betrachtet, stellt man mindestens ebenso schnell wie bei RMI fest, dass diese Möglichkeit ebenfalls verworfen werden muss, da sie nur für Windows nutzbar ist. 2

6 1.2. WARUM WEB SERVICES? KAPITEL 1. EINFÜHRUNG CORBA (Common Object Request Broker Architecture) ist also die einzig verbliebene Möglichkeit. CORBA bietet eine Anbindung an C++, Java, Delphi/Pascal, und viele weitere Programmiersprachen, da CORBA den Nachrichtenaustausch mit Hilfe von IDL festlegt. IDL (Interface Description Language) ist eine Sprache, mit der man Interfaces beschreibt. Aus der IDL-Datei kann man dann den Quellcode zum Implementieren des Servers wie auch des Clients generieren. Das heißt, man aus der IDL einen C++-Server bauen könnte, und mit Hilfe derselben noch einen Java-Client bauen könnte. dass Außer der breite Programmiersprachenunterstützung von CORBA ist CORBA auch auf sehr vielen Plattformen verfügbar. Vorraussetzung dafür, dass CORBA auf einer Plattform genutzt werden kann ist, dass für diese ein ORB (Object Request Broker) existiert. Für die Firma, die die Software anbietet jedoch, bedeutet CORBA einen großen Mehraufwand, da sie einen ORB auf dem Webserver aufsetzen muss, und die IDL- Beschreibung immer aktuell halten muss, falls neue Funktionalitäten in das Programm integriert werden. Und der noch viel größere Aufwand wäre, dass man das Programm für CORBA noch einmal komplett neu schreiben müsste. Und wenn man nochmal zurückkommt auf die Programmiersprachenauswahl, dann bemerkt man nach gründlicher Recherche auch, dass die Vielfalt von den verwendeten ORBs abhängt. C++ und Java werden zwar von allen unterstützt, jedoch hat man damit wieder ein gutes Stück an Programmiersprachenunabhängigkeit eingebüßt Stellung von Web Services Web Services nehmen nun eine Stelle ein, die zwischen der ursprünglichen Lösung HTTP und CORBA liegt. Web Services unterstützen sämtliche Systeme, die HTTP- Anfragen senden und empfangen können. Sie sind viel sprachunabhängiger als COR- BA und man muss keinen ORB aufsetzen, damit man sie benutzen kann. Ein einfacher Server, der z.b. CGI oder PHP kann könnte als Web Service Server fungieren, man braucht also keine besonderen Server zusätzlich zu installieren, konfigurieren und warten. Eben weil Web Services auf so weit verbreitete Systeme und vor allem Standards aufsetzen sidn Web Services nicht nur ein Hype sondern eine echte Bereicherung für die Software-Industrie. Ihre Anwendungsmöglichkeiten reichen von Übersetzungsdiensten (z.b. Babelfish), Suchdiensten (z.b. Google, Amazon.com) bis hin zum Grid- Computing. Viel mehr Beispiele kann man bei [3] sehen. 3

7 2 SOAP 2.1 Wozu SOAP? SOAP ist ein auf XML basierendes Protokoll, das bis vor kurzem noch in Version 1.1 vorlag. Version 1.2 liegt seit Juni 2003 vor und ist demnach der aktuelle Stand. SOAP dient zum Nachrichtenaustausch zwischen Anwendungen über das Internet oder Netzwerk und bietet durch den XML-Standard Plattform- wie auch Programmiersprachenunabhängigkeit. Außerdem werden SOAP-Nachrichten in der Regel über HTTP übertragen, was den Vorteil bietet, dass für SOAP keine besonderes exotischen Ports geöffnet sein müssen und von allen Systemen unterstützt wird. Zusätzlich jedoch gibt es die Möglichkeit SOAP-Nachrichten z.b. über SMTP (sprich: Mail) zu versenden. 2.2 Struktur von SOAP Eine gültige SOAP-Nachricht umfasst einen Root-Abschnitt, das SOAP-Envelope (sozusagen der Briefumschlag), und einen oder zwei Unterabschnitte, den SOAP-Header (Kopf, ist optional) und den SOAP-Body (Körper, enthält die eigentliche Nachricht) SOAP-Envelope Wie bereits gesagt ist das SOAP-Envelope ein unabdingbarer Teil der SOAP-Nachricht. Ohne es ist die Nachricht in keinem gültigen SOAP-Format und wird somit nicht anerkannt. Ein SOAP-Envelope oder besser: das Grundgerüst einer SOAP-Nachricht mit SOAP-Envelope (erstmal ohne Header und Body) sieht wie folgt aus: <?xml version=" 1. 0 " encoding="utf 8"?> <SOAP:Envelope xmlns:soap=" h t t p : //schemas. xmlsoap. org/soap/envelope "> <! o p t i o n a l e r SOAP Header > <! SOAP Body > </SOAP:Envelope> Abbildung 2.1: SOAPEnv01.xml SOAP Envelope Im Envelope wird wie von XML verlangt erst einmal die zugrunde liegende XML- Version (hier: 1.0) angegeben wie auch die verwendete Zeichenkodierung (hier: UTF- 4

8 2.2. STRUKTUR VON SOAP KAPITEL 2. SOAP 8). Direkt danach beginnt das eigentliche SOAP-Dokument. <SOAP:Envelope...> gibt an, dass es sich um ein SOAP-Envelope handelt und gibt mit dem Attribut xmlns:soap an, dass die Definition des SOAP-Envelope an besagter URL liegt. Das Beispiel bezieht sich noch auf SOAP 1.1. Der Unterschied zur Version 1.2 besteht lediglich in der URL, die in xmlns:soap steht. Bei SOAP 1.2 lautet die URL: SOAP-Header Der SOAP-Header ist optional. Wird er jedoch angegeben, so muss er vor dem SOAP- Body stehen. Mit ihm ist es z.b. möglich Daten zur Authentifizierung mit der SOAP- Nachricht zu übertragen. Versteht der Empfänger jedoch nicht, was im Header steht, so stellt dies kein Problem dar, dann wird der Header einfach verworfen. Um beim Beispiel von oben zu bleiben: Benötigt der Empfänger z.b. keine Authentifizierungsdaten, dann werden die Header-Daten einfach ignoriert. Das Attribut mustunderstand ermöglicht es jedoch die Interpretation des Headers zu erzwingen. Dieses Attribut muss man lediglich auf 1 setzen. Das hat zur Folge, dass wenn ein Empfänger den Header nicht versteht, ein Fehler zurückgegeben wird. Mehr zu SOAP-Fehlermeldungen jedoch später. [Seite 5, Abschnitt 2.2.3] <SOAP:Header> <! SOAP Header I n h a l t > <! B e i s p i e l : > < a u t h : a u t h e n t i c a t i o n xmlns:auth=" h t t p : //irgendwas. com/auth "> <auth:user>norman</auth:user> <auth:pass>webservices</auth:pass> </ a u t h : a u t h e n t i c a t i o n > </SOAP:Header> Abbildung 2.2: SOAPHead01.xml SOAP Header SOAP-Body Im SOAP-Body steht die eigentliche Nachricht mit den Informationen zum Funktionsaufruf, Parameterübergaben wie auch Rückgabewerte. SOAP-Fault Im Element SOAP-Fault werden Fehlermeldungen kodiert. Da bei der Benutzung von Web Services und insbesondere auch des Internet verschiedene Arten von Fehlern auftreten können, ist es wichtig die Fehlerarten und -ursachen bestimmen zu können. Zum Beispiel könnte es sein, dass man eine Funktion aufrufen will, die der Web Service gar 5

9 2.2. STRUKTUR VON SOAP KAPITEL 2. SOAP <SOAP:Body> <! SOAP Body I n h a l t > <! B e i s p i e l : > <anfrage:sayhello xmlns:anfrage=" h t t p : //irgendwas. com/anfrage " SOAP:encodingStyle=" h t t p : //schemas. xmlsoap. org/soap/encoding/"> <name>norman</name> </anfrage:sayhello> </SOAP:Body> Abbildung 2.3: SOAPBody01.xml SOAP Body <SOAP:Body> <! SOAP Body I n h a l t > <! B e i s p i e l : > <anfrage:sayhelloresponse xmlns:anfrage=" h t t p : //irgendwas. com/ SOAP:encodingStyle=" h t t p : //schemas. xmlsoap. org/soap/ anfrage " encoding/"> < r e s u l t >Hello Norman</ r e s u l t > </anfrage:sayhelloresponse> </SOAP:Body> Abbildung 2.4: SOAPBody02.xml SOAP Body (Response) nicht besitzt. Es gibt folgende Elemente innerhalb des Fault-Blocks, um den Fehler zu beschreiben: faultcode kann vier mögliche Fehler kodieren: VersionMismatch (wenn eine andere SOAP-Version als die verwendete erwartet wird für die Nachricht) MustUnderstand (falls der Empfänger oder ein Knoten über den die SOAP- Nachricht geleitet wird Angaben aus dem SOAP-Header, die mit mustunderstand markiert sind nicht versteht) Client (falls der Fehler auf seiten des Clients liegt) Server (falls der Fehler auf seiten des Servers liegt) faultstring hier wird ein String angegeben, um den Fehler genauer zu beschreiben. faultfactor hier kann man optional angeben auf welchem Knoten der Fehler auftrat. detail dieser Block wird nur benutzt, wenn der Fehler innerhalb des SOAP-Bodys auftritt. Es gibt Java-Implementierungen von SOAP, die hier entsprechende Exceptions angeben, damit das Exception-Handling auf dem entfernten Rechner weitergeführt werden kann. 6

10 2.3. SOAP UND DATENTYPEN KAPITEL 2. SOAP <SOAP:Fault> <! SOAP F a u l t I n h a l t > <! B e i s p i e l : > <faultcode>mustunderstand</faultcode> < f a u l t s t r i n g >Kann keine Authentisierungsdaten verarbeiten</ f a u l t s t r i n g > < f a u l t f a c t o r > auf dem weg. com/weiterleitung</ f a u l t f a c t o r > </SOAP:Fault> 2.3 SOAP und Datentypen Abbildung 2.5: SOAPFault01.xml SOAP Fault SOAP verwendet zur Übertragung von Informationen die XML-Datentypen. Handelt es sich jedoch nicht um simple Datentypen (z.b. Strings, Integer) sondern um Arrays oder Strukturen, dann gibt es auch dafür eine Umsetzungsmöglichkeit in SOAP. Es folgen jeweils ein Beispiel zu den Datentyp-Kategorien einfache Datentypen, Array und zusammengesetzte Typen Einfache Datentypen <SOAP:Body> <anfrage:sayhello xmlns:anfrage=" h t t p : //irgendwas. com/anfrage " SOAP: encodingstyle=" h t t p : //schemas. xmlsoap. org/soap/encoding/" xmlns:xsi=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " xmlns:xsd =" h t t p : //www. w3. org /2001/XMLSchema"> <name x s i : t y p e =" x s d : s t r i n g ">Norman</name> </anfrage:sayhello> </SOAP:Body> Abbildung 2.6: SOAPDatatypes01.xml SOAP Datentypen (simple Typen) Arrays Strukturen Array von Strukturen Analog zu den obigen Beispielen lassen sich auch Arrays und Strukturen kombinieren und es werden Arrays aus Strukturen möglich. 7

11 2.3. SOAP UND DATENTYPEN KAPITEL 2. SOAP <SOAP:Body> <anfrage:searchzipresponse xmlns:anfrage=" h t t p : //irgendwas. com/ anfrage " SOAP:encodingStyle=" h t t p : //schemas. xmlsoap. org/soap/ encoding/"> <! x s i und xsd D e k l a r a t i o n e n können auch im E n v e l o p e s t e h e n > < r e s u l t href=" # id0 "/> </anfrage:searchzipresponse> <id0 id=" id0 " SOAPenc:root=" 0 " x s i : t y p e =" SOAPenc:Array " SOAPEnc:arrayType=" x s d : s t r i n g [ 2 ] "> < i x s i : t y p e =" x s d : S t r i n g ">Cambria Hts. </ i > < i x s i : t y p e =" x s d : S t r i n g ">Baldwin</ i > </ id0> </SOAP:Body> Abbildung 2.7: SOAPDatatypes02.xml SOAP Datentypen (Arrays) <SOAP:Body xmlns:ns1=" h t t p : //www. meinefirma. de/url/"> <anfrage:searchadressresponse xmlns:anfrage=" h t t p : //irgendwas. com/ anfrage " SOAP:encodingStyle=" h t t p : //schemas. xmlsoap. org/soap/ encoding/"> < r e s u l t href=" # id0 "/> </anfrage:searchadressresponse> <id0 id=" id0 " SOAPenc:root=" 0 " x s i : t y p e =" ns1:adresse "> < s t r a s s e x s i : t y p e =" x s d : S t r i n g ">Mozartstr. 1 </ s t r a s s e > <plz x s i : t y p e =" x s d : S t r i n g ">34117</plz> < o r t x s i : t y p e =" x s d : S t r i n g ">Kassel</ o r t > </ id0> </SOAP:Body> Abbildung 2.8: SOAPDatatypes03.xml SOAP Datentypen (Strukturen) 8

12 3 WSDL 3.1 Wozu WSDL? WSDL (Web Service Description Language) dient zur Beschreibung von Web Services. WSDL in der aktuellen Version 1.1 ist kein W3C-Standard wie z.b. SOAP. WSDL 1.1 wurde unabhängig von diversen Unternehmen entwickelt und nun dem W3C zur Weiterentwicklung übertragen. Somit ist WSDL 1.1 im Moment noch nur ein note [4]. Jedoch wird an den Nachfolgeversionen 1.2 und 2.0 gearbeitet. Von ihnen gibt es augenblicklich nur Entwürfe, die aktuellsten sind für Version 1.2 vom 11. Juni 2003 und für Version 2.0 vom 10. November WSDL ist ebenfalls ein XML-Dokument. WSDL- Dokumente dienen auch als Implementierungsgrundlage für Client-Programme des Web Services. Denn mit Ihnen erfährt man welche Dienste ein Web Service anbietet und Welche Parameter, Rückgabewerte und Datentypen dieser verwendet. Manche IDEs wie z.b. Delphi oder der Borland C++ Builder bieten die Möglichkeit WSDL- Dokumente zu importieren und daraus automatisch ein Gerüst für das Client-Programm zu generieren. Ebenfalls ist es möglich erst ein WSDL-Dokument zu schreiben und daraufhin daraus das Gerüst für den Web Service zu generieren. Außerdem kann man auch erst den Web Service programmieren und aus diesem WSDL zu generieren. 3.2 Struktur von WSDL WSDL ist wie auch SOAP strukturiert und besteht aus dem Root-Element <definitions> und den teilweise optionalen Unterelementen definitions Hierbei handelt es sich um das Root-Element des WSDL-Dokuments. Hier werden Namespaces definiert. documentation Zusätzlich zu den normalen WSDL-Elementen gibt es noch die Elemente <documentation> und <import>. In <documentation> kann das WSDL-Dokument dokumentiert bzw. kommentiert werden. Dabei wird einfach zwischen dem öffnenden und schließenden Tag ein beliebiger Text geschrieben. 9

13 3.2. STRUKTUR VON WSDL KAPITEL 3. WSDL import Im Element <import> ist es möglich anderes Dateien in das Dokument einzubinden. Dadurch wird es z.b. ermöglicht WSDL-Dokumente modular aufzubauen indem einzelne Teile in eigene Dateien geschrieben werden und diese schließlich durch das <import>-element gemeinsam in ein großes WSDL-Dokument eingefügt werden können types Mit dem optionalen Element <types> ist es mögliche Datentypen, die für die SOAP- Nachrichten benötigt werden zu definieren. Benötigt z.b. ein Funktionsaufruf einen Parameter der einen eigenst definierten Datentypen hat, muss dieser Datentyp im WSDL- Dokument definiert werden. Werden nur Standard-XML-Typen verwendet kann man dieses Element weglassen message Das Element <message> dient zur Auflistung aller zur Verfügung stehender Funktionen des Web Services. Das Element hat das Attribut name und enthält den Namen der Funktion. Dieser Name muss eindeutig sein, also nicht nochmal verwendet werden. Innerhalb des <message>-elements kann es <part>-elemente geben, die je nach Funktion entweder die Parameter oder die Rückgabewerte angeben. Das <part>-element hat das Attribut name, das den Namen des Parameters enthält und das Attribut type, das den Typ des Parameters angibt. Gibt es mehrere Parameter werden einfach mehrere hintereinander folgene <part>-elemente angegeben. Funktionsergebnisse werden i.d.r. durch ein an den eigentlichen Namen angehängtes Response gekennzeichnet. Anfragen bzw. die Funktionsaufrufe vom Client zum Service haben i.d.r. an den Namen ein Request angehängt. Man kann diese Namen aber frei wählen porttype Das Element <porttype> fallst alle Operationen des Web Services zusammen und listet sie in <operation>-elementen auf, deren Attribut name die Namen der Funktionen enthalten. Das name-attribut muss innerhalb eines WSDL-Dokuments eindeutig sein. operation Das Unterelement <operation> des Elements <porttype> enthält wiederum Unterelemente, und zwar <input>, <output> und <fault>. Diese verweisen mit ihrem Attribut name und message auf die im WSDL-Dokument definierten Funktionen im Element <message>. Dabei wird zwischen dem Aufruf der Funktion (<input>), dem Ergebnis der Funktion (<output>) und ggf. eine Fehler-Nachricht (<fault>. Es gibt vier Nachrichtentypen: 10

14 3.2. STRUKTUR VON WSDL KAPITEL 3. WSDL One-way Es existiert nur ein <input>-element, die Operation kann Nachrichten empfangen antwortet jedoch nicht darauf. Die Anfrage sendet der Client. Request-response Es existieren ein <input>- und ein <output>-element, die Operation umfasst eine Anfragenachricht und eine Antwortnachricht. Ggf. gibt es auch eine <fault>-nachricht. Wichtig ist hier, dass der Client eine Anfrage sendet und eine Antwort vom Web Service erwartet. Solicit-response Hier gibt es die Möglichkeit Anfragenachrichten, Antwortnachrichten und Fehlernachrichten (<fault>) zu senden. Im Unterschied zu Requestresponse sendet hier der Web Service eine Anfrage, die vom Client beatwortet werden muss. Notification Es gibt nur eine <output>-nachricht, die vom Web Service an den Client gerichtet ist. Abbildung 3.1: WSDL Operationen binding Hier wird das Nachrichtenformat und die Art der Nachrichtenübertragung bestimmt. Dabei stehen SOAP, HTTP GET/POST und MIME zur Auswahl. Die für Web Services wohl gebräuchlichste Art ist SOAP, die auch im folgenden beschrieben wird. Das <binding>-element hat zwei Attribute: das name-attribut zur Festlegung eines Namens und das type-attribut, das auf ein <porttype>-element verweist. SOAP:binding Wird das SOAP-Protokoll verwendet, dann muss das Element <SOAP:binding/> angegeben werden. In diesem Element werden zwei Attribute transport und style 11

15 3.3. ALTERNATIVEN ZU WSDL KAPITEL 3. WSDL angegeben, die bestimmen über welches Transportprotokoll und welchen Stil die Nachrichtenübermittlung stattfindet. Für transport kommen z.b. HTTP, FTP oder SMTP in frage. Das üblichste ist HTTP, dann hat transport den Wert Für style kommen rpc und document in frage. SOAP:operation <SOAP:operation/> beschreibt eine vollständige Operation und besitzt wieder das Attribut style welche bestimmt ob SOAP-ANachrichten nach rpc- oder document- Stil erzeugt werden. rpc wird wie der Name schon andeutet für RPC, also Methodenaufrufe mit Parametern und Rückgabewerten benutzt, document hingegen ist zur allgemeinen Datenübertragung gedacht. Als zweiten Parameter kann man SOAPAction angeben, das die URI enthält, die im HTTP-Header angegeben wird, vorrausgesetzt man benutzt HTTP als Transportprotokoll. Ist HTTP nicht das verwendete Transportprotokoll, so darf dieses Attribut nicht verwendet werden. SOAP:body SOAP:fault SOAP:header SOAP:headerfault SOAP:address service Im Element service werden die verschiedenen Ports (nächster Unterabschnitt) zusammengefasst. port Ein Port beschreibt die Adressen des Services. Das Element besitzt wie in WSDL üblich ein Attribut name, das den Namen des Ports enthält und ein Attribut binding, das den Namen des Bindings enthält. Das port-element wiederum enthält ein Element <SOAP:address/> bzw. < das die URL zum Service im Attribut location enthält. 3.3 Alternativen zu WSDL Die ganzen Standards rund um Web Services befinden sich in ständiger Weiterentwicklung. Auch WSDL wird ständig weiterentwickelt. Es entstehen sogar neue Entwicklungen, die WSDL ersetzen könnten wie z.b. Resource Description Framework (RDF) oder DARPA Agent Markup Language (DAML). Diese sind sogar mächtiger als WSDL, was sie allerdings auch wieder komplexer macht. 12

16 4 UDDI 4.1 Wozu UDDI? Nachdem nun bekannt ist wie Clients mit Web Services kommunizieren und wie man Web Services mti Hilfe von WSDL beschreiben kann fehlt noch ein wesentlicher Punkt: das Finden von Web Services. Es ist günstig eine Art Katalog oder Google für Web Services zu haben, und in der Tat, so etwas gibt es: UDDI (Universal Description, Discovery Integration). Abbildung 4.1: Web Services Dreieck Mit Hilfe von solchen Verzeichnissen kann man nach Web Services suchen. Findet man einen Web Service, so er hält man vom Verzeichnis die zum Web Service gehörende WSDL-Datei, die den Service beschreibt. Mit Hilfe dieser Datei kann nun ein Client implementiert werden. Dieser kommuniziert dann mit dem Web Service auf die im WSDL-Dokument beschriebene Art mit den dort definierten Typen. In einem UDDI Register stehen jedoch nicht nur WSDL-Dateien zu den Web Services zur Verfügung, ein UDDI umfasst Informationen zum Anbieter, also dem Web Service Hersteller, eine nicht-technische Beschreibung des Services, die vom Anbieter gestellt wird und die technische Beschreibung, die die Schnittstellen beschreibt. UDDI ist jedoch im Gegensatz zu SOAP kein W3C-Standard sondern entstand aus einem Zusammenschluss diverser Firmen. WSDL ist auf dem Weg ein W3C-Standard zu werden. Auf [5] ist eine Liste der teilnehmenden Unternehmen einzusehen. Um nur einige zu nennen: AMD, Compaq/HP, Computer Associates, IBM, Intel, Microsoft, Oracle, SAP, Sun... 13

17 4.2. STRUKTUR VON UDDI KAPITEL 4. UDDI Aktuell liegt UDDI in der Version 3 vor, jedoch ist UDDI 2 sehr weit verbreitet und dient deshalb auch als Grundlage für dieses Kapitel. UDDI ist wie auch schon SOAP und WSDL strukturiert und baut ebenfalls auf XML auf. Es folgt eine Beschreibung der einzelnen Elemente von UDDI, wobei business entity das Root-Element darstellt. Es bleibt noch zu sagen, dass jedes UDDI-Element einen eindeutigen Schlüssel besitzt, eine UUID (Universal Unique IDentifier), der nach dem ISO/IEC 11578:1996-Algorithmus erzeugt wird. 4.2 Struktur von UDDI Abbildung 4.2: UDDI Struktur business entity Hier werden alle Informationen zu einem Anbieter einer Gruppe von Diensten zusammengefasst. Das Element business entity enthält wiederum andere Elemente, und zwar folgende: businesskey ist der eindeutige Schlüssel des Eintrags (UUID, 41 Hex-Zeichen lang) discoveryurls verweist auf andere Dokumente, wo dieser Dienst beschrieben wird (Struktur, optional) name enthält einen vom Menschen gewählten Namen (String, 255 Zeichen) 14

18 4.2. STRUKTUR VON UDDI KAPITEL 4. UDDI description enthält eine kurze Beschreibung des Unternehmens (String, 255 Zeichen, optional) contacts Liste von Ansprechpartnern (Struktur, optional) businessservices Liste angebotener Dienste (Struktur, optional) identifierbag Weil Sätze und textuelle Beschreibungen von Computern nicht auswertbar und Web Services auch von Programmen zur Laufzeit dynamisch gefunden und eingebunden werden sollen, gibt es dieses Feld identifierbag, das die Eigenschaften des Unternehmens und Dienstes in Form von Schlüssel-Werte- Paaren speichert. (Struktur, optional) categorybag Ebenfalls aus Schlüssel-Werte Paaren aufgebaute Liste, diesmal aber von Kategorien. (Struktur, optional) business service Im business service steht die Beschreibung eines Dienstes. businesskey kann angegeben werden und enthält dieselbe UUID wie beim zugehörigen business entity des Unternehmens. (UUID, 41 Hex-Zeichen, optional) servicekey enthält wieder eine 41-stellige UUID, diesmal jedoch identifiziert sie den Dienst eindeutig. name ist der vom Menschen gewählte Name für den Eintrag (String, 255 Zeichen) description textuelle Kurzbeschreibung des Dienstes (String, 255 Zeichen, optional) bindingtemplate enthält die technische Beschreibung der Dienstfamilie (Struktur) categorybag hier werden Schlüssel-Werte-Paare angegeben zur Kategorisierung des Dienstes, z.b. für geographische Position, Klassifikation, usw. (Struktur) binding template business template umfasst die technischen Informationen zum Service. bindingkey enthält die 41-stellige UUID, die das binding template eindeutg identifiziert. servicekey kann optional wiederholt werden (UUID, 41 Hex-Zeichen, optional) description enthält wieder eine optionale Kurzbeschreibung (String, 255 Zeichen) accesspoint hier wird die Adresse des Web Services, also z.b. URL, Mail-Adresse, etc. (String, 255 Zeichen) 15

19 4.3. BENUTZUNG VON UDDI KAPITEL 4. UDDI hostingredirector ist anzugeben, falls das erforderliche accesspoint fehlt, dann bedeutet dieses Feld, dass es bereits ein aktuelleres binding template gibt und verweist darauf. tmodelinstancedetails ist eine Liste von tmodelinstanceinfo-elementen, welche auf tmodels verweisen. [2] tmodel In tmodel steht ine technische Beschreibung des Dienstes, die als Grundlage für einen technischen Fingerabdruck dient. tmodelkey eindeutiger Schlüssel zur Identifizierung des tmodel (String, 255 Zeichen) authorizedname Name des Veröffentlichers des tmodel (String, 255 Zeichen) name des Eintrags (String, 255 Zeichen) description Beschreibung des Eintrags (String, 255 Zeichen, optional) overviewdoc ist eine Referenz auf externe Informationen oder Anweisungen zum tmodel identifierbag Schlüssel-Werte-Paare zur Beschreibung des tmodel, sind durchsuchbar (Struktur) categorybag enthält Schlüssel-Werte-Paare zur Kategorisierung des tmodel (Struktur) publisher assertion Hier werden Informationen dazu gesammelt, wie zwei Anbieter zueinander stehen, falls eine Beziehung zwischen ihnen besteht. 4.3 Benutzung von UDDI UDDI muss zwei Arten von Zugriffen unterscheiden: zum einen gibt es die Web Service Anbieter, die ihre Services in das UDDI Register eintragen wollen, sie müssen Schreibrechte besitzen. Die andere Gruppe sind die Web Service Nutzer, die nur Leserechte besitzen sollen. Wenn man das noch etwas feiner betrachtet, müssen Anbieter Web Services und Informationen zu ihrem Unternehmen eintragen können, löschen können, und ändern können. Nutzer müssen durch das Verzeichnis browsen und suchen können und müssen auch Informationen zu einzelnen Diensten anzeigen lassen können. 16

20 4.3. BENUTZUNG VON UDDI KAPITEL 4. UDDI Publizieren von Einträgen add_publisherassertions ermöglicht es Beziehungen zwischen Unternehmen herzustellen delete_binding Löschen eines bindingtemplate delete_business Löschen eines businessentity delete_publisherassertions Löschen von Assertions delete_service Löschen eines Services, der von einem businessentity angeboten wird delete_tmodel Macht ein tmodel unsichtbar. Eine echte Löschung kann nur der Administrator des UDDI-Registers vornehmen get_authtoken Hiermt wird ein Authentisierungs-Token vom Operator angefordert. Kann als Login angesehen werden discard_authtoken Hiermit wird ein zuvor vergebenes Token als ungültig erklärt, es entspricht einem Logout get_assertionstatusreport Mit dieser Funkion kann man sich eine Übersicht der Abhängigkeiten der Beziehungen anzeigen lassen get_publisherassertions Diese Funktion liefert die Assertions eines angegebenen Anbieters zurück get_registeredinfo Gibt eine Zusammenfassung aller Daten über einen Anbieter aus save_binding Mit dieser Funktion wird ein neues bindingtemplate angelegt save_business Hiermit legt man ein neues businessentity an save_service Hiermit legt man ein neues zu businessetity gehörendes businessservice an oder aktualisiert es save_tmodel Aktualisiert oder legt ein neues tmodel an set_publisherassertions Setzt alle Beziehungen und löscht evtl. vorhandene Abfragen von Einträgen Bei den Web Service Nutzer-Funktionen gibt es Funktionen, die mit find beginnen, die sind für das Browsen und Suchen nach Diensten zuständig, und Funktionen, die mit get beginnen. Diese sind dazu da zu Diensten detaillierte Informationen anzuzeigen. find_binding wird genutzt, um Informationen zur Anbindung zu erhalten 17

21 4.4. ALTERNATIVE ZU UDDI WSIL KAPITEL 4. UDDI find_business sucht nach Informationen über Unternehmen, zurückgegeben wird eine Liste von Unterehmen find_relatedbusiness Hier wird von einem gegebenen Unternehmen (als Parameter wird businesskey übergeben) ausgehend ein verwandtes Unternehmen gesucht. Passende Treffer werden als Liste zurückgegeben find_service Findet Dienste find_tmodel Hiermit kann man Modelle finden get_bindingdetails ermöglicht es Detailinformationen zu einem bindingtemplate anzuzeigen get_businessdetail Gibt die Informationen zu einem oder mehreren Unternehmen aus get_businessdetailext Gibt erweiterte Informationen zu einem Unternehmen zurück get_servicedetail Hiermit erhält man alle vorhandenen Informationen zu einem Service get_tmodeldetail Hiermit kann man detaillierte Informationen zu einem tmodel abrufen 4.4 Alternative zu UDDI WSIL WSIL (Web Service Inspection Language) ist eine Alternative und zugleich Ergänzung zu UDDI. Es basiert darauf, dass es nicht nötig ist wie in UDDI Daten und technische Details zum Web Service in einem Register zu speichern, sondern darauf, dass jeder Web Service Anbieter auch eine Beschreibung des Web Services anbietet, und zwar das WSDL-Dokument. WSIL hilft nun einem Web Service suchenden Client beim Auffinden von Informationen, sei es durch einen direkten Link zum WSDL-Dokument oder durch durchsuchen eines UDDI-Register, wo man wieder bei der Ergänzung zu UDDI wäre. 18

22 Literaturverzeichnis [1] ZIMMERMANN, OLAF, MARK TOMLINSON und STEFAN PEUSER: Perspectives on Web Services - Applying SOAP, WSDL an UDDI to Real-World Projects. Springer Verlag, ISBN [2] KUSCHKE, MICHAEL und LUDGER WÖLFEL: Web Services kompakt. Spektrum Akademischer Verlag, ISBN [3] XMethods.net. Internet. [4] CHRISTENSEN, ERIK, FRANCISCO CURBERA, GREG MEREDITH und SANJIVA WEERAWARANA: Web Services Description Language (WSDL) 1.1. Internet, [5] UDDI Mitglieder. Internet, [6] WSDL Tutorial. Internet, [7] SOAP Tutorial. Internet, [8] WSDL. Internet, [9] SOAP Services. Internet,

23 Abbildungsverzeichnis 2.1 SOAPEnv01.xml SOAP Envelope SOAPHead01.xml SOAP Header SOAPBody01.xml SOAP Body SOAPBody02.xml SOAP Body (Response) SOAPFault01.xml SOAP Fault SOAPDatatypes01.xml SOAP Datentypen (simple Typen) SOAPDatatypes02.xml SOAP Datentypen (Arrays) SOAPDatatypes03.xml SOAP Datentypen (Strukturen) WSDL Operationen Web Services Dreieck UDDI Struktur

24 Index SOAP, 4 7 Arrays, 7 Body, 5 Datentypen, 7 Envelope, 4 Fault, 5 Header, 5 Strukturen, 7 operation, 10 porttype, 10 Struktur, 9 types, 10 WSIL, 18 UDDI, Benutzung, 16 Abfragen, 17 Publizieren, 17 binding template, 15 business entity, 14 business service, 15 publisher assertion, 16 Struktur, tmodel, 16 Web Services, 1 WSDL, 9, 12 Alternativen, 12 binding, 11 SOAP:address, 12 SOAP:binding, 11 SOAP:body, 12 SOAP:fault, 12 SOAP:header, 12 SOAP:headerfault, 12 SOAP:operation, 12 definitions, 9 documentation, 9 import, 10 message, 10 21