|
CIM Tutorial
> CIM > CIM
Schema > Common Models > Event Model
 |
CIM Schema - Event Model
|
 |
Overview | CIM
Schema | Extension Schema | CIM
Certification | CIM Query Language
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.
|
