Inside Windows Management Interface

Since Windows NT's inception, the OS has incorporated integrated performance and system-event monitoring tools. Applications and the system typically use the Event Manager to report errors and diagnostic messages. The Event Viewer utility, which Microsoft built into NT, lets administrators view event output from either the local computer or another computer on the network. Similarly, the Performance API lets applications and OS subsystems report performance-related statistics that administrators then use the Performance Monitor utility to view.

Although NT's event- and performance-monitoring features meet their design goals, these features have limitations. For example, the facilities' programming interfaces differ from one another, and this variation increases the complexity of applications that use both event and performance monitoring to collect data. The Performance API's performance can be poor, especially across a network, because the API is an all-or-nothing proposition: No way exists for an application to query the performance information of only specific components. Perhaps the biggest drawback to the existing monitoring facilities is that they have little or no extensibility, and neither provides the two-way interaction necessary in a management API. Applications must provide data in predefined formats for event logging or performance-data collection. The Performance API provides no way for an application to receive notification of performance-related events, and applications that request notification of Event Manager events can't restrict notification to specific event types or sources. Finally, clients of either collection facility can't communicate with event- or performance-data providers through the Event Manager or Performance API.

Windows Management Interface (WMI) is Microsoft's next step in Windows enterprise-management support. WMI is Microsoft's implementation of Web-Based Enterprise Management (WBEM) technology. WBEM is a standard that the Distributed Management Task Force (DMTF—an industry consortium) defines. The WBEM standard encompasses the design of an extensible enterprise data-collection and management facility that has the flexibility and extensibility required to manage local and remote systems that comprise arbitrary components. Microsoft implemented WMI on Windows 98, made WMI available for NT 4.0 with Service Pack 4 (SP4) or later and Win95 OSR2, and integrated WMI into Windows 2000 (Win2K). However, Microsoft's WMI development targets Win2K. As third parties begin to implement WMI-based management tools, administrators will gain the ability to monitor and control all aspects of their Win2K, NT, or Win9x systems from anywhere in their enterprise. In this column, I take you inside WMI. Most of what I describe applies to all the Windows platforms that support WMI, but when I discuss implementation details, I focus on Win2K.

WMI Architecture
WMI architecture consists of the four segments that Figure 1, page 74, shows: management applications, WMI infrastructure, providers, and managed objects. Management applications are Windows applications that access and display or process data that the applications obtain about managed objects. A simple example of a management application is a Performance Monitor replacement that relies on WMI, rather than the Performance API, to obtain performance information. A more complex example is an enterprise-management tool that lets administrators perform automated inventories of the software and hardware configuration of every computer in their enterprise.

Developers typically must target management applications to collect data from and manage specific objects. An object might represent one component, such as a network adapter device, or a collection of components, such as a computer (the computer object might contain the network adapter object). Providers need to define and export the representation of the objects that management applications are interested in. For example, if the vendor of a network adapter wants the adapter to be WMI-capable, the vendor must develop a provider that serves as the interface to the adapter, querying and setting the attributes' state and behavior as the management applications direct. In some cases (e.g., device drivers), Microsoft supplies a provider that has its own API to help developers of provider plugins leverage the provider's implementation with minimal coding effort.

The WMI infrastructure is the glue that binds management applications and providers. The infrastructure also serves as the object-class store and, in many cases, as the storage manager for persistent object properties. WMI implements the store, or repository, as an on-disk database. As part of its infrastructure, WMI supports several APIs through which management applications access object data and providers supply data and class definitions.

Win32 programs use the WMI COM API, the primary management API, to directly interact with WMI. Other APIs layer on top of the COM API and include an ODBC adapter for Microsoft's Access database application. A database developer uses the WMI ODBC adapter to embed references to object data in the developer's database. Then, the developer can easily generate reports with database queries that contain WMI-based data. WMI ActiveX controls support another layered API. Web developers use the ActiveX controls to construct Web-based interfaces to WMI data. Another management API is the WMI scripting API, for use in script-based applications and Visual Basic (VB) programs. WMI scripting support exists for VBScript, JScript, Active Server Pages (ASP), and HTML.

