WebServices: Kommunikation

Transkript

1 WebServices: Kommunikation

2 WS Basiskomponenten & Rollen SOAP XML-RPC SOAP XML-RPC

3 WS-Kommunikations Paradigmen Kommunikation nicht an bestimmte Level5-Protokolle gebunden Üblicherweise jedoch: SOAP XML-RPC Kommunikation ebenfalls nicht an bestimmte Transport- Protokolle gebunden! HTTP JMS Partner müssen sich vorher auf Protokolle geeinigt haben

4 Kommunikation: RPC vs. Document-Style Document-Style Aufruf eines Dienstes Ergebnis: Dokument/Datei Vergleichbar mit Browser RPC: Remote Procedure Call Funktionsaufrufe bei entfernten Maschinen/Diensten Liefern in der Regel ein Ergebnis zurück

5 XML-RPC Einfaches Protokoll für entfernte Funktionsaufrufe über HTTP Knappe Spezifikation XML als Payload in HTTP Codierung der Übergabeparameter Request-Response-Prinzip Request via HTTP-POST

6 XML-RPC: Request Beispiel POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: calcservice.example.com Content-Type: text/xml Content-length: 181 <?xml version="1.0"?> <methodcall> <methodname>calculator.add</methodname> <params> <param> <value><int>41</int></value> </param> <param> <value><int>10</int></value> </param> </params> </methodcall>

7 XML-RPC: Request Anforderungen HTTP Header: Content-type = text/xml Content-Length muss angegeben sein HTTP Payload: XML-Dokument Eine einzige <methodcall> Struktur <methodcall> muss <methodname> enthalten <params> <param> <value> <Datentyp> Wert

8 XML-RPC: Datentypen 1 <string>: Defaultdatentyp <i4>, <int>: 4byte signed integer <boolean> <double> <datetime.iso8601>: z.b T14:08:55 <base64>

9 XML-RPC: Datentypen 2 - Arrays <array> <data> <value><i4>12</i4></value> <value><string>egypt</string></value> <value><boolean>0</boolean></value> <value><i4>-31</i4></value> </data> </array>

10 XML-RPC: Datentypen 3 - Structs <struct> <member> <name>lowerbound</name> <value><i4>18</i4></value> </member> <member> <name>upperbound</name> <value><i4>139</i4></value> </member> </struct>

11 XML-RPC: Response Beispiel HTTP/ OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul :55:08 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version="1.0"?> <methodresponse> <params> <param> <value><int>51</int></value> </param> </params> </methodresponse>

12 XML-RPC: Response Format HTTP Header: Wenn keine überliegenden Fehler: Response-Code = 200 OK Content-type: text/xml Payload:

13 XML-RPC: Vor- und Nachteile Vorteile: Geringe Komplexität Einfache Umsetzung von RPCs Nachteile Keine Schnittstellenbeschreibung keine lose Kopplung Keine Namespaces Wenige Datentypen Direkt an HTTP gebunden

14 SOAP Früher: SOAP v1.1 Simple Object Access Protocol Heute: SOAP v1.2 Kein Akronym mehr W3C-Recommondation Unterteilung: SOAP v1.2 Part 0: Primer SOAP v1.2 Part 1: Messaging Framework SOAP v1.2 Part 2: Adjuncts

15 SOAP Bindings Spezifikation darüber, wie SOAP in Protokolle der unterliegenden OSI Layer eingebracht werden kann In SOAP 1.2 Part 2: Lediglich HTTP Binding definiert Weitere Bindings über Eigendefinitionen möglich Es exisitieren im Netz weitere Bindings (z.b. SOAPover-SMTP), die jedoch nicht standardisiert sind!

16 SOAP Aufbau SOAP = SOAP Env. Header Optional Kann Applikationsspezifische Metadaten aufnehmen Sicherheitsinformationen Body Payload

17 SOAP 1.2 XSD

18 SOAP Beispiel Nachricht I (RPC Request) <?xml version="1.0"?> <env:envelope xmlns:env=" <env:header> <t:transaction xmlns:t=" env:encodingstyle=" env:mustunderstand="true">5</t:transaction> </env:header> <env:body> <m:add env:encodingstyle=" xmlns:m=" <m:summand>41</m:summand> <m:summand>10</m:summand> </m:add> </env:body> </env:envelope>

19 SOAP Beispiel Nachricht II (RPC Response) <?xml version="1.0"?> <env:envelope xmlns:env=" <env:header> <t:transaction xmlns:t=" env:encodingstyle=" env:mustunderstand="true">5</t:transaction> </env:header> <env:body> <m:addresponse env:encodingstyle=" xmlns:rpc=" xmlns:m=" <rpc:result>m:sum</rpc:result> <m:sum>51</m:sum> </m:addresponse> </env:body> </env:envelope>

