Web Services Teil 1 Grundlagen und SOAP

Transkript

1 Web Services Teil 1 Grundlagen und SOAP Dieses Kapitel entstammt in Teilen aus Dostal, Jeckle, Melzer, Zengler, Service-orientierte Architekturen und Webservices, Elsevier, 2005 Nik Klever FB Informatik - FH klever@fh-augsburg.de

2 Service-orientierte Architektur Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachen-unabhängige Nutzung und Wiederverwendung ermöglicht. Das Grundkonzept einer SOA geht davon aus, dass das Fundament von offenen Standards, Sicherheit und Zuverlässigkeit gebildet wird und die verteilten Dienste, die lose Kopplung, die Plattformunabhängigkeit und die prozessorientierte Struktur die tragenden Säulen bilden.

3 SOA Tempel Fachhochschule

4 SOA Grundkonzepte lose Kopplung der Dienste Dienste werden von Anwendungen oder anderen Diensten bei Bedarf dynamisch gesucht, gefunden und eingebunden (Bindung zur Laufzeit) Verzeichnisdienst oder Repository es muss ein Zugriff auf eine Instanz des Repositories vorhanden sein, man muss wissen unter welcher Kategorie der Dienst zu finden ist und der Dienst muss sich natürlich im verwendeten Repository registriert haben. Offene Standards Der Aufrufer muss in der Lage sein, sich mit dem Dienst zu unterhalten. Die essenzielle notwendige Forderung dazu ist, dass alle Schnittstellen in maschinenlesbar Form beschrieben sind. Wichtige Voraussetzung dazu ist, dass offene Standards genutzt werden, damit der Nutzer den Dienst eines unbekannten Anbieters auch verstehen kann.

5 SOA Dreieck Fachhochschule

6 Dienste In diesem Kontext ist ein Dienst ein Programm oder auch eine Softwarekomponente, die lokal oder über ein Netzwerk von anderen genutzt werden kann. Dienstbeschreibung Damit dies möglich ist, muss die Schnittstelle des Dienstes für potenzielle Benutzer öffentlich beschrieben sein. Es muss also eine so genannte Service Description in maschinenlesbarer Form vorliegen (z.b. IDL, WSDL) Kapselung Durch diese Kapselung wird das Prinzip des Information Hiding umgesetzt. Details der Implementierung sind dadurch für den Benutzer eines Dienstes unsichtbar. Plug-In Prinzip Bei sehr einfacher Betrachtung sind Dienste eine Weiterentwicklung der Idee der Plug-ins, die in vielen Quellen beschrieben wird. Plug-ins haben ebenfalls eine eindeutige Schnittstelle und eine für den Anwender nicht sichtbare Implementierung. Sie erweitern die Anwendung um gewisse Funktionalitäten, die bei der Programmentwicklung noch nicht notwendigerweise geplant waren. Allerdings sind Plug-ins deutlich unflexibler.

7 Dienstanbieter Der Dienstanbieter stellt eine Plattform zur Verfügung, welche über ein Netzwerk Zugriff auf mindestens einen Dienst ermöglicht. Damit seine Dienste auch von Nutzern gefunden werden können, registriert der Dienstanbieter seine Dienste bei einem Verzeichnisdienst. Plattform Zuständigkeit für die Aufrechterhaltung des Betriebs der Plattform (Datensicherung, Backup, Wartung sowie Quality of Service (QoS)) und damit die Verfügbarkeit des Dienstes. Sicherheit Aufgaben wie Authentifizierung und Authentisierung. Kapselung Ein Dienstanbieter muss nicht alle angebotenen Dienste selbst entwickeln und implementieren. Er kann durchaus andere Dienste über das Netz nutzen, diese kapseln, einen vereinfachten Zugriff ermöglichen oder mehrere einfache Dienste zu einem neuen, umfangreicheren und dadurch auch mächtigeren Dienst kombinieren.

