Chapter 8: The Listener Interface

This chapter relies heavily on the Event Common Model and, at the time of writing, several parts of this model are undergoing modification between version 2.7 and 2.8. I have tried to include the most up-to-date class hierarchy but, since some of this is experimental at the time of writing, it may change before version 2.8 finally appears.

The Indication Mechanism

Events occur and conditions causing alarms arise spontaneously in all systems. Some of these need to be brought to an operator's attention, some need to be logged for later review, some need to be passed to monitoring and analysis equipment (the "P" for performance in FCAPS) and many can be ignored. The handling of a particular alarm may change from minute to minute: perhaps an operator is trying to pin down an elusive fault and wants to be alerted as soon as it occurs, perhaps a particular fault is only important on certain days or if another fault has not also recently occurred.

The WBEM server provides the interfaces to allow operators to specify precisely the faults for which they want to be notified and to turn the notification on and off. The classes used to establish this monitoring are included in the Event Common Model.

There are several components in the path between an event occurring in a piece of hardware or software and an indication arriving on the screen of an operator. These include:

• The Indication Provider which detects the alarm and passes it to the WBEM server as an indication. An indication is an instance of a class derived from CIM_Indication.

• The Filters which the WBEM server consults to see whether the indication satisfies a predefined pattern. Filters are instances of classes derived from CIM_IndicationFilter. A filter might, for example, select all events arising from the class MyTemperatureAlarm where the

   Severity == Critical AND Temperature is > 180 

• The Subscriptions which the WBEM server consults to see whether any operator is interested in being notified about the indication. Subscriptions are instances of associations derived from CIM_IndicationSubscriptions.

• The Handlers to which the WBEM server sends the notification. Handlers are defined in instances of classes derived from CIM_IndicationHandler.

• The Listeners which represent the operators and receive the indications on their behalf .

• The Consumers, the CIM-speak term for the operator's software which will presumably display the indication on a screen, write it to a file, etc.

This whole mechanism is illustrated in Figure 8.1 where time is assumed to flow from top to bottom of the picture. The flow of activity in the figure is as follows :

1. An operator (or other WBEM client such as a mof compiler for static instances) creates an instance of the class representing the handler.

2. The operator creates an instance of the filter class describing precisely the types of indication in which he or she is interested.

3. The operator creates an instance of an association linking the filter to the handler.

4. When an event occurs, the associated provider (an Indication Provider) creates an instance of the Indication.

5. The WBEM server is aware of this instantiation and examines the filters to determine which filters allow it through. It then follows the associations to see which handlers (if any) are interested in this event.

6. The WBEM server then passes selected information from the indication instance to the handler.

7. The handler then passes it to the listener for display.

Figure 8.1: The Indication Mechanism

Figure 8.2 gives a little more detail of how filters and handlers may be combined. On my toaster there is an alarm, called TemperatureAlert , which signals a high or low temperature on the heating element. I have created two filters: one passing (accepting) alarms if the temperature becomes too low, the other passing alarms if it becomes too high. Handler 1 sends a copy of the Indication to the local fire station which is interested in the temperature becoming too high whereas Handler 3 is connected to my toaster repair shop which is only interested in the temperature becoming too low. I am monitoring Handler 2 myself and need to know of either event so it receives both types of Indication. Note that Figure 8.2 is an informal diagram: it is not UML.

Figure 8.2: Indication Filters and Handlers

If you are creating a listener to receive information about a particular alarm then you need only create a handler for it, define a filter (unless one already exists) and then create an instance of the association (the subscription) between the filter and the handler. Your listener will then start to receive events from the managed device as they occur. What it does with them is, of course, outside the scope of WBEM/CIM but could include writing a log file, sending a message to a pager, opening a window on an operator's screen or sending an e-mail (or instant message) to an operator. If the operator is managing the device with a Web browser, then possibly a Java thread could be waiting on the arrival of these messages and creating a pop-up window when they arrive .

In summary, instances of four classes are required to make all of this work: CIM_Indication, CIM_IndicationFilter, CIM_IndicationHandler and CIM_IndicationSubscription. These are described in the following sections.