verteilte anwendungen teil 13: xml-rpc und...

20.06.18 1VA – SS 2018 - Teil 13/Web-Services I

Verteilte Anwendungen

Teil 13: XML-RPC und SOAP

2VA – SS 2018 - Teil 13/Web-Services I

Literatur

[13-1] Stierand, Björn: Schonende Entwicklung: Erweiterungen des XML-RPC-Protokolls. Linux Enterprise 1/2, 2004, S.75-76

[13-2] St.Laurent, Simon; Johnston, Joe; Dumbill, Edd: XML-RPC. O'Reilly, 2001

[13-3] Badach, Anatol; Rieger, Sebastian; Schmauch, Matthias: Web-Technologien. Hanser 2003

[13-4] Eberhart, Andreas; Fischer, Stefan: Web Services. Hanser 2003

[13-5] Iverson, Will: Real World Web Services. O'Reilly, 2004

[13-6] http://www.xml-rpc.dehttp://www.xmlrpc.com


XML-RPC

• RPC über XML und HTTP

• Spezifikation in http://xmlrpc.scripting.com/

• Entwickelt ab 1992, erste Version April 1998

• Letzte Version der Spezifikation von 1999

• Unterstützt von vielen Programmiersprachen, u.a. auch von PHPSiehe dazu http://directory.xmlrpc.com/implementations/

• http://php.net/manual/de/book.xmlrpc.php

• http://gggeek.github.io/phpxmlrpc/

• http://tldp.org/HOWTO/XML-RPC-HOWTO/index.html


Beispiel I - Aufruf

<?xml version="1.0"?><methodCall> <methodName>mul</methodName> <params> <param> <value><int>2</int></value> </param> <param> <value><int>6</int></value> </param> </params></methodCall>

Entspricht dem Aufruf: mul(2,6)


Beispiel II - Antwort

<?xml version="1.0"?><methodResponse> <params> <param> <value><int>12</int></value> </param> </params></methodResponse>

Aufruf und Antwort werden vollständig in XML kodiert.


Datentypen (Einfach)

Datentyp Erläuterung

<i4><int>

4 Byte Integer (32 bit)

<boolean> Wahr (1) oder Falsch (0)

<string> ASCII String

<double> Fließkommazahl (64 bit)in amerikanischer Notation (Punkt)

<dateTime.iso8601> Datum / Zeit im ISO8601-Format

<base64> Binäre Daten im base64-Format(RFC 2045)


Arrays I

<value> <array> <data> <value><int>55</int></value> <value><double>3.14159</double></value> ... </data> </array></value>

• Felder sind Reihungen auch unterschiedlicher Datentypen.

• Jedes Array steht innerhalb eines value-Elements.

• Direkt lassen sich nur 1-dimensionale Felder definieren -Mehrdimensionale durch entsprechende Schachtelung.

• Nicht alle Dimensionen müssen gleich groß/lang sein.


Arrays II - Mehrdimensionale Felder

<value> <array> <data> <value><int>55</int></value> <value><double>3.14159</double></value> ... <value> <array> <data> <value><string>Hallo</string></value> <value><string>World</string></value> </data> </array> </value> </data> </array></value>


Strukturen I

<value> <struct> <member> <name>Vorname</name> <value><string>Ollibert</string></value> </member> <member> <name>Nachname</name> <value><string>van der Lucken</string></value> </member> <member> <name>Alter</name> <value><int>18</int></value> </member> ... </struct><value>


Strukturen II

• Sehr ähnlich zu Feldern aufgebaut.

• Jedes Element hat einen eigenen Namen, der explizit angegeben wird, d.h. keine implizite Zuordnung durch die Reihenfolge.

• Die Namen sollten den Namenskonventionen der Programmiersprachen entsprechen, da aus diesen auf die Elemente zugegriffen wird, also keine Umlaute etc.

• Strukturen und Felder können beliebig gemischt werden.

• Für die Freunde der Objekt-Orientierung:– Structs werden meist wie Objekte behandelt,

– Member-Elemente wie Eigenschaften/Attribute.


<methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>Fehlercode</int></value> </member> <member> <name>faultString</name> <value><string>Meldung</string></value> </member> </struct> </value> </fault></methodResponse>

Fehlerbehandlung

• Bei einem Fehler wird eine Struktur mit dem Fehlercode und einem Erläuterungstext zurückgeliefert.


Zukunft von XML-RPC

• Keine wesentlichen Änderungen seit 1999

