Basisdienste

    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.