The second interface allows CORBA-based applications to receive events which have been filtered by NetView. The NetView filter API supports filtering according to the following criteria: Enterprise ID, IP-address of the agent system, event time, event logged time, generic and specific trap types, frequency of occurrence. Filter expressions are represented by strings that consist of keywords representing the above criteria, values, logical and numeric operators.
As we want to ensure that CORBA-based management applications make use of the platform filter functionality, filtered SNMP-traps had to be converted back again into CORBA events. In the terminology of the CORBA event service, the platform must therefore be able to adopt the ``supplier'' role for filtered events. To make this possible, the object class EFD_Supplier was defined. This name of the object class was chosen because these objects have a functionality that is similar to the OSI Event Forwarding Discriminators (EFD). An EFD_Supplier receives NetView events which have passed a NetView filter, converts them into CORBA events and forwards them to the registered consumer objects (i.e. CORBA-based management applications) via a CORBA event channel (see figure 4). For technical reasons, we have implemented a helper class Event_Dispatcher whose purpose is to handle the registrations of event consumers and to distribute the filtered events to the appropriate consumers. The IDL definition of an EFD_Supplier is as follows:
interface EFD_Supplier : SOMObject
{
attribute string filter;
void set_Dispatch(in Event_Dispatcher disp);
oneway void activate();
}
A consumer can specify what kind of events he wants to receive by setting the EFD_Suppliers filter attribute. When an EFD_Supplier is activated, the filter attribute is converted into a NetView event filter and a session with the NetView filter process (ovesmd) is opened. Every NetView event that passes the filter is converted to the corresponding CORBA event and is forwarded to the registered consumers via the event channel. The conversion is done by a callback method that is activated whenever an event passes the filter. The purpose of this method is to map a filtered SNMP trap into an appropriate CORBA event according to the specific-ID of the trap. The parameters of the trap are included into the event message and forwarded to the Event_Dispatcher who introduces them into the corresponding event channels. As soon as the filter is initiated by the activate() method call, the traps are collected and handled by the callback method in an endless loop. In order to prevent that the consumer blocks, too, the activate method is defined as oneway. One EFD_Supplier object exists for every activated filter.
As the filtering happens completely in the SNMP-based management platform, the filter rules are restricted to the above described (SNMP-focused) criteria. A native CORBAservice that allows filtering according to more powerful criteria is therefore highly desirable. The standardization of an appropriate Notification Service is currently underway (see also section III-D.2).