WMI Nova : Direct Provider Access

Rev 1.02, 22-June-99, raymcc

1.0  Introduction

This memo concerns the implementation of DCR 51646, approved by the Committee on 16-Jun-99.

DCR 51646 concerns requests by ISVs to support direct access to a WMI provider.   In the original Nova M3 implementation, when a user requests instances from a provider, there is no way to suppress access to other providers or the repository if there is a complex inheritance chain involved.   For example, given the class hierarchy {A,B:A, C:A,D:B}, a query which selects all instances of A would conceivably call all providers for A, B, C, and D.    While this is correct and desirable from the client's point of view, providers themselves can experience internal difficulties.   If a provider needs instances of A in order to determine the values for its own instances, there is no viable way of executing a reentrant query, since that query would in turn visit the very provider which is making the request.

The new mechanism allows client requests to be directed at a particular provider, in isolation, with the understanding by the requester that not all information may be returned due to the absence of access to other providers.  Thus, in the class hierarchy {A,B:A, C:A,D:B}, access to instances of B is performed in isolation, ignoring both the superclass A and the subclass D, as well as the unrelated sibling class C.

Property providers and class providers are unaffected by this modification and continue to behave as they have.

2.0  WMI API Changes

The new flag is WBEM_FLAG_DIRECT_READ and can be applied to any of the reading APIs of IWbemServices, i.e.,  to the following:

• GetObject
• GetObjectAsync
• CreateInstanceEnum
• CreateInstanceEnumAsync
• ExecQuery
• ExecQueryAsync

Notably, CreateClassEnum and CreateClassEnumAsync are not covered by this DCR and will not be supported.

The flag will be accessible to both providers and clients, especially since the roles between the two are often vague.

Properties which have not been populated by the provider will be set to NULL.

+

3.0  Semantics

When the WBEM_FLAG_DIRECT_READ flag is applied to a reading API, such as GetObject, the class identified in the object path is retrieved from the repository.  Given the following two classes, both backed by providers:

[dynamic] class A { [key] sint32 p1; sint32 p2; }
[dynamic] class B : A { sint32 p3; sint32 p4; }
[dynamic] class C : B { sint32 p5; sint32 p6; }

A GetObject call with the path "B=10" will only access the provider for B.  By implication, in the returned object only p3 and p4 will be expected to have valid values.   In practice, the key, p1, is also returned.  Notably, p2 will likely not have a valid value, since it was provided by the provider for A, which was not accessed.  Nor is the provider for C accessed in any case, even if there are keys which match.

4.0  Limitations and Exceptions

It is not an error if more properties are returned than are supported by the class in question.  The purpose behind the functionality is to limit access to a particular provider, not to access the class-specific portion of a definition.

For example, assume the following two classes:

class A { [key] sint32 p1; sint32 p2; }
class B { sint32 p3; sint32 p4; }

A query such as select * from B in combination with the WBEM_FLAG_DIRECT_READ flag has the semantics of "only access the provider for B during execution."  If that provider elects to supply p1 and p2 during execution, it is not an error.

The provider should set to NULL all properties which are not being returned.

In fact, it is the normal behavior in the case of keys, since all providers of subclasses must at least return the key as well in order for CIMOM to the required joining operations.

As a result of this definition, the WMI repository will behave in this fashion and will not filter out such properties, given that it is acting in the role of a provider.