8 Dienstverzeichnis Das primäre Ziel eines Dienstverzeichnisses (Registry) ist das Finden von benötigten Diensten durch einen potenziellen Nutzer. Aktive Registrierung Jeder Anbieter registriert seine Dienste selber aktiv bei einem solchen Verzeichnis. Suchdienste Dienste, die - wie heutige Suchmaschinen - nach angebotenen Diensten suchen. Kategorien Ein weiterer Dienst könnte die gefundenen Dienste kategorisieren und damit einen entsprechenden Eintrag im Dienstverzeichnis ermöglichen. Eine gute Klassifizierung ist dann erreicht, wenn jeder Dienst genau einer Kategorie eindeutig zugeordnet werden kann. DNS Ansatz Kann eine Suchanfrage nicht beantwortet werden, so wird diese für den Benutzer transparent an ein anderes Verzeichnis (weiter oben in der Hierarchie) weitergeleitet. Die entsprechende Antwort wird in den Cache aufgenommen der anfänglich Befragte agiert also als Proxy und dann an den Anfragenden zurückgeschickt.

9 Dienstnutzer Der Dienstnutzer mit dem Klienten in einer traditionellen Client-Server Architektur verglichen werden. Lose Bindung Allerdings sind die Schritte bis zum Aufruf des Dienstes infolge der losen Bindung und der Auswahl des gewünschten Dienstes zur Laufzeit ohne explizite Kodierung unterschiedlich. Standards Zusätzlich ist es für einen Nutzer, der dem Anbieter des Dienstes ja nicht bekannt sein muss und dem wiederum egal ist, wer einen Dienst anbietet, wichtig, dass Standards vorhanden sind und eingehalten werden. Schnittstellenbeschreibung Der Dienst muss in der Lage sein, seine Schnittstelle dem Nutzer vollständig darzulegen. Protokoll Die Kommunikation zwischen Nutzer und Anbeiter findet über ein Protokoll statt, das beiden bekannt sein muss.

10 Einordnung des Konzepts Nachfolger von RPC? Betrachtet man das Konzept der Service-orientierten Architekturen nur oberflächlich, so gewinnt man schnell den Eindruck, dass hier ein Nachfolger für entfernte Funktionaufrufe (RPC) geschaffen wurde. Höherer Nutzen Die Zukunft liegt aber in einer anderen Nutzung des Konzepts, die einen viel höheren Nutzen stiften wird. Neues Programmierkonzept SOA sind das derzeit letzte Glied in einer Reihe von Programmierkonzepten (s. nächste Folie) Es wird beschrieben, wie die kleinen Teile oder Komponenten interagieren, wer wen aufruft und in welcher Reihenfolge was ablaufen soll. Die eigentliche Leistung ist die Erstellung einer gehobenen Architektur. Sie ermöglicht eine verständliche Beschreibung des ganzen Systems (Kenntnis der Geschäftsabläufe oder Prozesse). Gleichzeitig ist es danach möglich, die Bestandteile an verschiedenen Orten unabhängig voneinander zu erstellen.

11 Entwicklung der Programmierkonzepte Prozedurale Programmierung Kapselung einzelner Funktionalitäten und danach an beliebigen Stellen im Programm durch einen einzeiligen Aufruf zu nutzen. Modulare Programmierung Verteilung eines Programms auf mehrere Dateien. Dies ermöglichte eine erste übersichtliche Strukturierung der Programme und förderte die Erstellung von Bibliotheken. Objekte-orientierte Programmierung Als Nachfolgekonzept enstand Mitte der achtziger Jahre die objekt-orientierte Programmierung. Diese Philosophie erlaubt eine noch bessere Strukturierung und erstmals eine brauchbare Wiederverwendung. Komponenten-basierte Programmierung Mit einer komponenten-basierte Entwicklung und Strukturierung ist es möglich, sehr umfangreiche Architekturen verständlicher zu beschreiben (Application Service Providing) Service-orientierte Programmierung Ermöglicht eine verständliche Beschreibung des ganzen Systems (Kenntnis der Geschäftsabläufe oder Prozesse).

