Hauptseminar. Thema: WebServices

Transkript

1 Hauptseminar Thema: WebServices Studiengang: WIW-ET/IT-TK 1

2 Inhaltsverzeichnis 1. Einführung WebServices XML RPC HTTP SOAP-Simple Object Access Protocol Entwicklung von SOAP XML-RPC SOAP 1.1/ Struktur von SOAP Aufbau Encoding HTTP-Binding Attribute Fehlermeldungen Stile Einsatzgebiete von SOAP Sicherheit Unterstützende Dienste WSDL UDDI Implementierung Server-Implementierung Client-Implementierung Abschließende Betrachtungen Kritische Betrachtung Zusammenfassung Quellen Abkürzungsverzeichnis Anhang A. Beispiel-WSDL

3 1. Einführung Die vorliegende Arbeit beschäftigt sich mit dem Thema WebServices. Dabei werden die erforderlichen Bausteine wie Protokolle und unterstützende Dienste näher beleuchtet. Im ersten Kapitel soll zunächst eine Definition von WebServices erfolgen. Danach wird auf die Grundlagen von XML, die zur Beschreibung der WebServices dient, eingegangen. Im Folgenden werden entfernte Methodenaufrufe (RPC) erklärt, die aufgrund dieser Technologie möglich sind. Der letzte Abschnitt ist dem benutzten Transportprotokoll HTTP gewidmet WebServices WebServices stellen die Basis für verteilte Anwendungen im Internet dar. Für WebService- Applikationen sind folgende Techniken notwendig: Einlesungs-, Speicherungs- und Darstellungstechniken, Techniken um Daten auszutauschen und entsprechende Dienste zur Publikation. Als gemeinsame Beschreibungssprache dient XML. (vgl. [HZ03] S.143; [App04] S.7) WebServices haben die Eigenschaft der Interoperabilität, d.h. Applikationen können miteinander kommunizieren, unabhängig davon, in welcher Programmiersprache die jeweiligen Applikationen abgefasst sind und unabhängig davon, auf welcher Plattform sie implementiert worden sind. WSDL (Web Service Description Language) bietet die Möglichkeit, Schnittstellen zu beschreiben. Mit Hilfe der UDDI-Technologie kann man seinen eigenen WebService registrieren lassen bzw. WebServices suchen. Bei der Kommunikation der WebServices wird meist das Standard-Webprotokoll SOAP (Simple Object Access Protocol) eingesetzt. WebServices dienen vor allen Dingen als Informationsquellen. Diese vom WebService bereitgestellten Informationen können dann in Anwendungen integriert werden. Angebotene Dienste können zu neuen kombiniert werden, da Kommunikation zwischen verteilten Anwendungen möglich wird. ([Wol01] S.1-2) 1.2. XML XML steht für extensible Markup Language, es handelt sich hierbei um eine Auszeichnungssprache. Sie wurde aus SGML (Standard Generalized Markup Language) entwickelt. Mit XML kann man Texte strukturieren. Der große Vorteil von XML besteht darin, dass es sowohl maschinen- als auch durch Menschen lesbar ist. Die Lesbarkeit für Menschen wird durch die freie Definierbarkeit der Tags erreicht. Im Gegensatz zu HTML, wo es nur fest vorgeschriebene Tags gibt, kann man bei XML die Tags so definieren, dass man gleich herauslesen kann, was im Body angegeben werden soll. Die Tags dürfen dabei natürlich nicht mit der DTD (Document Type Definition) in Konflikt stehen. Die Gesamtheit der Tags wird als Markup bezeichnet, was in die Abkürzung XML eingeht. Dabei gibt es bei XML einige Regeln, die nachfolgend erläutert werden. ([And00] S.35) Es muss immer ein Starttag <tag-name> und ein Endtag </tag-name> geben. Die Tags können aber auch leergelassen werden um z.b. einen Ja/Nein-Status darzustellen, dies wird dann so gekennzeichnet: <tag-name/>. Zwischen Start- und Endtag steht dann der Body, also die eigentlichen Nutzdaten. Es können auch zusätzlich Attribute innerhalb der Tags untergebracht 3

4 werden, die Werte dieser Attribute müssen dabei immer in Anführungsstrichen gesetzt sein. Weiterhin muss noch beachtet werden, dass die Tags in der richtigen Reihenfolge geschlossen werden müssen (das zuletzt geöffnete Tag muss zuerst wieder geschlossen werden). Falls dies nicht der Fall ist, handelt es sich bei dem vorliegenden Dokument um kein wohlgeformtes Dokument, und es kommt dabei zu Fehlern. Bei HTML-Dokumenten werden diese Fehler einfach ignoriert, hätten dort also keine weitreichenderen Auswirkungen. Desweiteren ist noch anzumerken, dass im Gegensatz zu HTML bei XML die Groß- und Kleinschreibung berücksichtigt wird. HTML legt größeren Wert auf die Präsentation der Daten, wobei XML größeren Wert auf Inhalte und Daten legt. Diese scheinbare Vernachlässigung wird durch die Anwendung von XML-Style-Sheets aufgehoben. ([Knu03] Kapitel 1.5, S.19; weitergehend [HZ03] Kapitel 1.2, ab S.24) 1.3. RPC RPC ist die Abkürzung für Remote Procedure Call, d.h. entfernter Funktionsaufruf. Entfernt bedeutet, dass der Aufruf über jegliche Grenzen, also sowohl über Programm- als auch Rechnergrenzen hinweg erfolgen kann. Mit RPC kann man Programme auf anderen Rechnern aufrufen, dabei können auch Parameter übergeben werden. Sogenannte Stubs dienen hierbei als Vermittler oder Zwischenstelle. Auf der Client-Seite sorgen die Stubs für die Verpackung der zu übergebenden Parameter, auf der Server-Seite entpacken die Stubs dann die Parameter wieder. Die Parameter werden als Call-by-value übergeben. Es kann Probleme bei der Kommunikation geben, falls es sich bei den Kommunikationspartnern um unterschiedliche Rechnerarchitekturen handelt. Die Methodik des RPCs ist in Abbildung 1 zu sehen. ([Knu03] Kapitel 1.8, S.22-24; [Sti00] S.14; weitergehend [SS00] S ) Lokaler Aufruf Funktion Funktion Bibliothek Netzwerk Stub Client Abbildung 1: Remote Procedure Call Server Es gibt verschiedene Ansätze RPCs zu realisieren. Eine Möglichkeit besteht darin, die RPCs über die gleiche Programmiersprache zu gestalten, hierin liegt aber auch genau der Nachteil dieses Ansatzes, da keine Interoperabilität vorliegt. Ein zweiter Ansatz sind sogenannte Object Request Brokers, Beispiele dafür sind DCOM und CORBA. Der Nachteil bei dieser Methodik besteht darin, dass das gleiche Protokoll benutzt werden muss. ([Sti00] S.14, 15) SOAP kann man auch dazu benutzen, RPC-Mechanismen zu realisieren. Dabei wird auf bestehende Standards wie HTTP und XML zurückgegriffen. Hierbei wird die Anfrage als 4

