Dynamische Adaption in heterogenen verteilten eingebetteten ...

5 Kontroll- und Verwaltungsschicht
Ein System auf Basis dieses Ansatzes ist SUNs ursprüngliches EmbeddedJava. Es wurde jedoch
durch J2ME ersetzt und wird heute nicht mehr von SUN unterstützt 3 . Die Anwendung wird hierbei
gegen das JDK 1.1.7 entwickelt. Anschließend wird analysiert, welche Klassen und Felder von der
Anwendung benutzt werden (JavaFilter), um daraufhin die Klassenbibliothek auf den benötigten
Umfang zu reduzieren (JavaCodeCompact). Dabei werden die Klassen vorab geladen, das heißt, die
Datenstrukturen zur Verwaltung der Klassen werden erstellt und in C-Code ausgegeben. Anschließend
können die Dateien übersetzt und zusammen mit Unterstützungsbibliotheken und einem Betriebssystem
zu einem Speicherabbild für den Mikrocontroller gebunden werden.
Ein anderes Beispiel ist der VM-Baukasten VM* [KP05b]. Hier liegt die JVM in Komponenten vor,
aus denen, nach der Analyse der Anwendung, eine optimale Auswahl getroffen wird.
Als letztes Beispiel ist KESO zu nennen [WSSP07]. Bei KESO wird der Java-Bytecode in C-Code
übersetzt und dieser dann mit einer konfigurierbaren Betriebssystembibliothek (zum Beispiel OSEK)
zusammengebunden. Im Rahmen des Übersetzens wird die Anwendung analysiert und anwendungsspezifisch
um Code erweitert, der die Eigenschaften der JVM herstellt. So werden beispielsweise
Typprüfungen und Überprüfungen von Feldgrenzen direkt in den entstehenden Code eingefügt. Außerdem
werden die Verwaltungsstrukturen anwendungsspezifisch erzeugt, wie beispielsweise eine
optimale Repräsentation der Typhierarchie.
Vorteil des anwendungsspezifischen Anpassens ist, dass keine unnötigen Dienste angeboten werden.
Durch die Optimierung kann Speicherplatz eingespart werden, ohne die Anwendung zu beschränken.
Zu beachten ist allerdings, dass bei diesem Ansatz die dynamischen Eigenschaften der JVM verloren
gehen. Im Speziellen wird das dynamische Nachladen von Klassen nicht unterstützt, da neue Klassen
Dienste benötigen könnten, die durch die anwendungsspezifische Anpassung entfernt wurden. Für
Anwendungen, die auf solche dynamischen Eigenschaften angewiesen sind, kann somit dieser Ansatz
nicht eingesetzt werden.
5.3.3 Dynamisch anwendungsspezifisch angepasste Laufzeitumgebung
Die beiden vorgestellten Ansätze, eine Java-VM auf einem kleinen Knoten zur Verfügung zu stellen, haben
beide den Nachteil, dass die angebotene Funktionalität eingeschränkt und von Anfang an festgelegt
ist. Mithilfe eines Verwalters kann man auf die vorgestellten Ansätze aufbauen, ihre Vorteile nutzen und
gleichzeitig durch dynamische Adaption den vollen Funktionsumfang einer JVM zur Verfügung stellen.
Man verfolgt denselben grundsätzlichen Ansatz einer anwendungsspezifischen Laufzeitumgebung,
ist jedoch nicht auf die einmalige Anpassung beschränkt, sondern kann sie wiederholen, falls es zur
Laufzeit notwendig wird. Man erhält eine dynamisch der Anwendung angepasste JVM, die Dienste
nachträglich in die Laufzeitumgebung integriert, sobald sie benötigt werden. Zusätzlich kann man
optimierte Varianten der Dienste verwenden, die dynamisch gewechselt werden, sobald sie nicht mehr
den Anforderungen genügen. Die eingesparten Ressourcen können der Anwendung zur Verfügung
gestellt werden.
Da das Hinzufügen von Diensten und das Ersetzen von speziellen Varianten durch allgemeinere
zu einem höheren Speicherbedarf führt, kann ein Punkt erreicht werden, an dem der Speicher nicht
mehr ausreicht, um alle benötigten Dienste gleichzeitig lokal zur Verfügung zu stellen. Dann kann der
Verwalter Komponenten parken oder als entfernten Dienst anbieten.
3 Die Bezeichnung EmbeddedJava wird heute von SUN für andere Produkte verwendet. Informationen über das ursprüngliche
EmbeddedJava finden sich kaum noch. Eine Übersichtsseite ist jedoch noch im Internetarchiv “Wayback
Machine” enthalten: http://web.archive.org/web/20040813044332/http://java.sun.com/
products/embeddedjava/overview.html
106