A Practical Approach to WBEM[s]CIM Management

Assuming that the WBEM client has connected to the WBEM server, I now address three questions about the subsequent exchange:

1. What requests can be made by a WBEM client to a WBEM server?

2. How are those requests encoded?

3. How are the encoded requests actually transported to and from the WBEM server?

The protocols used to exchange information between a WBEM client and WBEM server are illustrated in Figure 7.2. The WBEM client prepares requests and commands in xmlCIM and logically exchanges these with the WBEM server. In practice, in order to encode the message, the WBEM client passes the xmlCIM to a CIM-XML client which itself inserts the request or command into an HTTP message, which is then transferred to an HTTP server, typically on the device being managed. The DMTF has reserved HTTP ports 5988 and 5989 for HTTP and HTTPS, respectively. Once received from the HTTP transport, the request is unpacked and passed as an xmlCIM packet to the CIM Object Manager (CIMOM).

The request, command, or response actually transmitted from the client to the server is formally known as a CIM Operation Message: it is effectively a message exchanged between two CIM-aware entities. Figure 7.3 illustrates a simple CIM-XML operational message: one which carries a query from a WBEM client to a WBEM server (this example, although generic, was taken from the openPegasus test suite and is therefore subject to the licence described on page 313. If you are XML-literate, you will see that this message contains a request for the WBEM server to enumerate (i.e., "list") the names of instances of the class Linux_CDROMDrive in the "root/cimv2" namespace. In simpler terms, this is a request from an operator to the WBEM server for a list of all CDROM drives being supported by a particular Linux operating system.

<?xml version="1.0" encoding="utf-8"?> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="34422" PROTOCOLVERSION="1.0"> <SIMPLEREQ> <IMETHODCALL NAME="EnumerateInstanceNames"> <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> <NAMESPACE NAME="cimv2"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="ClassName"> <CLASSNAME NAME="Linux_CDROMDrive"/> </IPARAMVALUE> </IMETHODCALL> </SIMPLEREQ> </MESSAGE> </CIM>

In order to define the contents of the CIM messages across the client/server interface, it is best to start with the list of operations that a client might wish to perform. These are divided into two basic types: intrinsic and extrinsic. The XML actually encodes the type of operation, using IMETHODCALL for an intrinsic operation as in Figure 7.3 and METHODCALL for an extrinsic one. I describe the intrinsic operations in the next section and extrinsic ones starting on page 140.