Vs7.21 7.2.0 Facetten der Verteilungsabstraktion Verteilungsabstraktion (distribution transparency) ist Sammelbegriff für verschiedene Eigenschaften eines.

Präsentation zum Thema: "Vs7.21 7.2.0 Facetten der Verteilungsabstraktion Verteilungsabstraktion (distribution transparency) ist Sammelbegriff für verschiedene Eigenschaften eines."—  Präsentation transkript:

1 vs7.21 7.2.0 Facetten der Verteilungsabstraktion Verteilungsabstraktion (distribution transparency) ist Sammelbegriff für verschiedene Eigenschaften eines Programmiersystems, die von den Verteilungsspezifika der Implementierung zu abstrahieren erlauben: Zugriffs- Abstraktion(access transparency) Lage/Orts- Abstraktion(location transparency) Migrations- Abstraktion(migration transparency) Replikations- Abstraktion(replication transparency) und weitere... 7.2 Mobile Objekte (mobile objects, auch Objektmigration, object migration)

2 vs7.22 Zugriffsabstraktion (access transparency): Zugriff auf entferntes Objekte unterschiedet sich weder syntaktisch noch semantisch (!) von einem lokalen Zugriff. Fernaufruf Lage/Ortsabstraktion (location transparency) Programmtext/Programmierer ist nicht damit befasst, auf welcher Station sich ein entferntes Objekt befindet.

3 vs7.23 Migrationsabstraktion (migration transparency) Ein Objekt kann sogar dynamisch auf eine andere Station verlagert werden, ohne dass die Klienten damit befasst sind. Replikationsabstaktion (replication transparency) Ein Objekt kann repliziert implementiert sein – z.B. mit Caching – ohne dass die Klienten damit befasst sind.

4 vs7.24 7.2.1 Grundbegriffe der Objektmobilität Mobile Objekte, Objektmigration bedeutet: Objekt ist nicht an den Ort gebunden, an dem es erzeugt wurde: es kann dynamisch verlagert werden. Wozu das?- Effizienz (Alternative: Replikation/Caching ( 7.3)) 7.3 - Verfügbarkeit (z.B. beim Mobilrechnen) - Verfügungsgewalt (Sicherheit) Achtung:Nicht Migration mit Kopieren verwechseln ! (allerdings enge technische Verwandtschaft)

5 vs7.25 Klassifikation: Steuerung der Migration explizitimplizit imperativdeklarativMigrationsabstraktion passiv: weak mobility Objekt ist während der Migration aktiv: strong mobility

6 vs7.26 Allgemeine Probleme bei der Migration: wenn Objekt verlagert wird: Aktiv oder nur passiv? Synchronisation erforderlich? Merkt es davon etwas, d.h. verhält es sich am Zielort anders? Werden Objekte, auf die es verweist, mitverlagert?... und wenn es nichtverlagerbare Systemobjekte sind? Sind Objekte nach mehrfacher Verlagerung schwerer erreichbar?

7 vs7.27 7.2.2 Imperative Migration wird explizit durch entsprechende Anweisung veranlasst Wünschenswert (nicht Java RMI !): Remote und UnicastRemoteObject haben Operationen void move(String url) void move(RemoteObject ob) - bringen eine Kopie des Objekts nach url bzw. zu ob (eingebettete Objekte werden wie in 7.1.5.4 behandelt)7.1.5.4 - ersetzen das Original durch einen Vertreter, der sich auf die Kopie bezieht

8 vs7.28 Mobile Agenten = mobile Objekte (oder Prozesse!), die selbst migrieren [nicht verwechseln mit Intelligenten Agenten für verteiltes Problemlösen] z.B. this.move("//remote:8300"); verlagert das Objekt und generiert am Zielort einen Thread, der die Ausführung fortsetzt Variante: void move(String url, String op) beendet laufende Operation des Objekts, verlagert das Objekt und generiert am Zielort einen Thread, der die Operation op ausführt, z.B. move("//market.com", "trade");

9 vs7.29 Information über mobile Agenten und einschlägige Systeme: http://www.davidreilly.com/topics/software_agents/mobile_agents/http://www.davidreilly.com/topics/software_agents/mobile_agents/ (1998) http://www.cs.dartmouth.edu/~dfk/papers/kotz:future2/http://www.cs.dartmouth.edu/~dfk/papers/kotz:future2/ (1999) http://mole.informatik.uni-stuttgart.de/mal/mal.html

