A Practical Approach to WBEM[s]CIM Management

Once all of the infrastructure described above has been set up, with filters, subscriptions, and handlers in place, indications start to flow to the handlers. The handlers then initiate transfers to the listeners and, since the listeners cannot be assumed to have knowledge of CIM namespaces, etc., the format of the XML is known as CIM Export Format and is slightly different from what I have described elsewhere in this book. I include an example in Figure 8.6 and, if you are an astute XML reader, you should have no problem in decoding it. Effectively, the namespace has been removed and more or less everything else remains unchanged.

<CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="1007" PROTOCOLVERSION="1.0"> <SIMPLEEXPREQ> <EXPMETHODCALL NAME="ExportIndication"> <EXPPARAMVALUE NAME="NewIndication"> <INSTANCE CLASSNAME="CIM_AlertIndication" > <PROPERTY NAME="Description" TYPE="string"> <VALUE>Sample CIM_AlertIndication indication</VALUE> </PROPERTY> <PROPERTY NAME="AlertType" TYPE="uintl6"> <VALUE>1</VALUE> </PROPERTY> <PROPERTY NAME="PerceivedSeverity" TYPE="uint16"> <VALUE>3</VALUE> </PROPERTY> <PROPERTY NAME="ProbableCause" TYPE="uint16"> <VALUE>2</VALUE> </PROPERTY> <PROPERTY NAME="IndicationTime" TYPE="datetime"> <VALUE>20010515104354.000000:000</VALUE> </PROPERTY> </INSTANCE> </EXPPARAMVALUE> </EXPMETHODCALL> </SIMPLEEXPREQ> </MESSAGE> </CIM>

Although the export process is designed to convey information in one direction, from the handler to the listener, the definition of the export interface is sufficiently general to allow parameters to be passed back if it is used for other, currently undefined , applications.