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

CIM Schema - Event Model

Core Model | Common Models

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

In the context of this specification, the concrete Indication of the occurrence of an event is represented by an instance of the CIM_Indication class. To improve readability, the redundant use of the 'CIM_' preface will often be omitted in the text when discussing the members of the CIM_Indication class hierarchy.

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

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

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

• 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. It is intended that specialized applications will be devised which will add more sophisticated post processing computations to an Indication stream on behalf of its clients. Such post processing may include creating unique keys, persistence, aggregation and correlation. Aggregation and correlation will be modeled in a future CIM Indication specification version. Thus indications in this model are not guaranteed to be uniquely identifiable. For example, if the time and date stamp provided is insufficient to distinguish between instances of, say, InstModification, then those instances are not identifiable unless the provider chooses to add an identifier or a logging entity exists which adds this as a post processing function.

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 IndicationFilter instances. A Subscription is expressed by the creation of an IndicationSubscription association instance that references an IndicationFilter (a Filter) instance, and an IndicationHandler (a Handler) 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 Indication class. A Handler subclass instance is used to specify the destination that is to receive the associated Indication stream. This version of the CIM Indication specification defines the IndicationHandlerCIMXML 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 IndicationHandler (rather than 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 IndicationSubscription SHOULD fail. Likewise, if there is no instance of the requested IndicationHandler the instantia tion of the IndicationSubscription SHOULD fail. The Modeling Events Section describes the properties and semantics of the CIM_Indication and Subscription class hierarchies.

Namespace and Subscription Management

Indications and their properties are to be interpreted in the context of a single namespace. The 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 Filter and Handler 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 has to be extensible allowing schema designers to add new types of indications (events) in arbitrary ways reflecting unforeseen Indication structure and usage. Second, it has to 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. In this proposal, the occurrence of an event is represented as an instance of the Indication class.