140 lines
5.3 KiB
HTML
140 lines
5.3 KiB
HTML
<html>
|
|
|
|
<head>
|
|
<title>WMI Nova </title>
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
|
|
</head>
|
|
|
|
<body bgcolor="#C0C0C0" text="#000080">
|
|
|
|
<p><u><big><big>WMI Nova : Direct Provider Access</big></big></u></p>
|
|
|
|
<p>Rev 1.02, 22-June-99, raymcc</p>
|
|
|
|
<hr>
|
|
|
|
<p><u><strong>1.0 Introduction</strong></u></p>
|
|
|
|
<p>This memo concerns the implementation of DCR <strong>51646, </strong>approved by the
|
|
Committee on 16-Jun-99.</p>
|
|
|
|
<p><strong>DCR 51646</strong> 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 <em>A </em>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 <em>A </em>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Property providers and class providers are unaffected by this modification and continue
|
|
to behave as they have.</p>
|
|
|
|
<hr>
|
|
|
|
<p><u><strong>2.0 WMI API Changes</strong></u></p>
|
|
|
|
<p>The new flag is <strong>WBEM_FLAG_DIRECT_READ </strong>and can be applied to any of the
|
|
reading APIs of <em>IWbemServices, </em>i.e., to the following:
|
|
|
|
<ul>
|
|
<li>GetObject</li>
|
|
<li>GetObjectAsync</li>
|
|
<li>CreateInstanceEnum</li>
|
|
<li>CreateInstanceEnumAsync</li>
|
|
<li>ExecQuery</li>
|
|
<li>ExecQueryAsync</li>
|
|
</ul>
|
|
|
|
<p>Notably, <em>CreateClassEnum </em>and <em>CreateClassEnumAsync</em> are not covered by
|
|
this DCR and will not be supported.</p>
|
|
|
|
<p>The flag will be accessible to both providers and clients, especially since the roles
|
|
between the two are often vague.</p>
|
|
|
|
<p>Properties which have not been populated by the provider will be set to NULL.</p>
|
|
|
|
<p>+</p>
|
|
|
|
<hr>
|
|
|
|
<p><u><strong>3.0 Semantics</strong></u></p>
|
|
|
|
<p>When the WBEM_FLAG_DIRECT_READ flag is applied to a reading API, such as <em>GetObject,
|
|
</em>the class identified in the object path is retrieved from the repository. Given
|
|
the following two classes, both backed by providers:</p>
|
|
|
|
<blockquote>
|
|
<p><font face="Courier New"><small>[dynamic] class A { [key] sint32 p1; sint32 p2; }</small><br>
|
|
<small>[dynamic] class B : A { sint32 p3; sint32 p4; }</small><br>
|
|
<small>[dynamic] class C : B { sint32 p5; sint32 p6; }</small></font></p>
|
|
</blockquote>
|
|
|
|
<p>A <em>GetObject </em>call with the path <em>"B=10" </em>will only access the
|
|
provider for <em>B. </em>By implication, in the returned object only <strong>p3</strong>
|
|
and <strong>p4 </strong>will be expected to have valid values. In practice,
|
|
the key, <strong>p1, </strong>is also returned. Notably, <strong>p2 </strong>will
|
|
likely not have a valid value, since it was provided by the provider for <em>A, </em>which
|
|
was not accessed. Nor is the provider for C accessed in any case, even if there are
|
|
keys which match.</p>
|
|
|
|
<p> </p>
|
|
|
|
<hr>
|
|
|
|
<p><u><strong>4.0 Limitations and Exceptions</strong></u></p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>For example, assume the following two classes:</p>
|
|
|
|
<blockquote>
|
|
<p><font face="Courier New"><small>class A { [key] sint32 p1; sint32 p2; }</small><br>
|
|
<small>class B { sint32 p3; sint32 p4; }</small></font></p>
|
|
</blockquote>
|
|
|
|
<p>A query such as <em>select * from B </em>in combination with the WBEM_FLAG_DIRECT_READ
|
|
flag has the semantics of <strong>"only access the provider for B during
|
|
execution." </strong>If that provider elects to supply <em>p1 </em>and <em>p2 </em>during
|
|
execution, it is not an error.</p>
|
|
|
|
<p>The provider should set to NULL all properties which are not being returned.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><u>As a result of this definition,</u><strong> </strong>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.</p>
|
|
|
|
<p> </p>
|
|
|
|
<hr>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
<p> </p>
|
|
<p> </p>
|
|
<p> </p>
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p> </p>
|
|
</blockquote>
|
|
|
|
<p> </p>
|
|
</body>
|
|
</html>
|