A Practical Approach to WBEM[s]CIM Management

Introduction

Chapters 11 and 13 describe WBEM servers, listeners, and clients in detail. An element common to these entities is the interfaces between them. This and the next chapter describe those interfaces, setting the scene for the later chapters.

It is the intent of the WBEM architecture that the WBEM clients and listeners have no knowledge of the providers and the manner in which the information that they are requesting and using is obtained. The protocol is designed to isolate the two parts , with the WBEM server acting as a broker between the two. For example, the operating system class has a property, LastBootUpTime , which reasonably holds the time that it was last booted . The manner in which this information is actually extracted from a running operating system by a provider differs , depending on the actual operating system: Linux, HPUX, AIX, MacOS, Z/OS, or Microsoft Windows. The WBEM client should be completely unaware of this, simply requesting the value of the LastBootTime property of the appropriate instance of the CIM_OperatingSystem class.

The WBEM server lies at one end of this interface but, as Figure 7.1 shows, two types of entity lie at the other end:

1. A number of WBEM clients ”the code which encapsulates the operators' requests and commands and passes them to the WBEM server for action.

2. A number of WBEM listeners ”the code which receives information about events ( indications ) that have occurred in the managed system.

Figure 7.1: The WBEM Client/WBEM Server Interfaces

The major distinction between these two is the stimulus which starts the interaction ”in the former case it is the operator or higher-level management system entering a command to which the WBEM server responds and in the latter case it is an event occurring in the system. There is, however, one slightly more subtle difference between these two interfaces ”in the case of the client/server interface it can be assumed that both ends understand CIM and have access to the CIM model; in the case of the server/listener interface it cannot be assumed that the listener has any understanding of CIM. Typically a listener will be handling events from different management systems and so any information sent to it must be carefully de-CIMed.

As part of its WBEM initiative, the DMTF has standardised these interfaces in a set of documents:

• CIM Operations over HTTP, DSP0200 which defines both the client/server and the server/listener interfaces. It defines the operations clients can ask a WBEM server to perform and the format of messages exported by the WBEM server to listeners.

• Representation of CIM in XML, DSP0201 which defines the precise XML syntax of the messages a client would use to invoke a function on a WBEM server. The document defines an XML grammar, written in DTD. ^[1]

• XML Document Type Definition which, for convenience, contains the DTD grammar extracted from document DSP0201.

All of these documents are freely available from the DMTF Web site.

Although the DMTF has standardised the interface between the WBEM client and the WBEM server using XML, note that most WBEM server implementations additionally provide a higher-performance binary interface: essentially the same functions but without the XML encoding. This is a typical trade-off ”use the XML interface for compatibility, use the binary interface for higher performance.

The remainder of this chapter deals with the details of the client/server interface; Chapter 8 deals with the listener interface.

^[1] Document Type Definition.