Remote Invocation und Middleware

Remote Invocation ermöglicht es einem Programm, eine Prozedur oder Methode auf einer anderen Maschine aufzurufen, als wäre sie lokal. Middleware ist die Softwareschicht, die dies und verwandte Abstraktionen über ein Netzwerk bereitstellt.

Definition

Remote Invocation ist eine Kommunikationsabstraktion, bei der ein Client eine Operation auf einem entfernten Prozess über eine lokale Prozeduraufruf-Schnittstelle aufruft, wobei die zugrunde liegende Middleware das Marshalling der Argumente, den Transport und die Fehlerberichterstattung übernimmt.

Scope

Dieses Thema behandelt Remote Procedure Call (RPC) und Remote Method Invocation, das Marshalling von Argumenten, Binding und Naming, Aufrufsemantik (at-most-once, at-least-once, exactly-once) sowie die Middleware-Schichten – Objekt-Broker, Message-Oriented Middleware und moderne RPC-Frameworks –, die diese implementieren. Es behandelt auch die bekannten Grenzen der Transparenz: die Wege, auf denen sich Remote-Aufrufe unweigerlich von lokalen unterscheiden.

Core questions

• Wie kann eine Netzwerkinteraktion mit der Bequemlichkeit eines lokalen Prozeduraufrufs dargestellt werden?
• Welche Aufrufsemantiken sind bei Nachrichtenverlusten und Prozessabstürzen erreichbar?
• Wo bricht die Abstraktion der Lokationstransparenz notwendigerweise zusammen?

Key theories

Remote Procedure Call

Die RPC-Abstraktion verpackt eine Remote-Interaktion als einen lokal aussehenden Aufruf, wobei Client- und Server-Stubs Argumente marshallen und unmarshallen; selbst das Erreichen einer At-Most-Once-Semantik erfordert eine sorgfältige Handhabung von Neuübertragungen und Duplikaterkennung.

Middleware-Schichtung

Middleware sitzt zwischen dem Betriebssystem und der Anwendung, um Benennungs-, Marshalling- und Aufrufdienste bereitzustellen, von Objekt-Request-Brokern bis hin zu nachrichtenorientierten und Publish-Subscribe-Systemen.

Grenzen der Verteilungstransparenz

Latenz, Teilausfälle, Parallelität und Speicherzugriff bedeuten, dass Remote-Objekte nicht vollständig von lokalen Objekten zu unterscheiden sind, sodass Designs, die diese Unterschiede ignorieren, unter Last oder Partitionierung tendenziell fehlschlagen.

Clinical relevance

RPC und Middleware sind das Bindegewebe moderner verteilter Software: Microservice-Architekturen, Service Meshes und Cloud-APIs basieren alle auf Remote-Invocation-Frameworks, und ihre Designer müssen explizit über Aufrufsemantik und Teilausfälle nachdenken.

History

Birrells und Nelsons Arbeit von 1984 etablierte RPC als praktische Abstraktion; die 1990er Jahre brachten objektorientierte Middleware wie CORBA und Java RMI, gemildert durch Waldos und Kollegen einflussreiche Warnung vor den Grenzen der Transparenz; moderne Frameworks setzen die Linie mit leichtgewichtigen, schema-gesteuerten RPC über das Web fort.

Debates

Sollten Remote-Aufrufe genau wie lokale aussehen?

Volle Lokationstransparenz vereinfacht die Programmierung, verbirgt aber Latenz und Teilausfälle, was zu anfälligen Systemen führt; die gegenteilige Ansicht, die von Waldo und Kollegen artikuliert wurde, besagt, dass die Verteilung offengelegt werden muss, damit Entwickler Fehler explizit behandeln können.

Key figures

• Andrew Birrell
• Bruce Nelson
• Jim Waldo
• Andrew S. Tanenbaum

Seminal works

• birrell1984
• waldo1994

Frequently asked questions

Was bedeutet At-Most-Once-Aufrufsemantik?

Sie garantiert, dass eine Remote-Operation entweder null oder einmal ausgeführt wird, niemals öfter, selbst wenn die Anfrage erneut gesendet wird. Dies ist das übliche praktische Ziel, da eine Exactly-Once-Ausführung bei Fehlern viel schwieriger zu garantieren ist.