2.2.1. XML-RPC

XML-RPC ist ein Standardprotokoll auf der Basis von XML . In GREYHOUND wurde die i8-Erweiterung implementiert (64-Bit Integer). Alle bekannten Programmier- und Scripting-Sprachen bieten mindestens eine Implementation (meist kostenlos) für einen XML-RPC Client, mit dem Daten aus anderen Applikationen (in diesem Fall GREYHOUND) abgerufen werden können. Der Nachteil von XML-RPC ist, dass neben den reinen Nutzdaten die durch XML bestimmten Meta bzw. Beschreibungsdaten relativ viel Platz in der Übertragung einnehmen. GREYHOUND hat deshalb eine eingebaute Optimierung, sodass Werte, welche leer sind, nicht übertragen werden. Wenn zum Beispiel ein String leer ist oder der Wert eines Integers 0 ist, so wird dieser im Ergebnisset nicht übertragen. Dies spart Bandbreite und erhöht somit die Geschwindigkeit der Antwort. XML-RPC wird per HTTP bzw. HTTPS über den GREYHOUND Server abgewickelt. Es funktioniert deshalb in aller Regel auch bei sehr restriktiv eingestellten Unternehmensfirewalls. XML-RPC bedeutet Extensible Markup Language Remote Procedure Call.

XML-RPC Daten sind immer gleich aufgebaut. Die Nutzdaten werden umschlossen vom Namen der entsprechenden (Objekt-)Variable und dem gewünschten Datentyp. Eine Beispielvariable könnte also so lauten:

Quelltext-Beispiel:

Es wird eine Variable mit dem Datentyp "Integer" (32-Bit) übermittelt. Der Wert der Variable ist 34. Der Name der Variable hängt vom Kontext ab (Request, Response, Array oder Struct). Neben dem Datentyp i4 gibt es noch folgende Datentypen: boolean, string, double, dateTime.iso8601, base64, i8. Der Datentyp i8 wurde weiter oben schon angesprochen. Er stellt eine kleine Erweiterung für die Unterstützung von 64-Bit Integer dar. In der offiziellen Spezifikation von XML-RPC gibt es ein paar Beispiele für die verschiedenen Datentypen.

Eine Anfrage per HTTP über XML-RPC für die Methode RpcInfo.GetServerSettings könnte nun wie folgt lauten:

Quelltext-Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13

POST /xmlrpc HTTP/1.0
User-Agent: MyTestClient
Host: 123.234.123.234
Authorization: Basic ZTRkOTA5YzI5MGQwZmIxY2EwNjhmZmFkZGYyMmNiZDAtb2c6bXlHUkVZSE9VTkRwYXNzd29yZA==
Content-Type: text/xml
Content-length: 202

<?xml version="1.0" encoding="ISO-8859-15"?>
<methodCall>
<methodName>RpcInfo.GetServerSettings</methodName>
<params><param><string>My Value of ExampleParam</string></param>
</params>
</methodCall>

Der Wert für das Header Feld Authorization ist das Ergebnis der Base64 Kodierung von Username:Password. Normalerweise unterstützen alle XML-RPC Clients diese Kodierung automatisch. Der Parameter ExampleParam kommt in der Schnittstelle in Wirklichkeit nicht vor, wurde hier jedoch für das Beispiel eingefügt. Wenn eine Funktion keine Parameter erwartet, dann ist der Bereich <params> leer. Die XML-RPC Anfrage wird per POST versendet.

Eine Antwort könnte so aussehen:

Quelltext-Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

HTTP/1.1 200 OK
Connection: close
Content-Length: 795
Content-Type: text/xml
Date: Fri, 09 Oct 2009 08:00:00 GMT
Server: GREYHOUND RPC Server

<?xml version="1.0" encoding="ISO-8859-15"?>
<methodResponse>
<params>
<param>
<value>
<struct>
<member><name>PhoneAddressItemCountryPrefix</name><value><string>+49</string></value></member>
<member><name>ElementsPerPage</name><value><i4>100</i4></value></member>
<member><name>ElementsPerList</name><value><i4>100</i4></value></member>
<member><name>EventsPerPage</name><value><i4>100</i4></value></member>
<member><name>EventsPerDay</name><value><i4>1000</i4></value></member>
<member><name>MaxSearchResults</name><value><i4>10000</i4></value></member>
<member><name>DefaultEditorFontName</name><value><string>Tahoma</string></value></member>
<member><name>DefaultEditorFontSize</name><value><i4>2</i4></value></member>
</struct>
</value>
</param>
</params>
</methodResponse>

Man sieht, dass die Antwort exakt der Struktur aus der Schnittstellenbeschreibung entspricht. Diese Analogie kann man auf sämtliche Teile der Schnittstellenbeschreibung anwenden. Falls bei der Entwicklung Probleme mit den XML-RPC Anfragen bzw. Antworten auftauchen, empfiehlt es sich, die entsprechenden XML-RPC Anfragen und Antworten für Debuggingzwecke zwischenzuspeichern. Viele Fragen lassen sich auf diese Weise klären.

Ein Fehler in XML-RPC würde so aussehen (in diesem Fall ohne HTTP-Header):

Quelltext-Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="ISO-8859-15"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>561</int></value>
</member>
<member>
<name>faultString</name>
<value><string>This is a sample error</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

Themen dieser Ebene
2.2.1. XML-RPC
2.2.2. JSON-RPC