Die gewöhnliche Kommunikationsform innerhalb CORBA ist der synchrone Methodenaufruf eines Clients auf einem Server. Der CORBA Event-Service entkoppelt die Kommunkikation durch Einführung eines event channel. Hierüber ist eine asynchrone Kommunikation zwischen mehreren Sendern (suppliers) und Empfängern (consumers) nach dem sog. publish/subscribe-Paradigma möglich. Eine allgemeine Einführung zum CORBA Event-Service bietet [Sie96]. Ein sehr gutes Tutorial ist [Sch96a]. Die Referenz zur VisiBroker-Implementierung ist [Vis97d].
Asynchrone Meldungen der Agenten an einen oder mehrere Manager werden auf das push model des Event-Services abgebildet, welches in Abbildung 6.17 für zwei Sender und einen Empfänger dargestellt ist. ,,Push`` drückt aus, daß der Sender die Kommunikation initiiert, indem er eine Nachricht an den Event Channel sendet. Dieser verteilt wiederum die Nachricht unaufgefordert an alle Empfänger (Manager). Umgekehrt verläuft die Kommunikation beim pull model. Hier würde der Event Channel regelmäßig bei den Agenten nachfragen (,,pull``), ob Nachrichten vorliegen und diese zwischenspeichern. Der Manager würde bestimmen, wann er die Nachrichten abholt. Der Event-Service unterstützt auch das Mischen, bei dem das Modell für die Sender unterschiedlich ist von dem der Empfänger. Für das Management liefert das Push-Modell die richtige Semantik, da ein Ereignis innerhalb eines Managed Object den Agenten veranlaßt, eine asynchrone Meldung an den Manager zu senden, die dieser sofort erhalten soll, um darauf reagieren zu können.
Wenn ein Agentenobjekt asynchrone Meldungen versenden soll, muß es das
PushSupplier-Interface implementieren. Ein Manager implementiert
dementsprechend das PushConsumer-Interface. Wie in
Abbildung 6.17 dargestellt, ist jedem Agent im Event
Channel ein ProxyPushConsumer-Objekt zugeordnet, welches
Meldungen an alle ProxyPushSupplier-Objekte (hier nur eines)
innerhalb des Kanals weiterleitet, die ihrerseits die Methode
push() auf dem PushConsumer-Interface ,,ihres`` Managers aufrufen, um die Nachricht zuzustellen. Zur Anbindung eines
Agenten bzw. Managers an einen Event Channel bedarf es mehrerer
Schritte. Tabelle 6.1 enthält die zugehörigen Methoden
und Klassennamen.
| Schritt | Agent: |
|---|---|
| PushSupplier | |
| 1. Lokalisieren des Event Channel | EventChannelHelper :: bind() |
| 2. Referenz auf Proxy-Factory | EventChannel :: for_suppliers() |
| 3. Proxy-Objekt im Event Channel anfordern | SupplierAdmin :: obtain_push_consumer() |
| 4. Proxy-Objekt binden | ProxyPushConsumer :: connect_push_supplier() |
| Senden / Empfangen einer Meldung | ProxyPushConsumer :: push() |
Ein Event Channel, der zunächst noch keine Proxy-Objekte enthält, wird
vom Hauptprogramm des Agenten (SystemAgentServer.java)
erzeugt und beim BOA angemeldet. Hierfür stellt VisiBroker eine
Bibliotheksfunktion bereit. Der Code ist im Anhang B zu
finden. Der erste Schritt für ein Agentenobjekt ist, die IOR des
eingerichteten Event Channel zu ermitteln. Damit es im Event Channel
ein Proxy-Objekt erzeugen kann, an das es seine Meldungen schicken
kann, erfragt es im zweiten Schritt die IOR einer
ProxyPushConsumer-Factory. Bei der Factory wird im nächsten Schritt
ein solches Proxy-Objekt angefordert (obtain). Der letzte
Schritt ist, den PushSupplier des Agenten mit dem Proxy-Objekt
im Kanal zu verbinden (connect). Anschließend kann der Agent
durch Aufruf der Methode push() auf dem Proxy-Objekt Meldungen
verschicken. Analog zum Agenten verläuft die Anbindung eines Managers
an den Kanal. Der Manager muß ebenfalls eine Methode push()
implementieren, die das ProxyPushSupplier-Objekt im Event
Channel zum Zustellen einer Meldung aufruft.
Die Methode push() erwartet die Nachricht in Form einer CORBA
any-Datenstruktur. VisiBroker unterstützt nur die generische,
untypisierte Ereigniskommunikation. Zu jeder benutzerdefinierten
IDL-Datenstruktur erstellt der IDL-Compiler in der Klasse
<datenstruktur>Helper.java die Methoden insert() und
extract(), die Variablen mit dieser Datenstruktur in
any-Objekte packen bzw. wieder extrahieren. Ein Event könnte daher
als Verbund aus Feldern wie Name, Source, Time,
Severity, Cause, etc. definiert werden.
Für den Prototypen wurde eine Klasse FilesystemMonitor implementiert, die den freien Platz bestimmter Filesysteme überwacht und Warnungen an den Manager schickt, sobald der freie Speicherplatz einen festgelegten Prozentsatz unterschritten hat. Die periodische Abfrage innerhalb des Agenten wird durch einen eigenen Java-Thread realisiert. Die Meldungen werden als Strings über den Event-Service an die Managementanwendung gesendet. Anhang B enthält den Quellcode zur Demonstration der Implementierung dieser Techniken.