Am Ende des Abschnitts 2.1 (Programmiertechniken) ist bereits darauf hingewiesen worden, dass es neben der direkten Nutzung der Socketschnittstelle auch eine indirekte gibt. Dabei handelt es sich um eine Programmiertechnik, die sich eng an die in den höheren Programmiersprachen üblichen Aufrufe von Unterprogrammen (Prozeduren, Methoden) anlehnt und als Aufrufe ferner Programme bezeichnet wird. Dabei ruft eine Anwendung, die als Client arbeitet, ein Programm auf, das jedoch nicht lokal, sondern von einem Server auf einem anderen Rechner ausgeführt wird. Die Anwendung arbeitet mit dem vom Server zurückgegebenen Ergebnis weiter, genau so, als wäre das Programm lokal ausgeführt worden. Die Kommunikation zwischen dem Client und dem Server erfolgt, für den Programmierer unsichtbar, über die Socketschnittstelle.
So angenehm diese Art der Programmierung für die Anwendungsprogrammierung ist, darf sie nicht darüber hinwegtäuschen, dass ihre Anwendbarkeit auf spezielle Anwendungen beschränkt ist. Üblicherweise stellen Server im Internet ihre Dienste nicht mit Hilfe von Aufrufen ferner Programme zur Verfügung, sondern arbeiten direkt mit der Socketschnittstelle.
Bereits 1976 wurden erste Verschläge für das Aufrufen ferner Prozeduren veröffentlicht. Die Technik wurde als Remote Procedure Calls (RPC) bezeichnet und in den achziger Jahren des letzten Jahrhunderts ursprünglich von der Firma Sun-Microsystems, die inzwischen von der Firma Oracle übernommen worden ist, entwickelt. Bekannt geworden ist die Technik durch ihren Einsatz in dem verteilten Dateisystem Network File System (NFS). Im Abschnitt 3.4 (Verteilte Dateisysteme) wird auf NFS noch etwas näher eingegangen.
Mit der Technik der fernen Prozeduraufrufe wird eine auf einem Client/Server-Modell basierende rechnerübergreifende Inter-Thread-Kommunikation realisiert, die den Aufruf von Prozeduren (Unterprogrammen, Funktionen, Methoden) in anderen Adressräumen erlaubt. Im Lauf der Jahre sind viele Implementierungen dieser Technik entstanden, die nur selten miteinander kompatibel sind.
In dem Client/Server-System der Remote Procedure Calls stellen die Server Prozeduren (Unterprogramme, Methoden) zur Verfügung, deren Ausführung von fernen Clients angefordert werden kann. Bei der Beauftragung eines Servers (durch einen Kommunikationsprozess) gibt der Client an, welches Unterprogramm ausgeführt werden soll und welche Parameter dabei auszuwerten sind. Nach dem Aufruf wartet er auf die Nachricht des Servers mit dem Ergebnis. Erhält ein Server einen Programmausführungsauftrag, dann bearbeitet er ihn und schickt das Ergebnis als Nachricht an den Client zurück. Das heißt, dass Client und Server synchron zusammenarbeiten.
Die RPC-Technik wurde mit dem Ziel entwickelt, Aufrufe ferner Prozeduren transparent durchzuführen zu können. Damit ist gemeint, dass die Anwendungsprogrammierung Aufrufe ferner Prozeduren genauso behandeln können soll, wie Aufrufe lokaler Prozeduren. Das allerdings ist nicht unproblematisch, wie die folgenden Absätze zeigen.
Jede Programmiersprache stellt Möglichkeiten zur Verfügung, mit dem Aufruf einer Prozedur die Übergabe von Daten (Parametern) an die aufgerufene Prozedur zu verbinden. Bei einem Remote Procedure Call werden die Prozedurparameter von einem Client über die Socketschnittstelle zu einem fernen Server geschickt, um dort verarbeitet zu werden.
In den Programmiersprachen gibt es üblicherweise zwei Möglichkeiten, Parameter an eine Prozedur zu übergeben:
Wird ein Remote Procedure Call mit einem Parameter gestartet, der als Wertübergabe angelegt ist, dann wird lediglich ein Wert, z.B. eine Integerzahl, von einer Anwendung zu einer anderen geschickt und dort verarbeitet. Bis auf den Nachrichtenaustausch gibt es keinen Unterschied zu einer lokalen Prozedurausführung.
Bei einer Adressübergabe wird an die aufgerufene Prozedur die Hauptspeicheradresse einer Variablen übergeben. Aber bei einem Remote Procedure Call läuft der Server in der Regel auf einem anderen Rechner als der Client und hat damit einen völlig anderen Adressraum als dieser. Das heißt, dass Adressübergaben bei Remote Procedure Calls nicht so ohne weiteres möglich sind. Dieser Sachverhalt hatte zur Folge, dass in den frühen Versionen der RPC-Software Adressübergaben unzulässig waren.
Werden Hauptspeicheradressen von Variablen nicht absolut, sondern relativ zum Anfang einer bestimmten Datenstruktur verwaltet, dann ergibt sich eine dritte Möglichkeit, um Parameter an Prozeduren zu übergeben. Man spricht von Kopieübergaben bzw. von Calls by Copy/Restore. Dabei wird an Stelle einer bei einem Prozeduraufruf als Parameter angegebenen Variablen die gesamte Datenstruktur, in der sich die Variable befindet, samt ihrer relativen Adresse an die Prozedur übergeben. Ist die Abarbeitung der aufgerufenen Prozedur zu Ende, wird die gesamte Datenstruktur zur aufrufenden Anwendung wieder zurückgegeben und überschreibt das Original. Das ist ein Verfahren, das auch bei Aufrufen ferner Prozeduren korrekt arbeitet. Die Programmiersprache Java beispielsweise geht bei ihrem Verfahren der Remote Method Invocation, das ist die Java-RPC-Implementierung, diesen Weg.
Remote Procedure Calls sind als Internetprotokoll entwickelt worden. Im ISO/OSI-Referenz-Modell gehören sie in die Schicht 5 (Kommunikationssteuerung), im DoD-Modell sind sie Teil der Anwendungsprotokolle. Implementierungsabhängig kann als Transportprotokoll TCP oder UDP benutzt werden. Die ursprüngliche Implementierung verwendete UDP. Der RPC-Protokollkopf enthält Angaben zur Identifikation der auszuführenden Prozedur und Felder für die Aufrufparamter. Eine Vertiefung dieser strukturellen Betrachtungen kann hier aus zeitlichen Gründen nicht erfolgen. Der nächste Abschnitt (2.3.2 Remote Method Invocation) zeigt ein praktisches Programmierbeispiel.
Die Kommunikation zwischen einer Anwendung (einem Client) und einem Server erfolgt bei den Remote Procedure Calls über die Socketschnittstelle. Dieser Sachverhalt wird vom Compiler mit Hilfe von zwei Programmzusätzen vor der Anwendungsprogrammierung verborgen. Bei der Übersetzung eines RPC-Clients entsteht ein zusätzliches Programm, das Stub (Stummel) genannt wird. Bei der Übersetzung des Servers entsteht zusätzlich ein sogenanntes Skeleton (Gerüst). Über diese beiden zusätzlichen Programmteile wird die Socketkommunikation abgewickelt. Das folgende Bild veranschaulicht die Zusammenhänge:
Beide Zusätze sind Stellvertreterprogramme, sogenannte Proxies. Das Stub spielt für den Client die Rolle des Servers, während umgekehrt das Skeleton für den Server die Rolle des Clients übernimmt.
Bereits im Abschnitt 1.1 (Begriff verteiltes System ) ist der Begriff Middleware erwähnt worden. Darunter versteht man eine Technik, bei der die eigenständigen Teile (die Komponenten) eines verteilten Systems softwaretechnisch durch einen Nachrichtenaustausch miteinander verbunden werden. Dadurch kann eine Unabhängigkeit von den eingesetzten Betriebssystemen erreicht werden. Typischerweise baut eine Middleware auf der Technik des Aufrufens ferner Programme auf.
Als Beispiel soll hier lediglich auf die CORBA-Entwicklung hingewiesen werden. Eine eingehendere Darstellung muss aus Zeitgründen einer Vertiefungsveranstaltung überlassen bleiben. CORBA steht für Common Object Request Broker Archticture, was als Allgemeine Architektur für Vermittler von Objekt-Nachrichten übersetzt werden kann. Mit CORBA sollen verteilte Anwendungen in heterogenen Umgebungen auf der Basis des Aufrufens ferner Programme realisiert werden. Ein Firmenkonsortium mit inzwischen mehr als 800 Mitgliedern, die Object Managemnt Group (OMG) entwickelt und pflegt CORBA. Das Konsortium wurde 1989 mit der Vorgabe gegründet, Standards für eine herstellerunabhängige, systemübergreifende objektorientierte Programmierung zu entwickeln.