• Relativ umfangreiche (und geschwätzige) Spezifikation der Parameter und Resultate

• Die meisten Implementierungen unterstützen aber SOAP.

Aber:

• Einfach und schlicht


SOAP I

• Beginn der Entwicklung 1998 durch Microsoft

• Mai 2000: SOAP 1.1Dezember 2002: SOAP 1.2

• Ursprünglich: SOAP – Simple Object Access ProtocolAber ab 1.2 einfach nur SOAP, nicht als Akronym

• Version 1.2 ist W3C Standard

• Teil des Web Service Konzepts

• Nicht Objektorientiert


SOAP II - Eigenschaften

• Unterstützt durch große Softwarehersteller

• Einfachere Kombination verschiedener Dienste

• Programmiersprachen-Unabhängigkeit

• XML-kompatibel

• Datentypen lassen sich gut ausdrücken

• Kosten für derartige Middleware sind hoch

• Herstellerabhängigkeiten, besonders von Microsoft

• Ineffizient: große Datenmengen

• Kompliziert, besonders WSDL

Vorteile

Nachteile


SOAP III - Versionen

• Verbreitete Version: 1.1– http://www.w3.org/TR/SOAP

– war nie IETF-Norm, nur eine Note

• Aktuelle Version 1.2 (Juni 2003)– http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

– http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

– http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

– Eine echte IETF-Norm

Leider sind die beiden Versionen nicht kompatibel....


Synchron/Asynchron

• Wie bei RPCs sind zwei gekoppelte Nachrichten möglich(Request - Response oder Send - Reply)

Diese Kommunikationsform wird synchron genannt, da der Sender unmittelbar nach dem Senden auf die Antwort wartet, ohne weiter zu arbeiten.

• Wie bei einem Message Queueing-System werden einfache Nachrichten benutzt.

Diese Kommunikationsform wird asynchron genannt, weil keine zeitliche Kopplung für die Antwort vorhanden ist.


Binding - Zusammenspiel mit unteren Protokollen

• In der Praxis wird SOAP in Verbindung mit HTTP 1.1 benutzt.

• Die HTTP-Codes werden entsprechend auf der SOAP-Ebene interpretiert.

• Wie HTTP ist SOAP zustandslos, es gibt keine Sessions.

• Diese müssen zusätzlich realisiert werden.


Kommunikationsvorgang

Wer welche Funktionen hat, wird durch die Rolle festgelegt.


Aufbau der Nachrichten

• Die Teilkomponenten werden durch Schachtelung realisiert.

• Der Kopf ist optional.


SOAP - Request I

<?xml version="1.0"?><soap:Envelope xmlns:soap=URI xmlns:xsi=URI xmlns:xsd=URI>

<soap:Header></soap:Header><soap:Body>

<m:GetPrice xmlns:m=ServiceURI><m:tickerSymbol>BAS</m:tickerSymbol>

</m:GetPrice ></soap:Body>

</soap:Envelope>


SOAP - Request II - URI für SOAP 1.1

xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance/"xmlns:xsd ="http://www.w3.org/2001/XMLSchema/"xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:enc ="http://schemas.xmlsoap.org/soap/encoding/"

• Die Angabe von xmlns:soap... ist Pflicht, alle anderen Angaben sind optional.

• Der Namensraum für den Body muss auch angegeben werden - im Beispiel oben xmlns:Prefix=ServiceURI, wobei ServiceURI der Identifier für die eigene Anwendung ist.

• xmlns:xsi muss dann vorhanden sein, wenn xmlns:xsd benutzt wird, d.h. wenn auf die Datentypen vom XML Schema zurück gegriffen wird, ist auch die Instance-Version notwendig.

• xmlns:enc wird zur Serialisierung bzw. Kodierung benötigt.


SOAP - Request III - URI für SOAP 1.2

xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance/"xmlns:xsd ="http://www.w3.org/2001/XMLSchema/"xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"xmlns:enc ="http://www.w3.org/2003/05/soap-encoding/xmlns:rpc ="http://www.w3.org/2003/05/soap-rpc/"

Da diese Version von W3C unterstützt wird, gibt es auch einenNamensraum vom W3C.

Der letzte Namensraum wird für das Resultat in der Antwort nacheinem RPC-Request benötigt. Dieser Raum wird im <body>gebraucht.


SOAP - Request IV

POST /Sample HTTP/1.1Host: www.seifenkiste.deContent-Type: text/xml; charset="utf-8"Content-Length: 245SOAPAction: "GetPrice"


