Modelling the Events

As you learned in Chapter 8, in order for an operator to receive notification of events, instances of three classes need to be created:

1. A class descended from CIM_Indication which contains details of the event.

2. A class descended from CIM_IndicationFilter to specify precisely which events the operator wishes to receive.

3. A class descended from CIM_IndicationSubscription to tie the filter with the operator's handler.

The only one of these classes which needs to be defined before the PBX is deployed is the descendant of CIM_Indication and so that is the only one which I will consider here. For the other two classes, the ones provided by the DMTF will probably suffice.

CIM_Indication, as shown in Figure 8.3 on page 155, is subclassed into class, instance, and process indications . The first two deal with events created by the WBEM server itself as classes and instances are created and destroyed . Our interest is in process indications and these are further subclassed as shown in Figure 8.3. Because we are not dealing with SNMP traps, the logical class for us to subclass is CIM_AlertIndication. All of the properties that we will require, including the time that the event was discovered , the description of the event, the identity of the entity discovering the event, the type and severity of the event and the probable cause of the event, are already available to us in the superclasses and so we simply need to define a class for each event which may occur and in which an operator might have an interest.

I list a few of these in Table 9.1 and illustrate them in Figure 9.7.

Figure 9.7: The PBX Events Classes