Extensible Markup Language Remote Procedure Call ist mehr als XML-RPC

XMLRPC, SOAP und Rest sind wichtige Werkzeuge zum Content Management meines Framework

Ein wichtiges Werkzeug zum administrative Management in meinem Framework ist der Remote Procedure Call. Das hört sich kompliziert an, ist es aber nicht, denn die Sache an sich ist eine sehr einfache Client/Server-Anwendung und die Übertragung erfolgt per HTTP.

Ein spezieller Abschnitt am Ende des Artikels ist der Fehlerbehandlung gewidmet. Ein Thema, was gerade bei automatisierten Prozessen sehr bedeutungsvoll ist.

Die ausführende Instanz im Content-Management

Charakteristisch für mein Frameework ist die Bindung einer Subklasse an den Request und damit die Erstellung einer Instanz dieser Klasse. Diese Instanz wird ebenfalls bei einem Remote-Procedure-Call gebildet und somit hat der Request den Vollzugriff auf den gesamten Content der über das Framework bereitgestelten Inhalte sowie Webanwendungen. In Fakt werden sämtliche Methoden des RPC über eine Instanz der Subklasse ausgeführt.

Client: Clientseitig kommt selbstverständlich Perl zum Einsatz. Genauer gesagt, verwende ich ein kleines aber feines Perl-Framework für die Kommandozeile (c.pl Beispiel siehe untenstehend).

Server: Auf dem Webserver ist, wie in meinem Framework üblich, die Anwendung an eine dedizierte Klasse gebunden oder es wird per Konfiguration ein Interface zugewiesen.

Speziell für das von mir entwickelte RPC-Verfahren wird der CODE nicht serverseitig vorgehalten, sondern vom Client gesendet und auf dem Server vor der Ausführung kompiliert. Von daher ist RPC ein scharfes Schwert und für spezielle Aufgaben extrem anpassungsfähig, weil Änderungen am CODE lediglich clientseitig gemacht werden müssen.

Ein weiterer und wesentlicher Unterschied zum klassischen XML-RPC besteht darin, dass ich in meiner Anwendung kein XML sende sondern eine binär serialisierte Datenstruktur. Damit ergibt sich der Vorteil, dass die Argumente für die serverseitig aufzurufende Funktion/Methode reine Binärdaten sein können. Infolgedessen ist meine Client/Server-Anwendung für den RPC völlig frei von irgendwelchen Einschränkungen hinsichtlich der zu übertragenden Daten.

So können Sie beispielsweise beliebig viele Multimedia-Dateien (Audio, Video, Grafik, Text) mit einem einzigen Remote-Procedure-Call vom lokalen System zum Server senden, wobei sich der mitgesendete CODE darum kümmert, was mit den Dateien serverseitig gemacht werden soll (Speichern im Dateisystem, Insert in Datenbanken usw).

Haupteinsatzgebiet des Kommandozeilen-Framework

D:\>c.pl RPC
Remote CMD auf dem Host
--attribute, -a: Zeigt Attribut+Value einer Entity in Konfiguration
--base, -b: Name der Datenbank für Option --sql
--cmd, -c: Freies Kommando im aktuellen Verzeichnis
--dump, -d: Dump Response Object
--entity, -e: Zeigt Attribute einer Entity in Konfiguration
--files, -f: Lokale Dateien für Upload
--host, -h: rolfrost.de oder rolfrost
--request, -r: HTTP Request auf den angegebenen URL oder auf alle URLs
--sql, -s: SQL Anweisung, erfordert --base
--urls, -u: Listet URLs in Konfiguration

Beispiel Content-Management;
D:\home\html>c.pl RPC --host rolfrost.de -d /tmp --files xforum.css xjs.js xforum.js red.gif
/tmp/xforum.css
/tmp/xjs.js
/tmp/xforum.js
/tmp/red.gif
4 Dateien Hochgeladen

Beispiel Konfiguration:
D:\>c.pl RPC  --host handwerkzeugs.de --request
200 /
200 /1989.html
200 /ajax_upload.html
200 /ajaxintro.html
200 /ajaxlog.html
200 /am_stammtisch.html
200 /amsel.html
200 /amselbrut.html
200 /arbeitsplatz_kueche
200 /backen
200 /beilage
200 /beobachtung.html
...


D:\>.pl RPC -host handwerkzeugs.de -entity /xmlrpc.html -attribute title
Extensible Markup Language Remote Procedure Call ist mehr als XML-RPC

D:\>.pl RPC -host handwerkzeugs.de -head /xmlrpc.html
$VAR1 = {
          'Server' => 'Apache',
          'statuscode' => '200',
          'statusmesg' => 'OK',
          'Date' => 'Sun, 21 Feb 2016 16:20:33 GMT',
          'Connection' => 'close',
          'Vary' => 'Accept-Encoding',
          'Last-Modified' => 'Sun, 21 Feb 2016 00:00:00 GMT',
          'Content-Length' => '16567',
          'Content-Language' => 'de',
          'x-class' => 'DBResponse',
          'Content-Type' => 'text/html; charset=UTF-8',
          'Set-Cookie' => 'FRAMEWORK=53ef63af1ced70093090d94003a7008a',
          'Expires' => 'Mon, 22 Feb 2016 00:00:00 GMT'
        };

Dadurch dass die Remote-Methoden von einer Instanz des Frameworks aufgerufen werden, lässt sich die Konfiguration der gesamten Domäne recht einfach aber umfangreich prüfen.

Remote Datenbank Management, MySQL

Um den Weg über einen SQL-Client zu sparen, erledigt mein Kommandozeilenframework auch solche Dinge. Über die Option --sql lässt sich auch eine Datei mit umfangreicheren SQL Anweisungen einspielen.

D:\>c.pl RPC --host rolfrost.de --base myweb --sql "select version()"
$VAR1 = [
          {
            'version()' => '5.6.24-log'
          }
        ];

Eine Verteilung von SQL-Anweisungen für mehrere Hosts/Datenbanken oder auch eine Softwareverteilung ist somit recht einfach zu automatisieren.

Fehlerbehandlung und HTTP Status Code

In meinem Framework wird im Fall einer Exception der HTTP Status 502 ausgegeben. Dieser Status ist legitim, weil es sich im weiteren Sinne um einen Gateway-Fehler handelt, siehe dazu auch die Spezifikation CGI/1.1. So kümmert sich mein Framework selbst um den passenden HTTP Status, wenn ein Remote Procedure Call fehlschägt. Selbstverständlich wird im Fehlerfall auch das error_log beschrieben und die Fehlerbeschreibung/Fehlertext ganz normal im HTTP-Response-Body ausgegeben.


Anbieter: nmq​rstx-18­@yahoo.de, die Seite verwendet funktionsbedingt einen Session-Cookie und ist Bestandteil meines nach modernen Aspekten in Perl entwickelten Frameworks.