<soap:Header></soap:Header><soap:Body>

<m:GetPrice xmlns:m=ServiceURI><m:tickerSymbol>BAS</m:tickerSymbol>

</m:GetPrice ></soap:Body>

</soap:Envelope>


Bemerkungen

• Wird die POST-Methode benutzt, so wird auf dem Hinweg und Rückweg SOAP verwendet.

• Wird auf dem Hinweg die GET-Methode benutzt, so wird dabei kein SOAP angewendet, sondern nur auf dem Rückweg. Dann muss auch im Header "Accept: application/soap+xml" angegeben sein.

• Der Header SOAPAction benennt die Funktion, die auch durch eine URL ausgedrückt werden kann, z.B.

http://ws.server.de/ws#getDate

wobei ws der Service und getDate die Funktion ist.


SOAP - Antwort

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: 178


<soap:Body><m:GetPrice xmlns:m=ServiceURI>

<m:Price>17.5</m:Price></m:GetPrice>

</soap:Body></soap:Envelope>

HTTP-Statuscodes


Bemerkungen

• Dies ist ein Beispiel einer Abfrage an einen Börsendienst, welchen Wert die BASF-Aktie (Kürzel BAS) hat.

• Das Beispiel beruht auf der Annahme, dass HTTP das Transport-Protokoll ist. Alternativ können beide Nachrichten per EMail transportiert werden.


MIME-Benutzung I

• Eine SOAP-Nachricht kann auch ähnlich zu Email auch mit MIME segmentiert werden.

• Jedes Segment (Attachment) muss im Header eine Content-ID definieren, z.B. Content-ID: Alpha.

• In der eigentlichen SOAP-Nachricht werden Anhänge per HREF über die Content-ID adressiert.Wenn cid (Content ID) der Namensraum-Identifier ist, so kann ein Attachment mit href="cid:Alpha" referenziert werden.

• Hinweis:Die Namensräume können auch für Attributwerte verwendet werden.

• In der SOAP-Nachricht selbst muss dies mit Content-Type: Multipart/Related angezeigt werden.

• Dies gilt natürlich für Requests und Responses.


MIME-Benutzung II

POST URL HTTP/1.1Host: ...Content-Type: Multipart/RelatedContent-Length: ...SOAPAction: "...."...<soap:Envelope xmlns:soap=URI>

.... <... href="cid:a"...> ....

.... <... href="cid:b"...> ....</soap:Envelope>...Content-ID:a......Content-ID:b...

HTTP-Header

SOAP-Nachricht

Attachment a

Attachment b


SOAP Header I

<soap:Envelope xmlns:soap=URI xmlns:xsi=URI xmlns:xsd=URI> <soap:Header> <Name:User xmlns:Name=URI soap:mustUnderstand="1">

Ollibert van der Quanten </Name:User> </soap:Header> ....</soap:Envelope>

• Die Elemente im Header heißen Header-Blocks (SOAP 1.2).

• Jeder Header-Block muss einen eigenen Namensraum benutzen.

• Es können in einem Header-Block noch weitere Attribute verwendet werden.


SOAP Header II - Attribute

Attribut Version Erläuterung

mustUnderstand beide Header-Block muss vom Adressaten verar-beitet werden (können), falls Wert true/1 ist

encodingStyle beide Legt Kodierung fest

actor 1.1 legt den Adressaten des Header-Blocks fest

relay 1.2 Falls true/1, soll der Zwischenknoten den Block weiterleiten

role 1.2 legt die Rolle für den Header-Block fest


Actor und Nodes (SOAP 1.1)

<soap:Envelope xmlns:soap=URI xmlns:xsi=URI xmlns:xsd=URI> <soap:Header> <Auth:Check xmlns:Auth=URI, soap:actor=URI> <Auth:User>Ollibert van der Quanten</Auth:User> <Auth:PW>Geheim42!</Auth:PW> </Auth:Check> </soap:Header></soap:Envelope>

• Der Header-Block wird nur von dem durch die URI spezifizierten Relay/Intermediär verarbeitet.

• Bei dieser Verarbeitung kann der Block entfernt oder ersetzt werden.

• Falls ein unbekannter Relay/Intermediär adressiert werden soll, wird als URI "http://www.w3.org/2001/05/SOAP-envelope/actor/next" benutzt. Dies bedeutet, dass der nächste gemeint ist, egal, welche das ist.


