vs Grundzüge der Fernaufruf-Implementierung = tatsächliche Aufrufbeziehungen Netz Fernaufrufdienst Transportdienst Hardware BS aus Bibl. Vertreter (proxy, client stub) Aufgerufener (Modul, Objekt,...) AufruferTreiber (skeleton, server stub) AdapterAdapter Aufruf x.op(arg)

vs7.12 Vertreter (proxy, client stub) hat gleiche Schnittstelle wie Aufgerufener und betreibt  Serialisierung (marshaling, serialization): Nachricht zusammenstellen, bestehend aus Treiberkennung Prozedur/Operations-Name Argumente  Benutzung des Fernaufrufdienstes zur Übermittlung der Nachricht und Entgegennahme der Ergebnisnachricht  Deserialisierung (unmarshaling, deserialization): Ergebnisse aus Nachricht extrahieren und gegebenenfalls in Ergebnisparametern ablegen bzw. als Ergebniswert abliefern

vs7.13 Treiber (skeleton, server stub) kennt Schnittstelle des Aufgerufenen und betreibt  Deserialisierung: Prozedur/Operationsname und Argumente aus Nachricht extrahieren  Entsprechenden Aufruf tätigen und Ergebnisse entgegennehmen  Serialisierung: Ergebnisnachricht zusammenstellen (Für mehrere Objekte mit gleicher Schnittstelle genügt auch die Bereitstellung eines Treibers.)

vs7.14 Adapter (adaptor) bestimmt das Verhalten des Server-Prozesses und betreibt zyklisch:  Entgegennahme einer Nachricht vom Fernaufrufdienst  Bestimmung und Aufruf des zuständigen Treibers, Entgegennahme der Ergebnisnachricht  Benutzung des Fernaufrufdienstes zur Übermittlung der Ergebnisnachricht (Achtung: Dies ist lediglich eine vereinfachte Darstellung für den Fall, dass im Server-Prozess nie mehr als eine Prozedur aktiv ist!)

vs7.15 Fernaufrufdienst mit Fernaufruf-Protokoll (RPC service/protocol) ist unabhängig vom Aufrufer/Aufgerufenen und den Stubs versendet Nachrichten unter Benutzung des Transportdienstes, z.B. mit TCP, aber auch mit UDP: Antwort des Aufgerufenen fungiert als Bestätigung des Aufrufs! erledigt Fehlerbehandlung (  )

Fernbinden (remote linking/binding) = Initialisierung des Vertreters: Einsetzen des Aufrufziels Station + Port + Treiber : Netzverweis (network reference) Wie wird der Netzverweis erzeugt? entweder:Registrierung eines Objekts bei Namensdienst (wo? s.u.) bewirkt dort Erzeugung – und Zuordnung zu einem Namen oder:Initialisierungscode veranlasst Fernerzeugung (wo? s.u.) und erhält Treiberkennung Wann wird der Netzverweis eingesetzt? Dynamisches Binden: Modul: bei Programmstart oder direkt vor erster Benutzung Objekt: bei Vertretererzeugung, typischerweise bei Übernahme eines Netzverweises als Parameter eines Fernaufrufs

vs Namensdienst (name service, naming service, name server)  wird typischerweise für langlebige öffentliche Module/Objekte, verwendet, die als Anbieter (servers) allgemein interessierender Dienste fungieren – ihre Lebensdauer ist unabhängig von der Lebensdauer der sie benutzenden Klienten (clients);  ist selbst ein solcher Anbieter, der über Fernaufruf angesprochen wird;  sein Stellvertreter wird über eine Standard-Bibliothek eingebunden und findet den benötigten Netzverweis z.B. über einen Rundruf (für vereinbarten Port) im lokalen Netz.

