4.5.1 Abbildung von SNMP-Traps auf generische CORBA-Events

  Die einfachste Möglichkeit, wie SNMP-Traps abgearbeitet werden können ist, einen SNMP-Trap unbearbeitet in einen generischen CORBA-Event zu packen und direkt an den Manager zu schicken (siehe Abbildung 4.11).

  

Abbildung 4.11: Traps als generische Events direkt an Manager

Ein Dämon snmptrapd am well-known Port 162 empfängt demzufolge eine Trap-PDU und ruft als PushSupplier die Methode push() eines PushEventConsumers des Managers auf (2a). Dabei wird die Trap-PDU als Parameter (Datentyp any) übergeben. Beim pull-Modell ruft der PullEventConsumer des Managers die Methode pull() des Trap-Dämons im Gateway auf. Ihm wird dann die Trap-PDU zurückgegeben. Diese Methode entspricht dem Polling

Im Prinzip werden bei dieser Vorgehensweise Ereignismeldungen ,,direkt an den Manager`` geschickt. Das Fehlen eines Event Channel Objektes -- laut des CORBA-Event-Dienstes durchaus legitim -- hat aber den Nachteil, daß es für das Gateway nicht transparent ist, wer der Empfänger der Events ist. Es benötigt nämlich für jeden Manager (Consumer) eine Objektreferenz und muß an jeden Manager jeden Event einzeln verschicken. Für einen Event Channel braucht das Gateway hingegen nur eine Objektreferenz; beliebige Consumer können sich an den Event Channel anschließen, um Ereignismeldungen zu empfangen, ohne daß dies für einen Supplier im allgemeinen und das Gateway im einzelnen Konsequenzen hat.

Abbildung 4.12 stellt eine Lösung mit einem generischen Event Channel dar (push-Modell).

  

Abbildung 4.12: Traps als generische Events an Event Channel

Das Gateway hat einen Event Channel erzeugt (beispielsweise bei der Initialisierung oder beim Eintreffen des ersten SNMP-Traps). Sobald ein SNMP-Trap empfangen wird, ruft der snmptrapd die Methode push() des Event Channels auf und schiebt die Daten der Ereignismeldung in den Event Channel. Nun ist es Aufgabe dieses Event Channels, die Ereignismeldung an alle Manager (Consumer) weiterzuleiten (3), die bei diesem Event Channel registriert sind.

Generische Events haben allerdings folgende Nachteile, sodaß das Modell der typisierten Kommunikation zwischen Manager und Gateway geeigneter ist:

• Die Methoden push() und pull() besitzen jeweils nur einen Parameter von Datentyp any. Damit muß ein Manager beispielsweise als PushConsumer alle Daten akzeptieren und interpretieren, die ihm beim Aufruf seiner push-Methode übergeben werden.
• Die ursprüngliche Herkunft der Ereignismeldungen kann nicht bestimmt werden. Beispielsweise kann nicht erkannt werden, ob ein Event direkt von einer CORBA-Umgebung oder (eigentlich) von einer SNMP-Domäne stammt.
• Vor der Verarbeitung des Events ist nicht feststellbar, welcher SNMP-Agent den Trap verschickt hat.
• Unterschiedliche Typen von SNMP-Traps (z.B. coldStart, warmStart, authenticationFailure ...) können nicht abgegrenzt werden.

Insgesamt sind die generischen push- und pull- Methoden nicht differenziert genug, um im Event Channel Ereignismeldungen sinnvoll zu filtern.