Next: Class-Loader
Up: Dienste
Previous: Dienste
Die Basisdienste stellen die Grundvoraussetzung für die
Implementierung eines lauffähigen Agenten oder Managers dar. Es wird
keine eigenständige Basisklasse zur Verfügung gestellt, sondern eine
Reihe von eigenständigen Klassen, welche als Summe die Basisdienste
darstellen. Dies hat den Vorteil, daß diese Einzelkomponenten später
leichter ersetzt, angepaßt oder erweitert werden können. Die
Basisdienste werden nachfolgend aufgeführt:
- Initialisierung des Core Management Framework
Jeder Agent, welcher unter JDMK entwickelt wird, muß als Grundlage
eine Instanz des Core Management Framework besitzen. In diesem
Rahmen werden alle M-Beans des Agenten integriert. Die
Instantiierung kann auf drei verschiedene Arten erfolgen:
- Standard-Konstruktor ohne weitere Argumente.
- Konstruktor unter Angabe der Domäne, in welcher der Agent aktiv
sein wird.
- Konstruktor mit Angabe der Domäne und einem spezifischen
Repository Service. Diese Variante wird bei persistenter
Speicherung der M-Beans verwendet.
- Der Repository Service
Dieser Dienst dient dazu, die M-Beans im CMF zu registrieren. Diese
Beans werden mit dem Objektnamen als Java-Objekte gespeichert. Sind
die Beans erst registriert, so kann auf sie über den Objektnamen
entsprechend ihrer Properties zugegriffen werden. Es ist nur eine
Instanz eines Repository Service pro JDMK-Agent möglich, d.h. auch
die Art und Weise wie der Agent seine M-Beans behandelt ist auf eine
Richtung festgelegt. Es werden drei Arten des Repository Service
unterschieden:
- Speicherung der M-Beans im Arbeitsspeicher (Volatile Repository)
Dies ist die einfachste Form des Repository Services. Die M-Beans,
welche in diesem Repository registriert werden, existieren nur zur
Laufzeit des Agenten. Falls der Prozeß des Agenten beendet wird,
sind auch die M-Beans und deren aktueller Zustand verloren.
- Dauerhafte Speicherung der M-Beans und deren derzeitigen
Zustand.
(Persistent Repository)
Abhilfe der temporären Lösung des Volatile Repository bietet das
Persistent Repository. Wie der Begriff der Persistenz bereits
aussagt, können hier die M-Beans und deren Zustand bei Beendigung
des Agenten gesichert werden, um bei einem erneuten Anlauf wieder
zur Verfügung zu stehen. Die Speicherung der M-Beans und deren
aktueller Zustand geschieht durch Serialisierung als Java Objekt in
eine Datei. Für jedes M-Bean werden drei Elemente gespeichert:
- Der eindeutige Objektbezeichner des M-Bean.
- Das serialisierte M-Bean (Java Objekt).
- Der Bezeichner des ClassLoaders, welcher das jeweilige M-Bean
geladen hatte. Da es möglich ist, mehrere ClassLoader zu verwenden
um auf unterschiedlich lokalisierte Klassen zuzugreifen, ist es bei
der Deserialisierung erforderlich, den richtigen ClassLoader,
welcher sich auf den entsprechenden ClassServer bezieht, zu
ermitteln.
Um den persistenten Repository Service zu verwenden muß zum einen eine
Instanz der FullPersistentRepSrv
Klasse geschaffen werden.
Danach ist eine Konfiguration notwendig, welche beinhaltet, daß das
Verzeichnis
und der Bezeichner der Speicherungsdatei angegeben wird.
Die Serialisierung eines M-Bean setzt voraus, daß das M-Bean
- das Interface
java.io.Serializable
oder
java.io.Externalizable
implementiert,
- Zugriff auf den Standard-Konstruktor der ersten nicht
serialisierbaren Superklasse besitzt und
- alle Elemente des M-Bean, welche nicht serialisiert
werden sollen, den
transient
Kennzeichner besitzen.
Die Deserialisierung eines M-Bean setzt, wie vorher erwähnt, voraus,
daß der Class Loader, welcher für das M-Bean zuständig ist, auf dem
Rechner existiert. Zudem muß er eine Methode getObjectName
unterstützen, um den Objektbezeichner des M-Bean interpretieren zu
können.\
- Mischung zwischen dauerhafter und ``flüchtiger'' Speicherung der
M-Beans
(Mixed Repository)
Es ist ebenso möglich, eine M-Bean bzw. seine Komponenten
unterschiedlich zu behandeln. An dieser Stelle kommt der oben
beschriebene transient
Kennzeichner zu tragen.
- Der Metadata Service
Der Metadata-Service wird benötigt, um die Eigenschaften und
Methoden eines M-Bean im CMF verwenden zu können. Der Service wird
unter JDMK mit der Klasse
com.sun.jaw.reference.agent.services.MetaDataSrv
zur
Verfügung gestellt. Diese Klasse basiert auf der Reflection API des
JDK und implementiert das
com.sun.jaw.reference.agent.services.MetaDataSrvIf
Interface.
Es gibt zwei Möglichkeiten, einen eigenen Metadata Service zu
implementieren:
- Verwendung einer
set
-Methode innerhalb des CMF.
Dies hat den Nachteil, daß externe Applikationen wie Manager und
andere Agenten keinen Zugriff auf diesen Service bekommen können.
Zudem kann er nur nicht persistent gespeichert werden.
- Instantiierung und Registrierung eines neuen Metadata-Service Objekts.
Damit wird der vorhergehende Metadata-Service ersetzt. Es muß ein
eindeutiger Bezeichner bestimmt werden. Der Vorteil eines eigenen Metadata-Service
besteht darin, daß für Applikationen, welche über die Reflection API auf den Agenten
zugreifen und damit seine Struktur analysieren können, nur ein vom Entwickler
gewünschter Teilbereich der Gesamtfunktionalität des Agenten bekannt gemacht
werden kann.
- Der Filtering-Service
Dieser Dienst ermöglicht es Applikationen auf spezifische M-Beans
zuzugreifen. Es kann eine Auswahl über die Wertebereiche von
Properties der M-Beans erfolgen.
Next: Class-Loader
Up: Dienste
Previous: Dienste
Beispielbenutzer SuSE Linux 6.0
Sun May 9 21:16:36 MEST 1999