HP StorageWorks SAN Virtualization Services Platform SMI-S User Guide (5697-0209, April 2010)

the SMI agent passes the CIM_IndicationFilter to each subclass that supports the Indication Provider
interface.
When an Indication Subscription is activated, the SMI agent will ask each appropriate Indication
Provider whether it supports the Indication (authorizeFilter() is called). The provider must verify that
the CIM_IndicationFilter instance specified contains appropriate values in its query, query language,
and SourceNamespace property values (see Profile specifications for required property values). The
Indication provider will return true if the Indication specified is supported, or false otherwise, in which
case the SMI agent will reject the CreateInstance operation for CIM_IndicationSubscription.
Many SMI agents have built-in Indication Polling mechanisms. Agents request a collection of instances
at intervals, and compare the collections for new, deleted, or modified instances (use of agent polling
is strongly discouraged, as they occupy the SMI agent and introduce performance overhead). If polling
is supported, the SMI agent will call mustPoll(), and check for a return of true to verify a provider
supports polling. All providers in this implementation should respond with false, indicating the provider
supports its own Indication delivery. Finally, the SMI agent will call the activateFilter() interface to
enable the Indication provider to subscribe to its underlying event mechanism. When the provider
detects the desired event, the provider must create and deliver the appropriate Indication instance
information to the SMI agent. Note that when the last CIM_IndicationSubscription involving a given
CIM_IndicationFilter is deleted, the SMI agent will call the deactivateFilter() to enable the Indication
provider to unsubscribe from its underlying event mechanism.
CIM classifies indications using two categories: process (or alert) and life cycle indications. Life cycle
indications represent the creation, deletion, or modification events of an instance in a namespace.
Generally, life cycle indications are used to convey telemetry, but may also be used to alert the client.
In the latter case, there are significant model changes that consist of an alert.
When providers generate life cycle indications, providers are required to furnish the indication with
a SourceInstance and (for modification) PreviousInstance properties. These properties are string type
with the EmbeddedObject qualifier applied, meaning that the string is an XML or MOF encoding of
an instance. Most CIMOM implementations do not require the provider to perform encoding of the
instance inside the provider. Rather, most CIMOM's have a paradigm to allow a provider developer
to affix the SourceInstance or PreviousInstance properties to the Indication instance as some kind of
instance datatype. When the Iindication instance is delivered from the provider, the CIMOM takes
care of encoding the attached instances into EmbeddedObject properties into a format required by
the client.
Alert indications are means to alert a client to a phenomenon of interest. An alert may or may not be
associated to a modeled element. Alerts are used to convey actionable messages to a client. The
means by which this message is conveyed is through standard messages.
An optional feature of the Indication Profile v1.4 is the concept of correlated indications. There are
cases where many indications are produced in response to an event. In most cases, one event (like
a network port failure) can cause changes in other components, and hence generate other indications
representing stripe set state changes. Correlation is the ability to relate one indication to others giving
a client collecting indications a 'side-effect' snapshot.
Note that the profile does not specify the class implementation themselves. HP expects to use
OpenPegasus 2.8 for the implementation of this profile. The WBEM infrastructure implements this
profile. However, this profile does document what values to provide for those instances that
OpenPegasus permits to be determined by the user of the WBEM infrastructure.
Object model
Object model overview
The key classes for the Indication Profile are presented in the instance diagram below.
Indication Profile272