WMI Architecture

[Previous] [Next]

WMI is an extensible data model of a computer system. The WMI architecture is illustrated in Figure 8-1. In this section, I discuss the components of the WMI architecture.

Windows Management Service

The Windows Management Service (WinMgmt.exe) is the primary component of WMI. WinMgmt brokers the communication between WMI consumers (management applications) and WMI providers. WMI data is stored in an object-oriented schema. This schema is designed by the DMTF and offers a single data description mechanism for all components exposing WMI data. By offering a standard schema that supports inheritance, WMI data providers can offer standard data classes and properties while also allowing others to derive vendor-specific extensions to differentiate specific products. Much of this chapter is dedicated to showing exactly how this is done.

Figure 8-1. WMI architecture

CIM Object Manager

The Common Information Model (CIM) Object Manager provides client interfaces that support a variety of access techniques such as COM, scripting, XML, ODBC, and ADO. The object manager supports APIs for creating, deleting, modifying, and retrieving classes and instances. The class instances are either supplied by the CIM repository, in which case they are static instances, or by a provider of some sort (implemented as a COM server), in which case they are dynamic instances.

CIM Repository

The CIM repository is typically used only for storing information about the classes supported by WMI. It is essentially a symbol table and should not be used for large volumes of data. The CIM repository is populated either through object manager APIs that allow the declaration of classes and instances or through a textual form known as MOF (Managed Object Format).

WMI Providers

Providers are COM components that complete the connection between the CIM Object Manager and the managed object. Providers can be built-in or application-specific.

Providers come in various forms, the most common of which is the instance provider, which returns specific information for a managed object. The class provider is a more complex type of provider that is able to return definitions of classes as well as instances. If, for example, you were trying to return information from a database in which someone might be adding new tables, it would be possible to return a class per table, with each class being defined at the time the provider opened the database. This type of provider is advanced and is usually not implemented by services. Active Directory is a rare example of a service that does implement a dynamic class provider. Property providers are a simpler type of provider that allows dynamic properties to be added to static instances.

The general intent of the WMI architecture is to make writing providers as simple as possible—for example, writing an instance provider might be just a matter of generating a few lines of code (that is, with the help of the provider-generating tools and samples in the WMI SDK). The construction of providers also takes advantage of inheritance. If you are adding a new subclass to a class that already has a provider, you need to supply only property values for your new properties or for the ones you are overriding.

Managed Objects

A managed object can be any enterprise component—for example, a Win32 object or service. A service that allows clients to connect using a named pipe could allow itself to be managed by exposing the name of the pipe in a WMI object instance.

Management Applications

Management applications are applications that communicate with a local or remote WinMgmt service. These applications can query the WinMgmt service to determine all the logical and physical components residing on a machine. This information can then be displayed and modified, allowing the user to really understand and change a machine's configuration. In addition, management applications can instruct the WinMgmt service to send notifications when special events occur. For example, a management application can receive a notification when the machine's hard drive has less than 20 percent free space, or when a new process begins running on the managed machine.

Schema

WMI hides all the ugly complexities of the management environment. It takes the Win32 APIs, registry settings, Simple Network Management Protocol (SNMP) Management Information Bases (MIBs) and traps, and all other miscellaneous management interfaces, and it wraps them in a carefully defined schema.

The schema isn't really a separate component of WMI, but it is an important part of WMI. The schema is a collection of classes that describe managed objects. All the components in the WMI architecture support the schema.

The schema, which is provided by the object manager, handles a whole range of information, including systems, networks, applications, devices, and physical components, that affects the installation, configuration, and management of services. The schema consists of instances arranged in classes that have properties, associations, and methods.

WMI Name Evolution

The Common Information Model (CIM) is a specification defined by the Distributed Management Task Force (DMTF) that describes an object-oriented approach to the management of systems and networks. Microsoft originally named its implementation of the CIM "Web-Based Enterprise Management (WBEM)" and named the kernel-mode portion "Windows Management Information (WMI)." The DMTF started a marketing initiative and used "WBEM" as the name to describe a set of management and Internet technologies based on CIM. Microsoft then changed the name of its implementation of the CIM to "WMI" and changed the name of the kernel-mode portion to "WMI extensions for the Windows Driver Model (WDM)." Because of this name evolution, you find "WMI," "WBEM," and "CIM" used throughout the Windows management architecture for functions, interfaces, and classes, as well as other elements.