Realisierung von Zustandserhaltung bei der Migration von OSGi-Bundles

Transkript

1 Realisierung von Zustandserhaltung bei der Migration von OSGi-Bundles Fortgeschrittenenprojekt an der Technischen Universität Clausthal Betreut von Holger Klus Dirk Herrling Diese Arbeit beschäftigt sich mit der Frage wie OSGi-Bundles über ein Netzwerk migriert werden können, ohne dabei ihren Zustand zu verlieren.

2 Einleitung 1 Inhaltsverzeichnis 2 Einleitung Ausgangssituation Konkrete Aufgabenstellung Anwendung Die OSGi Service Platform Einführung Lebenszyklusmodell eine Bundles Lösungsvarianten der Migration Arbeitsspeicher kopieren Zustand in Komponente laden & sichern Zustand von außen auslesen Umsetzung Herausforderungen bei der Umsetzung Der MigrationManager als Management Agent Der Zustand eines Bundles Das Bundle in einen konsistenten Zustand überführen Finden von migrierbaren Bundles Migration am Beispiel des Pac-Man-Spiels Migrierbarkeit herstellen Das Bundle übertragen und starten Den Zustand auslesen und zurückschreiben Verwandte Arbeiten Zusammenfassung Literaturverzeichnis

3 Einleitung 10 Abbildungsverzeichnis Anhang 1 MigrationManager Einrichten Vorrausetzungen MigrationManager starten Anhang 2 Migration Manager verwenden Einleitung Bundles installieren, starten und beenden Bundles migrieren Zustand laden und speichern Sonstiges Anhang 3 Richtlinien zur Erstellung migrierbarer Bundles

4 Einleitung 2 Einleitung 2.1 Ausgangssituation Im europäischen Forschungsprojekt OPEN (OPEN Team 2010) (Open Pervasive Environments for migratory interactive services) werden Anwendungen untersucht und entwickelt, welche in der Lage sind, zur Laufzeit von einem Gerät zu einem anderen zu migrieren. Hierbei sollen die Anwendungen in der Lage sein, sich zur Laufzeit an die wechselnde Ausführungsumgebung anzupassen. So müssen Anwendungen, die auf einem PC gestartet werden und anschließend z.b. auf einen PDA migriert werden, sich u.a. auf ein kleineres Display, weniger Speicherkapazität und CPU-Leistungsfähigkeit einstellen. Die Anpassungen zur Laufzeit betreffen sowohl die Benutzungsoberfläche als auch die Anwendungslogik. Die TU Clausthal ist in diesem Projekt verantwortlich für die Migration und Adaption der Anwendungslogik zur Laufzeit (Klus, Institut für Informatik: Studentische Arbeiten 2009). 2.2 Konkrete Aufgabenstellung Abbildung 1: Screenshot der OSGi Implementierung von Pac-Man In OPEN wird u.a. die Service-Plattform OSGi (OSGi Alliance 2010) zur Realisierung der Anwendungslogik verwendet. In OSGi werden Anwendungen aus sogenannten Bundles zusammengesetzt. Ein Bundle ist eine Kapselung von Java Klassen zu einer Komponente. Bei Migration der Anwendungslogik werden diese Bundles angehalten, der Code auf die Zielplattform übertragen, und dort wieder gestartet und deren Verhalten 4

5 Einleitung an die neue Ausführungsumgebung angepasst. Die Migration und Adaption ist bereits prototypisch implementiert. Allerdings ist es in diesem Prototypen zurzeit nicht möglich, den Zustand des Bundles vor der Migration zu extrahieren und ihn beim Start des Bundles auf der Zielplattform wiederherzustellen. In diesem Fortgeschrittenenprojekt soll der Prototyp dahingehend erweitert werden, dass bei der Migration eines OSGi-Bundles der Zustand des zu migrierenden Bundles automatisch extrahiert und nach der Migration wiederhergestellt wird, um für den Anwender eine nahtlose Fortsetzung der Anwendungsnutzung zu gewährleisten (Klus, Institut für Informatik: Studentische Arbeiten 2009). 2.3 Anwendung Als konkrete Anwendung ist eine Implementierung des Konsolenspiels Pac-Man aus den 1980er Jahren gegeben (Wikipedia 2011). Das Spiel liegt in Form von zwei OSGi Bundles vor, welche die Benutzereingaben von der Spiellogik und Darstellung trennt. Darstellung und Spiellogik werden vom Bundle eu.open.pacman.osgi.allinone gekapselt. Die Steuerung des Pac-Man kann entweder vom UI im allinone Bundle oder ausgelagert von einem anderen Bundle übernommen werden (vgl. Abbildung 2). Der Zustand des Pac-Man Spiels soll migriert werden. Der Benutzer erwartet nach einer Migration, dass er das Spiel so weiter spielen kann, wie er es auf der Quellmaschine verlassen hat. Das bedeutet, dass die Geister und der Pac-Man an derselben Position sein und sich in der gleichen Richtung wie zuvor bewegen müssen. Darüber hinaus müssen die Punkte, die im Labyrinth bereits fehlen, weil sie der Pac-Man gefressen hat, weiterhin fehlen und die Anzahl der verbrauchten Leben und die erreichte Punktzahl erhalten bleiben. Alle Variablen, die diese Größen speichern müssen bei der Migration erhalten bleiben. Da sie sich alle entweder der Spiellogik oder der Darstellung zuordnen lassen, liegen alle relevanten Variablen im Bundle eu.open.pacman.osgi.allinone vor. 5

6 Einleitung In dieser Arbeit wird davon ausgegangen, dass die Migration von einem PC auf einen anderen PC stattfinden soll. Eine Migration auf eine Mobilplattform wäre ebenso möglich, birgt aber technische Risiken, ohne dass sich die zugrunde liegenden Konzepte wesentlich änderten. Abbildung 2: OSGiBasedPacMan 6

7 Die OSGi Service Platform 3 Die OSGi Service Platform Das folgende Kapitel beschreibt die grundlegenden Konzepte von OSGi und erläutert diese am Beispiel des Pac-Man Spiels aus der Aufgabenstellung. 3.1 Einführung Die Arbeit an der OSGi Spezifikation begann Ein Konsortium aus verschiedenen Firmen begann an einem Software Standard zu arbeiten der es unabhängigen Dienstanbietern ermöglichen sollte Code auf Home Gateways auszuführen (Wütherich, et al. 2008). Über zehn Jahre später wird OSGi nicht nennenswert auf Home Gateways eingesetzt. Stattdessen findet es im Bereich der Desktop und Enterprise Applikationen Anwendung. In (Wütherich, et al. 2008) wird die OSGi Service Platform als ein dynamisches Modulsystem für Java beschrieben. Es handelt sich um eine Softwareplattform, die die dynamische Integration und das Fernmanagement von Softwarekomponenten (Bundles) und Diensten (Services) ermöglicht. Softwarekomponenten können als Äquivalent zu Bundles angesehen werden. Ein Bundle ist nach (Wütherich, et al. 2008) eine fachlich oder technisch zusammenhängende Einheit, die eigenständig im Framework installiert und deinstalliert werden kann. Um diese Dynamik zu realisieren müssen gewisse Konventionen eingehalten werden, auf die im weiteren Verlauf noch eingegangen werden wird. In Pac-Man existieren zwei Bundles. Eins zur Steuerung des Pac-Man (PdaService- Representator) und eins für die Spiellogik und Darstellung (allinone). Die Klassen und Ressourcen eines Bundles sind für andere Bundles nicht sichtbar. Um sie sichtbar zu machen, muss das zur Verfügung stellende Bundle die gewünschten Module (in Form von Java-Packages) explizit exportieren. Das nutzende Bundle muss diese Module seinerseits importieren. Diese Exports und Imports erfolgen deklarativ in einer Manifest Datei 7

