DMTF Tutorial > CIM > CIM Schema > Common Model

DMTF Tutorial > CIM > CIM Schema > Common Models > Event Model

CIM Schema - Event Model

Overview

The subject of events is complex as it covers a wide range of topics and scenarios. An event is typically assumed to be a change in the state of the environment or a record of the behavior of some component of the environment. For example, the state property for a service may go from Stopped to Started, indicating that the service is now started. Or a device may be added to a machine resulting in a plug and play Indication ultimately notifying the operating system that the device is present and should be configured with settings and drivers in order for it to be usable. An event may be a pervasive incident that occurs infrequently such as a system re-boot or it may reflect very small scale, frequently occurring incidents, for example mouse-clicks. Many things can be affected. The consequences of an event can last a long time. The way that events are dealt with may also vary enormously. Some events may require immediate action on the part of the observer. For example an ‘out of disk space’ event on a web server may require immediate action to make disk space available. Some events may only be of interest at a later time. An example of the interest at a later time is a ‘bandwidth utilization on an interface’ event that a billing application deals with only during nightly billing reconciliation.

Representation

For this tutorial, the occurrence of an event is represented by an instance of an CIM_Indication subclass.

Types of indications (representing different types of events) are denoted by CIM_Indication subclasses. These include:

CIM_InstIndication for modeling CIM life cycle events; instance creation, deletion, modification, method invocation and read access

CIM_ClassIndication for CIM Schema life cycle events; class creation, deletion and modification.

CIM_ProcessIndication for alert notifications associated with objects that may or may not be completely modeled in CIM or do not correspond to a simple life cycle event; like low-level instrumentation alerts, DMI alerts, SNMP traps and TMN events

Instances of indications cannot be enumerated because they are transient objects (not guaranteed to have persistence). Indications are only received after subscribing to them. They cannot be retrieved through enumeration or ordinary query processing in a CIM Object Manager. This was considered to be a necessary design constraint to ensure lightweight Indication processing.

The properties of CIM_Indication can be used by clients to perform sophisticated post processing computations performed of Indication streams. The IndicationIdentifier can be used to help distinguish between Indication instances. However, in this model, Indications are not guaranteed to be uniquely identifiable. For example, the IndicationTime property may have the same value if two Indications generated in rapid succession. The CorrelatedIndications property can be used to provide aggregation and correlation of Indications.

Publication and Subscription

A fundamental idea underlying the CIM approach to the representation of indications is the separation of Indication publication and Indication subscription. The publication of an Indication is accomplished using the same mechanism used for the publication of any other data in CIM; that is, through the declaration of classes and properties. Publication of events also implies the creation of CIM_IndicationFilter instances. A Subscription is expressed by the creation of an CIM_IndicationSubscription association instance that references an CIM_IndicationFilter (a Filter) instance, and an CIM_ListenerDestination (a Listener) instance. A Filter contains the query that selects an Indication class or classes. The size and complexity of the result delivered to the subscriber is dictated by the query.

The CIM Object Manager is designed to process queries on behalf of managed object providers. However, it is intended that CIM managed object providers may be designed (although not required) to handle ad hoc Filter queries directly.

Notifications of Filtered events are delivered as instances of the CIM_Indication subclass. A Handler subclass instance is used to specify the destination that is to receive the associated Indication stream. This version of the specification defines the CIM_ListenerDestinationCIMXML subclass that is used to deliver indications to clients over HTTP and encoded as cim/XML. Other protocols may be defined in the future to support point to point protocols, multi-cast delivery, email, paging, as well as associated actions like launching a process. Thus, the intent in naming this class CIM_IndicationHandler (rather than CIM_IndicationDelivery) is meant to convey that handling an Indication can require more than delivery.

If there is no provider capable of generating the requested Indication the instantiation of the CIM_IndicationSubscription SHOULD fail. Likewise, if there is no instance of the requested CIM_IndicationHandler the instantiation of the CIM_IndicationSubscription SHOULD fail. The Modeling Events Section describes the properties and semantics of the CIM_Indication and CIM_IndicationSubscription class hierarchies.

Namespace and Subscription Management

Indications and their properties are to be interpreted in the context of a single namespace. The CIM_IndicationFilter.SourceNameSpace parameter is used to denote the namespace in which the event that triggered the Indication occurred. This allows creation of all subscriptions in a single CIM namespace even if the events of interest originate from a different namespace. This schema allows creating and examining all Filters in a single namespace regardless of the origin of the events. In addition, since CIM_IndicationFilter and CIM_IndicationHandler are subclasses of CIM_ManagedElement, Filters and Handlers can be managed by higher-level services.

Modeling Events

The event model has to meet two conflicting requirements. First, it must be sufficiently extensible to allow schema designers to add new types of indications (events) in arbitrary ways reflecting unforeseen Indication structure and usage. Second, it must provide a basis for event analysis and applications that interpret the event flow for aggregation, correlation and throttling purposes without the application having to be aware of the full range of event types implied by the first requirement. As mentioned, while it is intended that this specification support aggregation, correlation and throttling, the exact mechanism for doing this is deferred to a future version.