vs7.2 1

7.2.0 Facetten der Verteilungsabstraktion

Verteilungsabstraktion (distribution transparency)

ist Sammelbegriff für verschiedene Eigenschaften einesProgrammiersystems, die von den Verteilungsspezifikader 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)

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 mobilityObjekt 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 !):

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)

- 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 Objektund generiert am Zielort einen Thread, der die Operation opausfü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-

Coderemote 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:

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

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: jpvm sucht Kontakt mit jprm per 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 mit jprm und jpvm hochgezogene 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 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 umMaschinencode handelt. (Daten dagegen können stetsumcodiert 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

Paradigma SA SB

Client/Server

A B

Code Ressourcen

Remote Evaluation(uploading)

A

Code

B

Ressourcen

Code on Demand(downloading)

A Ressourcen

B

Code

Mobile Agent(process, not object)

ACode

Ressourcen

Code

Code

ACode

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 !