Strategien zur automatischen Objektmigration auf Grundlage ...

KAPITEL 2 VERWANDTE ARBEITEN
festlegt, wann und wohin das Objekt migriert werden soll. Zur Auswahl stehen
call-by-move und call-by-visit. Mit call-by-move wird das Objekt auf den
angegebenen Rechner migriert und behält seine neue Platzierung bei. Mit callby-visit
behält das Objekt nur solange die neue Platzierung bei, bis der Zugriff
abgeschlossen ist. Nach dem Zugriff migriert es zu seiner Ursprungsplatzierung
zurück [JLHB1988].
TILEVICH und SMANAGDAKIS heben hervor, dass das Erstellen einer Migrationsstrategie
keine triviale Aufgabe ist. Eine falsche Wahl hat eine ineffektive und
inkorrekte verteilte Anwendung zur Folge [TS2002a].
Neben der Migrationsstrategie muss der Benutzer auch die Initialplatzierung
aller Objekte bei ihrer Klassifikation festlegen. Instanzen von anchored
Klassen werden einmal platziert und behalten ihre Platzierung während der
gesamten Laufzeit der verteilten Anwendung bei. Auf diese Weise legt der
Benutzer in JOchestra die Verteilungsstrategie fest.
Bei der Transformation werden durch den JOchestra-Transformator Stellvertreter-Klassen
im Sourcecode-Format und Remote-Klassen in Bytecode erzeugt.
Die Stellvertreter-Klassen werden zum Abschluss der Transformation
übersetzt. Die Original-Klassen werden so transformiert, dass sie nicht mehr
die Klasse java.lang.Object sondern die Klasse java.rmi.server.
UniCastRemoteObject erweitern. Dies ist notwendig, da die transformierte
Anwendung über RMI kommuniziert.
2.2 Migrationstrategien
2.2.1 REPLIXA
In [JGK1999, Jäg1999] stellen JÄGER, GOLM und KLEINÖDER ein auf Reflektion
[Mae1987] basierendes Framework names RepliXa zur transparenten und
anpassbaren Replikation von Objekten vor. RepliXa verfügt zur Zeit nur über
ein Grundsystem, das noch vieler Erweiterungen bedarf [Jäg1999]. Jedoch
zeigt es für die Entwicklung von Replikationsstrategien einige interessante
Aspekte auf.
Das wesentliche Anliegen der Entwicklung war es, für Programmierer ein
einfaches, transparentes, anpassbares und offenes System zur Objektreplikation
zu entwickeln. Hierbei bedeuten
einfach: eine einheitliche und kleine Schnittstelle zur Nutzung der Dienste
anzubieten,
transparent: Objekte entwickeln zu können, ohne Kenntnis darüber, ob sie
in der Zukunft repliziert werden,
anpassbar: die Ausrichtung für neue Ausführungsumgebungen einzurichten
und neue Replikationsprotokolle möglichst orthogonal zur Anwendung
hinzufügen zu können,
offen: neue Replikationsstrategien problemlos integrieren zu können.
8