12 Webservices Architektur Webservices sind eine mögliche Implementierung des Konzepts einer serviceorientierten Architektur (SOA) Definition (W3C): A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards.

13 Entwicklung (nach Melzer) Mensch Mensch Austausch von Text, der nicht von einem Computer interpretiert wird WWW: Mensch Computer Ein Mensch entscheidet, was als nächstes gelesen wird, der Computer ist passiv Web Services: Computer Computer Ein Computer liefert das Ergebnis eines Dienstes an einen anderen Computer Semantic Web: Die Zukunft? Die Computer verstehen, welche Art von Dienst bzw. welchen Dienst sie gerade bearbeiten sollen

14 Beispiel für die Entwicklung (nach Dostal) HTML Herkömmliche Bestellung einer Pizza Calzone bei meiner bevorzugten Pizzeria um die Ecke Java Mein Gefrierschrank kann mit meiner bevorzugten Pizzeria um die Ecke kommunizieren und einige weitere Pizzen Calzone bestellen, vorausgesetzt die Pizzeria arbeitet ebenfalls mit Java. Web Services Mein Gefrierschrank kann mit meiner bevorzugten Pizzeria kommunizieren obwohl diese intern mit.net arbeitet Semantic Web Services Mein Gefrierschrank kann neue Pizzen Calzone bestellen obwohl meine bevorzugte Pizzeria nicht offen hat und die nächste Pizzeria nur gefüllte Pizza in ihrem Angebot hat.

15 Grundlegendes Konzept Das grundlegende Konzept einer service-orientierten Architektur sind die Basiskomponenten Kommunikation Dienstbeschreibung Verzeichnisdienst In einer Web-Services-Architektur werden diese Komponenten zurzeit mit Hilfe der folgenden Spezifikationen realisiert: SOAP beschreibt das XML-basierte Nachrichtenformat der Kommunikation und dessen Einbettung in ein Transportprotokoll WSDL ist eine XML-basierte Beschreibungssprache um Web Services (Dienste) zu beschreiben UDDI unterscheidet sich dahingehend von den anderen Spezifikationen dahingehend, dass zur Beschreibung eines Verzeichnisdienstes im Prinzip keine eigene XML-Anwendung benötigt wird. Allerdings sollte ein Web-Services-Verzeichnisdienst mit WSDL-Dokumenten umgehen können und eine eigene SOAP-Schnittstelle macht sich auch gut.

16 Web-Services-Dreieck Fachhochschule

17 Web-Service Stack Fachhochschule

18 Aspekte und Abhängigkeiten einer Web-Services Architektur

19 Architekturmodell der Nachrichten Fachhochschule

20 Architekturmodell der Dienste Fachhochschule

21 Architekturmodell der Resourcen Fachhochschule

22 Architekturmodell der Richtlinien Fachhochschule

23 Verwandte Lösungen COM/DCOM RMI plattformabhängig (Windows-Systeme) plattformabhängig (Java-Systeme) CORBA Protokoll: IIOP, GIOP Endpunktreferenzierung: IOR, URL Schnittstellenbeschreibung: IDL Naming, Verzeichnis: Naming Service, Interface Repository, Trader Service Nutzlast: binär

24 Mythen Web Services sind einfach Web Services benötigen keine Programmierung Web Services sind nicht sicher Web Services sind per definitionem interoperabel Web Services sind an HTTP gebunden Web Services sind synchrone RPC-Aufrufe Web Services sind Punkt-zu-Punkt-Verbindungen Web Services sind langsam

25 SOAP SOAP ist die Kommunikationskomponente von Web Services SOAP ist nicht an irgendein Betriebssystem oder an eine Programmiersprache gebunden. Die SOAP-Spezifikation legt ausschließlich fest, wie die Nachricht aufgebaut sein muss, damit sie als SOAP- Nachricht gelten kann. Die Umsetzung dieser Nachricht in die entsprechenden Systeme (Betriebssystem, Programmiersprache) der SOAP-Nutzer ist nicht Gegenstand der Spezifikation. Die SOAP-Spezifikation besteht aus 3 Teilen: Primer: Message Framework: Adjuncts: und 2 Ergänzungen: SOAP Message Transmission Optimization Mechanism Resource Representation SOAP Header Block

26 SOAP Version 1.2 Part 0 Primer Diese Einführung besitzt keinen normativen (verbindlichen) Charakter. Sie ist als ein einfach zu verstehendes Tutorial gedacht, um die nachfolgenden normativen Spezifikationen besser nachvollziehen zu können. Mit Hilfe zahlreicher Beispiele sollen hauptsächlich technisch orientierte Personen in die Thematik eingeführt werden.

27 SOAP Version 1.2 Part 1 Messaging Framework Teil 1 der Spezifikation legt normativ den Rahmen einer SOAP-Nachricht fest. Es werden die Elemente einer Nachricht beschrieben. Es wird normiert, ob diese zwingend vorgeschrieben (mandatory) oder freiwillig (optional) sind. Auch die Regelung, wie eine Nachricht mit Hilfe eines Transportprotokolls befördert wird, ist Gegenstand von Teil 1 der Spezifikation.

28 SOAP Version 1.2 Part 2 Adjuncts Im Teil 2 der Spezifikation wird ein Datenmodel für SOAP und ein Kodierungsschema für entfernte Methodenaufrufe (RPC - remote procedure call) definiert. Ferner wird konkret für das HTTP-Protokoll beschrieben, wie die in Teil 1 beschriebene Anbindung (binding) an ein Transportprotokoll erfolgen kann.

29 SOAP Message Transmission Optimization Mechanism Dies ist eine ergänzende Spezifikation, die festlegt wie SOAP-Daten in einer auf XML-binary Optimized Packaging basierenden Form optimiert übertragen werden können.

30 Resource Representation SOAP Header Block Dies ist eine weitere ergänzende Spezifikation, die festlegt wie die Semantik und Serialisierung eines SOAP-Header-Blocks aussieht, um Resourcen in SOAP Nachrichten darstellen zu können. Mit dieser Spezifikation können somit auch Daten die nicht bzw. nur schwer in Form eines XML- Dokuments darstellbar sind, als Anhang an einer SOAP-Nachricht angebunden und verschickt werden.

31 Aufbau einer SOAP Nachricht Eine SOAP-Nachricht ist ein XML-Dokument, welches aus den 3 Teilen Envelope Header Body besteht

32 SOAP Beispiel Reservierung einer Flugreise (s. Primer) 2 Header Blöcke Reservierung Passagierdaten 2 Body Subelemente Reiseroute Übernachtung

33 SOAP Envelope <env:envelope xmlns:env= " <!- SOAP-Header (optional) --> <!- SOAP-Body (mandatory) --> </env:envelope>

34 SOAP Header <env:header> <m:reservation xmlns:m= env:role=" env:mustunderstand="true"> <m:reference> uuid:093a2da1-q r-ba5d-pqff98fe8j7d </m:reference> <m:dateandtime> T13:20: :00 </m:dateandtime> </m:reservation> <n:passenger xmlns:n= env:role=" env:mustunderstand="true"> <n:name>åke Jógvan Øyvind</n:name> </n:passenger> </env:header>

35 SOAP Body <env:body> <p:itinerary xmlns:p=" <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime> late afternoon </p:departuretime> <p:seatpreference>aisle</p:seatpreference> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>mid-morning</p:departuretime> <p:seatpreference/> </p:return> </p:itinerary> <q:lodging xmlns:q=" <q:preference>none</q:preference> </q:lodging> </env:body>