8 Die OSGi Service Platform die jedem Bundle beiliegt. Im allinone Bundle sieht die Manifest Datei wie folgt aus: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: PacMan Bundle-SymbolicName: OSGiBasedPacMan Bundle-Version: Bundle-Activator: eu.open.pacman.osgi.allinone.activator Bundle-Vendor: Holger Klus, TU Clausthal Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Import-Package: org.osgi.framework;version="1.3.0", org.osgi.util.tracker Export-Package: eu.open.pacman.osgi.allinone, eu.open.pacman.osgi.allinone.component.logic, eu.open.pacman.osgi.allinone.component.ui, eu.open.pacman.osgi.allinone.service Require-Bundle: eu.open.middleware.service.pdarepresentatorservice;bundleversion="1.0.0", MigrationManager;bundle-version="1.0.0" Die Module, beziehungsweise Java Packages, die das Bundle exportiert werden unter Export-Package angegeben. In diesem Fall sind das alle Pakete, die in Pac-Man verwendet werden. Benötigte Packages müssen importiert werden und werden unter Import-Package angegeben. Hier wird in der Regel org.osgi.framework aufgeführt falls das Bundle mit dem Framework kommunizieren will, was meistens der Fall ist. Verwendet das Bundle Services und möchte den Service Tracker nutzen, um Bundles zu finden, die einen Service anbieten, muss auch org.osgi. util.tracker importiert werden. Ein Service wird in (Wütherich, et al. 2008, 13) als ein Java-Objekt beschrieben, das unter einem Interface-Namen bekannt gemacht wird. Services können von einem Bundle zur Verfügung gestellt werden und stehen dann im gesamten System zur Verfügung. Im Fall von Pac-Man ist ein solcher Service der pdarepresentatorservice, der unter dem Namen PDARepresentatorIf bekannt gemacht wird. Services können zur Laufzeit registriert und deregistriert werden. Ein Bundle, das einen Service nutzt muss daher sicherstellen, dass ein Service, der genutzt werden soll, aktuell verfügbar ist. Services werden bei der Service 8

9 Die OSGi Service Platform Registry registriert, die zentral und Bundle übergreifend zur Verfügung steht. Um die Service Registry abzufragen und benachrichtigt zu werden, wenn ein bestimmter Service zur Verfügung steht können Service Tracker eingesetzt werden. Auf ihnen wird eine Methode addingservice( ) aufgerufen, sobald ein gesuchte Service registriert wird. Unter Umständen können Bundles nur gestartet werden wenn gewisse Abhängigkeiten, formuliert in einer Liste von benötigten Bundles, erfüllt sind. Diese Abhängigkeiten werden ebenfalls in der Manifest Datei angegeben. In unserem Beispiel oben ist zu erkennen, das OSGiBasedPac- Man die Bundles eu.open.pacman.pdarepresentatorservice und MigrationManager benötigt. 3.2 Lebenszyklusmodell eine Bundles Das Lebenszyklusmodell eines Bundles besteht aus sechs Zuständen. Die Veränderung des Zustands kann programmatisch durch die Framework- API oder von außen durch einen Management Agent geschehen. Ein Management Agent ermöglicht die Nutzung der Framework-API zum Beispiel über eine Konsole oder eine grafische Benutzungsoberfläche (Wütherich, et al. 2008, 61). Damit ermöglicht er unter anderem das Starten und Stoppen oder das Installieren einzelner Bundles in das Framework. Bekannte Management Agents sind zum Beispiel Knopfler- Abbildung 3: Das vollständige Lebenszyklusmodell eines Bundles (Wütherich, et al. 2008, 61) 9

10 Die OSGi Service Platform fish (The Knopflerfish Project 2010), Concierge (Institute for Pervasive Computing, ETH Zurich 2009) oder Eclipse Equinox (The Eclipse Foundation 2011), das in dieser Arbeit verwendet wurde. Ein Bundle muss in das Framework installiert werden, damit es verfügbar ist. Nachdem das geschehen ist, ist es im Zustand INSTALLED. Wenn alle Abhängigkeiten des Bundles aufgelöst werden können, geht das Bundle in den Zustand Resolved über. Bei der vorliegenden Pac-Man Implementierung würde osgibasedpacman, wenn es als erstes Bundle installiert wird, im Bundle INSTALLED verbleiben. Erst nachdem PdaRepresentatorService installiert wurde kann osgibasedpacman in den Zustand RESOLVED übergehen, weil zwischen den beiden Bundles eine Abhängigkeit existiert. Ein Bundle im Zustand INSTALLED oder RESOLVED kann deinstalliert werden. Es geht dann in den Zustand UNINSTALLED über und ist dem Framework nicht länger bekannt. Wenn ein Bundle im Zustand RESOLVED ist, kann es gestartet werden. Bis zur erfolgreichen Abarbeitung der start() Methode verbleibt das Bundle im Zustand STARTING. Wird eine Exception geworfen, wird das Bundle in den Zustand RESOLVED zurückgesetzt. Ist die start() Methode zurückgekehrt befindet sich das Bundle im Zustand ACTIVE. Im Fall von osgibasedpacman kann jetzt Pac-Man gespielt werden. Durch stop() wird das Bundle wieder in den Zustand RESOLVED überführt, von wo aus es erneut gestartet oder deinstalliert werden kann. 10

