Verteilte Systeme: Übung 4

Transkript

1 Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik

2 SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist <soap:envelope xmlns:soap= Childelemente sind <soap:header> (optional) <soap:body> (die eigentliche Nutzlast) 2

3 SOAP Header Enthält Metainformationen, z.b. Authentifizierungsdaten Verschlüsselungsparameter Abrechnungsdaten (für kostenpflichtige Services) Daten im Header können von Zwischenknoten (zwischen Absender und finalem Empfänger) gelesen und verändert werden. 3

4 SOAP Body Enthält anwendungsspezifische Daten Requests: Daten, die der addressierte Service benötigt, um die Anfrage zu verarbeiten Beispiel aus Übung 4: XML-Dokument mit MenuRequest-Element Responses: Daten, die das Ergebnis der Anfrage represäntieren Beispiel aus Übung 4: XML-Dokument mit MenuResponse-Element Das genaue Format der Nachrichten wird in der WSDL spezifiziert 4

5 WSDL 1.1 Beschreibung der möglichen Interaktionen mit Webservices in XML Root-Element einer WSDL Datei ist <wsdl:definitions xmlns:wsdl= > Definiert einen eigenen Target-Namespace für die enthaltenen Elemente Besteht aus 2 Teilen Abstrakter Teil Types Messages PortType (heißt in WSDL 2.0 Interface ) Konkreter Teil Binding Service 5

6 WSDL: Types XML Tag: <wsdl:types> Inhalt zwischen öffnendem und schließendem Tag: <wsdl:types> <xsd:schema> (hier Elemente und Typen definieren) </xsd:schema> </wsdl:types> Definition von Types 1. Erstellen eines XML-Schemas innerhalb des <wsdl:types>-elements 2. Inkludieren oder Importieren von externen Schemata mit a. <xsd:include> (wenn das inkludierte Schema den gleichen Target-Namespace hat) b. oder <xsd:import> (sonst) 6

7 7 Definition von Types (Variante 1) Die WSDL-Datei kann das komplette Schema enthalten Aufbau: <wsdl:types> <xsd:schema targetnamespace=" (hier Elemente und Typen definieren, wie in einer XSD-Datei) </xsd:schema> </wsdl:types>

8 8 Definition von Types (Variante 2) Inkludieren von externen Schemata Wenn das zu inkludierende Schema den gleichen Target-Namespace hat, wie das unter <wsdl:types> definierte Schema Aufbau: <wsdl:types> <xsd:schema targetnamespace=" <xsd:include schemalocation="/path/to/included/schema.xsd"> </xsd:schema> </wsdl:types> Hinweis: Das Schema unter /path/to/included/schema.xsd MUSS hier den Target- Namespace haben!

9 9 Definition von Types (Variante 3) Importieren von externen Schemata Wenn das zu importierende Schema einen anderen Target- Namespace hat, als das unter <wsdl:types> definierte Schema Aufbau: <wsdl:types> <xsd:schema targetnamespace=" <xsd:import namespace=" _ schemalocation="/path/to/included/schema.xsd"> </xsd:schema> </wsdl:types> Hinweis: Der Target-Namespace ist nur von Bedeutung, wenn darauf basierend neue Elemente definiert werden!

10 WSDL: Message Jede mögliche Nachricht wird in einem <wsdl:message> Element definiert Die konkrete Bedeutung, d.h. der Kontext, in dem diese Nachrichten verwendet werden, spielt hier noch keine Rolle Nachrichten bestehen aus Teilen <wsdl:part> Parts verweisen z.b. auf in Types definierte XML-Elemente Beispiel (aus Übung 4): <wsdl:message name="menurequestmessage"> <wsdl:part name="menurequestpart" element="mensaxsd:menurequest"/> </wsdl:message> 10

11 11 WSDL: PortType Abstrakte Beschreibung der Schnittstelle (ohne konkrete URIs, über die die Schnittstelle zu erreichen wäre) Ein PortType (<wsdl:porttype>) kann eine oder mehrere Operationen anbieten (<wsdl:operation>) Jede Operation besteht aus maximal einem Input (<wsdl:input>), maximal einem Output (<wsdl:output>) und evtl. Fehlermeldungen (<wsdl:fault >) Input und Output verweisen auf als <wsdl:message> definierte Nachrichten

12 12 WSDL: PortType Beispiel aus Übung 4: <wsdl:porttype name="menuporttype"> <wsdl:operation name="menuoperation"> <wsdl:input name="menurequest" message="mensawsdl:menurequestmessage"/> <wsdl:output name="menuresponse" message="mensawsdl:menuresponsemessage"/> </wsdl:operation> </wsdl:porttype>

13 WSDL: Binding Erstes Element (<wsdl:binding>) des konkreten Teils Wie kommen die Nachrichten vom Sender zum Empfänger? Möglich sind z.b. HTTP, FTP, SMTP, HTTP wird am häufigsten benutzt Wie sind die ankommenden Nachrichten zu interpretieren? Nachrichtenstil (RPC oder Document) Encoding (Encoded oder Literal) 13

14 WSDL: Binding Transportweg der Nachrichten Definition als Attribut transport von <soap:binding> z.b. für HTTP 2 mögliche Nachrichtenstile Definition als Attribute style von <soap:binding> 1. RPC (Remote Procedure Call) Root-Element innerhalb des übertragenen SOAP Body ist der Name der aufzurufenden Funktion Die Kindelemente sind die der Funktion zu übergebenden Parameter (Un-)Marshalling der SOAP-Nachrichten ist Teil des Standards 2. Document SOAP Body kann beliebiges XML enthalten (mit oder ohne Definition über ein Schema) (Un-)Marshalling der SOAP-Nachrichten ist Teil der Applikation Es ist nicht unmittelbar klar, welche interne Methode zur Verarbeitung zu verwenden ist Standard ist Nachrichtenstil Document RPC kann zu Inkonsistenzen bei der Interpretation der Nachrichten führen 14

