A Practical Approach to WBEM[s]CIM Management

Indications

Figure 8.3 illustrates the top level of the Indication class hierarchy. CIM_Indication is a very generic class and is defined with the ABSTRACT qualifier meaning that instances of it cannot be created; it is simply a superclass for all indications. It has three subclasses:

  1. CIM_ClassIndication , used to describe events arising from the manipulation of classes: their creation, deletion, and modification. In this case, the CIM server itself effectively acts as the Indication Provider, creating the Indication when a class is manipulated.

  2. CIM_InstIndication , used to describe events arising from the manipulation of instances. As with CIM_ClassIndication , this includes their creation, deletion and modification but also includes the invocation of a method on them. Again, the WBEM server acts as the Indication Provider. A listener could be set up to receive indications related to class and instance manipulation by subscribing to CIM_InstIndications and CIM_ClassIndications and, perhaps, create a log file as part of a security trace.

  3. CIM_ProcessIndication, used for all "external" events ”events not raised because of the manipulation of the model. In principle, this type of indication is not actually required because all externally occurring events could be mapped to an operation in the model (creation of an instance, for example). In practice, most event handling does occur through CIM_ProcessIndication because this class forms a superset with most of the standard properties required for an alarm notification: see Figure 8.3. This type of Indication was designed to allow an alarm detected deep in an operating system or telecommunications stack and possibly not associated directly with any CIM object to be signalled as easily as possible.

Figure 8.3: The Indication Classes

The subclasses of CIM_ProcessIndication as illustrated in Figure 8.3 are:

[1] A "trap" is SNMP-speak for an indication; see RFC1157.

Категории