Strategien zur automatischen Objektmigration auf Grundlage ...

2 VERWANDTE ARBEITEN
2 VERWANDTE ARBEITEN
In diesem Kapitel werden einige Arbeiten vorgestellt, die sich mit Teilgebieten
der Diplomarbeit beschäftigen. Zuerst werden einige ausgewählte Systeme
vorgestellt bevor Migrations- und Replikationsstrategien beschrieben werden.
Abschließend wird noch die Thread-Migration diskutiert.
2.1 Verteilte Systeme
2.1.1 JAVAPARTY
JavaParty [PZJ1998] ist eine Bibliothek zum Schreiben von verteilten
Anwendungen in Java. Hierfür erweitert es die Programmmiersprache um den
Modifier remote. Durch Verwendung des neuen Modifiers legt der Programmierer
fest, dass die Instanzen einer Klasse entfernt platziert werden
können. Diese Instanzen werden auch als remote objects bezeichnet.
JavaParty besteht aus einem Übersetzer und einem Laufzeitsystem. Der
JavaParty-Übersetzer generiert für jede Klasse einer in JavaParty geschriebenen
Anwendung, sieben Klassen und sechs Interfaces, ruft anschließend den
javac-Übersetzer auf und erzeugt unter Einsatz des RMI-Generators die für die
RMI-Kommunikation notwendigen Stub- und Skeletonklassen. Nach dem
Übersetzen kann das Programm im JavaParty-Laufzeitsystem ausgeführt
werden.
JavaParty unterstützt die Migration von Objekten und die Replikation
statischer Konstanten [PZ1997, Bor2002]. Wenn ein remote object auf einen
entfernten Rechner migriert wird, bleibt auf dem Ursprungsrechner ein
Stellvertreter zurück. Wird auf den Sellvertreter ein Zugriff ausgeführt, löst
dieser eine MovedException aus und gibt sie an das aufrufende Objekt
zurück. Mit der MovedException erfährt das aufgerufene Objekt die neue
Platzierung des migrierten Objektes und führt den misslungenen Zugriff ein
zweites mal auf das migrierte Objekt aus.
Als Stellvertreter eines remote objects dient in JavaParty ein sogenanntes
Handle. Über sie werden alle Zugriffe auf remote objects durchgeführt. Durch
das Weiterleiten der Zugriffe über Handles können alle Zugriffe auf remote
objects während dessen Migration solange aufgehalten werden, bis der Umzug
abgeschlossen ist.
Die Migration eines remote objects ist in JavaParty nur dann möglich, wenn
keine Methode auf dem zu migrierenden Objekt gerade ausgeführt und kein
anderes Objekt zum Zeitpunkt des Migrationswunsches migriert wird.
In JavaParty gibt es zwei unterschiedliche Möglichkeiten, das zu migrierende
Objekt neu zu platzieren. Bei der ersten wird das Objekt auf den Rechner
migriert, auf dem das zugreifende Objekt platziert ist. Als zweite Möglichkeit
kann ein beliebiger Rechner als neuer Platzierungsort gewählt werden, der
bereits ein remote object enthält. In beiden Möglichkeiten setzt JavaParty
3