5.1 Das JMAPI Event Model

Das JMAPI Event Model kennt drei verschiedene Rollen: Event Producer erzeugen Events und senden sie in Form von Event Messages an Event Dispatcher, welche die Verteilung an die interessierten Event Consumer übernehmen. Events können sowohl vom JMAPI System selbst ausgelöst (wie z. B. ein SHUTDOWN Event des Managed Object Servers), als auch durch Methoden von MOs und Agenten, generiert werden. Vom JMAPI System erzeugte Events werden auch als Notifications bezeichnet.

Ein Charakteristikum dieser Kommunikation ist es, daß mehrere Komponenten an einem Event interessiert sein können. Die Kommunikation ist also von der Form 1:n, im Gegensatz zur Remote Method Invocation, wo jeweils ein Client mit einem Server in synchroner Weise kommuniziert.

Die Entkopplung der Kommunikation von Event Producern und Event Consumern erfolgt mittels der Event Dispatcher. Jeder von einem Producer erzeugte Event wird an einen Event Dispatcher gesandt. Andererseits muß sich jeder Event Consumer, der Events empfangen möchte, bei mindestens einem Event Dispatcher registrieren. Trifft ein Event bei einem Event Dispatcher ein, so übernimmt dieser die Benachrichtigung aller bei ihm registrierten Event Consumer. Der Event Producer braucht sich somit nicht um die Verwaltung aller interessierten Event Consumer zu kümmern, da diese Aufgabe vom Event Dispatcher übernommen wird.

Um nicht eine Unzahl von Nachrichten zu erzeugen, an denen die Consumer u.U. gar nicht interessiert sind und die von diesen dann erst aussortiert werden müßten, bedient sich JMAPI zum einen der Strukturierung von Events mittels Event Trees, zum anderen kommen spezielle Filter zum Einsatz.

Jedem JMAPI Event wird bei seiner Erzeugung ein Knoten in einem konzeptionellen Baum, dem Event Tree, zugewiesen, der alle Events einer Baumstruktur eingliedert. Ein Beispiel eines solchen Event Trees ist in Abbildung 5.1 dargestellt.

  

Abbildung: Beispiel für einen Event Tree

Jeder Knoten in diesem Baum wird mit einer Zeichenkette bezeichnet. Der Wurzel des Baums ist der String * zugeordnet. Jeder andere Knoten erhält einen beliebigen String zugewiesen, der allerdings für alle Nachfolgeknoten eines gegebenen Knotens eindeutig sein muß. Die eindeutige Identifikation eines Knotens im gesamten Baum kann nun durch die Angabe des Pfades von der Wurzel zum Knoten erfolgen, wobei die den Pfadknoten zugeordneten Strings konkateniert und durch ,,.`` voneinander getrennt werden. Der Baum in Abbildung 5.1 besteht demnach aus den Knoten *, *.foo, *.JMAPI, *.foo.bar, *.foo.x und *.foo.bar.y.

Der Event Tree gestattet die Strukturierung benutzerdefinierter Events auf der einen Seite und der vom JMAPI System automatisch generierten Notifications auf der anderen Seite. Der Unterbaum mit Wurzelknoten *.foo ist ein Beispiel für einen Teilbaum, der der Strukturierung benutzerdefinierter Ereignisse dienen soll. Die Bezeichnung der Knoten ist frei wählbar.

Die von JMAPI erzeugten Notifications werden im Unterbaum *.JMAPI verwaltet (vgl. Abbildung 5.2), und sind dort vorgegebenen standardisierten Knoten zugeordnet.

  

Abbildung: Unterbaum für JMAPI Notifications

Notifications werden u.a. beim Eintreten folgender Ereignisse erzeugt:

• Eine MO Instanz wurde neu angelegt.
• Eine MO Instanz wurde gelöscht.
• Die Attributwerte eines MO wurden verändert.
• Der Managed Object Server wird heruntergefahren (SHUTDOWN).
• Ein Event konnte dem Event Dispatcher nicht zugestellt werden, weil die Anzahl der Retry Attempts überschritten wurde (siehe hierzu die Erläuterungen weiter unten).

Ferner gibt es einen Heartbeat, der standardmäßig alle 60 Sekunden vom Managed Object Server erzeugt wird. Er kann z. B. eingesetzt werden, um festzustellen, ob der Managed Object Server noch läuft.

Als Beispiel für einen Strukturierungsknoten für JMAPI Notifications sei der String *.JMAPI.system.SHUTDOWN aufgeführt, der den Knoten beschreibt, dem Notifications zugeordnet sind, die einen SHUTDOWN des Servers signalisieren.

