(mobile objects, auch Objektmigration, object migration) 8.2 Mobile Objekte (mobile objects, auch Objektmigration, object migration) 8.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 . . .

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.

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.

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

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

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?

wird explizit durch entsprechende Anweisung veranlasst 8.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 8.1.5.4 behandelt) - ersetzen das Original durch einen Vertreter, der sich auf die Kopie bezieht

= mobile Objekte (oder Prozesse!), die „selbst“ migrieren 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");

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

8.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.old.netobjectdays.org/pdf/00/papers/jit/dahm.pdf

Zusätzliche Mechanismen für Variablenparameter bei Fernaufrufen: 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 Keine Wertparameter in Emerald!

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

8.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

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 (!)

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

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“)

8.2.4.1 Dejay Probleme bei der Migration:  Granularität von Objektgraphen  Verlagerung aktiver Objekte (sehr aufwendig)  Erreichbarkeit von Objekten nach mehrfacher Verlagerung Virtual Backplane Virtuelle Maschine Betriebssystem 1 Hardware 1 Betriebssystem 2 Hardware 2 Virtueller Prozessor (umfasst lokale Objekte) lokaler Verweis Fernverweis Idee: Virtueller Prozessor als Migrations- und Ausführungseinheit

Dejay basiert auf Java, verwendet aber einen eigenen Übersetzer. Bedingung: Alle migrierbaren Objekte müssen Serializable sein. Für Fernverweise kommen Vertreter zum Einsatz, die beim Übersetzen des Programms automatisch erzeugt werden. Es wird strikt zwischen lokalen und Fernverweisen unterschieden: Klasse A und Vertreterklasse DjA sind unterschiedliche Typen! Objekte lassen sich entweder lokal erzeugen, oder mittels Fernerzeugung in einem anderen Prozessor. Hello hello_local = new Hello(); hello_local.sayHello("Karsten"); DjHello hello_remote = new DjHello(proc1); hello_remote.sayHello("Max"); Vertreter

Jedes Objekt ist eindeutig einem virtuellen Prozessor zugeordnet. Virtuelle Prozessoren können nur als Ganzes migriert werden: proc1.moveTo("tcp://obelix:7000"); proc1.moveTo(proc2); obj1.moveTo(obj2); Letzteres migriert den Prozessor von obj1 auf die Maschine, wo sich der Prozessor von obj2 befindet. Virtuelle Prozessoren können untereinander verknüpft werden, um gemeinsame Verlagerung zu bewirken: UniPull (transitiv) oder BiPull (transitiv und symmetrisch). Beim Migrieren bleiben alle Verweise gültig, auch Fernverweise: Die Backplane merkt sich das Ziel der Migration. Vertreter erhalten beim Zugriff von ihr eine Fehlermeldung mit Angabe des Ziels, und aktualisieren ihre Zieladresse daraufhin entsprechend.

Virtuelle Prozessoren sind ferner separate Ausführungseinheiten. Innerhalb eines Prozessors ist nur sequentielle Ausführung möglich (keine Threads!) Jeder Methodenaufruf geht zunächst an den viruellen Prozessor Prozessor reiht Aufrufe in Warteschlange ein Prozessor führt nur jeweils einen Aufruf davon auf einmal aus Dies schliesst Migrationswünsche mit ein! Damit erfolgt die Prozessor-Migration immer im passiven Zustand! (Nichtsequentielle Ausführung lässt sich trotzdem erzielen, indem auf derselben Maschine mehrere virtuelle Prozessoren erzeugt werden.)

8.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.

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)

Ressourcen A Code Mobile Agent (process, not object) B Code on Demand (downloading) Remote Evaluation (uploading) Code Ressourcen Client/Server SB SA Paradigma Code Code A Code

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) Achtung! Code übers Netz laden bedroht die Systemsicherheit !