Softwareentwicklung und Hypermedia Fachhochschule Dortmund Fachbereich Informatik Betreuer: Prof. Dr. Thiesing - 7042882-7042911 SS 2004 / Mai 2004 1 Einführung Was sind Web Services? Unter Web Services versteht man eine im Internet veröffentlichte Software, die über Standardschnittstellen angesprochen wird. Die Interaktion zwischen Client und Server geschieht durch den Austausch XML-basierter Nachrichten, die mittels Internetprotokollen übertragen werden. Da Web Services ein Internetdienst sind, müssen die eingesetzten Technologien Plattformunabhängig und unabhängig von einer bestimmten Programmiersprache sein. und sind zwei Möglichkeiten um Web Services zu implementieren. 2 1
Einführung Anwendungsmöglichkeiten von Web Services Direkte Kommunikation von Mensch und Computer Applikationen kommunizieren untereinander Mensch tritt als Einflussgröße in den Hintergrund 3 Was ist? steht für Simple Object Access Protocol Protokoll zum Austausch strukturierter Informationen Unterliegt dem W3C-Standard Aktuelle Version ist 1.2 Breite Unterstützung in der Wirtschaft 4 2
Merkmale von Basiert auf XML Plattformunabhängig Programmiersprachenunabhängig Kein bestimmtes Transportprotokoll, üblicherweise wird HTTP benutzt Leichtgewichtig, nur minimale Grundfunktionalität 5 Wie wird benutzt? RPC (Remote Procedure Call) Bei RPC ruft die -fähige Anwendung entfernte Methoden des Servers per Web Services auf. Es werden in der -Nachricht beim Methodenaufruf nur der Methodenname und die Parameter übertragen. Dokumentebasiert Es werden strukturierte Informationen versendet. Der Web Server verarbeitet diese Informationen und schickt das Ergebnis sofort oder zeitlich versetzt zum Sender zurück. 6 3
Struktur von -Nachrichten 7 -Envelope Grundgerüst einer -Nachricht Ist ein Behälter vergleichbar mit einem Briefumschlag In der -Envelope ist der -Header und der -Body enthalten Wichtig für die Erkennung als -Nachricht <?xml version="1.0" encoding="utf-8"?> <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <!-- optionaler -Header --> <!-- -Body --> </env:envelope> 8 4
-Header Optionaler Bestandteil Falls vorhanden, muss der Header vor dem Body stehen inhaltsunabhängige Daten und anwendungsspezifische Angaben Kann mehrere Blöcke besitzen Wenn der Empfänger den Header nicht verarbeiten kann, wird dieser ignoriert. Es sei denn das Attribut mustunderstand ist gesetzt <env:header> <x:ersterblock xmlns:x="http://example.com" env:mustunderstand="true">... </x:ersterblock> <y:zweiterblock xmlns:y="http://example.com">... </y:zweiterblock> </env:header> 9 -Body und Attachment -Body Beinhaltet die eigentliche Nachricht Keine festgelegte Struktur Muss im XML-Format geschrieben werden Bei RPC enthält er Informationen zum Funktionsaufruf: Methodenname, Parameterliste und Rückgabewert Attachment Optional und nicht Bestandteil der Envelope Zum Anhängen von Dokumenten Keine Beschränkung für das Dateiformat 10 5
-Fault Wird verwendet um Informationen über aufgetretene Fehler zu übermitteln -Fault ist ein Unterelement des Bodys Besteht aus den Unterelementen Code, Reason und den optionalen Elementen Node, Role und Detail Code: dient zur Fehlerklassifizierung Reason: dient der menschenlesbaren Fehlerbeschreibung Node: Node in welchem der Fehler aufgetreten ist Role: Funktion in welcher der Fehler aufgetreten ist Detail: weitere Informationen zum Fehler 11 Beispiel für eine RPC-Nachricht <?xml version='1.0' encoding="utf-8?> <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:header> <m:reservation xmlns:m="http://travelcompany.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d</m:reference> <m:date>2004-05-10</m:date> </m:reservation> </env:header> <env:body> <p:itinerary xmlns:p="http://travelcompany.org/reservation/travel"> <p:setreservation> <p:departing>duesseldorf</p:departing> <p:arriving>muenchen</p:arriving> <p:departuredate>2004-05-29</p:departuredate> <p:departuretime>mid-morning</p:departuretime> <p:class>business</p:class> </p:setreservation> </p:itinerary> </env:body> </env:envelope> 12 6
Beispiel für eine dokumentenbasierte Nachricht Alternativ könnte man die Anfrage auch dokumentebasiert senden. In diesem Fall würde keine Operation (setreservation) aufgerufen, sondern der Empfänger extrahiert aus der -Nachricht die Flugdaten. Es wird aber die gleiche Antwort zurückgegeben wie bei der RPC- Anfrage. Der fettgedruckte Text ändert sich wie folgt: <departing>duesseldorf</departing> <arriving>muenchen</arriving> <departuredate>2004-05-29</departuredate> <departuretime>mid-morning</departuretime> <class>business</class> 13 Encoding Definition der einzelnen Datentypen Das Attribut encodingstyle im Body gibt die Regeln zur Serialisierung von -Nachrichten an Man kann entweder eine eigene Regel im XML- Format definieren oder den Standard des W3C benutzen http://www.w3.org/2003/05/soap-encoding W3C-Standard http://example.org/encoding eigene Definition http://www.w3.org/2003/05/soap-envelope/encoding/none keine Regel Es gibt einfache und zusammengesetzte Datentypen 14 7
Was ist? steht für Representational State Transfer In der Dissertation von Roy Fielding zum ersten mal beschrieben Kein Standard wie Architekturvorbild für das Internet Plattform- und programmiersprachenunabhängig Auch geeignet für die Erstellung von Web Services Bei -Anwendungen ist jede Ressource, z.b. ein Artikel in einem Onlineshop, über eine URI adressiert und kann so angesprochen werden Transportprotokol ist HTTP 15 Merkmale von Ein -Netzwerk besteht aus Client und Server Ein -System besteht aus Ressourcen, die per URI adressiert werden Jede Anfrage muss alle notwendigen Informationen für die Durchführung beinhalten (da HTTP stateless ist) Antworten vom Server müssen in der Lage sein, als cacheable oder non-cacheable markiert zu werden Weder Client noch Server müssen die Bedeutung einer URI verstehen Darstellungen werden untereinander verlinkt, um dem Client die Möglichkeit zu geben, von einem Zustand in den nächsten zu wechseln 16 8
HTTP-Anfrage Es gibt derzeit zwei HTTP-Versionen, 1.0 und 1.1 Bei HTTP handelt es sich um ein verbindungs- oder statusloses Protokoll Die erste Zeile der Anfrage ist die Kommandozeile Ein HTTP-Kommando hat immer folgenden Aufbau: METHODE ID VERSION HTTP-Methoden: DELETE, GET, HEAD, LINK, OPTIONS, POST, PUT, TRACE, UNLINK Daran angehängt kann ein Message-Header folgen Der Header enthält weitere Parameter, die das Kommando spezifizieren 17 HTTP-Antwort Die Antwort auf ein Kommando besteht im Senden eines Statuscodes Es folgen optionale Felder und bei der Übertragung von Ressourcen die Daten Die Statuszeile hat folgenden Aufbau: VERSION STATUSCODE STATUSTEXT Der Statuscode ist eine eindeutige Nummer, die den Bearbeitungsstatus angibt, z.b. 404 für nicht gefunden ANFRAGE: GET /index.html HTTP/1.1 Host: www.fh-dortmund.de Accept: text/html, text/plain, text/sgml, text/xml If-Modified-Since: Wed, 28 Jan 2004 00:00:00 <CRLF> ANTWORT: HTTP/1.0 200 Document follows Date: Mon, 17 Mai 2004 17:09:45 GMT+100 Content-Type: text/html Last-Modified: Mon, 09 Feb 2004 14:43:13 Content-Length: 7856 <CRLF> <HTML> </HTML> 18 9
basierte Web Services Ein Web Service wird am Besten an einem Beispiel erläutert. Im folgenden Beispiel nehmen wir an, dass ein Unternehmen zwecks Einbindung ihrer Kunden in das eigene System sie befähigen soll eine Artikelliste anzufordern, detailliertere Informationen zu einem Artikel zu erhalten und sogar eine Bestellung auszulösen. Während die ersten beiden Aktionen nur read-only sind, kann man mit der Dritten Daten auf dem Server verändern. 19 basierte Web Services (2) 1) Artikelliste anfordern Der -Service macht eine URL zu einer Artikelliste-Ressource verfügbar. Der Client kann mit der HTTP-GET-Anfrage GET /artikelliste HTTP/1.0 die Repräsentation der Ressource anfordern. Die Artikelliste enthält Links, um detaillierteren Daten zu einzelnen Artikeln zu erhalten. Dies ist ein Schlüsselmerkmal von. Der Client wechselt von einem Zustand in den nächsten, indem es die alternativen URLs durchsucht und auswählt. <?xml version="1.0"?> <p:artikeliste xmlns:p="http://www.webserver.de" xmlns:xlink="http://www.w3.org/1999/xlink"> <Artikel id="00345" xlink:href="http://www.webservice.de/aritkelliste/00345"/> <Artikel id="00346" xlink:href="http://www.webservice.de/aritkelliste/00346"/> <Artikel id="00347" xlink:href="http://www.webservice.de/aritkelliste/00347"/> <Artikel id="00348" xlink:href="http://www.webservice.de/aritkelliste/00348"/> </p:artikelliste> 20 10
basierte Web Services (3) 2) Artikel anfordern Der Web Service macht eine URL zu jedem Artikel verfügbar. Hier zum Beispiel eine Clientanfrage zu einem bestimmten Artikel: http://www.webservice.de/artikelliste/00345. Die Einzelaufstellung zu einem Artikel wird durch Verfolgung des Hyperlinks gefunden. Jedes Antwortdokument erlaubt es dem Client zu noch detailliertertere Informationen zu gelangen. <?xml version="1.0"?> <p:artikel xmlns:p="http://www.webserver.de" xmlns:xlink="http://www.w3.org/1999/xlink"> <Artikel-ID>00345</Artikel-ID> <Name>Widget-A</Name> <Beschreibung>Zange für FBS </Beschreibung> <Einzelaufst xlink:href="http://www.webservice.de/aritkellist00345/einzelaufst"/> <Stueckpreis waehrung="eur"> 0.10 </Stueckpreis> <Menge> 10 </Menge> </p:artikel> 21 basierte Web Services (4) Bei der Adressierung von Ressourcen ist zu unterschieden zwischen logischen und physischen URLs. Logische URIs drücken aus, welche Ressourcen es gibt. Sie identifizieren kein physisches Objekt. Die Artikeldaten werden beispielsweise in einer Datenbank abgespeichert. Der Web Server erhält die logische URL-Anfrage, parsed sie und entscheidet welche Artikel angefragt wurden. Dann stellt er eine Abfrage an die Datenbank und generiert das Antwort- Dokument, das an den Client geschickt wird. Komplexe URL: http://www.webservice.de/artikelliste/? stueckpreis=1&menge=10 22 11
basierte Web Services (4) 3) Bestellung auslösen Der Web Service macht eine URL zur Auslösung einer Bestellung verfügbar. Der Client erstellt ein Dokument, zum Beispiel eine XML-Datei, die der xsd- Datei (Schema) des Servers entspricht. Die generierte Datei wird im Body einer POST-Anfrage an den Server gesendet. Der Empfänger verarbeitet die erhaltene Datei und gibt die Url der neu erstellten Ressource zurück. 23 Goldene Regeln bei der Implementierung von 1. Erstelle für jede Ressource eine eigene URI 2. Logische URIs sind physischen vorzuziehen, z.b. http://www.boeing.com/airplanes/747 ist besser als http://www.boeing.com/airplanes/747.html 3. Nutze Nomen in der URI anstatt Verben. Ressourcen sind konkrete Sachen, keine Handlungen 4. Benutze Links in den Antworten. Verbinde deine Antworten mit anderen Daten, damit der Client weiß welche Daten er noch abfragen kann. 5. Minimiere den Gebrauch von Abfrage-Strings, also http://www.webservice.de/artikelliste/00345 anstatt http://www.webservice.de/artikelliste?artikel-id=00345 So wird deutlich, dass zwischen der Artikelliste und dem Artikel 00345 eine Beziehung besteht. 6. Benutze ein Slash / in der Url, um Unterressourcen zu adressieren 7. Verwende anstatt POST immer die GET-Methode, wenn der Server eine Repräsentation einer Ressource zurückgeben soll. 24 12
Implementierung erfordert mehr Implementierungsaufwand als Für gibt es zahlreiche Lösungspakete fordert eine stärkere Bindung zwischen Client und Server als. Bei jeder Veränderung des Servers muss der Client angepasst werden : Ändert sich die Darstellung einer Ressource oder werden neue Ressourcen zur Verfügung gestellt, kann das Interface des Clients beibehalten werden Noch wird nur dort eingesetzt, wo man nur Daten erfragen kann. Das liegt daran, dass die HTTP-Methoden PUT und DELETE oft nicht unterstützt werden. Diese Unterstürzung müsste nachträglich implementiert werden. 25 : : Funktionsweise -Nachricht wird über POST verschickt Eigentlichen Funktionen sind innerhalb der Nachricht kodiert Alle Aufrufe werden zunächst an den Dispatcher gerichtet Dieser übernimmt die Aufgabe der Datenzustellung Bei wird durch die eindeutige URL die Ressource direkt angesprochen Der Web Server interpretiert die URL und entscheidet, welche Ressource gemeint ist 26 13
Sicherheit Web Services passieren Firewalls problemlos, da HTTP verwendet wird Inhalt der -Nachricht ist innerhalb des Bodys kodiert und Administratoren können nicht sehen was aufgerufen wird In ist die gesamte Nachricht in der URL kodiert. Firewalls können eine bestimmte URL (Ressource) sperren PUT und DELETE können vom Server gesperrt werden, dadurch kann die Anwendung nur lesen ( read-only ) Bei können die bestehenden Sicherheits-mechanismen der Server genutzt werden. Ressourcen lassen sich mit HTTP und HTTPS authentifizieren und autorisieren Bei und werden die Daten unverschlüsselt übers Netz transportiert Bei ist es sehr aufwendig atomare Transaktionen zu implementieren 27 Skalierbarkeit und Effizienz ist leichtgewichtig, daher wird im Standard auf Verschlüsselung, Zugriffskontrolle oder Transaktionen verzichtet -Nachrichten können nicht gecacht werden, da sie über POST verschickt werden -Anfragen können gecacht werden, dadurch Erhöhung der Performance In enteht bei jeder Nachricht neben den Nutzdaten ein großer Overhead Die logischen URLs müssen bei vom Server ausgewertet und interpretiert werden um die Ressource zu erkennen Komprimieren der Daten ist in beiden Verfahren nicht möglich Bei sind alle Anfragen stateless. Dies hat positive Auswirkungen auf die Skalierbarkeit 28 14
Fazit und Ausblick ist derzeit Standard und wird von W3C weiterentwickelt Dadurch wird die Zustimmung in der Wirtschaft gegenüber vergrößert In Sachen Skalierbarkeit, Sicherheit und Verschlüsselung wird sich zukünftig auch noch was tun Durch die Verbindung von und können Web Services-Architekturen gebaut werden, die sowohl die Flexibilität und Skalierbarkeit von nutzen als auch die Unterstützung von Web Services-Technologien wie und WSDL ermöglichen 29 Noch Fragen? 30 15