WMI and CIM Concepts and Terminology

Updated: December 4, 2001

CIM is an acronym for the Common Information Model. The model abstracts and describes the "managed environment" using an object oriented paradigm. The CIM object schema addresses systems, devices, application deployment and the physical environment. Additional models will soon be released that describe software that is running in the environment, as well as users, networks, and policies. Microsoft Windows Management Instrumentation (WMI) is the Microsoft implementation and supporting infrastructure for the Common Information Model. Both CIM and WMI bring new abstractions, concepts and terminology to the management domain. This article defines and describes the relationships between these various concepts and terms.

On This Page

  Introduction
  What Is CIM?
  Object-Oriented Design and Constructs
  How Are CIM Schemas Expressed?
  What Is WMI?
  Management Infrastructure
  Management Applications
  WMI Providers and Managed Objects
  Data Flow
  WMI and Directory Services
  References

Introduction

Traditionally, managing the computing environment has been a difficult and confusing task. Each problem domain (networks, operating systems, devices) has its own terminology and management requirements. Yet, all these "managed entities" must work together in order for business to proceed, or even for a home computer user to access the Internet and favorite web sites.

At the lowest level, management involves instrumentation (data) and the use of instrumentation to troubleshoot computing problems (management applications). If you put some framework between the data and the applications, then standard tasks (like managing the data, or registering for and forwarding events) does not have to be recreated in each management application. If you have a standard way of describing the instrumentation data, then more generic and wider ranging applications can be created (versus coupling the data with the application in a proprietary fashion).

Examined in this article are a framework (WMI) and a standard schema for data (CIM) to facilitate the management of the entire computing environment.

 Top of page

What Is CIM?

The Common Information Model (CIM) is an object-oriented model that represents and organizes the information in a "managed environment." CIM objects include computer systems, devices (like printers and batteries), controllers (for example, PCI and USB controllers), files, software, physical elements (like chassis and connectors), people, organizations, networks, protocol endpoints, policy, and more. CIM also is evolving its eventing object hierarchy and mechanisms.

Going beyond just describing raw data, CIM provides additional capabilities. It allows the definition of associations and methods. Associations describe relationships between objects--dependencies, component relationships (when an object is a component or part of a whole), connections (topologies), and more. Input/output parameter lists and return codes can be defined for methods.

CIM defines a series of objects with respect to a basic set of classes and associations. The following information models exist:

• Core models--incorporate notions applicable to all management domains.

• Common models--incorporate notions common to specific management domains, independent of particular technologies or implementations. Common domains include systems, applications, devices, users, and networks. These models provide a basis for the development of management applications and include a set of base classes for extension into technology-specific areas.

The models are extensible. Extension schemas represent technology-specific additions to the Common models. For example, extension schemas specific to certain operating systems (such as Windows and UNIX) have been defined.

The goal of the Distributed Management Task Force (DMTF), which publishes CIM, is to model all aspects of managed environments. By defining objects and their properties, methods, and associations in a uniform manner, information from networks, devices, systems, and applications can be accessed more easily by management applications. And the numerous problem domains can be tied together. Therefore, more powerful management capabilities can be provided.

 Top of page

Object-Oriented Design and Constructs

One of the goals of the CIM model is to consolidate and extend existing management standards and instrumentation such as Simple Network Management Protocol (SNMP), Desktop Management Interface (DMI), Common Management Information Protocol (CMIP), and so on. It does this by using object-oriented design and constructs.

Using an object-oriented approach provides:

• Object abstraction and classification. To decrease the complexity of managed domains, managed objects are defined and grouped into classes based on common properties, associations with other classes, and methods. Managed objects are either physical or logical entities in the computing environment, modeled using CIM. For example, a managed object can be hardware such as a cable or system chassis, software such as a database application, or other logical entities such as computer systems, files, and devices.

• Object inheritance. By creating subclasses from high-level, fundamental objects, developers can add the appropriate level of detail and complexity to the model. Subclasses inherit all the properties, methods, and associations of their higher-level parent objects.