In gleicher Weise wie jeder JMAPI Event einem Knoten im Event Tree zugeordnet wird, geben Event Consumer zum Zeitpunkt der Registrierung bei einem Event Dispatcher einen Knoten im Baum an. Dies deutet ein Interesse an allen Events an, die beim entsprechenden Event Dispatcher eintreffen und dem betreffenden Knoten oder einem direkten oder indirekten Nachfahren des Knotens im Baum zugeordnet sind. Registriert sich ein Consumer beispielsweise am Knoten *.JMAPI, so bekundet er damit auch sein Interesse an *.JMAPI.system.SHUTDOWN Ereignissen.

Kann durch die baumartige Strukturierung der Events im Zusammenhang mit der Registrierung an bestimmten Knoten bereits eine Reihe von uninteressanten Events ausgesondert werden, bietet der Einsatz von Filtern eine zusätzliche Möglichkeit, den Netzverkehr zu reduzieren.

Neben der Angabe eines Knotens im Event Tree gibt jeder Event Consumer auch ein Filter-Objekt an. Hierbei handelt es sich um ein Objekt mit einer evaluate-Methode, die nach der Auswertung des Events einen Wahrheitswert zurückliefert. Aufgrund dieses Ergebnisses wird dann der Event entweder als uninteressant verworfen oder aber weiterverarbeitet.

Für die Weiterverarbeitung sieht JMAPI zwei verschiedene Möglichkeiten vor. Zum einen kann ein Consumer bei der Registrierung ein Action-Objekt angeben. Dieses besitzt eine performAction-Methode, die im Falle der Evaluation des Filters zum Wert true zur Ausführung gelangt. Alternativ kann der Consumer bei der Registrierung auch einen Host und eine Portnummer angeben. In diesem Fall würde der Event dann an den entsprechenden Host weitergesandt werden.

Beim Eintreffen eines Events bei einem Event Dispatcher wird zunächst derjenige Knoten des von diesem Dispatcher verwalteten Event Trees behandelt, dem der eingetroffene Event zugeordnet ist. Die Filter der dort registrierten Consumer werden ausgewertet und der Event wird entsprechend weiterverarbeitet. Als nächster Schritt wird in analoger Weise mit dem Vaterknoten im Baum verfahren. Diese Vorgehensweise setzt sich solange fort, bis die Wurzel des Baumes erreicht ist.

Auf dem Managed Object Server läuft immer ein Event Dispatcher. Zusätzlich können auf beliebig vielen Appliances weitere Event Dispatcher instantiiert werden.

  

Abbildung 5.3: Event Dispatcher Hierarchie

Jedem Event Dispatcher ist ein EventMO Managed Object zugeordnet, welches für die Steuerung des Event Dispatchers verantwortlich ist (siehe Abbildung 5.3). Über das EventMO kann der entsprechende Event Dispatcher gestartet oder angehalten werden, oder es können sich Event Consumer beim zugehörigen Event Dispatcher registrieren. Ferner gibt es einen Event Dispatcher Controller mit zugehörigem Managed Object EvdController, welcher die Verwaltung aller einzelnen Event Dispatcher übernimmt. Ein Client kann mit Hilfe des Event Dispatcher Controllers folgende Operationen ausführen:

• Auflisten aller vorhandenen Event Dispatcher
• Anlegen von neuen Dispatchern
• Ermitteln von RMI Client Stubs bereits existierender Dispatcher
• Starten aller Event Dispatcher in der Management Domäne
• Anhalten aller Dispatcher in der Management Domäne

Bei der Erzeugung von JMAPI Events können folgende Parameter spezifiziert werden:

• der String BranchName, der den Knoten im Event Tree, dem der Event zugeordnet ist, identifiziert.
• die eigentlichen Daten des Events in Form eines VecList Objekts. Hierbei handelt es sich um eine Unterklasse von java.util.Vector, die die Möglichkeit bietet, über Schlüssel in Form eines Strings auf Objekte zuzugreifen. In diesem Sinne bestehen also die Daten eines Events aus key-value Paaren.
• ein Integer Wert RetryCount mit folgender Bedeutung: Wenn der Event dem Event Dispatcher aus irgendeinem Grund nicht zugestellt werden kann, so wird entsprechend dem Wert von RetryCount mehrfach versucht, den Event erneut zu übermitteln.
• ein Integer Wert RetrySleep, der die Anzahl von Sekunden angibt, die im Falle einer fehlgeschlagenen Zustellung an den Event Dispatcher zwischen erneuten Zustellversuchen gewartet wird.

Events werden als Event Messages verschickt. Abbildung 5.4 zeigt den prinzipiellen Aufbau einer JMAPI Event Message.

  

Abbildung 5.4: Prinzipieller Aufbau einer JMAPI Event Message