11 Lösungsvarianten der Migration 4 Lösungsvarianten der Migration Soll eine Anwendung, eine Komponente oder wie hier ein Bundle migriert werden, teilt sich diese Migration in zwei Aufgaben auf: 1. der ausführbare Code muss kopiert werden 2. der Zustand der Komponente muss erhalten bleiben. Die Aufgabenstellung dieser Arbeit ist die Kopie des Zustands (2). Für die Kopie der ausführbaren Bundles liegt bereits eine prototypische Implementierung vor. Drei Lösungsvarianten werden im Folgenden diskutiert. 4.1 Arbeitsspeicher kopieren Den zu einem Bundle gehörenden Arbeitsspeicher in seiner Gesamtheit zu kopieren, scheint eine einfache und naheliegende Lösung zu sein. Hierzu könnten die zugehörigen Threads auf Betriebssystemebene angehalten und danach der Speicher kopiert werden. Im Fall von Pac-Man müsste man die gesamte Java-VM anhalten und den von ihr zugesicherten Arbeitsspeicher auf die Zielmaschine kopieren. Dort müsste dann die Java-VM wieder gestartet werden. Neben der Einfachheit dieser Lösung ist auch die Tatsache, dass das zu migrierende Bundle nicht angepasst werden muss, ein großer Vorteil. Die Herangehensweise hat jedoch eine ganze Reihe von Nachteilen. Die zuvor gestoppten Threads müssen mit ihren Einsprungpunkten kopiert und in einer Reihenfolge die das Bundle erwartet erneut gestartet werden. Fehler an dieser Stelle können zu Race Conditions führen die vor der Migration nicht aufgetreten sind. Darüber hinaus ist diese Lösung sehr plattformabhängig. Wird eine Komponente auf eine Zielplattform mit anderer Endianess (das höchstwertige Bit steht an anderer Stelle als auf der Ausgangsplatt- 11

12 Lösungsvarianten der Migration form) übertragen wird sie nicht mehr funktionieren. Soll Pac-Man zum Beispiel von einem Computer auf einen anderen, mit einer anderen Java-Version migriert werden, könnten schwere Fehler auftreten, wenn die Java-VM versucht weitere Klassen aus der lokalen Installation zu laden. Erst Recht würde eine Migration von einem Windows-PC auf eine Mobil-Plattform mit ARM CPU scheitern. Die Vorteile der Plattformunabhängigkeit von Java wären verloren. Das Verhalten dynamisch geladener Bibliotheken, die zum Teil kopiert würden, könnte sich verändern, da unterschiedliche Versionen zwischen Quell- und Zielplattform zu Versionskonflikten führen könnten. Das Kopieren von geschütztem Speicher benötigt auf nahezu allen Betriebssystemen Systemrechte. Der Management Agent, der die Migration steuert, wäre damit ein Sicherheitsrisiko. Aufgrund der schwerwiegenden Gegenargumente wurde diese Lösungsvariante nicht umgesetzt. 4.2 Zustand in Komponente laden & sichern Statt den Arbeitsspeicher wie in 4.1 zu kopieren, kann der Zustand auch in einem Bundle zusammengefasst werden. Der offensichtliche Vorteil ist, dass der Komponentenentwickler weiß, welche Daten für sein Bundle wichtig sind. Er kann geeignete Methoden implementieren, die den Zustand der Komponente auslesen und zurückschreiben können. Durch eine geeignete Schnittstelle können diese Zustände durch das Framework abgerufen, versandt und injiziert werden. Der Nachteil liegt in den großen Anpassungen, die in jeder Komponente nötig sind. Die Implementierung einer Methode, die den Zustand ausliest oder zurückschreibt, kann sehr komplex sein und kostet den Entwickler Zeit. 12

13 Lösungsvarianten der Migration In Pac-Man könnten verschiedene Methoden implementiert werden, mit denen zum Beispiel der aktuelle Punktestand, die Position der Geister und des Pac-Man und die Positionen der gefressenen Punkte im Labyrinth gelesen und geschrieben werden kann. Diese Daten könnten in einem generischen Zustands-Objekt (zum Beispiel vom Typ Object) gespeichert werden und durch eine Schnittstelle dem Framework zugänglich gemacht werden. 4.3 Zustand von außen auslesen Die Nachteile aus 4.2 lassen sich abschwächen, wenn der Zustand von außen ausgelesen wird. Anstatt die Methoden zum Lesen und Schreiben des Zustands selbst zu implementieren, markiert der Komponentenentwickler Attribute, deren Inhalt bei der Migration übertragen werden sollen, durch ein Sprachkonstrukt. Eine Schnittstelle definiert Methoden, deren Implementierung durch den Komponentenentwickler erfolgt und die die Komponente in einen konsistenten Zustand überführen. Der Vorteil ist, dass der Komponentenentwickler in seinem Bundle nur markieren muss welche Attribute benötigt werden. Das Framework stellt sicher, dass diese korrekt gelesen und geschrieben werden. Das Risiko von Fehlern in der Implementierung wird minimiert, da immer die gleiche Implementierung verwendet wird und der Komponentenentwickler nicht für jedes Bundle neue Methoden zum Lesen und Schreiben der Zustände seiner Bundles implementieren muss. Darüber hinaus ist die Lösung sehr plattformunabhängig, da sich durch die Zustandsmigration keine neuen Anforderungen an die Plattform ergeben. Die Lösung setzt nur eine Java VM und ein OSGi Framework voraus. In diesem Kapitel wurden verschieden Möglichkeiten zur Migration eines Bundles unter Statuserhalt diskutiert. Im Folgenden wird auf die Umsetzung und konkrete Realisierung eingegangen. 13

14 Umsetzung 5 Umsetzung Dieses Kapitel beschäftigt sich mit der Umsetzung des Konzepts aus 4.3. Der MigrationManager, ein Management Agent mit Funktionen zur Migration von Bundles, der im Rahmen der Arbeit entstand wird vorgestellt und auf den Aufbau eines migrierbaren Bundles wird eingegangen. 5.1 Herausforderungen bei der Umsetzung Die in 4.3 skizzierte Lösung wurde umgesetzt, da sie den geringsten Aufwand für den Bundle-Entwickler bedeutet und das Lesen und Schreiben des Zustands von der Logik der Komponente gut trennt. Sie setzt sich aus den Lösungen für verschiedene Teilprobleme zusammen. Um die Migration auslösen zu können, wird ein vom Endnutzer bedienbarer Management Agent benötigt. Über die üblichen Funktionen wie Starten, Stoppen, Installieren und Deinstallieren von Bundles hinaus muss der Benutzer mit ihm das Migrationsziel auswählen und die Migration auslösen können. Ein Bundle kapselt Klassen zu einer Komponente. Der Zustand eines Bundles setzt sich aus den Zuständen seiner Klassen in Kombination mit den Ausführungszuständen seiner Threads und dem Ausführungszustand des Bundles (vgl. 3.2) zusammen. Am Beispiel von Pac-Man wäre das zum Beispiel, die Positionen aller Geister, die Position von Pac-Man, der Inhalt des Labyrinths und erspielte Punkte, als Zustand der enthaltenen Klassen, in Kombination mit der Information laufend für die Threads und ACTI- VE für den Ausführungszustand des Bundles. Der Ausführungszustand eines Bundles, das migriert werden soll, ist immer ACTIVE, da das Bundle sonst nicht erfolgreich gestartet wurde und in Folge dessen auch keine, für die Übertragung wichtigen Daten enthält. Der Zustand einer Klasse kann als die Belegung sämtlicher Attribute betrachtet werden. Der Ausführungszustand eines Threads kann zum Bei- 14

