next up previous contents
Next: 5.4.4 Empfang von gefilterten Up: 5.4 Implementierung Previous: 5.4.2 Die Klasse Event_Dispatcher

5.4.3 Empfang von Ereignismeldungen durch die Managementplattform

Damit CORBA-Ereignismeldungen von der Managementplattform verarbeitet werden können, wurden spezielle Event-Consumer-Objekte entwickelt:

NetView kann CORBA-Ereignismeldungen nicht direkt verarbeiten. Damit trotzdem die Event-Management-Services (EMS) der Plattform genutzt werden können, müssen die CORBA-Events in SNMP-Traps oder CMOT-Notifications umgewandelt werden.

Bei einem Vergleich dieser beiden Alternativen werden die Vorteile von CMOT deutlich:

1.
Möglicher Informationsgehalt der Ereignismeldungen. Die Bestandteile eines CMIS-Event-Report-Argument sind besser geeignet, um die Information eines CORBA-Events darin zu ,,verpacken`` als eine SNMP-Trap-PDU. Eine Betrachtung der beiden PDU-Typen macht dies deutlich. Ein CMIS-Event-Report-Argument besteht aus folgenden Komponenten (die Angabe des Typs bezieht sich auf den jeweiligen XOM-Datentyp): Eine SNMP-Trap-PDU hat neben den ,,üblichen`` Bestandteilen einer SNMP-PDU (request-id, error-status, error-index) folgende Komponenten:

Die CMOT-PDU hat zwei wichtige Vorteile gegenüber einer SNMP-Trap-PDU. Der erste ist die Information über die Quelle des Events. Sowohl bei OSI als auch bei CORBA ist der Versender einer Ereignismeldung eine Objektinstanz. Die CMOT-PDU enthält sowohl die Objektklasse als auch den Distinguished-Name des sendenden OSI-Objekts. Bei einer CMOT-Notification, die aus einem CORBA-Event erzeugt wird, ist es sinnvoll, die Objektreferenz (in String-Form) als Identifikator für die Objektinstanz anzugeben. Als Identifikator für die Objektklasse kann ein eindeutiger Name oder die Interface-Repository-ID verwendet werden. Eine SNMP-Trap-PDU enthält hingegen lediglich die IP-Adresse des Hosts, auf dem sich der sendende Agent befindet, als Information über die Quelle der Ereignismeldung. Die Konsequenz daraus sind eingeschränkte Filtermöglichkeiten (s.u.).

Der zweite Vorteil von CMOT betrifft die anwendungsspezifischen Daten, die in einer Event-Report-PDU verschickt werden können. Die event-Info-Komponente eines CMIS-Event-Report-Argument ist vom XOM-Datentyp Any. Dies bedeutet, daß die übergebene XOM-C-Datenstruktur einem beliebigen ASN.1-Datentyp entsprechen kann. Die Werte der Variable-Bindings einer SNMP-Trap-PDU sind eingeschränkt auf einige wenige ASN.1-Datentypen (die der Value-Komponente eines Variable-Bindings entsprechende C-Datenstruktur des NetView-SNMP-API ist sogar nur eine union aus u_char *, long * und ObjectID *).

Da bei der Modellierung von CORBA-Ereignismeldungen durch Methodenaufrufe die Parameter beliebige IDL-Datentypen sein können, kann es bei der Umwandlung in SNMP-PDUs leicht zu Problemen kommen, weil nicht alle IDL-Datentypen durch die ASN.1-Datentypen der Internet-SMI dargestellt werden können. Dies gilt allgemein für die Umwandlung von IDL nach Internet-SMI. Aus diesem Grund wurde auch die Übersetzung von IDL nach Internet-SMI bei der Arbeit der JIDM-Gruppe ([X/OPEN 95a]) nicht definiert. Es gibt jedoch definierte Abbildungsvorschriften für IDL nach GDMO/ASN.1, die bei der Umwandlung von CORBA-Event-Parametern angewendet werden können.

2.
Filtermöglichkeiten

Auch die Filtermöglichkeiten, die das NetView-Filter-API für CMOT-Event-Report-PDUs bietet, entsprechen eher den Anforderungen bei der Filterung von CORBA-Ereignismeldungen, als die Möglichkeiten bei SNMP-Traps. Insbesondere die Filtermöglichkeiten nach der Quelle der Ereignismeldung (Objektklasse und Objektinstanz bei CMOT / IP-Adresse des sendenden Hosts bei SNMP) sind bei CMOT besser. Für einen genauen Vergleich der Filtermöglichkeiten sei auf Kapitel 3 verwiesen.

Trotz der gerade beschriebenen Vorteile von CMOT wurden bei der Implementierung des Prototypen CORBA-Ereignismeldungen aus folgenden zwei Gründen in Enterprise-Specific-Traps umgewandelt:

Der Empfang und die Umwandlung von CORBA-Ereignismeldungen erfolgt durch Instanzen der Klasse EMS_Event_consumer.

Die Klasse EMS_Event_consumer ist von Event_consumer abgeleitet. Die Methoden wurden dahingehend überschrieben, daß beim Aufruf einer Event-Methode eine entsprechende SNMP-Trap-PDU aufgebaut und an NetView geschickt wird. Voraussetzung dafür ist, daß bei der Plattform für jede CORBA-Ereignismeldung ein Enterprise-Specific-Trap definiert ist. NetView bietet die Möglichkeit, eigene Enterprise-Specific-Traps zu definieren.


 
Abbildung 5.7: Umwandlung von CORBA-Events in SNMP-Traps
\begin{figure}
\begin{center}
\mbox { \epsffile{bilder/EMScons.eps} }\end{center}\end{figure}

Ein EMS_Event_consumer registriert sich bei seiner Initialisierung beim Event_Dispatcher und empfängt daraufhin von diesem alle managementrelevanten Ereignismeldungen. Zur Umwandlung der Ereignismeldungen in Traps und zum Versenden dieser Traps an NetView verwendet der EMS_Event_consumer ein Event_Adapter-Objekt. Ein Event_Adapter hat folgende IDL-Definition:





interface Event_Adapter : SOMObject
{
  void create_pdu(in long spec_id, in string source_host);
  void add_arg_long(in long arg);
  void add_arg_string(in string arg);
  void send_pdu();
 }
Eine Trap-PDU wird zuerst mit create_pdu erzeugt und initialisiert. Dabei wird u.a. die specific-ID des Traps und die dem host-Parameter des CORBA-Events entsprechende IP-Adresse als Agenten-Adresse eingesetzt. Danach werden mit den add_arg-Methoden die Parameter des CORBA-Events in Variable-Bindings ,,verpackt`` und schließlich wird der Trap abgeschickt. Die Methoden der Klasse Event_Adapter wurden mit dem NetView-SNMP-API implementiert.

Neben der Klasse EMS_Event_consumer wurde die Klasse GTM_Event_consumer entwickelt. Diese Klasse ist von Event_consumer abgeleitet, und die Event-Methoden wurden überschrieben. Ein GTM_Event_consumer empfängt alle topologierelevanten CORBA-Ereignismeldungen und aktualisiert daraufhin die GTM-Datenbank von NetView. Dabei verwendet er die in Kapitel 6 beschriebene CORBA-Schnittstelle für das GTM-API.


next up previous contents
Next: 5.4.4 Empfang von gefilterten Up: 5.4 Implementierung Previous: 5.4.2 Die Klasse Event_Dispatcher
Copyright Munich Network Management Team