• Ability to model dependencies, component, and connection associations. Using the object-oriented paradigm, the relationships between objects and their associations can be modeled directly. The ways in which such relationships are named and defined describe the semantics of the object associations. Properties of the associations can be used to provide additional semantics and information. Before CIM, management standards had to capture relationships between managed objects in multi-dimensional arrays or in cross-referenced data tables.

• Standard inheritable methods. Defining standard object methods (behavior) provides another level of abstraction and encapsulation. Imagine the flexibility and possibilities of a standard able to invoke a "Reset" method against a hung device or a "Reboot" method against a hung computer system regardless of the hardware, operating system, or device.

 Top of page

How Are CIM Schemas Expressed?

The CIM schemas are written in MOF (Managed Object Format). It is a human- and machine-readable format describing the structure and contents of the models. Example class definitions (from the CIM Core MOF) are included here for reference:

// ==================================================================















//    Product















// ==================================================================















        [Description (















         "CIM_Product is a concrete class that is a collection of "















         "PhysicalElements, SoftwareFeatures and/or other Products, "















       "acquired as a unit. Acquisition implies an agreement "















       "between supplier and consumer which may have implications "















       "to Product licensing, support and warranty.") ] 















class CIM_Product















{















        [MaxLen (64), Description (















         "A short textual description (one-line string) for the "















         "Product.") ] 















    string Caption;















        [Description ("A textual description of the Product.") ] 















    string Description;















        [Key, MaxLen (64), Description (















         "Product identification such as a serial number on software "















         "or a die number on a hardware chip."), 















         MappingStrings {"MIF.DMTF|ComponentID|001.4"} ] 















    string IdentifyingNumber;















        [Key, MaxLen (256),















       Description ("Commonly used Product name."), 















       MappingStrings {"MIF.DMTF|ComponentID|001.2"} ] 















    string Name;















        [MaxLen (64), Description (















       "Product SKU (stock keeping unit) information.") ] 















    string SKUNumber;















        [Key, MaxLen (256), Description (















         "The name of the Product's supplier. Corresponds to the "















         "Vendor property in the Product object in the DMTF Solution "















         "Exchange Standard."), 















         MappingStrings {"MIF.DMTF|ComponentID|001.1"} ] 















    string Vendor;















        [Key, MaxLen (64), Description (















         "Product version information. Corresponds to the Version "















         "property in the Product object in the DMTF Solution "















         "Exchange Standard."), 















         MappingStrings {"MIF.DMTF|ComponentID|001.3"} ] 















    string Version;















};































// ==================================================================















//    ProductParentChild















// ==================================================================















        [Association, Aggregation, Description (















         "The CIM_ProductParentChild association defines a parent "















         "child hierarchy among Products. For example, a Product may "















         "come bundled with other Products. ") ] 















class CIM_ProductParentChild















{















        [Aggregate, Key, Description (















       "The parent Product in the association.") ] 















    CIM_Product REF Parent;















        [Key, Description ("The child Product in the association.") ] 















    CIM_Product REF Child;















};

This last class definition, CIM_ProductParentChild, describes a relationship (or association) between Product classes. That the class is an "association" is described using a keyword or qualifier. The specific usage of the ProductParentChild association is to depict that one Product is bundled inside another. The particular Product instances that represent the "bundler" and "bundlee" would be "referenced" as the properties Product and Child, respectively. But how do you reference instances? Instances are referenced and named by concatenating all the properties of the class that are qualified with the "Key" qualifier.

For CIM_Product, these instances are:

• IdentifyingNumber
• Name
• Vendor
• Version

Key and Association are but two of many keywords (qualifiers) that precede a class or property declaration. Qualifiers are part of the MOF syntax and are found between brackets, "["and"]." They describe and characterize the class or property.

A qualifier is a name/value pair. For example, a "MappingString" qualifier is defined with a string array value to describe the "mappings" from DMI or SNMP to CIM. A "Units" qualifier would contain string values such as "Bytes," "Degrees C," and so on.

Another syntax for expressing CIM information is Extensible Markup Language (XML), a standard from the World Wide Web Consortium (W3C). It is a markup language like HTML, but is much more extensible. HTML deals with the syntax of web data. XML describes the content, indicating how it should look and how to understand it.

