A Practical Approach to WBEM[s]CIM Management

Overview

The chapter contains a description of the WBEM architecture. The WBEM server lies at the heart of this architecture and you may find it useful to place a bookmark in page 39 so that you can easily refer to Figure 4.4 as you read this chapter. I will start, however, with the problem that the WBEM architecture is designed to solve.

Figure 4.1 illustrates the management gap which WBEM is designed to fill: on the left are operators' workstations and on the right a device containing hardware (cards, slots, power supplies , etc.), software (word processors, Web browsers, OSPF routing stacks, operating systems, etc.) and services (voice mail, virtual networks, firewall, etc.). A mechanism is needed to connect the two to allow authorised operators to configure and interrogate the device and to receive information about alarms and events occurring on it. Equally important, it is necessary to prevent unauthorised operators from doing the same thing.

Figure 4.1: The Management Gap

Note that when I use the term "operator" in this chapter (and elsewhere in this book), I mean something or someone giving commands to the management system. This may be a human sitting at a workstation, it may be a program running a script to configure many devices or it may be a higher-level management system. By virtue of its sophisticated modelling language and flexible interface, WBEM is particularly suited for use in hierarchical management systems like this.

The two sides of Figure 4.1 represent two different levels of abstraction. The state of the cooling fan within the hardware of the device might actually be accessed by reading the top two bits of register 17 in the integrated circuit at address OxFFFF6638 and comparing the result with 00 (fan failed), 01 (fan operating), 10 (fan functional but off), and 11 (fan not fitted). This is something that the operator would prefer not to know; he or she simply wants to know the state of the fan, not how to obtain that state. We need a means of hiding the details from the operator, particularly if two different devices are being managed at the same time, each with a fan, but with disparate ways of accessing their state.

In Figure 4.2, a WBEM server, as illustrated in detail in Figure 4.4, has been added. The primary role of the WBEM server is to act as a broker between the WBEM clients , working on behalf of the operators, and the providers, working with internal knowledge of the hardware, software, and services. It can act as a broker in this way because it offers standard interfaces to these components ”thereby isolating the clients from the providers. Clients need have no knowledge of how their requests are being handled; in fact they need have no knowledge of the existence of providers. Providers, on the other hand, need have no knowledge of the origin of the commands they are being given to execute. The WBEM server provides this isolation, and WBEM clients and providers should be designed to be independent of each other to avoid restricting enhancements to the management system. This isolation means that a WBEM client, needing to know the amount of free disk space on a computer, should be able to address precisely the same request to PowerPC-based PCs running Linux, Spare Computers running Solaris, eServers running zOS, RISC computers running HPUX, or Intel-based PCs running Windows, and get an answer in the same format. The actual mechanism for obtaining the information on each of those operating systems may vary, but the means of accessing it does not.

Figure 4.2: The WBEM Components

The protocols used between a WBEM client and a WBEM server are described in Chapter 7.

Of course, the abstract model of the device must find its way from the imagination of the designer into the WBEM server. The starting point for this process is the set of models standardised by the DMTF and published in a formal language known as mof. For some devices, these standard models may suffice, but if they do not, you can extend them by writing additional mof code, known as "extension models." The standard and device-specific mof code is then passed through a compiler (see Figure 4.3) which acts as a WBEM client, and loads it into the WBEM server.

Figure 4.3: mof Compilation

In addition to checking the syntax of the mof code and producing a version of the model suitable for the WBEM server, the compiler may produce other output ”including skeleton code for providers and user documentation. This varies from implementation to implementation.

Therefore, the steps that you need to take to manage a new device using WBEM/CIM are as follows :

1. Examine the DMTF's standard models and determine how well they meet your needs. Write any additional mof code to extend the standard models as required. I describe the mof language in Chapter 5 and the standard models in Chapter 6.

2. Obtain, compile, and integrate a WBEM server with the software on your device. There are various open source and commercial WBEM servers available in C, C++, and Java (see Chapter 15).

3. Write the providers necessary to handle the low-level detail of your device. The WBEM architecture gives a useful infrastructure into which the providers are built, governed largely by the interface between the WBEM server and the providers (see Chapter 11 and the example in Chapter 12).

4. Write the necessary clients to interact with the WBEM server on behalf of the operators. Client development is also usefully circumscribed by the interface with the WBEM server (see Chapters 7 and 8). Note that the actual interface presented to the operator (graphical, textual, etc.) is outside the scope of WBEM/CIM; the WBEM/CIM architecture stops at the client. In effect, the use of the WBEM server as a broker allows the development of clients and providers to proceed independently of one another.

Once this work has been carried out, the management system is ready for use. For most applications, the most significant savings in development time arise through the reuse of the standard models and the WBEM server code. A substantial amount of work has gone into producing both of these and ongoing enhancement and bug fixing is also occurring. Given the free availability of the DMTF models and the open source WBEM server implementations , some decisions that you need to make concern your involvement with the communities producing them:

• Would it be useful to take your extension models back to the DMTF for standardisation within your industry? Would you get commercial advantage out of using a standardised management interface or do you need to keep it proprietary?

• Should you contribute to the development of the open source WBEM servers? By doing so, you can better influence the direction and release timings of the development.