Funktionen per Remote-Zugriff auf entfernten Computern im Netzwerk bzw. auf verteilten Systemen (Verbund unabhängiger Computer) aufzurufen, zählt seit Jahrzehnten zur gängigen Praxis. Der Grundgedanke für die zugrundeliegende Technologie RPC (Remote Procedure Calls) wurde bereits 1976 von James E. White in RFC 707 formuliert, womit das Prinzip beispielsweise älter als das World Wide Web ist.
Damit RPC den Anforderungen heutiger Computersystem-Strukturen gerecht werden kann, entwickelte Google 2015 das Framework gRPC.
Eine der beliebtesten Lösungen, die praktischen RPC-Anfragen für die eigenen Zwecke zu nutzen, ist XML-RPC. Dabei werden die Calls mithilfe des Protokolls HTTP(S) und der Extensible Markup Language (XML) realisiert. Was genau steckt hinter dieser Spezifikation, wo kommt sie zum Einsatz und wie funktioniert sie genau?
XML-RPC (Kurzform für: Extensible Markup Language Remote Procedure Call) ist eine Protokollspezifikation für die Ausführung von RPC-Calls (Remote-Aufrufe in Computer-Netzwerken) unter Zuhilfenahme des zustandslosen Netzwerkprotokolls HTTP und der – in diesem Fall auch namensgebenden – Auszeichnungssprache XML. Während HTTP dabei den Transport der Daten regelt, wird XML für die Darstellung dieser Daten verwendet. Bei der Festlegung des XML-RPC-Standards wurde insbesondere darauf Wert gelegt, dass er ohne großen Aufwand in verschiedene Programmiersprachen und Systemplattformen implementierbar ist.
Die XML-RPC-Spezifikation sieht zwar ausschließlich das ungesicherte HTTP-Protokoll für die Datenübertragung vor – mittlerweile existieren aber weit verbreitete und akzeptierte Variationen des Standards, die das wesentlich sicherere HTTPS unterstützen, das zusätzlich auf eine SSL/TLS-Verschlüsselung zurückgreift.
Entwickelt wurde XML-RPC im Jahr 1998, wobei der hauptverantwortliche Software-Entwickler Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft standen. Der Großkonzern sah nämlich das große Potenzial des neuen Standards für die Ankurbelung der eigenen B2B-Geschäftsbeziehungen. Durch Hinzufügen weiterer, neuerer Funktionen hat sich XML-RPC zudem als Schnittstellen-Protokoll für Webservices etabliert, wobei diese weiterentwickelte Form von XML-RPC in diesem Fall als SOAP (Simple Object Access Protocol) bekannt wurde.
Clients, die auf XML-RPC zurückgreifen möchten, nutzen das Übertragungsprotokoll HTTP, genauer gesagt die HTTP-Request-Methode POST (siehe hierzu auch GET vs. POST). Nach Erhalt der HTTP-Anfrage wertet der Server das XML-Dokument aus, das sich im Body dieser Anfrage befindet. Aus dessen Inhalt generiert er in der Folge den bzw. die Parameter für die gewünschte Funktion und führt diese aus. Das Ergebnis packt der Server erneut in ein XML-Dokument, das nun im Rahmen einer HTTP-Antwort zurück an den Client gesendet wird. XML-RPC unterstützt dabei folgende Datentypen für die Parameter-Übergabe bzw. in der Antwort, die ein Client erhält:
| Datentyp | Tag-Beispiel | Beschreibung |
|---|---|---|
| array | <array><data>…</data></array> | Liste, die mehrere Werte oder Datentypen enthalten kann |
| base64 | <base64>SGFsbG8gV2VsdA==</base64> | Binäre Daten, die nach dem Base64-Verfahren kodiert sind |
| boolean | <boolean>1</boolean> | Boolesche Variable (wahr = 1 vs. falsch = 0) |
| dateTime.iso8601 | <dateTime.iso8601>20200414T16:23:55</dateTime.iso8601> | Datum und Uhrzeit im ISO-8601-Format |
| double | <double>-0.32653</double> | Gleitkommazahl mit doppelter Genauigkeit (64 Bit) |
| integer | <int>32</int> oder <i4>32</i4> | Integer (ganzzahliger Wert) |
| string | <string>Hallo Welt!</string> | Zeichenkette; kann Null-Bytes enthalten |
| struct | <struct><data>…</data></struct> | Verbund von Schlüssel-Wert-Paaren (Schlüssel sind in diesem Fall Zeichenketten, Werte können von beliebigem Typ sein) |
Sollen mehrere Werte oder Datentypen zusammengefasst werden, stehen bei der XML-RPC-Notation also mit „array“ und „struct“ gleich zwei Optionen zur Verfügung. Mit ersterer Option lassen sich die gewünschten Daten in beliebiger Reihenfolge nacheinander auflisten, per „struct“ werden dem Server bereits vorstrukturierte Schlüssel-Wert-Paare übermittelt wie in nachfolgendem Beispiel zu sehen:
<struct>
<member>
<name>Eintrag 1</name>
<value><int>1</int></value>
</member>
<member>
<name>Eintrag 2</name>
<value><int>2</int></value>
</member>
</struct>Einige Sprachen wie Java, die über XML-RPC-Implementationen verfügen, bieten außerdem die Möglichkeit, Nullwerte anzugeben. Hierfür ist im XML-Dokument immer der Datentyp „nil“ zu verwenden, der allerdings kein offizieller Bestandteil der XML-RPC-Spezifikation ist und nicht von allen Servern unterstützt wird.
XML-RPC spielt in der heutigen Netzwerkkommunikation keine große Rolle mehr. Das Austauschformat hat sich nach seiner Veröffentlichung 1998 schnell als zu unflexibel erwiesen, u. a. aufgrund der eingeschränkten Erweiterbarkeit und der Tatsache, dass es keine eigenen XML-Strukturen übertragen kann. Der daraus resultierende hohe Aufwand für die Umwandlung machte eine neue Lösung quasi unverzichtbar, die schnell mit dem bereits erwähnten SOAP (ebenfalls von Winer’s Team in Kooperation mit Microsoft entwickelt) geliefert wurde.
Dennoch gibt es auch heute noch Webanwendungen, die über eine XML-RPC-Schnittstelle verfügen, um beispielsweise den einfachen Datenaustausch mit externen Diensten zu ermöglichen. Das Bundeszentralamt für Steuern stellt beispielsweise eine XML-RPC-Schnittstelle für die automatisierte Überprüfung ausländischer Umsatzsteuer-IDs zur Verfügung (seit 2019 via HTTPS-Abfrage). Auch Content-Management-Systeme wie WordPress besitzen häufig eine XML-RPC-Schnittstelle für den Austausch mit anderen Webservices. Zudem bildet das Austauschformat die Basis für die sogenannte Pingback-Technik, die Bloggern viele Jahre lang als wichtiges Instrument für den Link-Aufbau gedient hat (im Artikel „Pingbacks und Trackbacks Grundlagen“ erfahren Sie mehr zu diesem Thema).
Abschließend soll ein einfaches Beispiel die Client-Server-Kommunikation über eine XML-RPC-Schnittstelle verdeutlichen. Dabei sieht die HTTP-Request des Clients wie folgt aus:
<?xml version="1.0"?>
<methodCall>
<methodName>statustest</methodName>
<params>
<param>
<value><i4>10</i4></value>
</param>
</params>
</methodCall>In dem Container „methodCall“ wird in diesem Fall die Funktion „statustest“ aufgerufen, die ihrerseits in dem Container „methodName“ definiert ist. Als Parameter übergibt die Funktion den ganzzahligen Wert „10“.
Eine mögliche Antwort des Servers auf diesen „statustest“ könnte folgendermaßen aussehen:
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><string>Status: OK</string></value>
</param>
</params>
</methodResponse>Die einfache Antwort des Servers lautet in diesem Beispielfall also „Status: OK“.
Der als Kernel bezeichnete Hauptteil von Betriebssystemen wie Windows oder Linux ist für die effektive Nutzung der zugrundeliegenden Hardware unverzichtbar. Aus Sicherheitsgründen arbeitet dieser Systemkern auf einer übergeordneten Schicht, auf die Anwendungsprogramme standardmäßig keinen Zugriff haben. Erst mithilfe sogenannter System Calls gelangen Prozesse systemfremder Software vorübergehend...
Wrapper umhüllen einzelne Programmkomponenten wie Umschläge. Das Hauptprogramm kommuniziert nur mit dem Wrapper, der auf die Schnittstellen der umhüllten Programmteile zugreift. Dieses Vorgehen ermöglicht Software-Entwicklern bei der Verwendung unterschiedlicher Bibliotheken, Datenbanken oder Programmiersprachen bisher nicht vorhandene Kompatibilität.
