1 vs8 8 Verteilungsabstraktion (distribution/network transparency) [auch „Verteilungstransparenz“ – schlechte Übersetzung]

Präsentation zum Thema: "1 vs8 8 Verteilungsabstraktion (distribution/network transparency) [auch „Verteilungstransparenz“ – schlechte Übersetzung]"—  Präsentation transkript:

1 1 vs8 8 Verteilungsabstraktion (distribution/network transparency) [auch „Verteilungstransparenz“ – schlechte Übersetzung]

2 2 vs8 Verteilte Programmierung ist mühsam und fehleranfällig: Berücksichtigung technischer Spezifika des Transportsystems Umcodierung dieser Informationen bei Heterogenität von Programmiersprachen, Übersetzern, Rechnerarchitektur Packen/Entpacken von Informationen in Nachrichten - statt Auflistung von Parametern Kommunikation zwischen Prozessen – statt Aufrufe zwischen Objekten Verbindungsherstellung zwischen Prozessen

3 3 vs8  Verteilte Anwendungssoftware (distributed applications) sollte auf höherem Abstraktionsniveau entwickelt werden  Unterstützung durch diverse Systemsoftware: verteiltes Betriebssystem mit verteiltem virtuellen Speicher verteilte Plattform (middleware), sprach- und systemunabhängig verteiltes Laufzeitsystem einer verteilt implementierten Sprache

4 4 vs8 Def.:Ein Aufruf ist als Fernaufruf (remote invocation) implementiert, wenn der Aufgerufene von einem anderen Prozess in einem anderen Adressraum – und eventuell anderem Rechner – als dem des Aufrufers ausgeführt wird. prozedural:remote procedure call (RPC) objektorientiert:remote object/method invocation (ROI, RMI) z.B. Aufruf x.op(arg) lokal implementiert mit Sprung/Rücksprung als Fernaufruf implementiert mit Interprozesskommunikation 8.1 Fernaufrufe

5 5 vs8 Aufrufer:... res := server.op(arg);... Aufgerufener: proc R op(A arg)... return f(arg); proc R op2()... return g(); process X... request := pack("op", arg); send request to Y; recv reply from Y; res := unpack(reply);... process Y loop recv request from client; (proc,arg) := unpack(request); switch proc "op" : res := op(arg); "op2" : res := op2(); reply := pack(res); send reply to client; proc R op(A arg)... proc R op2()... implementiert als

6 6 vs8 = tatsächliche Aufruf- und Antwortbeziehungen 8.1.1 Grundzüge der Fernaufruf-Implementierung Aufgerufener (Modul, Objekt,...) Aufrufer Vertreter (proxy, client stub) Bibliothek Fernaufrufdienst BS Transportdienst Netz Hardware Fernaufrufdienst Transportdienst accept Treiber (skeleton, server stub) AdapterAdapter Aufruf res = x.op(arg)

7 7 vs8 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

8 8 vs8 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 (In der Regel genügt ein Treiber für mehrere Objekte mit gleicher Schnittstelle)

9 9 vs8 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!)

10 10 vs8 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 (  8.1.4.2)

11 11 vs8 8.1.2 Fernbinden (remote linking/binding) = Initialisierung des Vertreters: Einsetzen des Aufrufziels Station + Port + Treiber + ObjID : 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 dabei die 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

12 12 vs8 8.1.2.1 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 Vertreter (proxy) wird über eine Standard-Bibliothek eingebunden und findet den benötigten Netzverweis z.B. über einen Rundruf (für vereinbarten Port) im lokalen Netz.

13 13 vs8 interface NameService { // Pseudocode, NOT Java RMI ! // ref :: String -> Object void rebind(String name, Object object); // pre: - // post: ref' name == object && // all (n -> o | (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 -> o | (n!=name) // ‘implies‘ (ref' n == ref n)) // String }

14 14 vs8 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 &

15 15 vs8 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(;;); }

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

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

18 18 vs8 Ablauf der Fernerzeugung: 1. Aufruf übermittelt Information für Konstruktor-Aufruf: Klassenname + Parameter 2. Klassenlader lädt Implementierungs-Klasse und Treiber-Klasse, lokal oder übers Netz (falls plattformunabhängiger Code) 3. Objekterzeugung für Implementierung und Treiber, Treiber wird unter ObjID in Tabelle vermerkt 4. ObjID wird an Klienten zurückgeliefert, vervollständigt Netzverweis Anmerkung: Objekt wird oft erst erzeugt, wenn der Klient den ersten Aufruf durchführt (on demand).

19 19 vs8 8.1.3 Programmentwicklung 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.)

20 20 vs8 8.1.4 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: Zeitfaktor ( ≈ 10000) berücksichtigen nicht alle Sprachmittel erlauben semantische Abweichungen in Kauf nehmen Modifikationen am Quellcode in Kauf nehmen

21 21 vs8  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!

22 22 vs8 3 5 x y Übergabe zweier Variablenparameter i,k an die Funktion void inc2(var int x, var int y) { x := x + 1; y := y + 1 } zentralisiert verteilt 3 i 5 k 4 6 x y i k 3 x 5 y x y 4 6 4 6 3 x y 3 i,k 4 x y 3 x 3 y x y 4 4! 4 4 5

23 23 vs8 Ü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.

24 24 vs8  Netzbedingte Probleme ( Vorübergehende Leitungsstörungen: werden vom Transportsystem oder vom Fernaufrufdienst abgefangen) Unerreichbarkeit der Anbieter-Station oder der Klienten-Station, aber beide arbeiten separat weiter Absturz der Anbieter-Station oder der Klienten-Station Typische Auswirkung z.B.: Fernaufrufdienst wartet nach Aufruf vergeblich auf Antwort (Timeout!)

25 25 vs8 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 (nur akzeptabel bei idempotenten Operationen, bei denen wiederholte Ausführung den gleichen Effekt wie eine einzelne Ausführung hat). genau-einmal-Semantik (exactly-once semantics): Fernaufrufdienst führt Historie getätigter und bestätigter Operationen (aufwendig; nur möglich, wenn Anbieter-Station nicht permanent funktionsunfähig ist).

26 26 vs8... und bei Ausfall einer Klienten-Station muss der Anbieter verwaiste Auftragsergebnisse (orphans) erkennen und abräumen.