7.2.0 Facetten der Verteilungsabstraktion

1. 7.2 Mobile Objekte (mobile objects, auch Objektmigration, object migration) 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 . . . vs7.2

2. 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. vs7.2

3. 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. vs7.2

4. 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)) - Verfügbarkeit (z.B. beim Mobilrechnen) - Verfügungsgewalt (Sicherheit) Achtung: Nicht Migration mit Kopieren verwechseln ! (allerdings enge technische Verwandtschaft) vs7.2

5. Klassifikation: Steuerung der Migration explizit implizit imperativ deklarativ Migrationsabstraktion passiv: weak mobility Objekt ist während der Migration aktiv: strong mobility vs7.2

6. 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? vs7.2

7. 7.2.2 Imperative Migration wird explizit durch entsprechende Anweisung veranlasst Wünschenswert (nicht Java RMI !): Remoteund 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) - ersetzen das Original durch einen Vertreter, der sich auf die Kopie bezieht vs7.2

8. 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 Operationop ausführt, z.B. move("//market.com", "trade"); vs7.2

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

10. 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/ vs7.2

11. 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 vs7.2

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

13. 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 vs7.2

14. Benutzung von JavaParty: • 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 (!) vs7.2

15. 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:jpvmsucht Kontakt mitjprmper Rundruf; Stationen sollten daher im gleichen Subnetz sein * zufällige Namensgleichheit mit JPVM für Java PVM vs7.2

16. 4. Programm so starten, daß die .class-Dateien erreichbar sind, z.B. jp HelloJP 5. Die mitjprmundjpvmhochgezogene Plattform abräumen mit jprk („rk“ wie „remote kill“) vs7.2

17. 7.2.5 Klassifikation mobilen Codes Nicht vergessen:  Sowohl das Fernkopieren als auch die Migration von Objekten setzt voraus, dass der Codeentweder 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. vs7.2

18. 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 SA, SB. 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) vs7.2

19. Code Code A Code vs7.2

20. 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) vs7.2

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