Dynamische Adaption in heterogenen verteilten eingebetteten ...

4.1 Aufgaben und Dienste der Basisschicht
In einem Betriebssystem können Dienste, welche nur relativ selten verwendet werden, wie zum
Beispiel das Starten von neuen Anwendungen oder das Bereitstellen von neuen Aktivitätsträgern,
geparkt werden, wenn sie in absehbarer Zeit nicht genutzt werden.
4.1.3 Ersetzen von Modulen
Beim Ersetzen von Modulen soll ein Modul durch ein anderes Modul ausgetauscht werden. Mit
diesem Mechanismus ist es beispielsweise möglich, ein fehlerhaftes Modul durch eine neue, korrigierte
Version zu ersetzen. Das neue Modul muss dazu schnittstellenkompatibel mit dem alten Modul sein.
Üblicherweise ist auch die Funktionalität der Module gleich. Man kann diesen Mechanismus aber auch
dazu nutzen, zwischen verschiedenen Modulen umzuschalten, welche dieselbe Aufgabe erledigen,
jedoch auf unterschiedliche Art und Weisen und unter unterschiedlichen Rahmenbedingungen. In
Abschnitt 5.4 werden solche Szenarios am Beispiel einer Java-Umgebung vorgestellt.
Das Austauschen von Modulen basiert auf denselben Mechanismen wie das Parken und Installieren.
Das aktuelle Modul wird vom verwalteten Gerät entfernt, anschließend wird die neue Version installiert.
Da sich die Arbeitsweise des Moduls verändert haben kann, muss neben dem Austauschen des
Programmcodes möglicherweise auch eine Anpassung des Zustands erfolgen. Zu diesem Zweck wird
mit dem Entfernen des alten Moduls auch der dazugehörende Zustand gesichert. Vor dem Installieren
des neuen Moduls muss die Möglichkeit einer Zustandskonvertierung bestehen. Diese Konvertierung
ist modulspezifisch und hängt unter anderem von der Version des alten Moduls als auch von der des
neuen Moduls ab. Der Auftraggeber des Austausches, üblicherweise die Kontrollschicht, muss daher
eine Konvertierungsfunktion zur Verfügung stellen. Der angepasste Zustand wird dann mit dem neuen
Modul in den Knoten integriert.
4.1.4 Module als entfernten Dienst auslagern
Die bisher vorgestellten Verwaltungsoperationen dienten hauptsächlich dazu, die Softwarekonfiguration
eines verwalteten Knotens zu erstellen und zu verändern. Der Verwalter kann aber auch aktiv in die
Ausführung der Aufgaben mit einbezogen werden, indem Teile der Anwendung von ihm ausgeführt
werden. Zu diesem Zweck können Module vom verwalteten Knoten entfernt werden, um sie stattdessen
auf dem Verwalterknoten zu installieren. So ist es möglich, die Ressourcen des Verwalterknotens für
den verwalteten Knoten zu nutzen. Auf einem verwalteten Knoten können dadurch Anwendungen
ausgeführt werden, für welche die tatsächlich vorhandenen Ressourcen des Knotens nicht ausreichen
würden.
Dies ist beispielsweise notwendig, falls die Software durch Weiterentwicklung mit der Zeit anwächst
und nicht mehr vollständig von dem verwalteten Knoten ausgeführt werden kann. Anstatt Funktionen
komplett zu entfernen, können sie durch Auslagern dennoch genutzt werden.
Ein anderes Szenario stellt die Nutzung einer Laufzeitumgebung dar, mit deren Hilfe kleine Knoten
auf einem höheren Abstraktionsniveau dargestellt werden. Durch den Einsatz einer etablierten
Laufzeitumgebung könnte man eine große Vereinheitlichung verschiedener Knoten erreichen. Diese
Umgebungen sind jedoch ursprünglich für leistungsstärkere Knoten entwickelt worden (siehe Abschnitt
5.3.2). Das Auslagern von selten benötigten Funktionen ist eine Möglichkeit, eine solche
Laufzeitumgebung auf jedem kleinen Knoten zur Verfügung zu stellen. Somit steht die komplette
Laufzeitunterstützung der Umgebung zur Verfügung und kleine Knoten können theoretisch genauso
programmiert werden wie große Knoten.
Das Verwenden eines Moduls als entfernter Dienst wird durch einen Fernaufruf realisiert. Anstelle
des Moduls wird ein Stellvertreter in die Anwendung integriert. Hierzu wird der Mechanismus des
33