5 HTTP-Request und das Resultat als HTTP-Response übertragen. Bei einem solchen Aufruf müssen die URI (Uniform Resource Identifier) des Zielobjekts und der Methodenname bekannt sein. Methodenaufruf und zurückgegebenes Ergebnis werden als Struktur (Struct) präsentiert. Die jeweiligen Parameter stellen ein Element in dem Struct dar. Fehlermeldungen werden durch Benutzen des SOAP-Fault-Elements übergeben. ([Sti00] S.15) 1.4. HTTP HTTP steht für HyperText Transfer Protocol. Das HTTP-Protokoll dient der Kommunikation zwischen Client und Webserver. Eine sichere Verbindung ohne Abhörmöglichkeit wird dabei durch sogenannte Secure Sockets Layer, die einen sicheren Kanal bereitstellen, gewährleistet. Die eigentliche Übertragung bzw. Sendung der Nachrichten erfolgt mit dem TCP/IP-Protokoll (Transmission Control Protocol/Internet Protocol). Bei HTTP handelt es sich um ein Request/Response-Protokoll (siehe Abbildung 2). Es ist somit sehr gut für die Realisierung von RPCs geeignet. Bei HTTP ist die Groß- und Kleinschreibung nicht relevant. Es handelt sich hierbei um ein statusloses Protokoll, d.h. es besitzt keine Erinnerung, jede Anfrage ist komplett neu. HTTP hilft beim Herunterladen von Seiten aus dem Internet, die durch einen Browser dargestellt werden. Die HTTP-Version 1.0 beinhaltet eine nicht persistente Verbindung, d.h. nach jeder einzelnen Anforderung wird die Verbindung getrennt. In HTTP 1.1 wurde diese Schwäche behoben, denn jetzt wartet der Server, ob noch eine weitere Anfrage kommt. ([HTTP04a] S.1; [HTTP04b] S.1; [CGB00] S.22, 25; [Sti00] S.18) Client/Browser Request Response Server Abbildung 2: Anfrage-Antwort-Modell Die Struktur einer HTTP-Nachricht spaltet sich auf in Header und Body. Im Header sind Metainformationen enthalten. Der Body trägt die eigentliche Information, also die Nutzinformation. Dabei muss bei Anfragen nicht unbedingt ein Body vorhanden sein, bei Antworten sind immer Header und Body eingeschlossen (Ausnahme HEAD). Header und Body müssen immer durch eine Freizeile getrennt sein. ([HTTP04a] S.1; weiter [CGB00] S.22-36) Es gibt eine Reihe von unterschiedlichen Requests z.b. GET, HEAD, POST, PUT, DELETE, LINK und UNLINK. Mit GET erhält man den gesamten Inhalt der gesuchten Seite zurück. Als Antwort auf HEAD folgt nur der Header. POST wird vor allen Dingen auch bei SOAP eingesetzt, da damit Daten zum Server übertragen werden, die dieser dann in die angegebene URL einfügt. Mit LINK und UNLINK werden Links entweder erstellt oder wieder entfernt. DELETE dient zum Löschen von Adressen auf dem Server. Mit PUT sollen Daten auf der angegebenen URL gespeichert werden. ([HTTP04b] S.2; [CGB00] S.26-28) Der HTTP-Request hat natürlich wieder die typische Header-Body-Struktur. Die erste Zeile wird als Request- oder Statuszeile bezeichnet. Dort wird als erstes die Art des Requests angegeben, dann folgt die Adresse des zu bearbeitenden Links, also die URL, und dann noch die HTTP-Version. Diese drei Teile sind jeweils durch ein Leerzeichen getrennt. Danach folgen die Header-Felder, sie bestehen aus Name-Werte-Paaren, d.h. zuerst wird das Headerfeld 5

6 benannt z.b. Host und dann wird durch einen : ein Wert zugeordnet, z.b. Nach einer Leerzeile folgen dann die eigentlichen Daten. GET /index.html HTTP/1.1 Host: User-Agent: Mozilla/4.0 (compatible; MSIE 4.5;Windows NT 5.0) Die Antworten enthalten natürlich auch wieder Header und Body. Die Antwort kann aus den gewünschten Daten, Weiterleitungen oder Fehlern bestehen. Die erste Zeile ist wieder eine Art Statuszeile, sie enthält die benutzte HTTP-Version, den 3-stelligen Fehlercode und die Fehlermeldung. Es gibt fünf verschiedene Kategorien von Fehlern. Von handelt es sich um Informationen, sind erfolgreiche Anfragen, stellen Verschiebungen und allgemeine Veränderungen dar, sind Fehler beim Client und schließlich sind Fehler beim Server. Es gibt hier eine Reihe von möglichen Header-Feldern. Allow: Methode ist z.b. sehr üblich, hiermit wird eingeschränkt welche Methode der Client benutzen darf. Oder beispielsweise WWW-Authenticate: Authentifizierung dient dazu Einschränkungen zu treffen, so dass nicht jeder berechtigt ist bestimmte Daten zu empfangen. Desweiteren gibt es z.b. auch noch Content-Encoding, Content-Length, Content-Type, Date und viele weitere mehr. Im Body sind bei den Antworten natürlich wieder die Nutzdaten enthalten. ([HTTP04b] S.2-5; [CGB00] S.24-26, 28-36) HTTP/ OK Date: Sat, 01 Jan :24:45 GMT Server: Apache/1.3.9 (Unix) Last-Modified: Fri, 24 Dec :23:48 GMT 2. SOAP-Simple Object Access Protocol In diesem Abschnitt steht das den WebServices zugrunde liegende Protokoll im Mittelpunkt. SOAP heißt Simple Object Access Protocol. SOAP hat, wie der Name schon sagt, als großes Ziel die Einfachheit. Dabei sollen vor allem bereits existierende Standards (wie HTTP und XML) genutzt werden, darauf kann dann aufgesetzt werden. Die Erweiterbarkeit bzw. Verallgemeinerung des Austausches von Daten sollen natürlich auch nicht vernachlässigt werden, d.h. es soll z.b. auch die Anwendung anderer Transportprotokolle ermöglicht werden. Außerdem sollen mit SOAP sowohl RPC-Aufrufe als auch das normale Versenden von Dokumenten realisiert werden können. Desweiteren steht der Einsatz von SOAP in verteilten Systemen im Mittelpunkt, was mittels RPC geschafft wird. ([Sti00] S.1, 18; [HZ03] S.149; [W3CS03] S.2, 3) Es soll im folgenden Kapitel zuerst auf die Entwicklung von SOAP eingegangen werden. Dabei wird der Blick auf XML-RPC und SOAP 1.1/1.2 gelenkt. Danach folgt der größte Abschnitt, in welchem die Struktur von SOAP beleuchtet wird, dazu gehören Gesichtspunkte wie Aufbau, Encoding, HTTP-Binding, Attribute, Fehlermeldungen und Stile. Zuletzt wird noch ein Blick auf die Themen Einsatzgebiete und Sicherheit von SOAP geworfen. 6