15 WSDL: Binding Konkretisierung der bereits unter <wsdl:porttype> definierten Operationen Encoding der eingehenden Nachrichten Definition als Attribut use des Elements <soap:body> 2 mögliche Encodings 1. literal : Das XML im SOAP Body der Nachricht folgt einem Schema 2. encoded : Das XML im SOAP Body folgt der Spezifikation im SOAP Standard. Referenziert <wsdl:operation> und ggf. <wsdl:input> bzw. <wsdl:output> aus <wsdl:porttype> 15

16 16 WSDL: Binding (encoded vs. literal) Mit encoded erfolgt das (Un-)Marshalling des XML in den Nachrichten nach SOAP-Standard. SOAP-Standard definiert eigene Simple-Types (Integer, Float, String ) und und erweitert damit die Simple-Types für XML-Schema SOAP-Standard definiert keine komplexen Typen (z.b. Sequence) Beides kann zu Problemen führen (siehe späteres Beispiel )

17 WSDL: Binding (Übung 4) <wsdl:binding name="menubinding" type="mensawsdl:menuporttype"> <!-- Transport: Welches Application-Layer-Protokoll, Style: Default Style für operations!--> <soap:binding transport=" style= document"/> <!--Operationen an PortType binden--> <wsdl:operation name="menuoperation"> <!--soapaction: historische Gründe, style: falls verschieden von style aus soap:binding--> <soap:operation soapaction="/" style="document"/> <! - Die Angabe des Attributs message ist möglich aber unnötig (siehe porttype)--> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> 17

18 18 Beispiel: Distanz zwischen 2D-Punkten class Point { public int x; public int y; public Point(int x, int y) { this.x = x; this.y = y; } } float Distance(Point p1, Point p2) { // apply the Pythagorean Theorem } Quelle:

19 19 Beispiel: Auszug aus WSDL (Types) <wsdl:types> <xsd:schema targetnamespace= " <xsd:complextype name="point"> <xsd:sequence> <xsd:element name="x" type="xsd:int" /> <xsd:element name="y" type="xsd:int" /> </xsd:sequence> </xsd:complextype> </xsd:schema> </wsdl:types> Quelle:

20 20 Beispiel: Message und PortTypes <wsdl:message name="distanceinput"> <wsdl:part name="p1" type="tns:point" /> <wsdl:part name="p2" type="tns:point" /> </wsdl:message> <wsdl:message name="distanceoutput"> <wsdl:part name="result" type="xsd:float" /> </wsdl:message> <wsdl:porttype name="geometry"> <wsdl:operation name="distance"> <wsdl:input message="tns:distanceinput" /> <wsdl:output message="tns:distanceoutput" /> </wsdl:operation> </wsdl:porttype> Quelle:

21 21 Beispiel: Binding <wsdl:binding name="geometrybinding" type="tns:geometry"> <soap:binding style="rpc" transport=" <wsdl:operation name="distance"> <soap:operation soapaction="" style="rpc" /> <wsdl:input message="tns:distanceinput"> <soap:body namespace=" use="encoded" /> </wsdl:input> <wsdl:output message="tns:distanceoutput"> <soap:body namespace=" use="encoded" /> </wsdl:output> </wsdl:operation> </wsdl:porttype> Quelle:

22 22 Anfrage 1 Point one = new Point(10, 20); Point two = new Point(100, 200); float f = server.distance(one, two); SOAP Body entspricht dem Schema: <soap:envelope xmlns:soap=" <soap:body soap:encodingstyle=" <ns:distance xmlns:ns=" <p1> <x>10</x> <y>20</y> valide </p1> <p2> <x>100</x> <y>200</y> </p2> </ns:distance> </soap:body> </soap:envelope> Quelle:

23 23 Anfrage 2 Point one = new Point(10, 20); float f = proxy.distance(one, one); SOAP Body entspricht nicht dem Schema (meint aber das gleiche): <soap:envelope xmlns:soap=" <soap:body soap:encodingstyle=" <ns:distance xmlns:ns=" <p1 href="#id1" /> <p2 href="#id1" /> </ns:distance> <ns:point id="id1" xmlns:ns=" <x>10</x> <y>20</y> </ns:point> </soap:body> </soap:envelope> nicht valide! Quelle:

24 24 Fazit Manchmal sehen nach SOAP-Standard erstellte Nachrichten valide gegen das Schema aus und manchmal nicht Es existiert kein Standard zur allgemein gültigen Übersetzung zwischen Standard-Typen nach SOAP und Standard-Typen der XML- Schemata SOAP encoding sollte in der Praxis vermieden werden, da die Gefahr von Inkonsistenzen bezüglich der Interpretation von Nachrichten (z.b. durch verschiedene SOAP Frameworks bei Clients und Servern) besteht. Statt encoding besser literal verwenden!

25 25 WSDL: Service Definiert, wie die in <wsdl:porttype> beschriebenen abstrakten Schnittstellen konkret zu erreichen sind Element <wsdl:port> referenziert <wsdl:binding> Attribut address des Kindelements <soap:address> von <wsdl:port> definiert die Addresse (z.b. URI), über die der Service erreichbar ist

26 WSDL: Service (Beispiel aus Übung 4) <wsdl:service name="menuservice"> <wsdl:port name="menuport" binding="mensawsdl:menubinding"> <soap:address location=" </wsdl:port> </wsdl:service> 26

27 27 Zusammenhänge zwischen WSDL-Teilen Quelle: