Example | A Practical Approach to WBEM[s]CIM Management

I describe the interfaces between an operator, a WBEM client, a WBEM server, a listener and a provider in detail in later chapters. To give you an informal view of the interactions, this section outlines a simple use-case of a service-level command entered by an operator at position E in Figure 4.6.

Assume that the service-level operator has entered a command regarding the current state of a particular instance of a service. This operator may have little knowledge or understanding of the underlying components of the service which are implemented in a heterogeneous collection of devices from different manufacturers. The sequence of events is something like the following.

The operator's command is translated from the specific user interface (perhaps command-line or graphical) into a query on a particular service status. The service has been modelled in CIM and its model is contained in the repository of the high-level management server shown in Figure 4.6. The current state of the service has been modelled as a variable which may take various values such as "not installed," "running," "down for maintenance," and "failed."
The high-level WBEM client constructs a request for this value using a standard format defined by the DMTF. This request is encoded in a protocol known as CIM-XML and passed to the high-level WBEM server using HTTP.
The high-level WBEM server consults its model stored in the repository and finds that a provider is associated with the requested value.
The high-level WBEM server therefore invokes the service provider ( marked A in Figure 4.6) with a request for the current state of the service. Unfortunately, this is not something which the provider monitors in real-time because this would require a significant amount of unnecessary trafficif no one wants to know about the value, why collect it? The provider does, however, understand the semantics of the service and knows how to collect the information.
The service provider has access to the high-level model and, by acting as a WBEM client, extracts the information from the WBEM server about the precise devices forming part of the service. (Note: It could have held this information locally; but because the WBEM server is designed for this type of function, this is often unnecessary).
The service provider then requests the values of the current state fields from each of the component devices from the high-level WBEM server. The high-level WBEM server consults its model and finds that there are providers associated with each of these values and invokes themthe providers marked B in Figure 4.6.
These providers do not have the information stored locally, but they understand how it may be retrieved from lower-level management systemsthose on the devices. They therefore act as WBEM clients and issue commands, encoded in CIM-XML, to the individual low-level WBEM servers (marked C in Figure 4.6).
Each low-level WBEM server follows a pattern similar to that of its high-level brother: it scans its model (now very device specific) and finds that the information it requires is handled by a provider. It therefore invokes a provider ( D in Figure 4.6).
The low-level providers consult the actual device as necessary (reading registers, etc.) and return a response to the WBEM server.
The low-level WBEM servers each respond to the calls made to them by the higher-level system and eventually all of the responses are gathered together by the high-level service provider A.
The service provider then does whatever calculation is appropriate for the overall state of the service, given the states of the component parts , and returns the value to the high-level WBEM server.
The high-level WBEM server encodes the response in CIM-XML and passes it back to the WBEM client, which converts it into the required format for the operator and displays it.

When following this example, note that each provider only handles what it understands directly, the isolation provided by the WBEM architecture having allowed the management problem to be partitioned into smaller, more tractable parts. Note also that all messages sent between the WBEM clients and WBEM servers are encoded in exactly the same format, independent of the hierarchical levelthe commands and responses are always couched in terms of the model and the model is available to all parties.

The outcome of this rather complex example is that the operator entered a command at the service level, the level he or she understands, and got back a response at the same level. The management systems on the individual devices received only commands at their level and they responded at that level. There is a clear demarcation between the levels, but a common model, language, protocol, and architecture provided by WBEM to allow seamless interaction.