7 2.1. Entwicklung von SOAP In dem nun folgenden Kapitel soll die Entwicklung von XML-RPC hin zu SOAP 1.1/1.2 beschrieben werden. Es wird auf die Grundlagen von XML-RPC eingegangen und ein Vergleich der SOAP-Versionen 1.1 und 1.2 durchgeführt XML-RPC XML-RPC ist ein Protokoll zur Realisierung von WebServices und somit ein Vorläufer von SOAP. Es benutzt dabei XML und HTTP als Standards. HTTP wird deswegen als Grundlage genutzt, weil es gut durch Firewalls oder Proxies tunnelt. Mit XML-RPC kann man, wie der Name schon sagt, RPC-Aufrufe durchführen. Allerdings ist das auch ein Nachteil, denn es sind mit diesem Protokoll nur RPCs möglich. Sogenannte sessionbehaftete Aufrufe bei denen Methoden immer auf derselben Instanz auf der Serverseite aufgerufen werden, sind nur mit Hilfe von Cookies realisierbar. ([App04] S.8, 10; [HZ03] S.143, 147, 148; [SS00] S.75) XML-RPC ist ein sehr einfaches Protokoll. Es enthält keine Metainformationen, was zu Problemen führen kann. Es muss auf natürlichsprachliche Beschreibungen zurückgegriffen werden, wobei es zu Einschränkungen kommen kann und somit die Flexibilität sinkt. Aufgrund der Einfachheit ist auch eine einfache Implementierung möglich, da keinerlei Ausnahmen berücksichtigt werden müssen und nur RPCs realisiert werden müssen. XML-RPC überträgt Parameter durch das Kriterium der Position. Probleme kann es bei der Kodierung geben, diese ist auf ASCII festgelegt, damit können nicht alle Zeichen richtig dargestellt werden. Es können Records, Arrays und die normalen skalaren Datentypen, wie z.b. boolean, double, string dargestellt werden. Probleme treten bei Strings mit Sonderzeichen auf. Strings werden grundsätzlich nur als ASCII kodiert, das ermöglicht aber nicht die Darstellung von Sonderzeichen, somit müssen diese auf Basis von base64 kodiert werden. Aufgrund dieses Fakts bläht sich außerdem die Datenmenge auf, da Daten erst in Text überführt werden, dann als ASCII übertragen werden und auf der anderen Seite wieder entpackt werden. Auf der anderen Seite ist diese Festlegung auf ein einziges Encoding auch ein Vorteil bei der Implementierung von Server und Client. Ein weiteres Problem besteht mit dem Datumsformat, welches nicht auf eine bestimmte Zeitzone fixiert ist und damit Interpretationen Raum lässt. Wenn die Daten komplexer werden, kann man sie als Struct oder Array übertragen. Structs bestehen aus einer Liste von Membern, denen jeweils ein Name und Wert zugeordnet werden kann. Arrays sind Sequenzen von Werten. Ein weiterer Nachteil von XML-RPC besteht darin, dass es nicht möglich ist, zyklische Datenstrukturen zu übertragen, da die Daten als Baum übermittelt werden. ([HZ03] S ; [App04] S.8, 10) Aufrufe werden bei XML-RPC über HTTP-POST-Requests realisiert. Dabei müssen vier Headerfelder (richtig) gesetzt sein. Der Content-Type muss auf text/xml gesetzt werden. Im Headerfeld Content-Length muss die Größe des Requests in Bytes angegeben werden. Es muss außerdem ein Host-Header und ein User-Agent angegeben werden. Ein Aufruf ist in Haupt- <methodcall> und Unterknoten <methodname>, in denen der Name der Methode angegeben wird, und Paramsknoten gegliedert. Die Methoden können auf Parameter <param>, die im Paramsknoten <params> enthalten sind, zurückgreifen. Die einzelnen Parameter enthalten nun die jeweiligen Werte. Die Werte werden mit <value> eingeleitet, dann folgt der 7

