pegasus/doc/WorkPapers/TheRepositoryasDefaultInstanceProvider.htm - diff

Return to TheRepositoryasDefaultInstanceProvider.htm CVS log

Up to [Pegasus] / pegasus / doc / WorkPapers

Diff for /pegasus/doc/WorkPapers/TheRepositoryasDefaultInstanceProvider.htm between version 1.1 and 1.1.2.1

version 1.1, 2001/10/19 13:22:32

version 1.1.2.1, 2001/10/19 13:22:32

Line 0

Line 1

<html>

<head>

<title>Pegasus Project Working Paper</title>

</head>

<body>

<H1 align="center">Pegasus Project Working Paper</H1>

<H1 align="center">Unsupported Classes in the Repository</H1>

<b>AUTHORS:</b> 

<p><font size="1">Last Update <!--webbot bot="Timestamp" startspan

S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" -->Friday, October 19, 2001 08:07 AM<!--webbot

bot="Timestamp" i-CheckSum="57739" endspan -->

</font></p>

<p>Revision Status</p>

<tr>

<td width="20%" height="19">Revision</td>

<td width="25%" height="19">Author(s)</td>

<td width="25%" height="19">Reason</td>

</tr>

<tr>

<td width="30%" height="19"> 15 October 2001</td>

<td width="25%" height="19">K. Schopmeyer</td>

<td width="25%" height="19">Original</td>

</tr>

<tr>

<td width="30%" height="18">19 October 2001</td>

<td width="25%" height="18">Comments from Denise. Distribute this version to

Pegasus for Comment</td>

</tr>

<tr>

</tr>

<tr>

</tr>

</table>

<h2>Introduction</h2>

<p>The instance operation routing algorithms for the Pegasus platform treats the

instance repository (if it is activated) as the provider of last result so that

any instance operation request (create, enumerate, modify, etc.) for which there

is not a specific provider defined (via the provider qualifier today) is routed

to the instance repository for handling.  Thus, if a create instance for

any class which does not have a provider defined is received it is routed to the

instance repository or if an enumerate instance request arrives for a class that

does not have a provider defined, the request is passed to the instance

repository handler and the response provided according to any instance

information for the target class that might be in the instance repository.</p>

<p>At the same time, we typically load all of the classes of all or most of the

DMTF CIM Schemas and then add the classes required for our implementation and/or

environment. This means that typically there are a significant number of classes

in the class repository which are not  supported by providers.</p>

<p>Pegasus users have identified this as a potential problem for several

reasons:</p>

<ol>

<li>Existence of a class in the schema does not imply that the class is 

implemented/instrumented. </li>

<li>Clients can not differentiate implemented classes from unimplemented

 classes. </li>

<li>Browsers and other tools will produce a list of all classes giving no clue

to the user if there is any provider support other than the provider

qualifier.</li>

<li>CIM Clients can create instances for classes that are not supported and

this instance information will be placed in the instance repository with no

known strategy for ever understanding that it is worthless information.</li>

<li>A client may create an instance of the class, expecting an underlying

resource to be affected (e.g., a client may create an instance of a User

class expecting the user to get added).  </li>

<li>A client may see an instance created by another client and believe it

 reflects the state of an underlying resource</li>

</ol>

<p>It appears then that there is a requirement to be able to separate classes

that are supported in some way by the CIMOM and providers from those that are

not.  At the same time, this is not as simple as just using the provider

qualifier (or in the future the provider registration) because there may be

valid reasons for using the instance repository for storage of instance

information about selected classes.</p>

<p>For these reasons, it appears that the repository should be explicitly

registered for the classes it serves rather than the current situation of

letting it act as default.<br>

</p>

<h3>Limiting Access/Modification for Static Information</h3>

<p>

A related issue is that there is fundamentally a difference between a

"provider" manipulating instances that are served by the repository

and clients manipulating those instances.  That is, the instances generally

relate to the state of some underlying managed resource.  The resource

owner knows that state and can accurately supply the instance information to be

kept in the repository.  Clients, on the other hand, want to retrieve this

information rather than supply it.  Those clients should not generally be

trusted to manipulate the instances in the repository.<br>

<br>

Microsoft addresses this issue by defining "push providers" (as

opposed to the "pull providers" like what Pegasus currently has).

 </p>

<p>HP has  proposed that we devise a mechanism for Pegasus that allows static

instances to be created/manipulated by the resource owner while allowing only

read access by clients. We could be more general than this if we create access

control at the class level so that, for example, the resource owner could

dictate the access by other potential.  Thus the resource owner could

dictate read-only access by other users.</p>

<p>Somewhere in there there is a logical ground.  We probably do need to

limit the ability to change on some basis.  However, I suggest that we can

try to do that as part of the access control mechanisms we are planning to

design (which is another use case for class level access control) rather than

building a special mechanism.  </p>

<p>Therefore, I propose that we move this discussion to the access control

discussion and in this note consider primarily the algorithms for routing,

especially those dealing with the instance repository.</p>

<h3>Proposal to Establish ownership of Classes</h3>

<p>Note: Much of this discussion bears a strong relationship to ideas that would

come from ownership of entities within the CIMOM, Primarily the classes. 

However, until we resolve the access control definitions (authorization rules)

we do not know what we can do with ownership technologies.</p>

<h3>Proposal to Modify Operation of CIMOM Routing</h3>

<p>

We therefore propose that what we want to do is to force the identification of

not only classes with valid providers (that would be identified through the

provider qualifier or provider registration) but also to identify those classes

for which the instance repository is to be the "provider".  In essence

we are establishing ownership of classes. With the

provider qualifier this is a simple change since there is no concept of

ownership and involves:</p>

<ol>

<li>Change the CIMOM routing so that there is no default provider.  Any

instance operations against instances of classes for which there is no

provider will receive an error return.  Any class for which the

instance repository is to be used must have the provider qualifier set to

"Repository".</li>

<li>At the same time, this then requires that the provider qualifier be

supplied for all classes for which we are interested in using the instance

repository. Since today setting the provider qualifier is a very manual

activity (adding a qualifier to the class definition)  with no real

defined provider registration tools. We simply set the qualifier for classes

that will use the repository as part of the general process of setting the

provider qualifier. Thus a provider that wanted to register itself would add

the provider qualifier to classes that were to be routed directly to the

provider and also set the provider qualifier to "repository" for

classes that it wished to manipulate through the instance repository.</li>

</ol>

<p>This becomes more complex when we move to using provider registration as the

tool for determining the provider associated with a class.  The provider

class today lists the classes associated with a particular provider so that

these classes are "registered" for the provider when an instance of

the provider class in installed in the CIMOM.  However, to date, we have

assumed that the classes for which we are registering are to be associated with

the provider being registered.  However, we may want to register classes

against the "repository" provider in addition to registering classes

against the provider being registered. Thus the process of registering a

provider may associated certain classes with this provider but also associate

certain classes with the instance repository.  Further, when the provider

is de-registered, we would assume that these classes in the instance repository

might also be de-registered.</p>

<p>NOTE: At this point I am just preparing to look  through Christinas definitions

(an interop proposal) for provider registration to determine if we need to add something.</p>

<p>---END OF DOCUMENT--</p>

</body>

</html>

Legend:

Removed from v.1.1
changed lines
	Added in v.1.1.2.1

No CVS admin address has been configured