5.4.4 Empfang von gefilterten Ereignismeldungen durch CORBA-Anwendungen

Durch die Umwandlung von CORBA-Ereignismeldungen in SNMP-Traps können diese von der Plattform empfangen und verarbeitet werden. Damit ist ein wichtiger Teilaspekt realisiert, um die Event-Management-Dienste der Plattform für die Überwachung der CORBA-Umgebung einsetzen zu können. Darüberhinaus ist es jedoch für die Realisierung CORBA-basierter Managementanwendungen notwendig, daß die Anwendungen die von der Plattform gefilterten Ereignismeldungen empfangen können. Es mußte also eine Möglichkeit gefunden werden, um gefilterte SNMP-Traps, die aus CORBA-Events erzeugt wurden, wieder in CORBA-Events zurückzutransformieren. Zusätzlich wurde eine Schnittstelle entwickelt, über die CORBA-basierte Managementanwendungen sich zum Empfangen von gefilterten Ereignismeldungen registrieren können.

Aus CORBA-Sicht ist die Managementplattform ein Supplier von gefilterten Ereignismeldungen. Die Supplier-Rolle wird von sogenannten EFD_Supplier-Objekten übernommen. Der Name wurde gewählt, weil diese CORBA-Objekte eine ähnliche Funktionalität haben wie ein Event-Forwarding-Discriminator in der OSI-Welt (aus Sicht der Empfänger von gefilterten Events). Ein EFD_Supplier wandelt gefilterte SNMP-Traps (die aus CORBA-Events erzeugt wurden) zurück in CORBA-Events und leitet sie an einen Event_Dispatcher weiter, der sie an seine registrierten Consumer ,,verteilt``Die Klasse EFD_Supplier hat folgende IDL-Definition:

interface EFD_Supplier : SOMObject
{
  attribute string filter;
  void set_Dispatcher(in Event_Dispatcher dispatcher);
  oneway void activate();
}

Beim Erzeugen eines EFD_Suppliers erhält dieser eine Objektreferenz auf einen Event_Dispatcher. Nach dem Erzeugen wird das Filter-Attribut gesetzt. Die Registrierung von Consumer-Objekten wird beim Event_Dispatcher vorgenommen. Nach dem Aktivieren des EFD_Suppliers leitet dieser alle Ereignismeldungen, die den Filter passieren, an den Event_Dispatcher weiter.

 

Abbildung 5.8: Event-Filterung durch EFD_Supplier-Objekte

Der EFD_Supplier filtert die Ereignismeldungen nicht selbst, sondern verwendet dazu die Filtermöglichkeiten der Plattform. Beim Aktivieren des Suppliers werden folgende Aktionen ausgeführt:

• Das Attribut ,,filter`` wird umgewandelt in einen SNMP-Filterstring. Es könnte auch direkt der SNMP-Filterstring beim Erzeugen des EFD_Suppliers übergeben werden. Allerdings sind gewisse Abbildungen sinnvoll, um die Verwendung von SNMP transparent zu machen. Zumindest ist eine Abbildung zwischen dem Namen des CORBA-Events und der Enterprise-Specific-ID des Traps nötig. Eine Abbildungstabelle kann als Datei, als eigenes Objekt oder innerhalb der Klasse EFD_Supplier realisiert sein. Dadurch, daß eigentlich nicht die CORBA-Events selbst gefiltert werden, sondern SNMP-Traps, ist man bei der Definition des Filter-Attributs auf solche Filterausdrücke beschränkt, die in SNMP-Filter umgewandelt werden können. Die Beschränkungen der SNMP-Filtermöglichkeiten wurden im vorigen Abschnitt bereits genannt.
• Es wird eine SNMP-Session mit dem Filter-Dämon von NetView (ovesmd) aufgebaut. Dabei wird der aus dem CORBA-Filter erzeugte SNMP-Filter als Argument übergeben. Eine Callback-Funktion wird jedesmal automatisch ausgeführt, wenn ein SNMP-Trap den Filter passiert. Diese Callback-Funktion wandelt den SNMP-Trap um in die entsprechende CORBA-Ereignismeldung (der Identifikator dafür ist die Specific-ID des Traps). Die Parameter werden den Variable-Bindings des Traps entnommen. Anschließend wird die Ereignismeldung an den Event_Dispatcher weitergeleitet.

Sobald der SNMP-Filter aktiviert ist, werden in einer Endlosschleife Traps empfangen und durch die Callback-Funktion verarbeitet. Das bedeutet, daß die activate-Methode blockiert und daß, während der Filter aktiv ist, keine anderen Methoden auf dem EFD_Supplier aufgerufen werden können. Aus diesem Grund wurde die activate-Methode als oneway spezifiziert, damit der Aufrufer der Methode nicht ebenfalls blockiert.