36 Zwischenstationen Eine SOAP-Nachricht kann über mehrere Zwischenstationen laufen. Jede dieser Zwischenstationen ist prinzipiell in der Lage, eines der Header-Elemente zu verarbeiten. Falls eine der Zwischenstationen eine oder mehrere der Header-Elemente bearbeitet hat, dann muss das entsprechende Element aus der Nachricht entfernt bzw. modifiziert werden. Zur genaueren Bestimmung wie ein Header- Element verarbeitet werden muss, können für jedes Kindelement weitere Attribute spezifiziert werden.

37 Attribut role Dieses Attribut spezifiziert den Empfänger bzw. die Zwischenstation, die dieses Header-Element verarbeiten darf. Die Spezifikation definiert drei Standardrollen (none, next, ultimatereceiver), um verschiedene Zwischenstationen zu identifizieren. Der Empfänger ist beispielsweise mit identifiziert. Darüber hinaus ist es möglich, andere Zwischenstationen über einen gültigen URL zu adressieren.

38 Attribute mustunderstand Dieses Attribut kann die Werte true oder false annehmen. Ist der Wert des Attributs true, dann muss eine gemäß dem Attribut role entsprechende Station diesen Header-Eintrag auswerten können. Andernfalls ist die Weiterleitung zu unterbrechen und eine Fehlermeldung zum Absender zu schicken. Ist kein Attribut role angegeben, dann ist der Empfänger verpflichtet, das Element auszuwerten. Wird der Wert false angegeben, so ist es freigestellt, ob das Kindelement ausgewertet wird. Sollte ein Kindelement eines dieser Attribute definieren, das kein direktes Kindelement vom Header-Element ist, dann wird diese Information ignoriert.

39 SOAP Body Der Inhalt des SOAP-Body selber (Nutzlast, payload) muss - mit Ausnahme des Prologs - ein syntaktisch korrekt formuliertes, also wohlgeformtes XML-Dokument-Fragment sein. Je nachdem was verschickt wird, kann eine andere Struktur zugrunde liegen. In der Spezifikation SOAP Version 1.2 Part 1: Messaging Framework ist für den Inhalt des SOAP Bodies nur festgelegt, dass es sich um ein wohlgeformtes XML-Dokument-Fragment handeln muss. Mit SOAP lassen sich also alle Informationen verschicken, die sich als XML-Dokument darstellen lassen. Beispiele dafür sind HTML-Seiten, pdf-dokumente, Verträge bzw. Bestellformulare. Diese Form der SOAP-Kommunikation, bei der ein Dokument (HTML-Seite) ausgetauscht wird, wird auch document-style genannt. Die Auswertung, was genau mit der Information des Dokuments zu erfolgen hat, erfolgt später in der Anwendung, die das Dokument erhalten hat. Die Laufzeitumgebung, die das Dokument vom Kommunikationskanal entgegennimmt, interpretiert die Nachricht nicht, sondern reicht sie an die Anwendung weiter.

40 Attachments Problematisch wird das ganze mit binären Daten, die nicht ad-hoc als XML dargestellt werden können. Um derartige Dateien trotzdem mit SOAP versenden zu können, gibt es die Ergänzungen SOAP Message Transmission Optimization Mechanism und Resource Representation SOAP Header Block

41 SOAP Fehler Die erste Festlegung bestimmt, dass im Fehlerfalle ein SOAP-Fault Block als einziges Kindelement des SOAP-Body übertragen werden darf. Der Namespace des Fault-Blocks muss mit dem URI definiert werden. Für jedes Element existieren Festlegungen, wie es zu strukturieren ist und wie der Wert der Information zu übertragen ist. Für die zwei Pflichtelemente Code und Reason wird hier die Struktur nachfolgend detaillierter beschrieben. Die optionalen Elemente können bei Bedarf im Teil 1 der Spezifikation nachgelesen werden.