8 interface NameService {// Pseudocode, NOT Java RMI ! // ref :: String -> Object void rebind(String name, Object object); // pre: - // post: ref‘ name == object && // all (\n -> (n/=name) // ‘implies‘ (ref‘ n == ref n)) // String Object lookup(String name) throws Undefined; // pre: defined(ref name) // post: result == ref name void unbind(String name); // pre: - // post: not(defined(ref name) && // all (\n -> (n/=name) // ‘implies‘ (ref‘ n == ref n)) // String) }

vs7.19 Bereitstellung eines fernaufrufbaren Anbieter-Objekts: Programm Server starten, welches Server -Objekt erzeugt und es beim Namensdienst z. B. unter "Server" anmeldet. Der gestartete Prozess fungiert als Träger des Objekts und wartet auf eintreffende Fernaufrufe. Start mit java Server Server &

vs7.110 Benutzung durch Klienten:... // NOT Java RMI ! Server s = (Server)NameServer.lookup("Server"); // creates local proxy for server Result r = s.op(x); // creates local skeleton for x // creates local proxy for result... Anbieter: class Server implements Service {// NOT Java RMI ! public Result op(Argument a) {.....} public static void main(String[] arg) { Server s = new Server(); NameServer.rebind(arg[0], s); // creates local skeleton for s // creates proxy for s at name server for(;;); }

vs Fernerzeugung von Objekten (remote creation) typischerweise bei privaten Objekten verteilter Programme mit Hilfe entfernter Fabrik-Objekte (object factories) - 3 Alternativen:  über im Programm zuvor fernerzeugte Objekte,  über bereits vor Programmstart existierende, über Namensdienst erreichbare Fabrikobjekte, über allgegenwärtige, generische Fabrikobjekte (object servers, analog zu process servers).

vs7.112  Atype x = remote.create(); // creates Atype object // co-located with remote  Afact af = (Afact)NameServer.lookup("Atype factory“); Atype x = af.create(); Atype x = new // NOT Java RMI ! // employs invisible Object Server

vs Programmentwicklung bei konsequenter Verteilungsabstraktion 1. Auf jeder Station den jeweils benötigten Anwendungscode bereitstellen. 2. Auf jeder Station mittels Vertretergenerator (stub generator) den Code für jeweils benötigte Vertreter und Treiber bereitstellen. Vertretercode trägt denselben Namen wie der Originalcode ! 3. Auf jeder Station alles übersetzen und gegebenenfalls (lokal) statisch binden. (Komplikationen, falls irgendwo Objekte der gleichen Klasse sowohl lokal als auch entfernt benutzt werden.)

vs Semantik von Fernaufrufen sollte eigentlich kein Thema sein – Verteilungsabstraktion! Aber subtile (und weniger subtile) Abweichungen von der Semantik lokaler Aufrufe sind oft nur schwer vermeidlich  wegen Spracheigenschaften, die sich einer effizienten verteilten Implementierung widersetzen,  wegen unzuverlässiger Hardware-Komponenten im Netz. Konsequenzen: warnen vor Ineffizienz (Zeitfaktor  10000) nicht alles erlauben semantische Abweichungen in Kauf nehmen Modifikationen am Quellcode in Kauf nehmen

vs7.115  Sprachbedingte Probleme (Auswahl) Identitätsprüfung: Wenn zwei Vertreter x und y sich auf das gleiche entfernte Objekt beziehen, sollte x==y sein! (referential transparency) Variablenparameter: Formaler Parameter ist Alias für aktuellen Parameter. „Fernzugriff“ auf aktuellen Parameter unterstützen? Teuer! Spezieller Übersetzer!  Häufig als Wert/Ergebnisparameter realisiert, d.h. subtil andere Semantik!

vs7.116 Übergabe von Geflechten: häufig als tiefe Kopie (serialisiert in Nachricht gepackt), d.h. mit subtil anderer Semantik. Übergabe von Objektverweisen: müssen „im Fluge“ in Netzverweise umgewandelt werden – oder bei Geflechten: Übergabe von Feldern: Problematisch sowohl als Variablenparameter als auch bei Wertübergabe eines Feldverweises. Daher häufig Wertübergabe des Feldes, d.h. Übergabe einer Kopie (serialisiert in Nachricht gepackt), d.h. mit subtil anderer Semantik.

vs7.117  Netzbedingte Probleme ( Vorübergehende Leitungsstörungen: werden vom Transportsystem oder vom Fernaufrufdienst abgefangen) Unerreichbarkeit der Anbieter-Station oder der Klienten-Station Absturz der Anbieter-Station oder der Klienten-Station Typische Auswirkung z.B.: Fernaufrufdienst wartet nach Aufruf vergeblich auf Antwort (Timeout!)

vs7.118 Fernaufrufdienst hat bestimmte Fehlersemantik (failure semantics) – 3 Alternativen: höchstens-einmal-Semantik (at-most-once semantics): Fernaufrufdienst gibt auf. mindestens-einmal-Semantik (at-least-once semantics): Fernaufrufdienst macht permanent neue Versuche (akzeptabel bei idempotenten Operationen, bei denen eine wiederholte Ausführung den gleichen Effekt wie eine einzelne Ausführung hat). genau-einmal-Semantik (exactly-once semantics): nur dann erreichbar, wenn Anbieter-Station nicht permanent funktionsunfähig.

vs und bei Ausfall einer Klienten-Station muß der Anbieter verwaiste Auftragsergebnisse (orphans) erkennen und abräumen.