Wie schon im Überblick angedeutet, reguliert der Roblet®-Server den Zugriff auf Ressourcen und stellt darüber hinaus eine Laufzeitumgebung für Roblets® bereit. Die Ressourcen werden vom Server jedoch nicht direkt betreut. Diese Aufgabe haben Module.
Im Prinzip ist ein Modul eine Java™-Klasse, die die Schnittstelle genRob.genControl.modules.Module2 implementiert. Damit der Server eine Modul-Klasse verwendet, muß ihr Name bei seiner Ausführung als Argument übergeben werden und die Klasse über den Klassenpfad auffindbar sein.
Modul initialisieren
Der Konstruktor einer Modul-Klasse sollte wenig oder nichts machen, um eine störungsfreie Initialisierungsphase zu ermöglichen und in vielen Fällen dadurch auch die Fehlersuche zu vereinfachen. Die eigentliche Initialisierung eines Moduls erfolgt hingegen in der zu implementierenden Methode genRob.genControl.modules.Module2.moduleInit(...).
Der Server ruft moduleInit nur einmal nach dem Laden der Modul-Klasse auf. An dieser Stelle kann ein Modul z.B. persistente Daten vom letzten Lauf laden oder einmalig notwendige Untersuchungen des unterliegenden Systems vornehmen. Dabei sind zeitlich grundsätzlich keine Grenzen gesetzt. Log-Ausgaben sind möglicherweise bei längeren Arbeiten sinnvoll. Der Server wartet, bis die Initialisierung abgeschlossen ist.
Die Methode moduleInit wird durch einen Thread aufgerufen, der im offenen Sicherheitsbereich des Servers läuft. Das bedeutet, daß standardmäßig sämtlicher Code eines Moduls inkl. all seiner Klassen unbeschränkten Zugriff auf die Klassen- und Laufzeitbibliothek des Java™-Systems (Java™-Bibliothek) hat. Administratoren, die mit eigenen Sicherheitsrichtlinien arbeiten, müssen gegebenenfalls für die jeweiligen Module "Löcher" ermöglichen.
moduleInit bekommt als Parameter einen Modul-Kontext. Der Modul-Kontext ist eine Instanz von genRob.genControl.modules.ModuleContext und dient zum Zugriff auf gewisse Teile des Servers insbesondere den genRob.genControl.modules.Logger.
Läuft ein Modul während der Initialisierung auf einen Fehler, der seine Funktion verhindert, so ist es üblich, eine Ausnahme zu werfen. In diesem Falle wird der Server das betreffende Modul nicht weiter verwenden.
Modul aufräumen
Will der Server enden, so beendet er zunächst alle Roblets® und ruft danach für jedes Modul einmal die Methode genRob.genControl.modules.Module2.moduleDone(...) auf. Dadurch hat jedes Modul die Möglichkeit, abschließende Aufgaben zu erledigen. Dabei können z.B. Daten für den nächsten Lauf persistent gemacht werden, Datei- und Netzwerk-Verbindungen geschlossen werden u.v.a.m.
Im wesentlichen gelten für diese Methode die gleichen Bemerkungen, wie für moduleInit. Der zentrale Unterschied ist jedoch, daß keine Ausnahmen geworfen werden dürfen, um sicherzustellen, daß der Server alle Module aufräumen kann. Hier sind dann nur Log-Ausgaben erlaubt.
Einheiten bereitstellen
Ein Modul kann eine beliebige Anzahl von Einheiten umfassen und die Einheiten können beliebig definiert werden. Meist bestimmen entwicklungsrelevante Bedingungen, wie z.B. die Funktionalität einer Hardware, die Grenzen einer Einheit und ihre Anzahl.
Die Methode genRob.genControl.modules.Module2.getUnit(...) ermöglicht dem Server, die Anfrage eines Roblets® auf Herausgabe einer Instanz einer Einheiten-Implementierung einer bestimmten Einheiten-Definition zu beantworten. Dabei ist zu beachten, daß die Laufzeitumgebung des Servers die parallele, gleichzeitige Ausführung von mehreren Roblets® erlaubt, weshalb pro Roblet® eine eigene Einheiten-Instanzen herausgegeben werden muß. Konflikte, die bei der gemeinsamen Nutzung einer Ressource auftreten, müssen durch das Modul aufgelöst werden. Nachfolgend sind weitere Bedingungen für die Implementierung von Einheiten genannt.
Die Einheiten-Definition wird der Methode getUnit4Slot als Instanz vom Typ java.lang.Class übergeben. Es handelt sich um genau die Klasse, die ein Roblet® übergibt. Von einer beliebigen Einheiten-Definition ist die Klasse immer über "Einheiten-Definitions-Name.class" erhältlich. Über einen entsprechenden Vergleich (==) mit den vom jeweiligen Modul betreuten Einheiten-Definitionen kann der Wunsch eines Roblets® aufgelöst werden.
Der zweite übergebene Parameter ist ein Roblet®-Repräsentant vom Typ genRob.genControl.modules.RobletHandle. Diese Instanz repräsentiert das Roblets® für das Modul und ist pro Roblet® eindeutig. Damit kann das Modul die einzelnen Roblets® unterscheiden und über dabei vorhandene Methoden auch Daten einem Roblet® zuordnen. Der Roblet®-Repräsentant ermöglicht darüberhinaus den Zugriff auf die Laufzeitumgebung des jeweiligen Roblets®.
public Unit getUnit (Class clazz, RobletHandle handle)
{
if (clazz == HelloUnit.class)
// Es wird in diesem Fall bei jedem Aufruf
// eine neue Instanz erzeugt.
return new HelloUnitImpl ();
// Ansonsten: Einheit nicht hier implementiert.
return null;
}
Weitere Funktionalität
Die API-Dokumentation für Module gibt einen genaueren Einblick und Hinweise.