42 SOAP Fault Element Code Das Element Code besteht aus den zwei Kindelementen Value enthält den Fehlercode der Fehlermeldung und ist verpflichtend. Die möglichen Fehlercodes sind durch die Spezifikation vorgegeben. In der nachfolgenden Tabelle sind diese aufgelistet. Subcode ist ein optionales Kindelement im Element Code. Damit ist es möglich den Fehlerkode aus dem Element Value genauer zu spezifizieren. Wichtig ist festzuhalten, dass das Element Subcode rekursiv aufgebaut ist.

43 SOAP Fault Element Reason Als zweites verpflichtendes Element in einem Fault-Block ist das Element Reason vorgeschrieben. Dieses Element ist im Unterschied zum Code-Element nicht primär für die Auswertung durch eine Anwendung gedacht. Das Reason-Element enthält ein oder mehrere Kindelemente Text, in denen sich eine für Menschen gut lesbare Beschreibung des Fehlers befindet. Jedes Kindelement Text sollte (muss aber nicht) die gleiche Fehlerbeschreibung in einer anderen Sprache enthalten. Deshalb muss für jedes Text-Element ein eindeutiges Attribut xml:lang definiert werden

44 Elemente des SOAP Fault Blocks Elementname verpflichtend Beschreibung Code Ja Eine von der SOAP- Spezifikation festgelegte Kodifizierung Reason Ja Textuelle Beschreibung des aufgetretenen Fehlers Node Nein Beschreibt, an welcher Stelle der SOAP-Kommunikation der Fehler aufgetreten ist Role Nein Beschreibt die Rolle des Node, bei dem der Fehler aufgetreten ist Detail Nein Enthält weitere Informationen zum aufgetretenen Fehler

45 SOAP Fault Code SOAP Fault Code Beschreibung VersionMismatch MustUnderstand DataEncodingUnknown Sender Receiver Der Knoten in der SOAP- Kommunikation erwartet eine andere SOAP-Version Ein Knoten kann ein Pflichtelement eines SOAP-Header Eintrags nicht auswerten Es sind Datentypen aufgetreten, die nicht in eine SOAP-Nachricht übersetzt werden können Die SOAP-Nachricht konnte vom Sender nicht verarbeitet werden Die SOAP-Nachricht konnte vom Empfänger nicht bearbeitet werden

46 Remote Procedure Call mit SOAP 1. Anfrage (Request) Der Requestor ruft eine Methode des Providers auf und übergibt dazu die geforderten Parameter in der richtigen Reihenfolge. 2. Antwort (Response) Die Anfrage des Requestors konnte vom Provider fehlerfrei bearbeitet werden und das Ergebnis wird nun vom Provider an den Requestor übergeben. 3. Fehlerfall (Fault) An irgendeiner Stelle der SOAP-Übermittelung ist ein Fehler aufgetreten, der an den Requestor weitergereicht wird, damit dieser entsprechende Maßnahmen einleiten kann.

47 SOAP Request <?xml version= 1.0?> <env:envelope xmlns:env= > <env:body> <m:bestellen env:encodingstyle= xmlns:m= > <m:nr> </m:nr> </m:bestellen> </env:body> </env:envelope>

48 SOAP Response <?xml version= 1.0?> <env:envelope xmlns:env= > <env:body> <m:bestellenresponse env:encodingstyle= xmlns:m= > <m:result> </m:result> </m:bestellenresponse> </env:body> </env:envelope>

49 SOAP Request mit Datentyp <?xml version= 1.0?> <env:envelope xmlns:env= > <env:body> <m:bestellen env:encodingstyle= xmlns:m= xmlns:xsi= xmlns:xsd= > <m:nr xsi:type= xsd:string > </m:nr> </m:bestellen> </env:body> </env:envelope>