6.1 Agent Objects und die Agent Object Factory

 Bei Agent Objects handelt es sich um RMI Remote Objects. Die Managed Objects auf dem MO-Server kommunizieren tatsächlich mit Client Stubs, die dann mit Hilfe der Server Skeletons die eigentliche Kommunikation zwischen den MOs und den Agent Objects abwickeln. Gewöhnliche RMI Remote Objects haben die Eigenschaft, vom Garbage-Collection-Mechanismus der Java VM entfernt zu werden, sobald keine Referenzen von Client-Seite mehr auf das Objekt verweisen. Um die Möglichkeit von long running agents zu schaffen, die dieser Einschränkung nicht unterliegen, sieht JMAPI die Verwendung sog. named agent objects vor.

Zur Erzeugung neuer Agent-Object-Instanzen bedient sich ein MO der Agent Object Factory. Hierbei handelt es sich, analog zur MO Factory auf dem MO Server, um einen Prozeß, der beim Hochfahren des JMAPI-Systems auf den jeweiligen Appliances gestartet wird. Die Agent Object Factory bietet die Methoden newAgentObj und newNamedAgentObj für das Anlegen entsprechender Agent-Object-Instanzen an.

Im allgemeinen wird es nicht immer möglich sein, sämtliche auf den Agenten durchzuführenden Operationen vollständig in Java zu implementieren. Mittels des Java Native Interface (JNI) können jedoch einzelne Methoden der Agent Objects als native methods in einer anderen Programmiersprache implementiert werden. Der entsprechende Code wird in Shared Libraries zusammengefaßt, die dann vom Agent Object mittels des im folgenden erläuterten Library Loaders bei Bedarf geladen und auf dem Agenten gespeichert werden (siehe Abbildung 6.1). Durch Verwendung von native methods wird allerdings in den sonst plattformunabhängigen Code des Java-Agenten eine Abhängigkeit von Hardware- und Betriebssystemgegebenheiten induziert. Um dennoch die Möglichkeit zu haben, plattformunabhängige Agenten einzusetzen, stellt das JMAPI Native Library Loading Interface einen Mechanismus zur Verfügung, der das automatische Laden der richtigen Bibliothek vom Managed Object Server ermöglicht (vgl. [Sun97c], [Sun97g]). Bei der Konfiguration des Agenten mit Hilfe der JMAPI-Properties-Datei (vgl. Abschnitt 9.1 und Anhang D) wird das Verzeichnis auf dem Server angegeben, von dem aus Bibliotheken für den jeweiligen Agenten zu laden sind. Hierdurch können Betriebssystemversion und Hardware-Architektur des Agenten berücksichtigt werden. Wie bereits erwähnt, werden vom Server geladene Bibliotheken auf dem Agenten für evtl. weitere Verwendung lokal gespeichert. Um sicherzustellen, daß die vom Agenten gecachete Bibliotheksversion auch der aktuellsten Version auf dem Server entspricht, werden vom JMAPI Native Library Loading Interface intern Versionsnummern verwaltet.

  

Abbildung 6.1: Agent Object Factory und Benutzung des JNI

Der Ladevorgang läuft im einzelnen wie folgt ab ([Sun97g], [Sun97c]):

1.

Das Agent Object fordert mittels Aufrufs der statischen Methode loadLibrary der Klasse sunw.arm.agents.LibraryLoader eine Bibliothek an.

2.

Zunächst wird überprüft, ob die Bibliothek auf dem Appliance bereits vorliegt. Ist dies der Fall, wird mit Hilfe der lokal und auf dem MO Server verwalteten Versionsnummern festgestellt, ob die Version, die lokal vorliegt mit der aktuellsten Version auf dem Server übereinstimmt.

3.

Ist die lokal vorhandene Version veraltet, oder ist die Bibliothek noch nicht vorhanden, wird die aktuellste Version vom Server geladen.

Bei der Installation einer neuer Bibliotheksversion auf dem Server wird die dort verwaltete aktuellste Versionsnummer entsprechend angepaßt.

Mit dem oben beschriebenen Mechanismus wird sichergestellt, daß die Agenten immer über die jeweils neueste Version verfügen. Ein Versions-Update ist nur auf dem Server vorzunehmen. Die Agenten ziehen die notwendigen Änderungen automatisch nach.