Remote Procedure Call / RPC-Webservices

Im Grunde genommen gibt es Remote-Dienste schon seit einer Ewigkeit. Sie stellen durch die gegebene Möglichkeit, auf entfernten Rechnern arbeiten zu können, genau das dar, was durch die Schaffung des ARPANets Ende der 60er erreicht werden sollte. Terminal-Werkzeuge wie Telnet, rlogin oder auch SSH bilden mit ihren Kommandozeilen also bereits genau die Remote-Funktionalität ab, die auch RPC für sich als technologisches Mittel der Internet-Neuzeit nutzt.

Der Gedanke der RPC Entwicklung stellt aber nicht den Anwender in den Mittelpunkt, der sich durch Telnet oder SSH Remote Protokolle auf andere Server einloggt, sondern richtet zunächst an die Vermittlung und Kommunikation von entfernten autonomen Softwarekomponenten.  Das eigentliche Ziel, das RPC verfolgt, ist die „konsequente Fortsetzung der Modularisierung in der Programmierung“1 und das Zusammenspiel von netzwerkfähigen Plattformen im Sinne einer verteilten Anwendung.

GESCHICHTE UND HINTERGRUND VON REMOTE PROCEDURE CALLS (RPC)

In seinem Ursprung wurden Remote Procedure Calls (RPC, Aufruf einer fernen Prozedur) erstmalig 1976 publiziert. Sie waren Bestandteil des Xerox Network Systems sowie Novells Netware. Als ein in den RFC Standards 1057, 5531 eingetragenes Konzept wurde 1988 das ONC RPC (Open Network Computing RPC) von Sun Microssystems entwickelt, das zunächst für das hauseigene Network File System (NFS) verwendet wird. Aufgrund seiner Beliebtheit und hohen Verbreitung fand die Implementierung letztlich auch ihren Weg in das Linux Betriebssystem. Die Windows Seite verfügt ihrerseits über eine eigene Microsoft RPC Variante, die eine andere Referenzimplementierung nutzt (DCE RPC), sich über die Schaffung des DCOM-Standards weiterentwickelte und heute im .NET Remoting Framework enthalten ist.

In einem großen Ideenrahmen ermöglichen verteilte Anwendungen nicht nur Synergien, auch ungünstig gewachsene Infrastrukturen lassen sich durch sie einfach verbinden – ganz zu schweigen von den Vorteilen, die sich bieten, wenn flexibel auf makroökonomische Schwankungen des Marktes kostengünstig reagiert werden muss.

Bezogen auf die reinen softwaretechnischen Inhalte führt RPC uns direkt zum Thema Middleware mit ihrem typischen Schichtenkonzept. Dabei ist es egal, ob realisiert als Interprozesskommunikation auf Betriebssystemebene im Kernel  oder als Java Interpreter, viele Softwaresysteme profitieren vom Remote Procedure Konzept. Eigentlich aber stehen Middleware Anwendungen vor allem für den folgenden Gedanken: Die Ausprägung in Kombination von Frontend, Backend und Datenbank – auf den Punkt gebracht – WEBSERVICES.

RPC und Webservices stehen insbesondere für freie wie auch kostenpflichtige APIs und eine IT Landschaft, die es erlaubt, auf Basis von bereitgestellten Framworks (Google, Amazon) profitorientierte Internetdienste anzubieten und verteilte Anwendungen zu entwickeln, die globale Webanwendungen ermöglichen.

KOMMUNIKATION ÜBER REMOTE PROCEDURE CALLS (RPC)

Eine Realisierung von Remote Procedure Calls ist an sich die Implementierung eines Client Servers Modells. Als Protokoll sitzt RPC auf der fünften Schicht (Session Layer) des OSI-Modells und ist gekennzeichnet durch den Client, der parametrisierte Übergaben bei Aufruf einer Anwendung auf dem Server initiiert und mit der Ausführung eigener Prozesse bis zum Eintreffen einer Antwort des Servers und den entsprechenden Ergebnissen wartet.

Um eine entfernte bzw. fremde Prozedur aufzurufen, wird dazu auf Client-Seite zunächst eine Nachricht mit einem eindeutigen Identifier der Prozedur versandt und als Anfrage (Call Message) kommuniziert. Auf Seite des Servers übernimmt der Portmapper-Daemon (ONC RPC auf UDP/TCP Port 111) bzw. Endpointmapper (DCE RPC auf UDP/TCP Port 135) die Funktion des zentralen Empfängers, der die Informationen der Client Nachricht ausliest und an die Server Anwendung weiterleitet. Die Server-Anwendung generiert auf Basis der hereingereichten Daten daraufhin ihre Antwort, deren Ergebnisse dann als Reply Message an den Client ergeht. Für das Verständnis wichtig ist die wichtige Eigenschaft von RPC, dass es den Portmappern gestattet ist, die aufgerufenen Prozesse erstmalig neu zu erschaffen bzw. nach Belieben zu aktivieren. Zudem ist der Umstand erwähnenswert, dass mit und durch RPC mehrere Prozesse gleichzeitig verarbeitet werden können.

Das für die Software-Entwicklung kritische Moment in Bezug auf RPC ist vor allem die Fehlerbehandlung und die Anbindung von Variablen an lokale und entfernte Namensräume. Die im Allgemeinen verbindungslose Kommunikation über UDP macht dabei eine etwas aufwendigere Lösung hinsichtlich der Auswertung von Fehlern notwendig, die insbesondere das Vorhandensein von Doubletten ausschließen muss, und es verstehen sollte, hängende oder ausbleibende Server-Antworten zu kompensieren. Neben dem Java RMI Mechanismus stellen insbesondere CORBA und XML-RPC interessante Architekturen bereit, die für die technische Umsetzungen mit RPC uneingeschränkt genutzt werden können.

IT erscheint Ihnen kompliziert?

Wir helfen gerne

Sie müssen nicht verstehen, was eine Programmiersprache ist, um erfolgreich im Web zu sein. Wir helfen gerne bei der Technik. Sie konzentrieren sich auf Ihr Business.

Wir haben die Profis

Das eLancer-Team vereinigt junge Profis aus allen Bereichen der IT und des Online-Marketing. Sie müssen nicht länger suchen, wir vermitteln Ihnen bezahlbare Freelancer, die für Ihr Projekt passen.

Wir geben gratis Tipps

Beschreiben Sie uns doch kurz Ihren Bedarf. Hinterlassen Sie bitte auch Ihre Telefonnummer. Wir rufen Sie zurück, wann immer Sie Zeit haben. Fragen zu Aufwand und Komplexität eines Projektes beantworten wir natürlich kostenlos.