15 Umsetzung spiel wartend oder laufend sein. Der Zustand eines Bundles muss ausgelesen, transportiert und zurückgeschrieben werden können. Darüber hinaus sind Fälle denkbar, in denen der Komponentenentwickler die Menge der migrierten Daten einschränken will. Es muss also möglich sein, durch ein geeignetes Sprachkonstrukt die für den Zustand wichtigen Attribute zu markieren oder andere auszuschließen. Um das Bundle in einen konsistenten Zustand zu überführen und um dem Komponentenentwickler eine Möglichkeit zu geben auf die anstehende Migration zu reagieren, muss eine geeignete Schnittstelle definiert werden, die vom Komponentenentwickler implementiert und vom Framework genutzt werden kann und eine Vor- und Nachbereitung der Migration ermöglicht. Ein nicht-migrierbares Bundle muss von migrierbaren Bundles unterschieden werden können um Fehlfunktionen bei Migrationsversuchen auf nicht-migrierbaren Bundles zu verhindern. 5.2 Der MigrationManager als Management Agent Im Rahmen dieses Fortgeschrittenenprojekts wurde der Migration- Manager als Management Agent entwickelt. Er bietet dem Endnutzer die Möglichkeit Bundles vom Sekundärspeicher zu laden und ins Framework zu installieren. Darüber hinaus sind Funktionen zum Starten und Stoppen von Bundles implementiert. Im Gegensatz zu anderen Management Agents wurde keine automatische Auflösung von Abhängigkeiten zwischen Bundles implementiert, da diese im Rahmen der Lösungsvorstellung nicht relevant ist. Wie in Abbildung 4 dargestellt, bietet der MigrationManager über die Standardfunktionen eines Management Agent hinaus, eine Übersicht über alle im Framework vorhandenen Bundles, sowie Eingabefelder für das Migrationsziel und eine Schaltfläche um die Migration auszulösen. Details zur Inbetriebnahme des MigrationManager sind in Anhang 1 MigrationManager zu finden. Weitere Informationen zur Verwendung finden sich im Anhang 2. 15

16 Umsetzung Abbildung 4: MigrationManager Software Um ein Bundle mit MigrationManager migrieren zu können muss sein Zustand ausgelesen und übertragen werden. Das folgende Kapitel beschäftigt sich mit der Frage was der Zustand eines Bundles ist und wie er sich darstellt. 5.3 Der Zustand eines Bundles OSGi schreibt für jedes Bundle eine Activator Klasse vor. Diese Klasse muss im Bundle Manifest explizit angegeben werden und die Schnittstelle BundleActivator implementieren. Dadurch implementiert die Activator Klasse die Methoden start( ) und stop( ) welche beim Übergang des Bundles zwischen den Lebenszykluszuständen RESOLVED und STARTING beziehungsweise STOPPING und RESOLVED vom Framework aufgerufen werden (vgl. Abbildung 3 und Abbildung 5). Der Zustand eines Bundles ist neben dem Lebenszykluszustand noch durch die Ausführungszustände eventuell enthaltener Threads und den Zuständen seiner Klassen, die die Datenhaltung darstellen, zusammen. Der Zustand einer Klasse kann als die Belegung sämtlicher Attribute betrachtet werden. Der Zustand eines Bundles im Bezug auf die Datenhaltung ist also ein Objektgeflecht, das alle Objektinstanzen enthält. 16