20 SOAP Beispiel Nachricht III (Conversational) <?xml version="1.0"?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m=" env:role=" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</m:reference> <m:dateandtime> t13:35: :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> <env:body> <p:itineraryclarification xmlns:p=" <p:departure> <p:departing> <p:airportchoices>jfk LGA EWR</p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportchoices>jfk LGA EWR</p:airportChoices> </p:arriving> </p:return> </p:itineraryclarification> </env:body> </env:envelope>

21 SOAP Fault Überträgt spezifiziert Fehlermeldungen in einer SOAP Nachricht Definiert als erstes Kindelement innerhalb von env:body Struktur: siehe Schema nächste Folie

22 SOAP Fault

23 SOAP Fault Beispiel <?xml version="1.0"?> <env:envelope xmlns:env=" xmlns:rpc=" <env:body> <env:fault> <env:code> <env:value>env:sender</env:value> <env:subcode> <env:value>rpc:badarguments</env:value> </env:subcode> </env:code> <env:reason> <env:text xml:lang="en-us">processing error</env:text> <env:text xml:lang="de-de">verarbeitungsfehler</env:text> </env:reason> <env:detail> <e:myfaultdetails xmlns:e=" <e:message>invalid Application-ID</e:message> <e:errorcode>999</e:errorcode> </e:myfaultdetails> </env:detail> </env:fault> </env:body> </env:envelope>

24 SOAP Fault Fault Codes VersionMismatch MustUnderstand DataEncodingUnknown Sender Receiver

25 SOAP Processing Modell - Nodes Ursprünglicher Absender (initial SOAP sender) Zwischenstation (SOAP Intermediary) Endgültiger Empfänger (ultimate SOAP Receiver/Recipient)

26 SOAP Processing Modell - Rollen In Headerblöcken als Attribut env:role über URIs definiert none next ultimatereceiver Benutzerdefinierte URIs Schreiben Verarbeitungsweise der Infoblöcke vor Knoten Rolle Fehlt none next ultimate Receiver Zwischenstation Endgültiger Empfänger

27 SOAP Processing Modell Infoblöcke im Header können als MUSS Verarbeitung festgelegt werden Mittels Attribut env:mustunderstand Wenn Attribut=false oder fehlt, optionale Verarbeitung möglich Wenn Verarbeitung nicht möglich SOAP Fault

28 SOAP Fault Beispiel Processing Fehler <?xml version='1.0'?> <env:envelope xmlns:env=" <env:header> <env:notunderstood qname="t:transaction" xmlns:t=" </env:header> <env:body> <env:fault> <env:code> <env:value>env:mustunderstand</env:value> </env:code> <env:reason> <env:text xml:lang="en-us">header not understood</env:text> </env:reason> </env:fault> </env:body> </env:envelope>

29 SOAP Processing Modell Weiterleitung von Header-Blöcken Definiert durch optionales env:relay Attribut im Header-Block Trifft nur zu für SOAP-Intermediäre Trifft nur zu wenn mustunderstand!= true Hintergrund: Standardverhalten von SOAP Intermediären: Entfernung von allen nicht verarbeiteten Header-Blöcken vor Weiterleitung der Nachricht

30 SOAP Weiterleitung Rolle Header Block Name Eingenommen Verstanden & Verarbeitet next Benutzer-definiert ultimatereceiver Ja Ja Ja Nein Ja Nein Nein - Ja Ja Ja - Nein - none Nein - Ja Weiterleitung Nein* Wenn relay= true Nein* Wenn relay= true *: es sei denn, Header-Block durch Verarbeitung neu eingefügt

31 SOAP Weiterleitung - Beispiel <env:envelope xmlns:env=" <env:header> <p:oneblock xmlns:p=" env:role=" env:mustunderstand="true"> </p:oneblock> <q:anotherblock xmlns:q=" env:role=" env:relay="true"> </q:anotherblock> <r:athirdblock xmlns:r=" </r:athirdblock> </env:header> <env:body> </env:body> </env:envelope> Muss-Verarbeitung Optionale Neueinspeisung des Blocks Keine Weiterleitung, wenn nicht verarbeitet Weiterleitung auf jeden Fall, auch wenn keine Verarbeitung stattfindet bzw. der Knoten den Block nicht versteht

32 SOAP Processing Modell SOAP Processing Steps: 1. Rollen-Ermittlung, die ein Knoten einnimmt 2. Identifizierung aller obligatorischen Header-Blöcke, die an den Knoten gerichtet sind 3. Falls Blöcke aus (2) nicht verarbeitbar sind SOAP Fault und keine weitere Verarbeitung 4. Verarbeitung aller obligatorischen und ggf. optionaler Header-Blöcke, die an den Knoten gerichtet sind. Wenn Knoten = ultimatereceiver, dann auch env:body verarbeiten 5. Wenn Knoten = Intermediary, dann Weiterleitung der Nachricht (unter Beachtung von Header-Blöcken)