10 vs7.210 7.2.3 Deklarative Migration wird unterstützt durch spezielle Sprache mit entsprechenden Konstrukten bzw. durch deklarative Spracherweiterungen – Annotationen – und entsprechenden Vorübersetzer Ausgewählte Beispiele: Emerald (Univ. of Washington, Seattle, 1983-86) http://www.diku.dk/forskning/distlab/Research/Internal/DistOOS/Emerald/ Doorastha (M. Dahm, FU Berlin, 2001) http://www.inf.fu-berlin.de/~dahm/doorastha/

11 vs7.211 Emerald Zusätzliche Mechanismen für Variablenparameter bei Fernaufrufen: Call-by-move:Argument migriert zum aufgerufenen Objekt: server.op(move arg); Call-by-visit:Argument migriert zum aufgerufenen Objekt und zurück: server.op(visit arg); (! Nicht verwechseln mit call-by-value-result !) Plattform: Workstation Cluster, Programmcode auf allen Stationen repliziert

12 vs7.212 Doorastha = Java-Erweiterung mit Annotationen, ohne (sichtbaren) RMI-Code, übersetzt nach JVM Klasse für Fernobjekte: class Table... Fernerzeugung: Table t = new Table(); Spezifikation von call-by-move: void op( Table t)... + weitere Annotationen, auch für Attribute von Objekten

13 vs7.213 7.2.4 Migrationsabstraktion z.B. bei JavaParty (Univ. Karlsruhe, M. Philippsen) http://wwwipd.ira.uka.de/JavaParty/ = minimal erweitertes Java für hochgradige Verteilungsabstraktion zwecks Parallelrechnen im Lokalnetz – ohne (sichtbaren) RMI-Code remote class X.. bewirkt, dass die X-Objekte fernaufrufbar und mobil sind Migration wird von intelligentem Laufzeitsystem gesteuert (explizite Steuerung ist ebenfalls möglich) Voraussetzung: alle Stationen sehen gemeinsames (verteiltes) Dateisystem

14 vs7.214 Benutzung von JavaParty: 1.Programm z.B. HelloJP.java public remote class HelloJP { public static void main(String[] arg) { System.out.println("Hello JavaParty!"); }..... } übersetzen mit JavaParty-Übersetzer: jpc HelloJP.java generiert diverse Klassen, einschließlich Hilfs- und Stub-Klassen für RMI (!)

15 vs7.215 2. JavaParty Runtime Manager starten: jprm & 3. Eine oder mehrere JavaParty Virtual Machines starten, z.B. auf verschiedenen Stationen, aber so, dass die.class -Dateien erreichbar sind: jpvm & * Achtung: jpvm sucht Kontakt mit jprm per Rundruf; Stationen sollten daher im gleichen Subnetz sein * zufällige Namensgleichheit mit JPVM für Java PVM

16 vs7.216 4. Programm so starten, daß die.class -Dateien erreichbar sind, z.B. jp HelloJP 5. Die mit jprm und jpvm hochgezogene Plattform abräumen mit jprk (rk wie remote kill)

17 vs7.217 7.2.5 Klassifikation mobilen Codes Nicht vergessen: Sowohl das Fernkopieren als auch die Migration von Objekten setzt voraus, dass der Code entweder am Zielort vorhanden ist (schon geladen oder dynamisch aus dem Dateisystem nachladbar) oder zusammen mit den Daten im Netz übertragen werden kann. Code-Übertragung zwischen Rechnern mit verschiedener Architektur kommt nicht in Frage, wenn es sich um Maschinencode handelt. (Daten dagegen können stets umcodiert werden!) Code-Übertragung (wenn möglich) wird natürlich vielfach - und wurde immer schon - auch ohne Objekte eingesetzt.

18 vs7.218 Allgemeine Situation ohne Objektorientierung: Prozess A ist an einer Dienstleistung interessiert, Prozess B ist an deren Erbringung beteiligt, A und B befinden sich auf verschiedenen Stationen S A, S B. Dienstleistung wird erbracht durch Ausführung von Code (evtl. parametrisiert) auf Daten/Ressourcen Klassifikation von Mobilcode-Paradigmen: (Fuggetta et al. in IEEE-TSE May 1998)

19 vs7.219 ParadigmaSASA SBSB Client/Server AB Code Ressourcen Remote Evaluation (uploading) A Code B Ressourcen Code on Demand (downloading) A Ressourcen B Code Mobile Agent (process, not object) A Code Ressourcen Code A Code

20 vs7.220 Extreme Flexibilität dank interpretiertem Code z.B. bei Java: Dynamisches Laden von Code (.class ) nicht nur aus Dateisystem sondern auch über Netz Beispiele: Applets (downloading) Fernaufruf von Compute Server (uploading mit Objektdaten) Fernaufruf von Objektfabrik (downloading mit Objektdaten)

21 vs7.221 Achtung! Code übers Netz laden bedroht die Systemsicherheit !