|
DMTF Tutorial
> CIM > CIM
Schema > Common Models > Event Model
 |
CIM Schema - Event Model
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
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
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.
|