As they are for management applications, WMI COM interfaces constitute the primary API for providers. However, unlike management applications, which are COM clients, providers are COM or Distributed COM (DCOM) servers (i.e., the providers implement COM objects that WMI interacts with). Possible embodiments of a WMI provider include DLLs that load into WMI's manager process, and standalone Win32 applications or Win32 services. Microsoft includes a number of built-in providers that present data from well-known sources such as the Performance API, the Registry, and the Event Manager. The WMI software development kit (SDK) lets developers develop third-party WMI providers.

Providers
At WBEM's core is the DMTF-designed Common Information Model (CIM) specification. CIM specifies how management systems represent, from a systems management perspective, anything from a computer to an application or device on a computer. Provider developers use CIM to represent the components that make up the parts of an application for which the developers want to enable management. Developers use the Managed Object Format (MOF) language to implement a CIM representation.

In addition to defining objects, a provider must interface WMI to the objects. WMI classifies providers according to the interface features the providers supply. Table 1 lists WMI provider classifications. Note that a provider can implement one or more features; therefore, a provider can be, for example, both a class and an event provider. To clarify the feature definitions in Table 1, let me discuss a provider that implements most of those features. The Event Log provider defines several objects, including an Event Log Computer, Event Log Record, and Event Log File. The Event Log provider is a Class provider because it defines these objects using classes and must give the class definitions to WMI. This provider is also an instance provider because it can define multiple instances for several of its classes. One class for which the Event Log provider defines multiple instances is the Event Log File class; the Event Log provider defines an instance for each of the system's event logs (i.e., System Event Log, Application Event Log, and Security Event Log).

The Event Log provider defines the instance data and lets management applications enumerate the records. The Event Log provider also lets a management application query specific Event Log records' properties; this capability classifies the Event Log provider as a Property provider. To let management applications use WMI to back up and restore the Event Log files, the Event Log provider implements backup and restore methods for Event Log File objects. Doing so makes the Event Log provider a Method provider. Finally, a management application can register to receive notification whenever a new record writes to one of the Event Logs. Thus, the Event Log provider serves as an Event provider when it uses WMI event notification to tell WMI that Event Log records have arrived.

CIM and MOF
CIM follows in the steps of object-oriented languages such as C++ and Java, in which a modeler designs representations as classes. Using classes lets developers use the powerful modeling techniques of inheritance and composition. Subclasses can inherit the attributes of another class and add their own characteristics or override the characteristics they inherit from the parent class. A class that inherits properties from another class derives from the parent class. Classes also compose: A developer can build a class that includes other classes.

The DMTF provides multiple classes as part of the WBEM standard. These classes are CIM's basic language and represent objects that apply to all areas of management. The classes are part of the CIM core model. An example of a core class is CIM_ManagedSystemElement. This class contains a few basic properties that identify physical components such as hardware devices and logical components such as processes and files. The properties include a caption, description, installation date, and status. Thus, the CIM_LogicalElement and CIM_PhysicalElement classes inherit the attributes of the CIM_ManagedSystemElement class. These two classes are also part of the CIM core model. The WBEM standard calls these classes abstract classes because they exist solely as classes that other classes inherit (i.e., no object instances of an abstract class exist). You can therefore think of abstract classes as templates that define properties for use in other classes.

A second category of classes represents objects that are specific to management areas but independent of a particular implementation. These classes constitute the common model and are considered an extension of the core model. An example of a common-model class is the CIM_FileSystem class, which inherits the attributes of CIM_LogicalElement. Because virtually every OS, including Win2K, Linux, and other varieties of UNIX, rely on file-system-based structured storage, the CIM_FileSystem class is an appropriate constituent of the common model.

The final class category comprises technology-specific additions to the common class. Win2K defines a large set of these classes to represent objects specific to the Win32 environment. Because all OSs store data in files, the CIM common model includes the CIM_LogicalFile class. The CIM_DataFile class inherits the CIM_LogicalFile class, and Win32 adds the Win32_PageFile and Win32_ShortCutFile file classes for those Win32 file types.

   Previous  [1]  2  Next