8 Datentyp, als Tag dargestellt, also z.b. <boolean>, danach kommt der eigentliche Wert und dann werden die Tags wieder in richtiger Reihenfolge geschlossen. Beispielaufruf ([HZ03] S.144): POST /xmlrpc-app HTTP/1.1 Host: euklid.toxine.lan User-Agent: Java-Client Content-Type: text/xml Content-length: 243 <?xml version= 1.0?> <methodcall> <methodname> Hallo </methodname> <params> <param> <value><string> Welt </string></value> </param> </params> </methodcall> Die Antwort kann entweder ein Rückgabewert oder ein Fehler sein. Es wird dabei dieselbe Struktur wie bei den Anfragen verwendet. Dem Knoten <methodresponse> folgen die Parameter, die dann den eigentlichen Rückgabewert als <value> enthalten. Bei Fehlern steht anstelle des <params>-tag ein <fault>-tag. Der Fehler selbst wird darin als Struct mit Fehlerdefinition realisiert. ([SS00] S.75, 76; [HZ03] S.143, 144, 146, 147; weitergehend XML- RPC-Spezifikation unter: Beispielantwort ([HZ03] S.146): HTTP/ OK Date: Sat, 01 Jan :24:45 GMT Server: Apache/1.3.9 (Unix) Content-Type: text/xml Content-length: 800 <?xml version= 1.0?> <methodresponse> <params> <param> <value><string> Hallo Welt </string></value> </param> </params> </methodresponse> SOAP 1.1/1.2 SOAP 1.2 wurde auf Basis von SOAP 1.1 erarbeitet. Im September 2000 wurde mit der Arbeit begonnen, dabei wurden die technischen Lösungen von SOAP 1.1 bewertet. Mit SOAP 1.2 wird erhöhte Interoperaberilität, bessere Web-Integration, höhere Flexibilität und ein klareres Verarbeitungsmodell angestrebt. SOAP 1.2 soll einen robusteren und eindeutigeren Verarbeitungsprozeß anbieten. ([W3CF03] S.1) SOAP 1.1 basiert auf der XML 1.0 Serializiation wohin gegen SOAP 1.2 auf dem XML Information Set basiert. SOAP 1.2 enthält keine Einschränkungen, wie die Nachrichten transportiert werden sollen. ([W3CF03] S.2; [Had02] S.2) 8

9 Der XML-Namespace für den Envelope und Encoding Schemas hat sich von Version 1.1 ( zu Version 1.2 ( 2002/12/soapenvelope) geändert, damit ist eine leichte Unterscheidung der Nachrichten durch die SOAP-Prozessoren gewährleistet. In SOAP 1.1 sind hinsichtlich der Struktur nach dem Body-Element noch weitere Elemente möglich, dies ist in SOAP 1.2 untersagt. ([Had02] S.2) Bezüglich des Bindings zeigt SOAP 1.2 echte Protokollunabhängigkeit auf, dies wird durch Definition eines abstrakten Bindingsrahmen möglich. Wenn die spezifische Protokollbinding mit dem Rahmenbinding konform geht, kann das jeweilige Protokoll zum Transport benutzt werden. Zusätzlich definiert SOAP 1.2 wie auch Version 1.1 eine spezielle HTTP-Binding, und außerdem stellt die Version 1.2 noch ein -Binding zur Verfügung. ([Had02] S.4,5; [W3CF03] S.2) Bezüglich der Attribute gab es auch Veränderungen, das Actor-Attribut wurde in Version 1.2 in Role-Attribut umbenannt, was der eigentlichen Funktion auch näher kommt. In SOAP 1.1 gab es nur eine vordefinierte Rolle bei der Übertragung von Nachrichtenketten, nämlich die Rolle Next. SOAP 1.2 definiert noch zwei zusätzliche Rollen. None kennzeichnet Headerblöcke, die nie direkt verarbeitet werden sollen. Ultimate Receiver wird benutzt, wenn Headerblöcke nur von dem wirklichen Empfänger der Nachricht verarbeitet werden sollen. ([Had02] S.3) Im Bereich der FaultCodes gab es einige Umbenennungen und Erweiterungen. Die Fehlerklasse Client wurde in SOAP 1.2 in Sender, und Server in Receiver umbenannt. Zusätzlich wurden DataEncodingUnknown, falls eine empfangene Nachricht eine einen unbekannten Wert des Encodingstyle-Attributs benutzt, und DTDNotSupport, wenn eine empfangene Nachricht eine Document Type Declaration benutzt, definiert. Die Kodierung wurde im Wesentlichen gleich gehalten, es wurden nur einige Vereinfachungen vorgenommen, es gibt z.b. kleine Unterschiede in der Referenzgebung. Bei Arrays wird das arraytype-attribut ersetzt durch das itemtype-attribut, zusätzlich wurde noch ein arraysize-attribut definiert. SOAP 1.2 bietet im weiteren Semantiken zum Verwalten von Nachrichten unterschiedlicher SOAP-Versionen an. ([Had02] S.3-5) 2.2. Struktur von SOAP Der nächste Abschnitt ist der Strukturerläuterung von SOAP gewidmet. Hierbei sollen der Aufbau (Header, Body), das Encoding und die Bindung an HTTP beschrieben werden. Desweiteren erfolgt die Erklärung der in SOAP benutzten Attribute, der zurückgegebenen Fehlermeldungen und der möglichen SOAP-Stile Aufbau Da SOAP auf XML basiert, müssen die Header- und Nutzinformationen in XML verpackt werden. Daher wurde ein Envelope (Briefumschlag) entwickelt, dieser stellt das Wurzelelement dar. Der Envelope besteht aus zwei Elementen, dem Header und dem Body. ([Knu03] S.38; [HZ03] S.149, 150; [W3CS03] S.4; [Sti00] S.3) 9

10 <?xml version= 1.0 encoding= UTF-8?> Envelope Header Body <soap-env:envelope xmlns:soap= /soap/envelope/ > <soap-env:header> Header-Information </soap-env:header> <soap-env:body> Nutzdaten </soap-env:body> </soap-env:envelope> Abbildung 3: Struktur von SOAP ([Knu03] S.38, Abb. 2.9; [HZ03] S.150) Der Header muss dabei nicht unbedingt vorhanden sein, ist also optional. Falls der Header vorhanden ist, steht er immer an erster Stelle im Envelope. Es gibt auch gewisse Syntaxregeln für den Envelope: Der Name lautet Envelope Der Envelope muss immer vorhanden sein, bei jeder SOAP-Nachricht Es dürfen Deklarationen von Namensräumen enthalten sein. Außerdem können zusätzliche Attribute und Unterelemente eingebaut werden, wobei jeweils ein Namensraum zugeordnet werden muss. Durch den Header sind Erweiterungen bezüglich der Nachricht möglich. In ihm sind die Informationen zwischen den Kommunikationspartnern enthalten, die nicht direkt die Nutzinformationen betreffen. Dies können z.b. Informationen zu Authentifikation oder zur Transaktionsverarbeitung sein. Im Header werden also sogenannte Metainformationen übertragen, dadurch bekommt man eine Unabhängigkeit vom Übertragungsprotokoll, man muss sich also nicht nur auf HTTP beschränken, sondern kann z.b. auch SMTP benutzen. Im Header werden einige Attribute definiert, die aber erst später behandelt werden. Im Body sind dann die eigentlichen Informationen, also die Nutzdaten enthalten. Die Nutzdaten können entweder einen Methodenaufruf (RPC) oder XML-Dokumente realisieren. Binäre Daten sind für XML-Dokumente nicht so gut geeignet, da sie erst verpackt und auf der anderen Seite wieder entpackt werden müssten, und auf Basis von base64 kodiert werden müssten. Um diese Art von Daten zu übertragen, arbeitet man mit Attachments auf Basis des MIME- Standards (Multipurpose Internet Mail Extensions). ([HZ03] S.149, 150; [W3CS03] S.7, 8; [Sti009] S.4-6; weitergehend [HZ03] S ) Encoding Bei einfachen Datentypen kann auf die XML-Schema-Definition zurückgegriffen werden, da diese bereits dort definiert sind. Diese Datentypen können dann einfach direkt zugeordnet werden. Einfache Datentypen sind: string, boolean, float, double, decimal, time- Duration, recurringduration, binary, urireference, ID, IDRef, Entity, QName. Alle anderen Datentypen müssen auf Basis der XML-Schema-Deklaration extra definiert werden. ([Sti00] S.8, 9) 10

11 Bei Aufzählungstypen (Listen) werden die einzelnen Elemente durch den Namen des Wertes repräsentiert. Dabei ist zu beachten, dass der Name und der dazugehörige Wert vom gleichen Basistyp sind. ByteArrays werden auf Basis von base64 kodiert, SOAP stellt dabei schon einen vordefinierten Typ zu Verfügung: SOAP-Enc:base64. Variante Datentypen werden durch das sogenannte xsi:type-attribut realisiert. Außerdem kann man mit SOAP noch zusammengesetzte Datentypen darstellen, es gibt zwei Typen: Structs und Arrays. ([Sti00] S.9, 10) Bei Structs wird jedes Element durch seinen Namen erkennbar, d.h. es wird die Eindeutigkeit der Namen gefordert. Die einzelnen Elemente des Structs können alle anderen Datentypen realisieren, auch Structs sind bei den Unterelementen als Datentyp wieder möglich. ([Sti00] S.10, 11) Arrays hingegen sind geordnete Reihen von Elementen, hierbei ist die Position zur Identifizierung der Elemente entscheidend. Man kann Arrays auch teilweise übertragen, dies wird durch Benutzen des SOAP-Enc:offset-Attribut erreicht. Hier wird ab einem festzulegenden Offset eine bestimmte Reihe von Elementen übertragen. Außerdem können Arrays auch auszugweise übermittelt werden, dabei wird die Position des Elements durch das SOAP- Enc:position-Attribut angegeben. ([Sti00 S.11, 12]) HTTP-Binding Protokollbindungen im Allgemeinen dienen der Sicherung der Interoperabilität. SOAP ermöglicht die Benutzung verschiedener Transportprotokolle. Mit einer SOAP- Transportprotokoll-Binding werden Regeln für die Übermittlung von SOAP-Nachrichten auf Basis des jeweiligen Transportprotokoll definiert. Die SOAP-1.1.-Spezifikation legt nur ein Binding für HTTP fest. Das liegt an der großen Verbreitung von HTTP als Transferprotokoll. SOAP-Request-Parameter werden dabei immer innerhalb von HTTP-Requests realisiert, SOAP-Response-Parameter innerhalb von HTTP-Responses. ([W3CS03] S.14, 15; ) Das Headerfeld Content-Type muss bei der Übertragung von SOAP-Nachrichten immer auf text/xml gesetzt sein. Die SOAP-Spezifikation schreibt weiterhin POST als Art des Requests vor. Weiterhin wird ein neues HTTP-Headerfeld: SOAPAction definiert. Mit SOAPAction wird der Zweck der SOAP-Nachricht beschrieben. Der Wert ist ein URI (Uniform Resource Identifier). Der HTTP-Client, der einen SOAP-Request verschicken will, muss das SOAPAction-Feld nutzen. Wenn dieses Feld keinen Wert enthält, so wird der Zweck nicht näher beschrieben. Wenn das Feld leer ist, d.h. mit gefüllt ist, kann bezüglich des Zwecks auf die URI im HTTP-Request zurückgegriffen werden. Bei den Antworten werden die gleichen Statuscodes wie bei HTTP benutzt, um Fehler oder erfolgreiche Anfragen zu identifizieren. ([Knu03] S.39-41; [W3CS03] S.15; [Sti00] S.13) Attribute Es gibt drei wesentliche Attribute, die SOAP kennzeichnen. Dazu gehören das Actor-, das MustUnderstand- und das EncodingStyle-Attribut. 11

12 Mit Hilfe von SOAP kann man Kommunikationsketten realisieren, d.h. neben dem Empfänger kann es auch noch viele Zwischenstellen geben. Damit verbunden ist auch, dass nicht alle Informationen für jede Station bestimmt sind. Jede Station muss die für sie bestimmten Informationen heraussuchen, kann dann selbst noch Informationen für den Empfänger oder für irgendeine nachfolgende Zwischenstelle hinzufügen und muss dann die Nachricht weiterleiten. Die für sie bestimmten Informationen muss die Zwischenstation verarbeiten. Um den Empfänger der einzelnen Informationen eindeutig festzulegen, wird das SOAPActor-Attribut eingesetzt. Der Wert dieses Attributs ist jeweils ein URI. Falls kein Actor-Attribut in der Nachricht verwendet wurde, sind alle Informationen für den Empfänger bestimmt und sollen dort verarbeitet werden. SOAP stellt einen vordefinierten Wert für das Actor-Attribut zur Verfügung, dabei handelt es sich um den Wert für die jeweils nächste Station (URI = Somit ist der Empfänger der Information der nächste Knoten in der Kommunikationskette. ([W3CS03] S.13, 14; [Sti00] S.5; [Knu03] S.38, 39) Das MustUnderstand-Attribut wird benutzt, um den jeweiligen Empfänger zur Verarbeitung/ Auswertung der Headerinformationen zu bringen. Es kann die Werte 0 oder 1 annehmen. Ist das MustUnderstand-Attribut auf 1 gesetzt, so muss der Empfänger die Informationen verarbeiten. Falls dies nicht möglich ist oder nicht erfolgreich geschieht, wird ein Fehler zurückgegeben. Ein MustUnderstand-Attribut mit dem Wert 0 impliziert einen Defaultwert (Nullwert wird angenommen, wobei die exakte Repräsentation vom Datentyp abhängt), d.h. man kann die Headerinformationen einfach ignorieren und die Verarbeitung fortsetzen. Wenn das MustUnderstand-Attribut weggelassen wurde, wird auch ein Defaultwert angenommen. ([Knu03] S.39; [W3CS03] S.12; [Sti00] S.5, 6) Das Encodingstyle-Attribut wird benutzt um die Kodierung zu identifizieren, die jeweils angewendet wird. Der Wert dieses Attributs repräsentiert eine Liste von URIs, diese sind jeweils durch Leerzeichen getrennt, und werden vom speziellsten zum allgemeinen Kodierungssatz geordnet. ([Sti00] S.4) Fehlermeldungen Beim Auftritt von Fehlern wird immer eine Fehlermeldung, die durch das Fault-Element repräsentiert wird, zurückgegeben. Das Fault-Element ist als Element immer im Body aufgeführt. Dieses Element hat vier Unterelemente. ([Sti00] S.6; [Knu03] S.39) Als erstes Unterelement wird der Faultcode angeführt, dieser muss bei Auftritt eines Fehlers immer zurückgegeben werden. Durch diesen Code wird der Fehler eindeutig identifiziert (namespace qualified name). Er dient zur Auswertung durch Software, ist von Menschen nicht interpretierbar. Desweiteren muss auch immer ein Faultstring vorhanden sein. Dieser String ist für Menschen lesbar und kann somit interpretiert werden. Der Faultactor hat als Wert einen URI, er zeigt den Verursacher bzw. die Quelle des Fehlers auf. Zuletzt können noch Detailinformationen bezüglich des Fehlers bereitgestellt werden. Diese weitergehenden Informationen werden nur bei Fehlern erzeugt, die bei der Verarbeitung des Bodies auftreten. Das Detailelement kann weitere Unterelemente enthalten. Es stellt einfach nur weitere Informationen bereit. ([Knu03] S.39; [Sti00] S.7; [W3CS03] S.9, 10) SOAP stellt vier vordefinierte Fehlercodes bereit ([Sti00] S.7; [W3CS03] S.10): 12

13 VersionMismatch wird zurückgegegeben wenn ein ungültiger Namensraum für das Envelope-Element gefunden wurde. MustUnderstand wird benutzt, wenn ein Header-Element nicht erkannt bzw. nicht verarbeitet wird, obwohl das MustUnderstand-Attribut auf 1 gesetzt ist. Das Benutzen des Client-Codes bedeutet, dass der Empfänger die Nachricht nicht verarbeiten kann, dies kann aufgrund eines ungültigen Formates der Nachricht oder aufgrund von fehlenden Informationen relevant werden. Server bedeutet, dass die Verarbeitung der Nachricht aus nichtinhaltlichen Gründen nicht funktioniert hat Stile Bei SOAP werden grundsätzlich zwei Stile unterschieden, der Dokument- und der RPC-Stil. Beim Dokument-Stil wird ein XML-Dokument verschickt, über dessen Format sich Sender und Empfänger einig sein müssen. Mit dem Dokumentstil können neben Dateien auch RPC- Aufrufe realisiert werden. Der RPC-Stil kann hingegen, wie der Name schon sagt, nur RPC- Aufrufe realisieren, der Aufruf wird dabei auch in XML verfasst. ([W3CS03] S.17, 18) 2.3. Einsatzgebiete von SOAP SOAP sollte vorzugsweise eingesetzt werden in heterogenen Umgebungen, wenn nicht so hohe Performance gefordert wird, wenn die Sicherheitsanforderungen begrenzt sind und bei der Kommunikation verschiedener Systeme aus unterschiedlichen Umgebungen über Internet. Es sollte weiterhin in offenen Systemen, wo die Vorteile von WebServices wirklich gebraucht werden, genutzt werden. Offene Systeme bedeutet hierbei, dass es keine klar definierte Zielgruppe gibt. Ebenfalls nicht anwendbar sind Webdienste auf Basis von SOAP, wenn hohe Zuverlässigkeit gefordert wird. ([Sti00] S.19; [FJ03] S.34, 35) 2.4. Sicherheit Die Sicherheit von SOAP war kein primäres Designziel, somit ist SOAP selbst unsicher. Die Daten werden im Klartext übermittelt, was einige Risiken birgt. Außerdem bietet SOAP auch keine Möglichkeiten der Verschlüsselung bzw. Authentifikation. Die Sicherheitsproblematik wurde und wird teilweise auf das Transportprotokoll bzw. auf den Anwender übertragen. Es werden z.b. sichere Verbindungen, sogenannte Secure Sockets Layer, durch HTTP zur Verfügung gestellt, außerdem stellt HTTP Möglichkeiten zur Authentifikation bereit. Man kann auch einzelne Verschlüsselungsstationen einschalten, oder nur einmalige IDs zur Authentifikation einer Nachricht vergeben. Mit der Erweiterung von SOAP werden und wurden auch spezielle Spezifikationen zum Thema Sicherheit entwickelt. Beispiele hierfür sind die WS-Security-Spezifikation, die eine Verschlüsselung gewährleistet, und die WS-License-Spezifikation, die Methoden bereitstellt, um die Identität des Anfragers zu garantieren. ([Sti00] S.17, 18; [Wol01] S.4) 13

14 3. Unterstützende Dienste Das Kapitel Unterstützende Dienste beschäftigt sich mit den Technologien WSDL und UDDI. Zuerst erfolgt die Betrachtung von WSDL als Methodik zur Schnittstellenbeschreibung. Dann wird das Suchen und Registrieren mittels UDDI erläutert WSDL WSDL steht, wie bereits erwähnt, für WebService Description Language. WSDL ist aus zwei verschiedenen Beschreibungssprachen hervorgegangen: NASSL (Network Accessible Service Specification Language) von IBM und SCL (SOAP Contract Language) von Microsoft. Auf Grundlage dieser beiden Sprachen wurde dann WSDL erarbeitet. WSDL 1.1. gilt z.z. als defacto Standard, er findet breite Unterstützung in der Industrie. An WSDL 1.2. wird gerade durch die W3C gearbeitet. ([HZ03] S.165; [W3CW03] S.5-6; [App04] S.9) WSDL beschreibt auf Basis von XML den Austausch von Nachrichten und die Nachrichten selbst. Der Code ist dabei sowohl menschen- als auch maschinenlesbar, meist aber werden die WSDL-Nachrichten von Software erzeugt und auch in Empfang genommen, es werden dazu entsprechende Tools zur Verfügung gestellt. Diese XML-Schema-Basis bietet einige Vorteile, man erreicht damit eine Unabhängigkeit von spezifischen Programmiersprachen, außerdem ist die Standardisiertheit ein weiterer Pluspunkt. Mit WSDL versucht man eine Strukturierung der Daten zu erreichen. Es werden dabei Nachrichten zu Operationen, und diese wieder zu Schnittstellen zusammengefasst. ([Wol01] S.4, 5) Es gibt vier Hauptbereiche, die mit Hilfe von WSDL abgedeckt werden sollen. Als erstes sollen mit WSDL Schnittstellen zwischen angefragten Dienst und Client definiert werden. Desweiteren sollen die Datentypen, die beim Austausch von Nachrichten benutzt werden, beschrieben werden. Eine weitere Aufgabe besteht in der Beschreibung der Bindung an ein Transportprotokoll. WSDL soll weiterhin Informationen zum Finden von bereitgestellten Diensten definieren. Im Mittelpunkt steht dabei immer die Schnittstellenbeschreibung. WSDL benutzt dabei diesen XML-Namensraum: ([HZ03] S.165; [W3CW03] S.6) Die Struktur eines WSDL-Dokuments gliedert sich in einzelne Teildefinitionen (Teilelemente), die jeweils durch ein Tag eingeleitet werden. Die Elemente types, message und porttype sind abstrakte Definitionen der WebService-Schnittstelle, sie bilden die Schnittstelle zur eigenen Implementierung. Die anderen beiden Elemente binding und service beschreiben die konkreten Details, wie die abstrakte Schnittstelle auf die zu versendenden Nachrichten abgebildet wird. ([W3CW03] S.7) Im Nachhinein sollen einige dieser Definitionen erläutert werden: Types-Element Mit dem Types-Element können Datentypen beschrieben werden, dabei sind beliebige Typspezifikationen möglich, wobei SOAP-Typdefinitionen Standard sind. Das Element kann weggelassen werden, wenn nur einfache SOAP-Datentypen verwendet werden. ([W3CW03] S.7-9; [HZ03] S.166) 14

15 Message-Element Das Message-Element definiert unidirektionale Nachrichten, wie Anfragen oder Antworten. D.h. das Message-Tag beschreibt jeweils nur den Input oder Output für eine Operation. Es muss jeweils der Name der Nachricht und falls vorhanden Part-Elemente angegeben werden. Das Part-Element enthält Anfrageparameter bzw. Rückgabewerte. Der Name der Nachricht muss eindeutig sein, man muss darauf von allen WSDL-Teilen aus zugreifen können. ([W3CW03] S.7, 9, 10; [HZ03] S.166) PortType-Element (auch Interface-Element) Durch das PortType-Element werden die Schnittstellen, also der bidirektionale Nachrichtenaustausch beschrieben. Es werden also Kombinationen von Input- und Outputelementen beschrieben. Die Input- und Outputelemente werden zusammengefasst, durch die jeweilige Reihenfolge von In- und Output-Elementen entstehen Nachrichtenaustauschmuster. Dabei unterscheidet man vier verschiedene Muster ([W3CW03] S.7, 10-12; [HZ03] S.166). One-way d.h. es gibt nur ein Input-Element, somit bekommt der Empfänger eine Nachricht Request-Response d.h. ein Input-Element wird von einem Output-Element gefolgt, der Empfänger bekommt eine Nachricht und sendet eine Antwort Solicit-Response d.h. einem Output-Element folgt ein Input-Element, der Empfänger sendet eine Nachricht und bekommt eine Rückantwort Notification d.h. es gibt nur ein Output-Element, der Empfänger versendet eine Nachricht Binding-Element Das Binding-Element beschreibt, wie ein bestimmtes Protokoll beim Nachrichtenaustausch verwendet wird. Es muss einen eindeutigen Namen besitzen, so dass von überall im WSDL-Dokument darauf zugegriffen werden kann. ([W3CW03] S.7, 12-17; [HZ03] S.167) Service-Element Mit dem Service-Element werden die Adressen für das Holen eines WebServices beschrieben, es werden meist HTTP-konforme URIs benutzt. Mit diesem Element werden Ports definiert, die jeweils mit eigenem Namen und speziellem Binding verbunden sind. Innerhalb des Port-Elements wird dann die eigentliche Adresse durch das Extensibility-Element dargestellt. ([W3CW03] S.7, 17, 18; [HZ03] S.167) Weiterhin gibt es neben diesen Elementen noch das Documentation-Element, mit welchem Erklärungen und Beispiele erfasst werden und das Import-Element, das dazu dient andere WSDL-Dokumente oder XML-Schema-Definitionen einzubinden. ([HZ03] S.167; weitergehend: WSDL-Spezifikation unter WSDL-Tags: [Knu03] S ) Eine vollständige WSDL für das später beschriebene WebService Beispiel (AddSubService) ist im Anhang A zu finden. 15

16 3.2. UDDI UDDI ist die Abkürzung für Universal Discovery Description and Integration. Aus Anwendersicht dient UDDI als Suchmaschine, dabei wird im Gegensatz zu Suchmaschinen im Internet ein Format für den jeweiligen Zweck festgelegt. Die Informationen werden teilweise für den Nutzer in Portalen aufbereitet. Aus Entwicklersicht hat UDDI zwei Funktionen: das Publizieren und das Auffinden von Diensten. Vorteile beim Suchen sind die Eingrenzbarkeit der Suchparameter und der hohe Automationsgrad. UDDI beschreibt die Schnittstelle zwischen Dienst-Anbieter (Service Provider) und Client, dabei wird die Service Broker Architektur benutzt. ([HZ03] S ; ) Service Client Service Provider auffinden (Find) Verbinden (Bind) Service Provider Service Broker Dienst registrieren (Publish) Abbildung 4: Service Broker Architektur ([HZ03] S.169, Abbildung 3.6) Die UDDI-Registry dient der Registrierung und Verbreitung der Dienstbeschreibungen. Die Einträge in die UDDI-Registry sind XML-Dateien, sie bestehen aus drei Teilen: den Weißen Seiten, den Gelben Seiten und den Grünen Seiten. 1. Die Weißen Seiten enthalten allgemeine Informationen über das dienstanbietende Unternehmen, dazu gehören z.b.: Name, Adresse, Kontaktpersonen, Steuernummer usw. 2. In den Gelben Seiten werden die Dienste in Gruppen erfasst, es erfolgt eine Einordnung des Dienstes in eine Kategorie. 3. In den Grünen Seiten werden die technischen Informationen für den Zugriff und somit auch die Schnittstelle des Dienstes beschrieben. Zu diesen Informationen zählen auch Informationen über den physischen Standort, Verhalten und Support-Funktionen eines Dienstes.([HZ03] S.171; [Wol01] S.5; ) Die UDDI-Registry bildet ein dezentrales technisches System. Es besteht aus einer Vielzahl von Knoten (Operator Nodes), deren Gesamtheit die Business Registry (UBR) bezeichnet. Die einzelnen Knoten gleichen sich ständig über einen Replikationsmechanismus ab. Wenn an einem Knoten etwas eingefügt wird, ist es kurze Zeit später im ganzen System verfügbar. Der Knoten, an dem Informationen eingefügt werden, ist der logische Eigentümer (Master Owner), d.h. Löschen und Ändern der Informationen ist auch nur an diesem speziellen Knoten möglich. Die Eigenschaft der Dezentralität bietet die Möglichkeit sowohl private als auch öffentliche UDDI-Server zu betreiben. ([HZ03] S.172) 16

17 UDDI benutzt fünf verschiedene elementare Datenstrukturen, die im Folgenden kurz erläutert werden sollen ([HZ03] S ): businessentity-struktur Die businessentity-struktur beschreibt die Geschäftsinformationen, wie z.b. Kontakt, Kategorisierung, Beschreibung, Beziehungen zu anderen Unternehmen, Schlüssel (ID). Jedes Unternehmen wird als businessentity definiert. publisherassertion-struktur Mit dieser Struktur wird die Beziehung zwischen Unternehmen definiert, es muss von beiden Seiten eine äquivalente Beziehung aufgebaut worden sein, eine Seite reicht für eine wirkliche Beziehung nicht aus. businessservice-struktur Eine oder mehrere dieser businesservice-strukturen können Inhalt einer businessentity-struktur sein. Die businessservice-struktur dient der Gruppierung von Diensten, es können dann einzelne Dienstleistungen näher beschrieben werden. tmodel-struktur Mit dieser Struktur können Dienste identifiziert werden, desweiteren wird die Kommunikation mit dem WebService beschrieben. Dabei werden Zeiger auf Ressourcen im Web oder auf Ressourcen in der realen Welt anstelle von Spezifikationen verwendet. bindingtemplate-struktur Eine businessservice-struktur kann eine oder mehrere bindingtemplate-strukturen enthalten. Die bindingtemplate-struktur dient der technischen Beschreibung und der Angabe einer Zugriffs-URL. Dabei enthält diese Struktur ein accesspoint-element, welches die Zugriffsadresse des Services beinhaltet, und Referenzen auf eine tmodel- Struktur. Um die UDDI-Registry anzusprechen unterscheidet man fünf grundlegende UDDI- Nachrichtentypen: Authentifikationsnachrichten Die Authentifikationsnachrichten haben als Zweck die Anbzw. Abmeldung bei der UDDI-Registry. Für alle schreibenden Zugriffe braucht man eine vorherige Authentifikation. Suchnachrichten Suchnachrichten dienen, wie der Name schon sagt, dem Suchen von Diensten. Eine vorherige Authentifikation ist beim Suchen nicht notwendig. Anfragen beginnen immer mit find, dieses wird abhängig von der jeweiligen Datenstruktur mit einem Zusatz ergänzt. Nachrichten um Detailinformationen abzufragen Diese Nachrichten werden benutzt, um zusätzlich spezielle bzw. tiefergehende Informationen zu erhalten. Um diese Informationen zu beschaffen, ist wie beim Suchen auch keine vorherige Authentifikation nötig. Alle Anfragen beginnen mit get und haben dann einen Zusatz, der sich auf die jeweilige Datenstruktur bezieht. Zum Suchen der Detailinformationen werden 17

18 Primärschlüssel (IDs) benutzt, diese werden schon beim Einfügen der Struktur angelegt. Nachrichten zum Hinzufügen/Ändern Für die Operationen des Hinzufügens und Änderns ist immer eine vorhergehende Authentifikation notwendig, bei der Anmeldung wird eine Authentifikationsmarke zurückgegeben, diese Marke muss beim Hinzufügen/Ändern bei jeder Operation weitergegeben werden. Das Hinzufügen und Ändern wird durch einen Nachrichtentyp abgedeckt. Es wird innerhalb der Registry gesucht ob eine Struktur vorhanden ist. Wenn sie schon vorhanden ist, wird das Ändern durchgeführt. Wenn eine Struktur nicht gefunden wird, wird sie hinzugefügt. Die Anfragen beginnen meist mit save, aber es gibt auch Ausnahmen. Löschnachrichten Nachrichten zum Löschen sind schreibende Zugriffe, d.h. sie benötigen auch eine vorangegangene Authentifikation. Diese Nachrichten beginnen immer mit delete, dann folgt auch hier der jeweilige Datenstrukturzusatz. ([HZ03] S ; weitergehende Infos unter und [Knu03] S ) 4. Implementierung Die Autorin hat sich zwecks Implementierung für die Benutzung des Microsoft Visual Studio.NET entschieden. Mit diesem Tool ist die Implementierung sehr einfach. Im Folgenden soll die Server- bzw. Client-Implementierung anhand eines gewählten Beispiels, welches die Addition bzw. Subtraktion von zwei Zahlen realisieren soll, erläutert werden Server-Implementierung Wenn man das Microsoft Visual Studio.NET geöffnet hat, muss man zuerst die Option Neues Projekt wählen. Daraufhin öffnet sich ein neues Fenster, indem man den Projekttyp und eine entsprechende Vorlage auswählt. Die Autorin hat die Implementierung mit C# realisiert, also die Option Visual C#-Projekte benutzt. Um einen Server zu implementieren muss man als Vorlage ASP.NET-Webdienst auswählen. Diesem Webdienst kann man dann einen entsprechenden Namen geben, er wurde AddSubService benannt. Der Vorgang der Projektund Vorlagenauswahl wird in Abbildung 5 dargestellt. 18

19 Abbildung 5: Auswahl von Projekt und Vorlage In der.asmx-datei wird nun die Implementierung der Funktionen vorgenommen, dies ist in Abbildung 6 zu sehen. Abbildung 6: Implementierung der Funktionen Dabei gibt es ein vorgegebenes Template. Für das Beispiel der Addition/Subtraktion muss man nur noch die beiden Funktionen Add und Sub einfügen. Mit F5 kann man den WebService nun debuggen und starten. Ist das Debuggen erfolgreich, öffnet sich das WebService- Fenster, hier kann man jetzt zwischen Addition und Subtraktion wählen. Abbildung 7 zeigt nun den erstellten WebService im Browserfenster. Wenn man hier die Dienstbeschreibung wählt, erhält man die WSDL-Beschreibung (siehe Anhang A). Wenn man sich für eine Operation entschieden hat, kann man dann zwei Operanden eingeben, als Ergebnis wird eine XML-Struktur zurückgegeben. Hier wird ein Beispiel für die zurückgegebene XML-Antwort gegeben, das Ergebnis beträgt in diesem Fall 0. <?xml version="1.0" encoding="utf-8"?> <int xmlns=" 19

20 Abbildung 7: Der fertige WebService 4.2. Client-Implementierung Bei der Client-Implementierung muss man genauso, wie bei der Server-Implementierung zuerst ein Neues Projekt anwählen. Diesmal entscheidet man sich bei der Vorlage aber für eine Windows-Anwendung. Dieser kann man nun wieder einen passenden Namen geben (AddSubClient). Danach muss man in der Datei Form1.cs[Entwurf] ein geeignetes Clientfenster erstellen. Als Unterstützung dient dabei die Toolbox. Im Beispiel der Autorin wurden drei Textboxes für die Operanden und das Ergebnis, eine Combobox zur Auswahl der Methode und ein Button zum Berechnen erstellt. Die erstellte Form und die Toolbox zeigt Abbildung 8. 20

21 Abbildung 8: Client-Erstellung mit der Toolbox (links im Fenster) Der nächste Schritt ist die Einbindung des schon vorhandenen WebServices. Hierzu zeigt man mit der Maus in der Klassenansicht auf den Ordner AddSubClient, und betätigt die rechte Maustaste. Im nun erscheinenden Menü wählt man den Punkt Webverweis hinzufügen. Daraufhin öffnet sich ein neues Fenster, dort wählt man die Option Navigieren zu: Webdienste auf dem lokalen Computer aus, und es werden alle schon vorhandenen WebServices angezeigt (man kann natürlich auch gleich die Adresse des gewünschten WebServices eingeben). Nach Auswahl des entsprechenden WebServices (AddSubService) kann man den Verweis hinzufügen. Jetzt muss nur noch die Aktion, die beim Klicken auf den Button ausgeführt werden soll, durch Code im Template beschrieben werden. Dazu muss in die Code-Ansicht gewechselt werden (z.b. durch Doppelklick auf den Button). Zuerst muss ganz oben im Code noch zusätzlich using <Clientname>.localhost; (using AddSubClient.localhost;) eingefügt werden. Danach wird der Button beschrieben, wie in Abbildung 9 dargestellt ist. Im Folgenden kann der Client mit F5 gestartet werden, und auf den bereits vorhandenen WebService zugreifen. 21

22 Abbildung 9: Beschreibung des Buttons 5. Abschließende Betrachtungen Bisher wurde ein Überblick über WebServices auf Basis von XML und HTTP gegeben. Es wurde das SOAP-Protokoll mit seiner Struktur, Einsatzgebieten und dem wichtigen Thema Sicherheit beleuchtet. Desweiteren sind unterstützende Technologien wie WSDL und UDDI erklärt worden. Die Implementierung (sowohl Client als auch Server) wurde anhand eines Beispiels praktisch dargestellt. In diesem Kapitel soll nun das Thema WebServices durch einen Überblick von Vorteilen und Nachteilen einmal kritisch betrachtet werden. Zum Schluss wird eine Zusammenfassung vorgenommen Kritische Betrachtung Aufgrund der Erfahrungen der Autorin und der angewendeten Literatur ([Wol01] S.1, 2, 5, 6; [FJ03] S.32-38) ergeben sich folgende Probleme und Vorzüge von WebServices: 22

23 Vorteile von WebServices setzen auf standardisierten Protokollen (HTTP, TCP/IP), Sprachen (XML) und Tools auf gewährleisten Interoperabilität, d.h. sie sind programmiersprachen-, plattform- und protokollunabhängig es sind sowohl RPCs als auch die Übertragung von XML-Dokumenten realisierbar nicht nur Punkt-zu-Punkt-Übertragungen, sondern Übertragungsketten möglich einfach, Beschränkungen auf das Wesentliche programmatischer Zugriff einfacher und zuverlässiger als bei Webseiten programmtechnische Änderung einfacher herstellerunabhängig Kostenersparnis aufgrund der Anwendung von Standards bei der Einführung einfache Implementierung mit den entsprechenden Tools leicht erlernbar, da man über die Protokolle, XML, HTML gar nicht so genau Bescheid wissen muss, vieles wird maschinell erstellt es gibt eine Technologie zum Auffinden: UDDI mit bestehenden WebServices kann man leistungsfähigere Anwendungen erstellen, dabei auch wieder Kostenersparnis Nachteile von WebServices unreife Technologie es fehlen noch einige Features in Bezug auf Sicherheit, Routing, Zuverlässigkeit, Transaktionen, zuverlässiges Messaging, dies wird versucht durch Spezifikationen innerhalb der Global XML WebServices Architektur zu beheben noch nicht genug getestet bei Einführung ins Geschäft fraglich ist auch noch wie das System von den Konsumenten angenommen wird, in der Industrie wird es breit unterstützt WebServices bieten also durch ihre einfache Implementierung sowohl blutigen Anfängern als auch erfahrenen Entwicklern zugleich die Möglichkeit über sehr leicht handhabbare Tools wie z.b. Microsoft Visual Studio.NET Webdienste zu erstellen. Dabei müssen natürlich noch die Probleme wie Sicherheit und Zuverlässigkeit aus der Welt geschafft werden. Im Großen und Ganzen bieten WebServices eine ganze Reihe von Einsatzmöglichkeiten von einfachen Informationsdiensten wie z.b. Aktienkursen bis hin zu komplexeren Einkaufsprogrammen. Sie sind flexibel einsetzbar Zusammenfassung WebServices sind ein Instrument zur Realisierung von verteilten Anwendungen im Internet. Sie basieren dabei auf Standards wie HTTP und XML. HTTP wird aufgrund der weiten Verbreitung benutzt, außerdem kann es sehr gut durch Firewalls tunneln. Durch Einsatz der SSL- Technologie werden die Verbindungen dann auch relativ sicher. XML hat zum Vorteil, dass es durch die freie Definierbarkeit der Tags, sowohl maschinen- als auch menschenlesbar ist. Aufgrund der Anwendung dieser Standards finden WebServices große Verbreitung innerhalb der Industrie und die Einstiegskosten werden gering gehalten. 23