In XML, the emphasis is on data domain extensions, rather than rendering. (The latter can be addressed, however, using other standards like Extensible Style Sheet Language (XSL).) Data domains can define their own extensions and language--therefore, defining their own semantics.

Last year, the DMTF released an XML Document Type Definition (DTD) to define a CIM semantic for XML data content. It specifies a grammar for expressing CIM classes and instances. This grammar is used as the payload of an HTTP access of CIM-based data.

CIM methods are handled in XML through XML RPC. These operations are defined by the Internet Engineering Task Force (IETF) and extended by the DMTF.

 Top of page

What Is WMI?

Windows Management Instrumentation (WMI) is an infrastructure to support the CIM model and Microsoft-specific extensions of CIM. It offers a powerful set of services, including query-based information retrieval and event notification. Data is input into the CIM-based repository via Providers (conceptually similar to SNMP Agents). Data is accessed via a COM/DCOM API: IWbemServices. Scripting via the Windows Scripting Host (WSH) is also provided.

The WMI infrastructure ships in Windows 98, Microsoft Windows NT 4.0 SP4, Windows 2000, and Windows XP. It also is supported on Windows 95. It runs as the "Windows Management" Service.

The architecture of the Windows Management Instrumentation technology consists of:

• A management infrastructure
• Management applications
• Providers of data from "managed objects"

This is described pictorially in Figure 1.

Figure 1. WMI Infrastructure

 Top of page

Management Infrastructure

The management infrastructure includes the CIM Object Manager (CIMOM) and the WMI repository. The executable process that provides all of the WMI functionality is WinMgmt.exe.

CIMOM provides a collection and manipulation point for objects and information stored in the repository. It facilitates gathering and manipulating information about these objects. A communication path between management applications and Providers is supported by CIMOM, via the IWbemServices COM/DCOM API. This API allows for object creation, deletion, data retrieval and much more. It supplies event notification and query processing services, and can be accessed from several programming languages such as Microsoft C and C++ development systems.

The WMI repository is a central storage area for management data. It holds static management data and information on which Provider to contact for dynamic data. Data can be placed in the repository by using either the Managed Object Format (MOF) language (and the WMI compiler, mofcomp.exe), or the CIMOM COM/DCOM API.

