Verteilte Anwendungen Teil 13: XML-RPC und...
Transcript of Verteilte Anwendungen Teil 13: XML-RPC und...
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
3VA – SS 2018 - Teil 13/Web-Services I
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
4VA – SS 2018 - Teil 13/Web-Services I
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)
5VA – SS 2018 - Teil 13/Web-Services I
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.
6VA – SS 2018 - Teil 13/Web-Services I
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)
7VA – SS 2018 - Teil 13/Web-Services I
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.
8VA – SS 2018 - Teil 13/Web-Services I
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>
9VA – SS 2018 - Teil 13/Web-Services I
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>
10VA – SS 2018 - Teil 13/Web-Services I
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.
11VA – SS 2018 - Teil 13/Web-Services I
<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.
12VA – SS 2018 - Teil 13/Web-Services I
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
13VA – SS 2018 - Teil 13/Web-Services I
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
14VA – SS 2018 - Teil 13/Web-Services I
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
15VA – SS 2018 - Teil 13/Web-Services I
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....
16VA – SS 2018 - Teil 13/Web-Services I
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.
17VA – SS 2018 - Teil 13/Web-Services I
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.
18VA – SS 2018 - Teil 13/Web-Services I
Kommunikationsvorgang
Wer welche Funktionen hat, wird durch die Rolle festgelegt.
19VA – SS 2018 - Teil 13/Web-Services I
Aufbau der Nachrichten
• Die Teilkomponenten werden durch Schachtelung realisiert.
• Der Kopf ist optional.
20VA – SS 2018 - Teil 13/Web-Services I
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>
21VA – SS 2018 - Teil 13/Web-Services I
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.
22VA – SS 2018 - Teil 13/Web-Services I
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.
23VA – SS 2018 - Teil 13/Web-Services I
SOAP - Request IV
POST /Sample HTTP/1.1Host: www.seifenkiste.deContent-Type: text/xml; charset="utf-8"Content-Length: 245SOAPAction: "GetPrice"
<?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>
24VA – SS 2018 - Teil 13/Web-Services I
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.
25VA – SS 2018 - Teil 13/Web-Services I
SOAP - Antwort
HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: 178
<?xml version="1.0"?><soap:Envelope xmlns:soap=URI xmlns:xsi=URI xmlns:xsd=URI>
<soap:Body><m:GetPrice xmlns:m=ServiceURI>
<m:Price>17.5</m:Price></m:GetPrice>
</soap:Body></soap:Envelope>
HTTP-Statuscodes
26VA – SS 2018 - Teil 13/Web-Services I
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.
27VA – SS 2018 - Teil 13/Web-Services I
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.
28VA – SS 2018 - Teil 13/Web-Services I
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
29VA – SS 2018 - Teil 13/Web-Services I
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.
30VA – SS 2018 - Teil 13/Web-Services I
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
31VA – SS 2018 - Teil 13/Web-Services I
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.
32VA – SS 2018 - Teil 13/Web-Services I
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"
33VA – SS 2018 - Teil 13/Web-Services I
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.
34VA – SS 2018 - Teil 13/Web-Services I
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:
35VA – SS 2018 - Teil 13/Web-Services I
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
36VA – SS 2018 - Teil 13/Web-Services I
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
37VA – SS 2018 - Teil 13/Web-Services I
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.
38VA – SS 2018 - Teil 13/Web-Services I
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.
39VA – SS 2018 - Teil 13/Web-Services I
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
40VA – SS 2018 - Teil 13/Web-Services I
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