1.2 The WMI provider types


1.2 The WMI provider types

A WMI provider registered in the CIM repository is an instance of the _Win32Provider system class. Basically, the _Win32Provider system class registers information about a provider's physical implementation with WMI. So, requesting all instances of the _Win32Provider system class in a particular WMI namespace will list all registered providers in that particular namespace.

During the WMI discovery, we saw that a set of system classes is available to define the nature of the providers (see Figure 1.1).


Figure 1.1: The provider registration system classes.

WMI defines a certain number of provider types, which determine the nature of the information delivered by the providers. These providers are as follows:

  • The class providers: These providers supply applications with class definitions. They are rarely implemented, because classes are usually stored in the CIM repository. In most cases, the classes are slow-changing and finite. If classes need to be dynamically generated, then a class provider must be implemented, but this slows down the performance of information retrieval. This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __ClassProviderRegistration system class (see Figure 1.2). The Active Directoryproviders and the SNMP providers are two examples of providers that implement a class provider.

    click to expand
    Figure 1.2: The SNMP class provider registration.

  • The instance providers: These providers are the most common providers and supply instances of a given class. Usually, they provide services such as: instance retrieval, enumeration, modification, deletion, and query processing. This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __InstanceProviderRegistration system class (see Figure 1.3). For instance, the Win32 provider and the Registry provider are implemented as instance providers.

    click to expand
    Figure 1.3: The Registry instance provider registration.

  • The property providers: These providers can support the retrieval and the modification of individual property values. This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __PropertyProviderRegistration system class (see Figure 1.4). The Registry provider is also implemented as a property provider.

    click to expand
    Figure 1.4: The Registry property provider registration.

  • The methods providers: These providers implement the methods of one or more classes. This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __MethodProviderRegistration system class (see Figure 1.5). For example, the Win32 provider and the Registry provider are implemented as method providers as well.

    click to expand
    Figure 1.5: The Win32 method provider registration.

  • The event providers: These providers deliver event notifications to WMI. Next, WMI forwards the events to the appropriate event consumers (temporary or permanent, based on the consumer type). This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __EventProviderRegistration system class (see Figure 1.6). For instance, the SNMP provider, the NT Event Log provider, and the Registry provider are implemented as event providers.

    click to expand
    Figure 1.6: The NT Event Log event provider registration.

  • The event consumer providers: These providers were examined during the WMI discovery. They simply act as consumers of WMI events. This type of provider is registered in the CIM repository with an instance of the __Win32Provider system class, which has a reference to an instance of the __EventConsumerProviderRegistration system class.The Command-Line event consumer, the SMTP event consumer, and the Active Script event consumer are examples of event consumer providers (see Chapter 6 in Understanding WMI Scripting).

Among these provider types, WMI also supports high-performance providers. These providers greatly increase the speed at which WMI clients can obtain information from WMI. They are nothing more than instance providers implemented as Dynamic-Link Libraries (DLL). We will revisit this provider type later in this book when examining the Performance Counter provider and the Cooked Counter provider in Chapter 3, section 3.8.

Throughout Understanding WMI Scripting, we explain the difference between a class and an instance. While examining the properties exposed by some classes representing real-world manageable entities, we have seen that some classes only expose properties (i.e., Win32_WMISetting or Win32_NTLogEvent classes), while others expose both properties and methods (i.e., Win32_Service class). Because the characteristics implemented in the classes are nothing more than an object model representing the real-world manageable entities, it is clear that the primary role of the WMI provider is to provide the real-world information. This implies that a provider will be:

  • An instance provider, if it provides instances of real-world manageable entities

  • A property provider, if it provides properties

  • A method provider, if it provides methods

Since the real-world entities can be instantiated with WMI to represent real-world objects, this also implies that methods can be invoked to perform some actions and that WMI events can be received to monitor modifications. Therefore, it is very common that a single provider combines different roles at the same time. For instance, the Registry provider is made of one single DLL called STDPROV.DLL, which exposes three COM objects. These three COM objects implement the four provider types used by WMI to manage the registry:

  • The first COM object implements an instance and a method provider. It is called RegProv.

  • The second COM object implements a property provider and is called RegPropProv.

  • The third COM object implements an event provider and is called RegistryEventProvider.

Therefore, the Registry provider must be registered accordingly in the CIM repository with:

  • Three instances of the __Win32Provider system class for its physical implementation (STDPROV.DLL), where each instance contains the CLSID of the COM object registered in the registry (see Figure 1.7).

    click to expand
    Figure 1.7: The Registry provider registration in the CIM repository and in the registry.

  • An instance of the __InstanceProviderRegistration system class with a reference to its __Win32Provider instance.

  • An instance of the __MethodProviderRegistration system class with a reference to its __Win32Provider instance.

  • An instance of the __EventProviderRegistration system class with a reference to its __Win32Provider instance.

When we began the WMI discovery, we saw what a reference and an association are (please refer to Chapters 2, 3, and 4 in Understanding WMI Scripting for more information on this subject). We learned how to locate references and associations that exist with a class and an instance. This knowledge is useful, because this is the way to determine the provider type. Each time an instance of the __Win32Provider system class is available, we have an instance of a WMI provider. By examining the references available from that instance, we determine the WMI provider type (Instance provider, Method provider, etc.). Doing so, we have created a WMI provider discovery technique that helps us to understand some of the WMI provider capabilities, which also determine the behavior of the WMI classes they support.




Leveraging WMI Scripting
Leveraging WMI Scripting: Using Windows Management Instrumentation to Solve Windows Management Problems (HP Technologies)
ISBN: 1555582990
EAN: 2147483647
Year: 2003
Pages: 82
Authors: Alain Lissoir

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net