A Practical Approach to WBEM[s]CIM Management

This section deals with four problems facing a WBEM client:

1. Where is the WBEM server? There may be several WBEM servers in a network, each handling different namespaces. How does a WBEM client find the one with which it should communicate?

2. What can each WBEM server do? Not all WBEM servers support all CIM operations ”perhaps a particular server cannot handle queries. Having found the WBEM server, how can the WBEM client determine its capabilities?

3. Having found the WBEM server and its capabilities, what namespaces does it support?

4. How many tasks has the WBEM server handled and how much information has it received and generated?

These questions are answered in the subsections below.

Finding the WBEM Server

At the time of writing, the task of finding a particular WBEM server (i.e., a WBEM server supporting a particular namespace) is being addressed by the DMTF's InterOp Working Group . It appears that the recommendation, when it emerges, will use the IETF's Service Location Protocol (SLP) and several WBEM server implementations , including openPegasus, have produced code based on that assumption.

SLP is described in RFC2608 and is effectively a protocol whereby so-called User Agents, acting on behalf of clients, can search for a particular service. This can be done in a small network by multicasting or broadcasting requests and in a larger network by making use of a Directory Agent. If you are familiar with CORBA, it might be useful to think of the Directory Agent as a Trader Service, receiving and storing registrations by servers and responding to requests from clients seeking a particular service.

WBEM servers register themselves with a Directory Agent or, in smaller networks, respond to multicast requests from clients.

Finding the Capabilities of the WBEM Server

Anticipating the problem of finding what operations a particular WBEM server supports, the DMTF has defined several classes which all WBEM servers must implement. These classes, which qualify for Olympic honours in any name length competition, are described in detail in the DMTF's "CIM InterOp Model" white paper (DSP0153) and are illustrated in Figure 13.1.

Figure 13.1: WBEM Server Capabilities

These classes inherit from the CIM_Service and CIM_ServiceAccess-Point classes described on page 92. If you are hazy on these two important classes, then I strongly recommend that you reread that section.

As Figure 13.1 illustrates, a CIM_ObjectManager is a CIM_WBEM-Service which is a CIM_Service. Most of the useful information about accessing the WBEM server is held in an instance of the CIM_ObjectManagerCommunicationMechanism class which can be reached through an association on the CIM_ObjectManager instance. CIM_ObjectManager itself does hold one piece of information: a flag to specify whether statistical information about the WBEM server itself is being collected. If this flag is false, then information is not being collected; even if instances of the CIM_CIMOMStatisticalData class are present, no statistics are being gathered.

The instances of the CIM_ObjectManagerCommunicationMechanism class are, however, the main source of information. They contain information about how the WBEM server may be accessed:

• CommunicationMechanism. This is an enumeration describing an encoding for CIM messages and a protocol which may be used to access the WBEM server. Currently only CIM-XML and CIM-SOAP are defined by the DMTF, but you may define your own protocol and specify your support for it here.

  If your WBEM server supports multiple protocols, then one instance of CIM_ObjectManagerCommunicationMechanism will have been created for each protocol.

• FunctionalProfilesSupported. For the purposes of determining what a particular WBEM server can do, the intrinsic methods are grouped into so-called functional groups. These groups are interrelated in the way illustrated in Figure 13.2. FunctionalProfilesSupported is an array of enumerated values which specifies which functional groups the WBEM server supports. Of course, all WBEM servers must support Basic Read operations, otherwise the WBEM client could not access the instances of this class to find out that the CIM server cannot do Basic Read operations!

  Figure 13.2: Functional Groupings of Intrinsic Methods

  The basic classifications given in Figure 13.2 can be broken down further by using free-form strings to specify, for example, precisely which query languages are supported.

  You need to be careful when interpreting the FunctionalProfilesSupported enumeration. If a particular WBEM server indicates that it does not support a particular functional group, then you can be sure that it does not support any of the operations in that group. If, on the other hand, a WBEM server indicates that it does support a particular group then this only indicates that zero ( sic! ) or more of the operations in that group are supported ”i.e., it tells you nothing. If you try to invoke a function which is not supported then the WBEM server will return the CIM_ERR_NOT_SUPPORTED exception.

• MultipleOperationsSupported. Some WBEM servers can only handle a single request in a message, others can handle several ”this Boolean property specifies this. As we will see later, the WBEM server keeps statistics about the number of times each intrinsic method has been called. If multiple operations are included in a single call, then these counters are not kept for individual operations ”a single "multiple operation" counter being incremented instead.

• AuthenticationMechanismsSupported. This defines the types of authentication in which the WBEM server is willing to participate. See page 142 for more details.

• Version. The version number of the protocol in the form M.N where M is the major version number and N the minor one.

Finding the Supported Namespaces

The InterOp common model from the DMTF also covers the question of determining the namespaces supported by a WBEM server. The CIM_ObjectManager class described above has an additional association, CIM_NamespaceInManager, which associates it with a CIM_Namespace class.

Namespaces can therefore be created within a WBEM server by creating an instance of the CIM_Namespace class and associating it with the CIM_ObjectManager. Namespaces can be found by following the CIM_NamespaceInManager associations from the CIM_ObjectManager instance.

Getting Statistics From the WBEM Server

If the CIMOM is collecting statistical data (see the GatherStatisticalData property of CIM_ObjectManager), then one instance of the CIM_CIMOMStatisticalData class is created for each type of intrinsic method call handled by the WBEM server.

For example, a particular instance can be read by a WBEM client to determine how many calls have been made to getInstance(), how much time was spent in total in the WBEM server during these calls, how much time was spent in providers during these calls and the total size of the responses sent back as a result of these calls.

As you can imagine collecting these data can consume a lot of processor time and their collection should be turned on circumspectly.