Automatische Benachrichtigung der Applets bei Veränderungen des Agentensystemzustands

Um die in den Applets angezeigten Daten aktuell zu halten, beispielsweise wenn neue Agenten geladen/beendet, weitere Agentensysteme gestartet oder beendet werden etc., war es nötig, eine Möglichkeit zu finden, die Applets über diese Ereignisse ,,zu informieren``. Die Implementierung der MASA sieht bereits vor, daß beim Starten bzw. Beenden von Agenten und Agentensystemen entsprechende Ereignisse über einen CORBA Event Channel ausgelöst werden. Zusammen mit diesen Ereignissen werden auch Daten versendet, welche die genaue Art des Ereignisses spezifizieren. Auf diese Weise können Applets, die diese Ereignisse registrieren, entsprechend reagieren, also etwa eine Liste mit laufenden Agenten aktualisieren, falls ein weiterer Agent im betreffenden Agentensystem geladen wird, etc.
Um diese Ereignisse an Applets weiterzureichen, müßten diese direkten Zugang zum CORBA Event Service besitzen. Problematisch ist dabei jedoch, daß Applets einem strengen Sicherheitsmodell unterliegen, das es verbietet, auf Dienste zuzugreifen, die nicht auf dem gleichen Rechner im Netz laufen wie der Webserver, über den das Applet geladen wurde. Daher muß ein Weg gefunden werden, wie die Applets trotzdem benachrichtigt werden können.
Die Lösung besteht darin, einen Proxy-Agenten zu definieren, der direkten Zugang zum CORBA Event Channel besitzt. Die Applets müssen mit diesem kommunizieren können, ohne die an sie gestellten Sicherheitsanforderungen zu verletzen.
Die erste Forderung kann erfüllt werden, da ein MASA-Agent nicht den strengen Sicherheitsanforderungen unterliegt, die an Applets gestellt werden. Er ist weitgehend frei in seinen Kommunikationsmöglichkeiten. Der zweiten Bedingung wird entsprochen, indem der Agent in jedem Agentensystem gestartet wird, für das ein solches Applet geladen werden soll. Dadurch befindet er sich auf der gleichen Maschine wie der Webserveragent, über den das Applet geladen wird, welches auf diese Weise ungehindert mit dem Proxy-Agenten kommunizieren kann.
Der Agent, der diese Proxy-Funktionalität übernimmt, ist der ASManagementAgent. Durch ,,Horchen`` am CORBA Event Channel registriert er eingehende Ereignisse und gibt sie an Applets weiter. Das allgemeine Schema, nach dem der Agent diese Ereignisse empfängt, ist das sogenannte Push Modell .

 

Abbildung 3.3: Allgemeines Push-Modell

Dabei sendet der PushSupplier (hier das Agentensystem) Daten an seinen ProxyPushConsumer . Auf der anderen Seite verbringt der PushConsumer , der vom ASManagementAgent erzeugt und bei einem ProxyPushSupplier registriert wird, die meiste Zeit in einer Event-Schleife und wartet darauf, daß Daten von dem ProxyPushSupplier ankommen, bei dem er als Empfänger registriert ist. Der Event Channel sorgt für die Übertragung von Daten vom ProxyPushConsumer zum ProxyPushSupplier .
Damit die Ereignisse und die damit verbundenen Daten auch zu den Applets gelangen, definiert jedes Applet eine eigene PushConsumer Klasse. Eine Instanz dieser Klasse wird beim Start des Applets erzeugt, beim CORBA ORB registriert und dem ASManagementAgenten mit dessen Methode connect_push_consumer(...) übergeben. Dieser erhält dadurch CORBA-Referenzen der PushConsumer der Applets. Jeder PushConsumer besitzt definitionsgemäß die Methode push(...) , die bei eingehenden Events automatisch aufgerufen wird. Sie definiert daher das Verhalten, mit dem auf Ereignisse reagiert wird.
Der ASManagementAgent hält die übergebenen Objektreferenzen in einer eigens dafür vorgesehenen Datenstruktur. Wird nun von seinem eigenen PushConsumer ein Ereignis vom CORBA Event Service empfangen, so ruft dessen push(...) -Methode wiederum die push(...) -Methoden aller PushConsumer -Objektreferenzen auf, die von Applets an den Agenten übergeben wurden, und übermittelt damit die CORBA Events an die PushConsumer der Applets. Da die Applets ihre eigenen PushConsumer -Klassen und die damit verbundenen push(...) -Methoden definieren, kann jedes Applet individuell auf die Events reagieren, die ihnen vom ASManagementAgenten übergeben werden. Die nachstehende Abbildung erläutert das eben beschriebene nocheinmal.

 

Abbildung: Weiterleitung von CORBA Events durch den ASManagementAgenten

Auf diese Weise werden alle beim Agenten eingehenden CORBA Ereignisse über CORBA-Kommunikationsmechanismen an die Applets weitergeleitet. Die damit verbundenen Daten werden dabei ebenfalls weitergegeben. Sie werden von den push(...) -Methoden der Applet-PushConsumer ausgewertet, um auf die Ereignisse der Situation entsprechend zu reagieren.