7.2 Mobile Objekte

(mobile objects, auch Objektmigration, object migration)

bedeutet: Objekt ist nicht an den Ort gebunden, an dem es erzeugt wurde,

kann dynamisch verlagert werden.

Warum? - 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)

Klassifikation:

Steuerung der Migration

explizit implizit

imperativ deklarativ Migrationsabstraktion

passiv: weak mobilityObjekt 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?

7.2.1 Imperative Migration

wird explizit durch entsprechende Anweisung veranlaßt

Wünschenswert (nicht in 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.3 behandelt)

- ersetzen das Original durch einen Vertreter, der sich auf die

Kopie bezieht

Mobile Agenten

= mobile Objekte, die „selbst“ migrieren

[nicht verwechseln mit Intelligenten Agenten für „verteiltes Problemlösen“]

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.

this.move("//market.com", "trade");

Information über mobile Agenten und einschlägige Systeme:

http://www.davidreilly.com/topics/software_agents/mobile_agents/

http://mole.informatik.uni-stuttgart.de/mal/mal.html

7.2.2 Deklarative Migration

wird unterstützt durch spezielle Sprache mit entsprechenden Konstrukten

bzw. durch deklarative Spracherweiterungen – Annotationen – und

entsprechenden Vorübersetzer

2 Beispiele:

Emerald (Univ. of Washington, Seattle, 1983-86)http://www.diku.dk/research-groups/distlab/Research/Internal/DistOOS/Emerald/

Doorastha (FU Berlin, Markus Dahm) http://www.inf.fu-berlin.de/~dahm/doorastha/

Emerald

Zusätzliche Parametermechanismen 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

Doorastha

= Java mit Annotationen < ..... > , ohne (sichtbaren) RMI-Code

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

7.2.3 Migrationsabstraktion

z.B. bei JavaParty Univ. Karlsruhe, Michael Philippsen)

http://wwwipd.ira.uka.de/JavaParty/(lokal: file:/import/public/opt/JavaParty/doc/features.html)

= minimal erweitertes Java für hochgradige Verteilungsabstraktion

zwecks Parallelrechnen im Lokalnetz – ohne (sichtbaren) RMI-Code

remote class X ... bewirkt, daß die Objekte fernaufrufbarund 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. Übersetzen mit JavaParty-Übersetzer:

jpc <filename>.java

z.B. jpc HelloJP.java mit

public remote class HelloJP {public static void main(String[] arg) {

System.out.println("Hello JavaParty!"); }}

generiert diverse Klassen, einschließlich Hilfs- und Stub-Klassen

2. JavaParty Runtime Manager starten:

jprm &

3. Eine oder mehrere JavaParty Virtual Machines starten, z.B.

auf verschiedenen Stationen, aber so, daß die .class-Dateien

erreichbar sind:

jpvm

Achtung: jpvm sucht Kontakt mit jprm per Rundruf;

Stationen sollten daher im gleichen Subnetz sein

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