Rollen in SOAP 1.2

• Das Attribute role="..." gibt die Rolle am Header-Block an.

Rolle1: "http://www.w3.org/2003/05/role/none"Rolle2: "http://www.w3.org/2003/05/role/next"Rolle3: "http://www.w3.org/2003/05/role/ultimateReceiver"


Serialisierung I

• Zusätzlich kann beim Envelope-Element noch das Attribut encodingStyle verwendet werden.Dieses regelt die Art und Weise wie die Daten nach XML und umgekehrt umgewandelt werden.

• Dazu gibt es ein eigenes Schema für SOAP 1.1:xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"

Und für SOAP 1.2:xmlns:enc="http://www.w3.org/2003/05/soap-encoding/"

• encodingStyle kann im Header oder im Body benutzt werden.


Serialisierung II

Name Herkunft Erläuterung

rpc/encoding "Traditionell" Encoding und Kommunikatonsart sind verknüpft

Von W3C standardisiert

document/literal Microsoft Verwendung in .NETMessage-Queuing ohne Encoding(Zugriff auf Datentypen der Schema-Defintion)Nicht von W3C standardisiert

Es kann auch auf ein Encoding verzichtet werdenVon W3C standardisiert

Leider herrscht bei der Art der Kodierung Uneinigkeit:


Datentypen (Auszug) I

Die folgenden Datentypen gelten nur für SOAP 1.2 (W3C-Version):

Typ Erläuterung

string Zeichenkette entsprechend Kodierung

boolean true(1) oder false(0)

int 32 bit-Integer

positiveInteger

nonPositiveInteger

negativeInteger

nonNegativeInteger

Unterbereiche von int

decimal Float ohne Exponent

float 32 bit-Floating Point

double 64 bit-Floating Point

long 64 bit-Integer


Datentypen (Auszug) II

Typ Erläuterung

short 16 bit-Integer

byte 8 bit-Integer

duration Dauer im ISO8601-Format

dateTimetimedate

Datum mit Uhrzeit im ISO8601-FormatUhrzeit im ISO8601-FormatDatum im ISO8601-Format

hexBinary Binärdaten in Hexcode

base64Binary Binärdaten in base64-Format

anyURI URI und Namensräume

language Sprachdefinition nach RFC 1766, z. B. de

name Beliebiger XML-Name

QName Name mit Präfix

NCName XML-Name ohne Doppelpunkt


Array (SOAP 1.1)

... mit xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"für SOAP 1.1 ...

<enc:Array id=Name enc:arrayType="xsd:string[2]"> <Item>String für [0]</Item> <Item>String für [1]</Item></enc:Array>

• Alle Elemente des Feldes haben denselben spezifizierten Typ, hier String.

• Ansonsten ist alles sehr XML-RPC ähnlich.

• Bei SOAP 1.2 gibt es für die Größe ein zusätzliches Attribut arraySize, wobei dann die Längenangabe in [] entfällt.

• id=Name definiert einen lokalen Anker (ID-Attribut) mit dem auf das Feld aus dem Umfeld zugegriffen wird.


Struct (SOAP 1.1)

... mit xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"für SOAP 1.1 ...und xmlns:My="http://....." für die eigene Anwendung:

<My:Struktur id=Name xsi:type="My:Struktur"> <My:Name xsi:type="xsd:string">Ollibert</My:Name> <My:Alter xsi:type="xsd:int">27</My:Alter></My:Struktur>

• Die Darstellung ist zu den Feldern ähnlich, nur dass für jedes Element der Struktur die Typen angegeben werden müssen.

• Weiterhin muss der Namensraum für die Benennung der Struct-Elemente benutzt werden. Das erfolgt über die xsd/xsi-Konstruktion.


Sicherheit

• SOAP kann/sollte sichere Protokolle bzw. Formate nutzen:– HTTP mit SSL (HTTPS)

– IPsec

– Secure MIME (S/MIME) für einige Daten

• Security im <header> vereinbaren

• Nutzung von LDAP und X.509 für Authentifikation


Probleme der Web Services

• Für HTTP muss bei vielen Firewalls der Port offen sein.• Nur wenige Firewalls können die Inhalte der Pakete prüfen.• Zuverlässigkeit der Services• Komplexität der Serviceschnittstellen• Schlechte Performance • Komplexität der Skalierung


Nach dieser Anstrengung etwas Entspannung...

verteilte anwendungen teil 13: xml-rpc und...

Documents