Implementing the Primary Interface for a Class Provider
There are two ways to implement a class provider: implement the interface as a push provider, or as a pull provider.
The following sections are discussed in this topic:
- Implementing the Primary Interface for a Push Class Provider
- Implementing the Primary Interface for a Pull Class Provider
Implementing the Primary Interface for a Push Class Provider
Whereas all providers implement IWbemProviderInit for initialization and at least one other interface as their primary interface, a push provider implements only IWbemProviderInit.
Ensure that your implementation performs the following tasks:
- Retrieves the appropriate class data.
- Places the data in the WMI repository.
- Deletes obsolete data.
After completing the initialization process, WMI handles all application requests for classes belonging to the push provider without any further provider interaction. Afterward, the push provider effectively acts as a client of WMI rather than a provider. For more information about implementing IWbemProviderInit, see Initializing a Provider.
Note
When calling WMI to create, update, or remove data in a push provider, set the lFlags parameter to include the WBEM_FLAG_OWNER_UPDATE flag in all calls to IWbemServices methods.
Implementing the Primary Interface for a Pull Class Provider
A class pull provider should implement IWbemServices as the primary interface. The IWbemServices interface supports data retrieval, data update, data removal, enumeration, and query processing. However, because IWbemServices is also used by applications and providers to request services of WMI, IWbemServices contains many methods that are irrelevant to a class provider. Your implementation must support class retrieval and enumeration, through the GetObjectAsync and CreateClassEnumAsync methods respectively. The following table lists the additional asynchronous IWbemServices methods that you can implement for a class provider.
| Method | Feature |
|---|---|
| PutInstanceAsync | Modification |
| DeleteClassAsync | Deletion |
Note
Because the callback to the sink might not be returned at the same authentication level as the client requires, it is recommended that you use semisynchronous instead of asynchronous communication. For more information, see Calling a Method.
Your class provider should supply a stub implementation that returns WBEM_E_PROVIDER_NOT_CAPABLE for all of other IWbemServices methods that do not support your feature set. Specifically, WMI does not support query processing for class providers. As such, a class provider must return WBEM_E_PROVIDER_NOT_CAPABLE from their implementation of IWbemServices::ExecQueryAsync, set their QuerySupportLevels registration property to NULL, or both.
The interfaces that a class provider implements are very similar to the interfaces for an instance provider and a method provider. In fact, a single provider can act as all three types of provider by implementing all the methods and registering properly.