Namespaces in the Repository
Data in the WMI repository is organized by schemas, which are loaded into "namespaces." A namespace provides a "domain" (or container) for a schema and for the instances of the classes in that schema. (Note that all instances must be uniquely named, by their Key properties, within a namespace. To completely and unambiguously specify an object name, both a namespace path and the object's "model name" must be defined. The "model name" is the concatenation of all the Key properties of the object.)

Namespaces can be used to:

• Define collections of management information (objects and associations) to limit resource requirements, such as repository size, or for optimized query.
• Define specific "views" to address particular management domains--for example, aggregating all environmental data (temperature and voltage) for an office in one namespace, placing storage-related data in another namespace, and managing a cluster in a third namespace.
• Allow the use of different models and schemas.

Namespaces can overlap with respect to their contents.

One might assume that all schemas in the WMI repository are CIM-based schemas. This is not true. The schemas are all defined in MOF, but currently only the "CIMV2" namespace is CIM schema based. The "CIMV2" namespace represents data from the local platform. Most of the data is obtained from Microsoft Win32 APIs. Its schema is based on the CIM Core, System, Devices and Application Models. Other WMI namespaces contain directory schema objects, SNMP OID-based (object ID-based) objects, DMI group objects, and so on. Although defined using MOF syntax, these models do not utilize or derive from the CIM schema's object definitions and hierarchy. It is assumed that these "other" and "legacy" namespaces will disappear over time--their data being mapped directly into the CIM object hierarchy.

 Top of page

Management Applications

Management applications are MMC snap-ins, stand-alone applications, or Windows NT services that use or process information originating from managed objects. Applications can (and typically do) directly access the CIMOM COM interfaces. However, additional access methods are available, such as Open Database Connectivity (ODBC) and Active Directory Service Interface (ADSI) interfaces, or the WMI scripting API.

 Top of page

WMI Providers and Managed Objects

Managed Objects are either physical or logical entities that are described using MOF and stored in the WMI repository. Management applications can access these objects using CIMOM.

WMI Providers act as intermediaries between the CIM Object Manager and one or more managed objects. When CIMOM receives a request from a management application for information that is not available from the WMI repository (that is, dynamic data from a managed object), or for notification of events that it doesn't support, it forwards the request to the appropriate Provider. The Provider then supplies the information or event notification requested. Providers are standard COM and DCOM servers (implemented either in-proc or out-of-proc).

What Providers Are Available Now?The Windows Management Instrumentation Software Development Kit (SDK) includes several built-in Providers. These built-in (or standard) Providers supply data from sources such as the system registry and the Event Log.

The following Providers are currently available:

• Performance Monitor Provider--provides access to Windows NT Performance Monitor data.
• Registry Provider--provides access to system registry data.
• Registry Event Provider--sends events when changes occur to registry keys, values, or trees.
• SNMP Provider--provides access to events and data from SNMP devices.
• Windows NT Event Log Provider--provides access to data and event notifications from the Windows NT Event Log.
• Win32 Provider--provides access to data from the Win32 subsystem.
• WDM Provider--provides access to data and events from device drivers that conform to the Windows Driver Model WMI extensions.

 Top of page

Data Flow

In order to understand how WMI functions, it is useful to track a piece of data from definition through retrieval by a management application. Although this is just one of many scenarios and data flows that could occur, it serves to illustrate the WMI infrastructure and usage of the CIM schemas.

The following data flow may occur:

1. An AAAProvider is coded and registers with COM (via the registry, independent of WMI).

2. An MOF is created specifying that a new "AAAProvider" is being registered with WMI. Specifically, two new instances of WMI classes are defined. First, an instance of the _Win32Provider class describes the physical implementation of the AAAProvider (for example, its COM class ID). Second, an instance of the _InstanceProviderRegistration describes the logical implementation of the Provider (for example, whether the Provider supports Gets and Puts of instances). (Note that WMI uses its repository and MOF syntax to manage its namespace, Providers, and so on.)

3. In this same MOF, a subclass of CIM_Product named AAA_SoftwareProduct is defined. Let's assume that a few new properties are added, such as LanguageEdition and DestinationCountry. And, among the qualifiers for the class, Dynamic and Provider ("AAAProvider") are declared.

4. The new MOF is compiled into the CIMV2 namespace using the WMI mofcomp executable. (This can either be done manually, or by placing the MOF into the directory identified by the registry key: SOFTWARE\Microsoft\WBEM. This key contains a REG_SZ value named "MOF Self-Install Directory.")

5. Later, a management application queries CIMOM for all instances of CIM_Product (via IWbemServices::CreateInstanceEnumAsync).

6. CIMOM locates the CIM_Product object in the repository and attempts to enumerate its instances (and those of any subclass). CIMOM loads the AAAProvider and asks it to enumerate instances of the AAA_SoftwareProduct class.

7. The management application finds that instances of AAA_SoftwareProduct are returned. It then does an IWbemServices::GetObjectAsync request against those instances to obtain the class data.

 Top of page

WMI and Directory Services

The Directory and WMI are similar and complementary. Both offer a data store, and query and indexing engines. However, the uses for the data stores and engines are different.

The Directory provides a replicated, highly available store, optimized for fast access to largely static information. Directory-based data relationships are simple. Basically, the Directory holds the necessary location information for finding users, systems and devices in the enterprise, as well as storing meta-information about the network and environment that is not available from any other data store.

WMI provides access to detailed system and device information for "managed objects" in the enterprise. Both static and volatile properties are supported. WMI describes much more complex relationships and other associations (such as dependency relationships) than the Directory can. The primary focus of WMI is the storage and retrieval of management data.

WMI and the Directory can be used together to locate and bind to system, device and user objects, gather information from these objects, and manage the enterprise.

 Top of page

References

• For more information on the CIM standard, refer to the DMTF web site at http://www.dmtf.org .
• For more information on the WMI framework, refer to the Microsoft web site at http://msdn.microsoft.com/en-us/library/ms257340(VS.80).aspx.
• For more information on XML, refer to the W3C web site at http://www.w3.org .
• For more information on the XML RPC standard, refer to the IETF web site at http://www.ietf.org .