17 Umsetzung public class Activator extends Migrateable implements BundleActivator, Serializable { private transient Thread private PacManMainFrameUI pacmanmainframeui; private transient PDAServiceTracker public void start(bundlecontext context) throws Exception { super.makemigrateable(context, this); this.pacmanmainframeui = new PacManMainFrameUI(); this.t = new Thread(this.pacManMainFrameUI); this.t.start(); } this.tracker = new PDAServiceTracker( this.pacmanmainframeui, context, PDARepresentatorIf.class.getName()); public void stop(bundlecontext context) throws Exception { this.pacmanmainframeui.removeall(); this.pacmanmainframeui.dispose(); public void setstate(object state) { super.setstate(state); public void beforestateretrieval() { public void afterstateretrieval() { public void beforesetstate() { this.pacmanmainframeui.removeall(); this.pacmanmainframeui.setvisible(false); } public void aftersetstate() { this.pacmanmainframeui.setvisible(true); this.t = new Thread(this.pacManMainFrameUI); this.t.start(); this.tracker = new PDAServiceTracker( this.pacmanmainframeui, super.getbundlecontext(), PDARepresentatorIf.class.getName()); this.tracker.open(); } Abbildung 5: Die Activator-Klasse von Pac-Man 17

18 Umsetzung Die Repräsentation von Objektgeflechten ist ein über viele Jahre erforschtes Gebiet. In diesem Projekt muss ein Objektgeflecht, das durch einen Graph dargestellt werden kann, durch einen Datenstrom transportiert werden. Der Graph muss auf der Senderseite traversiert und auf der Empfängerseite wiederhergestellt werden. Es liegt nahe, hier eine bestehenden Lösungen zu verwenden, statt ein eigenes Verfahren zu entwickeln. Die Java Serialization API (Oracle 2010) wird als geeignete Lösung in diesem Projekt eingesetzt. Da die Serialisierung auf Reflexion basiert (Grosso 2001), ist wichtig, dass sogenannte Inseln im Objektgeflecht vermieden werden. Inseln sind in diesem Zusammenhang eine oder mehrere Klassen, die keine Verbindung zur Activator-Klasse haben. Abbildung 6: Die Insel im Objektgeflecht rund um das Thread Objekt kann per Reflexion nicht gefunden werden. 18

19 Umsetzung Solange keine Inseln im Objektgeflecht existieren kann jede Objektinstanz mittels Reflexion von der Activator-Klasse ausgehend gefunden werden. Nicht referenzierte Klassen, die nicht zusammen mit einer Instanz vom Typ Thread eine Insel wie in Abbildung 6 bilden, werden vom Garbage Collector in regelmäßigen Abständen gelöscht (Ullenboom 2009). Der Vorteil der Verwendung der Java Serialization API liegt neben der Tatsache, dass die Traversierung und serielle Repräsentation eines Objektgraphs gelöst ist auch darin, dass geeignete Methoden zur Verfügung stehen um Objektströme zu speichern und zu versenden. Abbildung 7: Nur die Instanzen von C und B werden migriert Grundsätzlich werden in der vorliegenden Implementierung die Activator Klasse und all ihre Attribute serialisiert. Aus Sicht des Komponentenentwicklers sind eventuell nicht alle Attribute der Activator Klasse von Belang. Einige Attribute sollen unter Umständen nach der Migration nicht überschrieben werden, da sie beispielsweise plattformspezifische oder nur lokal interessante Informationen enthalten (etwa eine lokale Pac- Man Bestenliste), andere dürfen die Quellplattform zum Beispiel aus Sicherheitsgründen gar nicht erst verlassen. 19

20 Umsetzung Diese Anforderung wird durch die Einführung einer Annotation zur Markierung von zu migrierenden Attributen erfüllt. Der Komponentenentwickler muss alle Attribute, die auf der Zielplattform zurückgeschrieben werden sollen, explizit mit Annotation markieren (siehe Abbildung 7). Soll darüber hinaus verhindert werden, dass der Inhalt bestimmter Attribute die Quellplattform verlässt, kann das Java Schlüsselwort transient verwendet werden. Mit transient markierte Attribute werden bei der Serialisierung ignoriert. Diese Art der Einschränkung muss auch bei nicht serialisierbaren Attributen verwendet werden und kann genutzt werden, um migrierte Teilgraphen einzuschränken. War Annotation in einer frühen Entwicklungsphase eingeführt worden um Attribute zu markieren, die migriert werden sollen, stellte sich später heraus, dass mit ähnlichem Aufwand unter Zuhilfenahme der Java Reflection API die gleiche Funktionalität mit dem transient Schlüsselwort zur Einschränkung des Zustands realisierbar ist. Trotzdem wurden die Annotationen beibehalten, um das Versehentliche migrieren von Attributen zu verhindern und das Bewusstsein, dass es sich bei einem annotierten Attribut um ein zu migrierendes handelt, zu stärken. Es zeigte sich, dass eine Annotation im Quelltext deutlicher auffällt, als das Nichtvorhandensein eines transient Schlüsselworts. Eine große Herausforderung für den Komponentenentwickler liegt darin, alle Klassen, die er migrieren möchte, serialisierbar zu machen. Um serialisierbar zu sein, muss eine Klasse die Schnittstelle Serializeable implementieren. Die Schnittstelle dient nur der Markierung und definiert keine Methoden (Oracle 2010). Sämtliche enthaltene Attribute müssen entweder primitiv oder ebenfalls serialisierbar sein. Da Threads nicht serialisierbar sind, muss ihre Logik von den Daten, die sie verarbeiten, getrennt werden. Durch geeignete Methoden, die vor und nach dem Auslesen und Schreiben des Zustands auf dem migrierten Object aufgerufen wer- 20

21 Umsetzung den, können Threads nach der Migration neu erstellt und gestartet werden (vergleiche hierzu auch 5.4). Für weitere Hinweise zur Erstellung migrierbarer Bundles siehe Anhang 3. In einem migrierbaren Bundle muss die Activator Klasse als Ausgangspunkt der Serialisierung zusätzlich von der Klasse Migrateable erben. Diese abstrakte Klasse implementiert die Methoden setstate(object state) und getstate():object, die vom MigrationManager zum Schreiben und Lesen des Zustands eines Bundles verwendet werden. Der Komponentenentwickler hat die Möglichkeit diese Methoden zu überschreiben, um eine eigene Zustandsübertragung zu realisieren. Abbildung 8: Die Superklasse Migrateable In Abbildung 8 sind die Methoden von Migrateable dargestellt. Auf getstate() und setstate( ) wurde bereits eingegangen, die weiteren Methoden werden in den folgenden Kapiteln behandelt. 5.4 Das Bundle in einen konsistenten Zustand überführen Bevor der Zustand eines Bundles ausgelesen werden kann, muss das Bundle in einen konsistenten Zustand überführt werden. Hierzu müssen unter Umständen Threads angehalten oder Schleifendurchläufe abgewartet werden. Daher sind Mechanismen nötig, die dem Komponentenentwickler die Möglichkeit geben, das Auslesen des Zustands Vor- und Nachzubereiten. Bevor der Zustand in ein Bundle injiziert werden kann, muss es gestartet werden, da es sonst nicht im Framework gefunden 21

22 Umsetzung werden kann. Dabei geht es von dem Lebenszykluszustand INSTALLED in RESOLVED, dann in STARTING und zuletzt in ACTIVE über (vergleiche 3.2). Damit das Bundle im Zeitraum zwischen dem Übergang nach ACTIVE und dem Zurückschreiben seines Zustands (was in ACTIVE stattfindet) kein ungewolltes Verhalten zeigt und um dem Komponentenentwickler die Möglichkeit zu geben, auf das Zurückschreiben des Zustands auf Empfängerseite zu reagieren (zum Beispiel indem der Start verschiedener Threads verzögert wird bis der Zustand geladen wurde), muss auch hier eine Vor- und Nachbereitung möglich sein. Um diese Anforderungen zu erfüllen, wurde die bereits existierende Migrateable Superklasse um die vier synchron aufgerufenen, abstrakten Methoden beforestateretrieval(), afterstateretrieval(), beforesetstate() und aftersetstate() erweitert (siehe Abbildung 8: Die Superklasse Migrateable). beforestateretrieval() wird unmittelbar bevor der Zustand ausgelesen wird aufgerufen. Das Bundle befindet sich im Lebenszykluszustand ACTIVE. Die Implementierung dieser Methode kann genutzt werden, um die verschiedenen Threads, sofern vorhanden, anzuhalten, Schleifendurchläufe abzuwarten oder beispielsweise ein Spiel zu pausieren. afterstateretrieval() wird unmittelbar nach Auslesen des Zustands aufgerufen. Soll das Bundle migriert werden, kann es hier auf der Quellplattform angehalten werden. Es kann also vom Lebenszykluszustand ACTIVE in STOPPING übergehen. Soll das Bundle über die Migration hinaus auf der Quellplattform bestehen, können die in beforestateretrieval() angehaltenen Threads neu erstellt werden. beforesetstate() wird aufgerufen bevor der Zustand zurückgeschrieben wird. Das Bundle befindet sich beim Aufruf dieser Methode bereits im Lebenszykluszustand ACTIVE Hier kann der 22

23 Umsetzung Komponentenentwickler sein Bundle auf das Zurückschreiben des Zustands vorbereiten. aftersetstate() ist die letzte Methode die im Laufe einer Migration aufgerufen wird. In der Implementierung dieser Methode kann der Komponentenentwickler zum Beispiel Threads neu erstellen und starten. Diese vier Methoden abstrakt zu deklarieren war eine bewusste Entscheidung, damit ihre Implementierung bei der Entwicklung nicht versehentlich vergessen wird. Auch erleichtert es die Arbeit eines Entwicklers, der sein Bundle migrierbar realisieren möchte, da offensichtlich ist, an welchen Stellen zum Beispiel Threads gestartet und gestoppt werden können. Sind einzelne Implementierungen nicht nötig, steht es dem Entwickler frei, die Methoden leer zu implementieren. Wie in 5.1 erwähnt, setzt sich der Zustand eines Bundles nicht nur aus den Zuständen seiner Klassen, sondern auch aus den Ausführungszuständen seiner Threads zusammen. Da diese nicht durch eine Serialisierung erfasst werden können, obliegt es dem Komponentenentwickler, die Migration der Ausführungszustände seiner Threads in den vier oben stehenden Methoden zu realisieren. 5.5 Finden von migrierbaren Bundles Damit der Migration Manager ein Bundle als migrierbar erkennt, muss dieses den MigrateableIf Service anbieten. Die Superklasse Migrateable registriert den Service beim Aufruf von make- Migrateable( ) (vgl. Abbildung 5 und Abbildung 8). Der objectformigration Parameter dieses Aufrufs sollte einen Zeiger auf die Acti- Abbildung 9: Das MigrateableIf Interface vator Klasse (this falls der Aufruf in der start() Methode erfolgt) enthalten, kann aber auch genutzt werden, um die Serialisierung nicht in der Activator Klasse zu beginnen. Wird eine andere Klasse als Ausgangspunkt für die 23

24 Umsetzung Zustandsmigration verwendet, müssen in dieser statt der Activator Klasse die Attribute annotiert werden. Dieses Kapitel hat sich mit der technischen Umsetzung von MigrationManager beschäftigt. Im folgenden Kapitel wird eine Migration im Detail beschrieben 24

25 Migration am Beispiel des Pac-Man-Spiels 6 Migration am Beispiel des Pac-Man-Spiels Im Folgenden wird eine Migration am Beispiel des Pac-Man-Spiels exemplarisch beschrieben. Es wird davon ausgegangen, dass sowohl auf der Sender- als auch der Empfängerseite ein Bundle installiert und gestartet ist, das den PDARepresentatorService zur Verfügung stellt da der MigrationManager nicht in der Lage ist Abhängigkeiten automatisch aufzulösen und Pac-Man diesen Service benötigt. Abbildung 10: Der Ablauf einer Migration Die einzelnen Schritte können am Sequenzdiagramm in Abbildung 10 nachvollzogen werden und werden nun detailliert beschrieben. 6.1 Migrierbarkeit herstellen Nachdem ein migrierbares Bundle im Framework installiert wurde, muss es seinen MigrateableIf Service registrieren. Bleibt diese Registrierung aus, wird das Bundle vom MigrationManager nicht als migrierbar betrachtet. In der Pac-Man Implementierung geschieht diese Registrierung durch den Aufruf von makemigrateable( ). Der Aufruf dieser Methode regis- 25

26 Migration am Beispiel des Pac-Man-Spiels triert darüber hinaus eine Referenz auf die Klasse, von der die Zustands- Migration ausgehen soll. Im Fall von Pac-Man ist das die Activator Klasse des Bundles. 6.2 Das Bundle übertragen und starten Hat der Anwender eine IP-Adresse und einen Port für das Migrationsziel im MigrationManager eingetragen und den Migrate-Button betätigt, beginnt dieser mit der Migration. Hierzu kopiert er zuerst das Bundle über das Netzwerk auf die Zielmaschine. Der MigrationManager auf der Gegenseite versucht darauf hin, das Bundle zu starten, was gelingt, falls alle Abhängigkeiten erfüllt sind. Das gestartete Bundle registriert seinen MigrateableIf Service in der Service Registry des OSGi Frameworks der Zielmaschine. 6.3 Den Zustand auslesen und zurückschreiben Die Vorbereitung auf die anstehende Zustandsübertragung erfolgt im nächsten Schritt. Die Methode beforestateretrieval() ist in Pac-Man leer implementiert, da eine Überführung in einen konsistenten Zustand nicht nötig ist. getstate() wird auf dem Quellbundle auf Senderseite aufgerufen und liefert die Referenz zurück, die zu Beginn durch makemigrateable( ) gesetzt wurde. Die serialisierte Form dieses Objekts wird über das Netzwerk übertragen und afterstateretrieval() auf dem Bundle auf Senderseite aufgerufen. Im Fall von Pac-Man ist die Implementierung dieser Methode ebenfalls leer. Wären in beforestate- Retrieval() zum Beispiel Threads angehalten worden, müssten diese hier erneut gestartet werden, falls das Bundle weiterlaufen soll. Das ist in Pac-Man nicht der Fall. Auf Empfängerseite entfernt beforesetstate() das gesamte Pac-Man UI. Anschließend wird das empfangene Zustandsobjekt deserialisiert. In einer Iteration über alle Attribute der Activator Klasse wird für jedes Attribut geprüft, ob es annotiert wurde. Ist dies der Fall wird der 26

27 Migration am Beispiel des Pac-Man-Spiels initiale Wert dieses Attributs mit dem Wert von der Migrationsquelle überschrieben. Im letzten Schritt erzeugt aftersetstate()einen Thread der das gesamte Spielgeschehen verarbeitet und macht das GUI sichtbar. Die Migration ist abgeschlossen. Dieses Kapitel hat den Ablauf einer Migration im Detail betrachtet. Im Folgenden wird kurz auf verwandte Probleme und Lösungen eingegangen. 27

28 Verwandte Arbeiten 7 Verwandte Arbeiten Unter Linux-artigen Betriebssystemen, die das X Window System verwenden, ist eine Migration von Anwendungsfenstern zur Laufzeit möglich. Xpra (X Persistent Remote Application) (xpra - partiwm - Project Hosting on Google Code 2009) ist ein Tool, das eine Abstraktionsschicht zwischen X Window System und Applikation implementiert. Durch diese Abstraktionsschicht können Ein- und Ausgaben beliebig migriert werden. Die Applikation selbst wird nicht migriert, sondern verbleibt auf der Maschine, auf der sie ursprünglich gestartet wurde. Am HIIS Laboratory (Human Interfaces in Information Systems Laboratory) der Universität von Pisa wird unter der Leitung von FabioPaternò im Bereich Migratory User Interfaces an Benutzeroberflächen geforscht, die zur Laufzeit zwischen verschiedenen Plattformen transferiert werden können und es so dem Benutzer erlauben seine Aufgabe ununterbrochen durchzuführen (Paternò 2010). Im Rahmen des OPEN Forschungsprojekts wurde an unterschiedlichen Arten von Migrationen gearbeitet. Eine Übersicht über die erforschten Szenarien kann in (Faatz und Goertz 2008) gefunden werden. An der TU Clausthal wurde in diesem Projekt an der dynamischen Rekonfiguration von Anwendungen zur Laufzeit gearbeitet (Klus, Niebuhr, et al. 2009). Diese Rekonfiguration stellt unter anderem den nächsten Schritt nach einer gelungenen Migration einer Anwendung dar. Unter Rekonfiguration wird eine Anpassung des Verhaltens zur Laufzeit verstanden. In bestimmten Fällen (zum Beispiel wenn sich zur Verfügung stehender Speicher oder Displaygröße geändert haben) bietet es sich an, die hier gewonnen Kenntnisse einzusetzen um das Verhalten der migrierten Anwendung an die neuen Gegebenheiten anzupassen. 28

29 Zusammenfassung 8 Zusammenfassung Im Rahmen dieser Arbeit wurde ein Konzept zur Zustandserhaltung bei der Migration von OSGi Bundles entwickelt. Hierfür wurde der Zustand als die Menge aller Attribute aller Klassen in Kombination mit den Ausführungszuständen der enthaltenen Threads und des Bundles betrachtet. Der Komponentenentwickler kann den zu migrierenden Zustand einschränken und Operationen definieren, die auf Quell- und Zielmaschine vor und nach der Migration durchgeführt werden um so Vor- und Nachbereitungen zu treffen oder die Ausführungszustände der Threads zu erhalten. Um die Migration zu unterstützen wurde der Migration Manager, ein Management Agent mit zusätzlichen Funktionen zur Steuerung der Migration, entwickelt. Mit seiner Hilfe kann ein Anwender ein migrierbares Bundle, das in der Software als solches zu erkennen ist, auf einen Zielcomputer migrieren, sofern dort ebenfalls der Migration Manager gestartet wurde. Der Zustand des migrierten Bundles wird dann automatisch wiederhergestellt um für den Anwender eine nahtlose Fortsetzung der Anwendungsnutzung zu ermöglichen. 29

30 <Literaturverzeichnis 9 Literaturverzeichnis Faatz, Andreas, und Manuel Goertz. Requirements for OPEN Service Platform. Deliverable, EU, Grosso, William. Java RMI: Chapter 10: Serialization. Herausgeber: O'Reilly (Zugriff am ). Institute for Pervasive Computing, ETH Zurich. Maven- Concierge OSGi - An optimized OSGi R3 implementation for mobile and embedded systems - Overview (Zugriff am ). Klus, Holger. Institut für Informatik: Studentische Arbeiten. Fortgeschrittenenprojekt Realisierung von Zustandserhaltung bei der Migration von OSGi-Bundles. TU Clausthal Dokumente/2009-FP-Herrling-Dirk-AS.pdf (Zugriff am ). Klus, Holger, Dirk Niebuhr, Björn Schindler, Michael Deynet, und Constanze Deiters. Solutions for Application Logic Reconfiguration Model View Controller. Wikipedia (Zugriff am ). OPEN Team. Open Pervasive Environments for migratory interactive services (Zugriff am ). Oracle. Serializeable (Java Platform SE 6) l (Zugriff am ). 30

31 <Literaturverzeichnis OSGi Alliance. OSGi Alliance Specifications (Zugriff am ). Paternò, Fabio. Human Interfaces in Information Systems Laboratory (Zugriff am ). The Eclipse Foundation. Eclipse Downloads (Zugriff am ).. Equinox (Zugriff am ). The Knopflerfish Project. Knopflerfish OSGi - open source OSGi service platform (Zugriff am ). Ullenboom, Christian. Galileo Computing :: Java ist auch eine Insel (8. Auflage) Eigenschaften von Java mj c6f6d07094fc3c0c33bf9fbe (Zugriff am ). Wikipedia. Pac-Man - Wikipedia (Zugriff am ). Wütherich, Gerd, Nils Hartmann, Bernd Kolb, und Matthias Lübken. Die OSGi Service Platform. Heidelberg: dpunkt.verlag GmbH, xpra - partiwm - Project Hosting on Google Code (Zugriff am ). 31

32 Abbildungsverzeichnis 10 Abbildungsverzeichnis Abbildung 1: Screenshot der OSGi Implementierung von Pac-Man... 4 Abbildung 2: OSGiBasedPacMan... 6 Abbildung 3: Das vollständige Lebenszyklusmodell eines Bundles (Wütherich, et al. 2008, 61)... 9 Abbildung 4: MigrationManager Software Abbildung 5: Die Activator-Klasse von Pac-Man Abbildung 6: Die Insel im Objektgeflecht rund um das Thread Objekt kann per Reflexion nicht gefunden werden Abbildung 7: Nur die Instanzen von C und B werden migriert Abbildung 8: Die Superklasse Migrateable Abbildung 9: Das MigrateableIf Interface Abbildung 10: Der Ablauf einer Migration Abbildung 11: Projekt in Eclipse Importieren Abbildung 12: Projekt in Eclipse Exportieren Abbildung 13: Zu exportierende Projekte auswählen Abbildung 14: PacMan starten Abbildung 15: MigrationManager im Überblick Abbildung 16: Struktur eines migrierbaren Bundles

33 Anhang 1 MigrationManager Einrichten 11 Anhang 1 MigrationManager Einrichten 11.1 Vorrausetzungen Java 6: Java 6 muss installiert sein. OSGi Framework: MigrationManager wurde entwickelt mit Eclipse Helios for RCP and RAP Developers (The Eclipse Foundation 2011). MigrationManager: Der Quellcode kann von wuala.com/contents/looking_eye/projects/fortgeschrittenenproje kt/fortgeschrittenenprojekt.zip?key=jpb98d5onhwo heruntergeladen werden. Das Archiv muss entpackt und die drei enthaltenen Projekte importiert werden. Abbildung 11: Projekt in Eclipse Importieren Bundle Jars: Um ein Bundle migrieren oder starten zu können, muss es als.jar-datei vorliegen. MigrationManager sucht diese Dateien im Stammverzeichnis des Benutzers. Unter Windows ist das typi- 33

34 Anhang 1 MigrationManager Einrichten scherweise C:\Users\<username>\migrationManager\bundles. Wenn es nicht existiert, wird es beim ersten Start angelegt. In jedem Fall müssen die jar-dateien erstellt und dorthin gespeichert werden. Hierzu müssen in Eclipse folgende Schritte durchgeführt werden: 1. Rechtsklick auf das zu exportierende Projekt und Export... anklicken. 2. Deployable plug-ins and fragments anwählen und weiter mit Next >. Abbildung 12: Projekt in Eclipse Exportieren 3. In der folgenden Maske müssen alle Projekte, die exportiert werden sollen (mindestens PdaRepresentatorService und OSGiBasedPacMan) angehakt werden (siehe Abbildung 13: Zu exportierende Projekte auswählen). Im Reiter Destination muss Directory ausgewählt, und der Pfad, in den die Bundles exportiert werden sollen, einge- 34

35 Anhang 1 MigrationManager Einrichten tragen werden. Eclipse wird dort, in einem Unterordner plugins, die exportierten Bundles ablegen. Abbildung 13: Zu exportierende Projekte auswählen 4. Die exportierten Plugins müssen aus dem Unterverzeichnis bundles/plugins der MigrationManager Installation in das Unterverzeichnis bundles kopiert werden. Alle Vorbereitungen sind abgeschlossen und MigrationManager kann gestartet werden MigrationManager starten Im importierten MigrationManager Projekt befinden sich drei Run- Configurations: Run Configuration MigrationManager.launch Startende Bundles MigrationManager MigrationManagerWithPDARepresentor.launch MigrationManager, PdaRepresentatorService 35

36 Anhang 1 MigrationManager Einrichten PacMan.launch OSGiBasedPacMan, PdaRepresentatorService, MigrationManager Über das Kontextmenü einer.launch Datei kann eine Run Configuration gestartet werden. Um zu testen ob alles soweit funktioniert, bietet es sich an PacMan.launch zu starten. Abbildung 14: PacMan starten Nach einiger Zeit sollten sich PacMan und MigrationManager öffnen. 36

37 Anhang 2 Migration Manager verwenden 12 Anhang 2 Migration Manager verwenden Abbildung 15: MigrationManager im Überblick 12.1 Einleitung MigrationManager wird durch sämtliche Run Configurations gestartet. Für die folgenden Punkte empfiehlt sich die MigrationManager.launch Konfiguration. Wie sie gestartet wird kann in 11.2 nachgelesen werden. Nachdem MigrationManager gestartet wurde öffnet sich die Ansicht aus Abbildung 15: MigrationManager im Überblick. In der Liste (1) sind sämtliche, dem MigrationManager bekannten, Bundles aufgeführt. Die Liste setzt sich zusammen aus den Bundles, die als.jar Dateien auf der Festplatte vorhanden sind (in den drei Spalten Installed?, Running?, Migrateable? ist kein Haken gesetzt) und den im Arbeitsspeicher vorhandenen (mindestens in der Spalte Installed? ist ein Haken gesetzt; ein Beispiel ist immer org.eclipse.osgi). Die verschiedenen Lebenszykluszustände der OSGi-Bundles werden, reduziert, durch die Haken in den Spalten der Tabelle repräsentiert Bundles installieren, starten und beenden Ein Bundle, das auf der Festplatte liegt, kann durch Install Bundle (2) in das Framework installiert werden. Danach erscheint in der Tabelle ein neuer Eintrag für die Repräsentation des Bundles im Arbeitsspeicher. Falls ein Bundle ausgewählt ist, das bereits installiert ist, ändert sich die Be- 37

38 Anhang 2 Migration Manager verwenden schriftung in Uninstall Bundle und es wird aus dem Framework entfernt. Da MigrationManager über kein Abhängigkeitsmanagement zwischen Bundles verfügt, muss der Benutzer sicherstellen, dass alle Abhängigkeiten erfüllt sind. Bei OSGiBasedPacMan betrifft das konkret die Bundles MigrationManager und PdaRepresentatorService, die installiert sein müssen. Run Bundle (3) überführt das ausgewählte Bundle in den Zustand Running. Falls das Bundle bereits läuft, ist die Beschriftung Stop Bundle und das Bundle wird angehalten Bundles migrieren Um ein Bundle zu migrieren, müssen Target IP Address und Target Port Number (12) ausgefüllt sein. IP Adresse und Port werden auf der Seite des Bundle Empfängers in den Feldern Source IP Address und Source Port Number (11) angezeigt. Wenn alle Daten eingetragen sind, kann ein in der Tabelle als Migrateable markiertes Bundle durch Migrate Bundle (4) migriert werden. Es wird dann auf die Zielplattform übertragen und dort mit seinem aktuellen Zustand gestartet Zustand laden und speichern Der Zustand eines Bundles kann lokal gespeichert werden. Dadurch wird es zum Beispiel bei Pac-Man möglich, einen Spielstand zu speichern. Save Bundle state to disk (6) und Load Bundle state from disk (7) dienen dem Speichern und Laden des Zustands des selektierten Bundles Sonstiges Falls der Computer über mehrere IP Adressen verfügt gibt Show IPs (10) eine Liste aller bekannten IP Adressen aus. Refresh Table (9) aktualisiert die Liste der installierten Bundles, falls es zu Darstellungsfehlern kommt. Mit Exit (8) kann MigrationManager beendet werden. In diesem Fall wird das Framework ebenfalls angehalten, sämtliche Bundles gestoppt und deinstalliert. 38

39 Anhang 3 Richtlinien zur Erstellung migrierbarer Bundles 13 Anhang 3 Richtlinien zur Erstellung migrierbarer Bundles Ein Bundle hat eine Activator-Klasse, die BundleActivator implementiert. Da eine Migration in der Regel von der Activator-Klasse ausgeht, muss diese Serializeable implementieren. Das ist nicht zwingend erforderlich, aber häufig der Fall weil in dieser Klasse die start() und stop() Methoden des Bundles liegen. Alles was hier für die Activator-Klasse steht gilt gleichermaßen für eine beliebige, andere Klasse, falls sich der Komponentenentwickler entschließt diese als Ausgangspunkt für die Migration zu verwenden. Damit die Activator-Klasse serialisierbar ist, müssen alle von ihr referenzierten Klassen ebenfalls serialisierbar sein (also entweder von Serializeable erben oder primitiv sein) oder als transient markiert sein. Ein einfaches Beispiel ist in Abbildung 16 zu sehen. Abbildung 16: Struktur eines migrierbaren Bundles In diesem Beispiel wird nach der Migration der Zustand der Instanz von A erhalten bleiben, während der Zustand der Instanz von B verloren geht. 39

40 Anhang 3 Richtlinien zur Erstellung migrierbarer Bundles Die Instanz von B auf der Zielplattform wird nach der Migration unverändert sein. Das gleiche Verhalten wäre auch erreicht worden, wenn Serializeable von B implementiert, aber nicht annotiert würde. Im Konstruktor der Activator-Klasse muss sie makemigrateable( ) auf ihrer Superklasse Migrateable aufrufen, damit das Bundle als migrierbar bei der ServiceRegistry registriert wird. MigrationManager wertet diese Informationen aus und erkennt so die migrierbaren Bundles. Um die Migration von Bundles zu erleichtern empfiehlt es sich auf ein Entwurfsmuster zurück zu greifen, das die Darstellung und Verarbeitung der Information von Ihrer Verwaltung trennt (zum Beispiel (Model View Controller 2010) (im Folgenden MVC). Bei einer so gewählten Architektur kann die Implementierung des Modells von der Acitvator Klasse gut referenziert und annotiert werden. Im Fall von MVC würde die Klassen, die das Modell darstellen annotiert werden, während die Präsentation und die Steuerung keine, für den Zustand des Bundles relevanten, Daten enthielten und daher auch nicht migriert werden müssten. Bei der Konzeption und Implementierung von migrierbaren Bundles muss verhindert werden, dass Threads entstehen, die Referenzen auf Daten enthalten, die nirgendwo sonst referenziert werden. Daten die nur von Klassen, die von Thread erben, referenziert werden, können nicht migriert werden, da die Java Klasse Thread nicht serialisierbar ist. Ihr Zustand geht bei der Migration verloren. Abhilfe schafft die Auslagerung der Daten in ein Datenmodell auf das der Thread zugreift. Bei Bedarf kann der Ausführungszustand des Threads ebenfalls in diesem abgelegt und nach der Migration wiederhergestellt werden. Eine Alternative ist der Transport der relevanten Daten in einem eigens dafür angelegten, serialisierbaren Datenmodell, das durch die Methoden beforestateretrieval() und aftersetstate() geschrieben und gelesen wird. 40