Anwendungen verteilt auf mehreren Systemen Was ist ein Remote Procedure Call - RPC?

Remote Procedure Call bedeutet auf Deutsch „Aufruf einer fernen Prozedur“ und ist eine Programmierschnittstelle zum Starten von Prozeduren auf entfernten Rechnern. Das RPC setzt auf dem UDP- oder TCP-Protokoll auf und stellt eine häufig verwendete Technik zur Realisierung von Client/Server-Architekturen dar.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Fujitsu Technology Solutions GmbH

Datacenter One GmbH

Protokoll Remote Procedure Call (RPC) zum Aufruf entfernter Prozeduren wurde ursprünglich von Sun Microsystems für das Network File System (NFS) entwickelt. Von dieser Technik existieren im Grunde viele Implementierungen, die untereinander jedoch meist nicht kompatibel sind.

Die ersten Ansätze von RPC wurden bereits 1976 von James E. White im RFC 707 dargestellt. In Xerox Courier, einem Teil des Xerox Network Systems (XNS), sowie in Novells Netware kommt RPC ebenfalls zum Einsatz. Andrew Birrell und Bruce Nelson erhielten dafür als Entwickler im Jahre 1994 den ACM Software System Award.

Dabei die Variante des Sun-RPC, die auch als ONC-RPC (Open Network Computing Remote Procedure Call) bekannt wurde, und die Variante Distributed Computing Environment Remote Procedure Call (DCE-RPC) als insgesamt am weitesten verbreitet gelten. Für den Sun-RPC gibt es auch eine Implementierung in Linux. Von der DCE-RPC 1.1 leitete Microsoft den Microsoft-RPC (MSRPC) ab.

Wie funktioniert RPC?

In der Grundidee ging es darum, dass das Network File System (NFS) über ein Netzwerk Speicherplätze zur Verfügung stellen und gleichzeitig so zuverlässig wie ein stationäres Dateisystem arbeiten sollte. Dafür wurde mithilfe des RPC eine Reihe von Befehlen erstellt, die im Sinne eines Client-Server-Modells diese Speicher-Routinen abarbeiten.

Eine RPC-Kommunikation verläuft nach folgendem Prinzip: Zuerst sendet die Client-Anwendung eine RPC-Nachricht an den Server. Der auf dem Server installierte Portmapper (Endpointmapper) empfängt diese RPC-Anfrage, liest die enthaltenen Daten über die Anwendung aus und leitet sie dann an die jeweilige Server-Anwendung weiter. In der Folge verarbeitet die Server-Anwendung den Auftrag und schickt eine Antwort an den Client zurück.

Wie entstehen Kommunikationsfehler?

Bei Remote Procedure Calls können in der Kommunikation verschiedene Fehler entstehen, die bearbeitet werden müssen. Programmierer müssen eine solche Fehlersemantik bei der Entwicklung einer Anwendung auf jeden Fall beachten. So könnte zum Beispiel eine Server-Antwort auf eine RPC-Nachricht ausbleiben und einen so genannten „hängenden Zustand“ auslösen. Darüber hinaus sollten wiederholt gesendete RPC-Nachrichten beim Server identifiziert werden, um unbeabsichtigte Mehrfach-Ausführungen zu vermeiden.

RPC bietet verschiedene Möglichkeiten, solche Vorfälle zu definieren, um eine zuverlässige Datenintegrität zu gewährleisten. Dafür muss bei der RPC-Verarbeitung zwischen einem synchronem RPC und asynchronem RPC unterschieden werden. Bei einem synchronen RPC erfolgt die Verarbeitung Schritt für Schritt.

Das heißt: Wenn der Client eine Nachricht an den Server schickt, muss erst eine Antwort abgewartet werden, bevor die Prozedur weitergehen darf. Im Falle von asynchronem RPC ist es dem Client nach der Versendung noch möglich, weitere Operationen auszuführen, da auch ein späterer Erhalt der Server-Antwort erlaubt ist.

Wenn mit synchronem RPC kommuniziert wird, muss also für die Anwendung eine höhere Laufzeit für die Server-Antwort einkalkuliert werden. Wird dies unterlassen, so könnte die Anwendung stehen bleiben oder zu einem „hängenden Programm“ werden. Auf der anderen Seite benötigt ein asynchroner RPC meist einen größeren Programmieraufwand. Generell gibt es keine Garantie für ein einwandfreies Funktionieren. Wenn beispielsweise ein Knoten im Netzwerk ausfällt, so wird keine einzige Prozedur der anstehenden Aufgaben ausgeführt.

Weitere Variante: SOAP

SOAP (Simple Object Access Protocol) ist eine Weiterentwicklung der Variante XML-RPC, die im Jahre 1999 vorgestellt wurde. An der ersten Version von SOAP arbeiteten Dave Winer sowie der Branchenriese Microsoft. Dieses Team war auch im Wesentlichen für die Erstellung von XML-RPC zuständig. Im Laufe der Zeit beteiligten sich immer mehr Programmierer und Unternehmen an der Verbesserung von SOAP. Im Jahr 2003 veröffentlichte eine offizielle Arbeitsgruppe die SOAP-Version 1.2.

Da SOAP neben XML über HTTP auch beispielsweise Nachrichten per FTP oder SMTP versenden kann, ist SOAP deutlich vielseitiger. Dank des flexiblen Aufbaus können zahlreiche Abfragen innerhalb einer Transaktion miteinander verbunden werden. Dadurch verringert sich der gesamte Übertragungs- und Verarbeitungsaufwand. Damit ist SOAP in der Entwicklerwelt als eines der wichtigsten Datenaustauschprotokolle nicht mehr wegzudenken.

(ID:45284754)