33 SOAP Adressierung Durch Transportprotokoll geregelt i.d.r. wird ein Service-Endpunkt mittels einer URL benannt SOAP-Dispatcher Schaffung einer WS übergreifenden Adressierungs- Spezifikation WS-Adressing (W3C Submission)

34 SOAP-Adressierungs- und Verarbeitungs- Problematik bei SOAP-Dispatcher SOAP Methoden-Name erst innerhalb des SOAP-Bodys UltimateReceiver muss komplette SOAP-Nachricht parsen, bevor er den eigentlichen Dienst aufrufen kann Bsp: UltimateReceiver = ShopSystem-Service Erreichbar über URL (SOAP Dispatcher) Funktionen: getarticlelist() getarticle() order() Alle Funktionen sind über gleiche URL mittels SOAP Nachrichten anzusprechen, Dispatcher entscheidet anhand des SOAP-Bodys, welche Service-Funktion gewählt werden soll Nachteil: Erhöhte Verarbeitungsdauer; keine eindeutige, funktions- bzw. Ressourcen-orientierte Adressierung möglich Vorteil: Für WS-Konsumenten ist nur ein Endpunkt sichtbar

35 SOAP-Dispatcher SOAP envelope Request (XML doc) HTTP POST URL 1 getarticlelist() Response (XML doc) HTTP Response Request (XML doc) Response (XML doc) order (XML doc) HTTP POST HTTP POST URL 1 HTTP Response URL 1 Web Server SOAP Server getarticle(id) submit(order) Response (XML doc) HTTP Response

36 SOAP-Dispatcher HTTP POST getarticlelist() HTTP POST URL 1 SOAP Server getarticle(id) HTTP POST submit(order)

37 SOAP HTTP Binding Bei Request-Response Message Exchange Pattern: HTTP POST Bei Response Message Exchange Pattern: HTTP GET Bei Faults: HTTP Status Code 500 Internal Server Error mit SOAP Fault als Payload

38 SOAP-HTTP Binding und Adressierung SOAP 1.2 erlaubt Benennung der auszuführenden Methode (SOAP Action) auch außerhalb des SOAP- Payloads Beispiel Client: POST /exampleshop/exampleservice HTTP/1.1 SOAPAction: "getarticlelist" <?xml version='1.0' encoding='utf-8'?> <env:envelope xmlns:env=" <env:body /> </env:envelope>

39 SOAP Vor- und Nachteile Vorteile: Hoher Spezifizierungsgrad & aktuelle Weiterentwicklung Unterstützung Namespaces Spezifizierte APIs Ermöglicht Loose Kopplung Nicht nur RPC durchführbar Keine harte Bindung an HTTP Trennung von Nutzdaten und Metadaten Multi-Hop-fähig Nachteile Relativ komplex (im Vergleich zu XML-RPC)

40 REST REpresentational State Transfer Hervorgegangen aus R. Fieldings Ph.D. Dissertation beschreibt einen Architekturstil von Netzwerksystemen REST ist kein Standard/Spezifikation Empfiehlt jedoch den Einsatz von einigen Standards: HTTP, URL, XML/HTML/GIF/JPEG/etc.

41 REST Client: Zugriff mittels Links auf Ressourcen des Server Antwort des Servers: Representation of the applications state Zugriff/Links: state transitions Zielsystem/Server/Service/Anwendung: state machine State-Transitions eng an HTTP-Methoden gebunden Interaktionen sind zustandslos

42 REST: HTTP Methoden HTTP GET: Abrufen einer Ressource HTTP POST: Erstellung einer neuen Ressource HTTP PUT: Aktualisierung einer Ressource HTTP DELETE: Löschen einer Ressource

43 REST: Ressourcen Ressourcen identifiziert mittels URIs Repräsentation des Ressourcen-Inhalt nicht festgelegt Anwendungsabhängig, i.d.r. jedoch HTML, XML, o.ä. Ressourcen können Verweise auf weitere (Folge-) Ressourcen enthalten

44 REST: Beispiel HTTP GET request URL 1 Response (HTML/XML doc) HTTP response Article List HTTP GET request URL 2 Response (HTML/XML doc) HTTP response Web Server Article Order HTTP POST URL 3 (HTML/XML) URL zur übermittelten Bestellung HTTP response Order

45 REST: Beispiel [Schritt 1: Artikelliste abrufen] Client: GET /shopsystem/articlelist HTTP/1.1 Server-Antwort: HTTP/ OK Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="utf-8"?> <al:articlelist xlmns:al= urn:example.org:shopsystem:alist xlmsn:xlink= > <al:article id= 01 xlink:href= /> <al:article id= 02 xlink:href= /> </al:articlelist>

46 REST: Beispiel [Schritt 2: Artikel abrufen] Client: GET /shopsystem/article/01 HTTP/1.1 Server-Antwort: HTTP/ OK Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="utf-8"?> <a:article a:id= 01 xlmns:a= urn:example.org:shopsystem:article > <a:name> </a:name> <a:details> </a:details> </a:article>