1 karl 1.1.2.1 <html>
2
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
5 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
6 <meta name="ProgId" content="FrontPage.Editor.Document">
7 <title>Pegasus Project Working Paper</title>
8 </head>
9
10 <body>
11
12 <H1 align="center">Pegasus Project Working Paper</H1>
13
14 <H1 align="center">Unsupported Classes in the Repository</H1>
15
16 <b>AUTHORS:</b>
17 <p><font size="1">Last Update <!--webbot bot="Timestamp" startspan
18 S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" -->Friday, October 19, 2001 08:07 AM<!--webbot
19 bot="Timestamp" i-CheckSum="57739" endspan -->
20 </font></p>
21 <p>Revision Status</p>
22 karl 1.1.2.1 <table border="1" width="80%" height="124">
23 <tr>
24 <td width="20%" height="19">Revision</td>
25 <td width="30%" height="19">Date</td>
26 <td width="25%" height="19">Author(s)</td>
27 <td width="25%" height="19">Reason</td>
28 </tr>
29 <tr>
30 <td width="20%" height="19">1.0</td>
31 <td width="30%" height="19"> 15 October 2001</td>
32 <td width="25%" height="19">K. Schopmeyer</td>
33 <td width="25%" height="19">Original</td>
34 </tr>
35 <tr>
36 <td width="20%" height="18">2.0</td>
37 <td width="30%" height="18">19 October 2001</td>
38 <td width="25%" height="18">KS</td>
39 <td width="25%" height="18">Comments from Denise. Distribute this version to
40 Pegasus for Comment</td>
41 </tr>
42 <tr>
43 karl 1.1.2.1 <td width="20%" height="19"> </td>
44 <td width="30%" height="19"> </td>
45 <td width="25%" height="19"> </td>
46 <td width="25%" height="19"> </td>
47 </tr>
48 <tr>
49 <td width="20%" height="19"> </td>
50 <td width="30%" height="19"> </td>
51 <td width="25%" height="19"> </td>
52 <td width="25%" height="19"> </td>
53 </tr>
54 </table>
55
56 <h2>Introduction</h2>
57
58 <p>The instance operation routing algorithms for the Pegasus platform treats the
59 instance repository (if it is activated) as the provider of last result so that
60 any instance operation request (create, enumerate, modify, etc.) for which there
61 is not a specific provider defined (via the provider qualifier today) is routed
62 to the instance repository for handling. Thus, if a create instance for
63 any class which does not have a provider defined is received it is routed to the
64 karl 1.1.2.1 instance repository or if an enumerate instance request arrives for a class that
65 does not have a provider defined, the request is passed to the instance
66 repository handler and the response provided according to any instance
67 information for the target class that might be in the instance repository.</p>
68
69 <p>At the same time, we typically load all of the classes of all or most of the
70 DMTF CIM Schemas and then add the classes required for our implementation and/or
71 environment. This means that typically there are a significant number of classes
72 in the class repository which are not supported by providers.</p>
73
74 <p>Pegasus users have identified this as a potential problem for several
75 reasons:</p>
76
77 <ol>
78 <li>Existence of a class in the schema does not imply that the class is
79 implemented/instrumented. </li>
80 <li>Clients can not differentiate implemented classes from unimplemented
81 classes. </li>
82 <li>Browsers and other tools will produce a list of all classes giving no clue
83 to the user if there is any provider support other than the provider
84 qualifier.</li>
85 karl 1.1.2.1 <li>CIM Clients can create instances for classes that are not supported and
86 this instance information will be placed in the instance repository with no
87 known strategy for ever understanding that it is worthless information.</li>
88 <li>A client may create an instance of the class, expecting an underlying
89 resource to be affected (e.g., a client may create an instance of a User
90 class expecting the user to get added). </li>
91 <li>A client may see an instance created by another client and believe it
92 reflects the state of an underlying resource</li>
93 </ol>
94 <p>It appears then that there is a requirement to be able to separate classes
95 that are supported in some way by the CIMOM and providers from those that are
96 not. At the same time, this is not as simple as just using the provider
97 qualifier (or in the future the provider registration) because there may be
98 valid reasons for using the instance repository for storage of instance
99 information about selected classes.</p>
100
101 <p>For these reasons, it appears that the repository should be explicitly
102 registered for the classes it serves rather than the current situation of
103 letting it act as default.<br>
104 </p>
105
106 karl 1.1.2.1 <h3>Limiting Access/Modification for Static Information</h3>
107
108 <p>
109 A related issue is that there is fundamentally a difference between a
110 "provider" manipulating instances that are served by the repository
111 and clients manipulating those instances. That is, the instances generally
112 relate to the state of some underlying managed resource. The resource
113 owner knows that state and can accurately supply the instance information to be
114 kept in the repository. Clients, on the other hand, want to retrieve this
115 information rather than supply it. Those clients should not generally be
116 trusted to manipulate the instances in the repository.<br>
117 <br>
118 Microsoft addresses this issue by defining "push providers" (as
119 opposed to the "pull providers" like what Pegasus currently has).
120 </p>
121
122 <p>HP has proposed that we devise a mechanism for Pegasus that allows static
123 instances to be created/manipulated by the resource owner while allowing only
124 read access by clients. We could be more general than this if we create access
125 control at the class level so that, for example, the resource owner could
126 dictate the access by other potential. Thus the resource owner could
127 karl 1.1.2.1 dictate read-only access by other users.</p>
128
129 <p>Somewhere in there there is a logical ground. We probably do need to
130 limit the ability to change on some basis. However, I suggest that we can
131 try to do that as part of the access control mechanisms we are planning to
132 design (which is another use case for class level access control) rather than
133 building a special mechanism. </p>
134
135 <p>Therefore, I propose that we move this discussion to the access control
136 discussion and in this note consider primarily the algorithms for routing,
137 especially those dealing with the instance repository.</p>
138
139 <h3>Proposal to Establish ownership of Classes</h3>
140
141 <p>Note: Much of this discussion bears a strong relationship to ideas that would
142 come from ownership of entities within the CIMOM, Primarily the classes.
143 However, until we resolve the access control definitions (authorization rules)
144 we do not know what we can do with ownership technologies.</p>
145
146 <h3>Proposal to Modify Operation of CIMOM Routing</h3>
147
148 karl 1.1.2.1 <p>
149 We therefore propose that what we want to do is to force the identification of
150 not only classes with valid providers (that would be identified through the
151 provider qualifier or provider registration) but also to identify those classes
152 for which the instance repository is to be the "provider". In essence
153 we are establishing ownership of classes. With the
154 provider qualifier this is a simple change since there is no concept of
155 ownership and involves:</p>
156
157 <ol>
158 <li>Change the CIMOM routing so that there is no default provider. Any
159 instance operations against instances of classes for which there is no
160 provider will receive an error return. Any class for which the
161 instance repository is to be used must have the provider qualifier set to
162 "Repository".</li>
163 <li>At the same time, this then requires that the provider qualifier be
164 supplied for all classes for which we are interested in using the instance
165 repository. Since today setting the provider qualifier is a very manual
166 activity (adding a qualifier to the class definition) with no real
167 defined provider registration tools. We simply set the qualifier for classes
168 that will use the repository as part of the general process of setting the
169 karl 1.1.2.1 provider qualifier. Thus a provider that wanted to register itself would add
170 the provider qualifier to classes that were to be routed directly to the
171 provider and also set the provider qualifier to "repository" for
172 classes that it wished to manipulate through the instance repository.</li>
173 </ol>
174 <p>This becomes more complex when we move to using provider registration as the
175 tool for determining the provider associated with a class. The provider
176 class today lists the classes associated with a particular provider so that
177 these classes are "registered" for the provider when an instance of
178 the provider class in installed in the CIMOM. However, to date, we have
179 assumed that the classes for which we are registering are to be associated with
180 the provider being registered. However, we may want to register classes
181 against the "repository" provider in addition to registering classes
182 against the provider being registered. Thus the process of registering a
183 provider may associated certain classes with this provider but also associate
184 certain classes with the instance repository. Further, when the provider
185 is de-registered, we would assume that these classes in the instance repository
186 might also be de-registered.</p>
187
188 <p>NOTE: At this point I am just preparing to look through Christinas definitions
189 (an interop proposal) for provider registration to determine if we need to add something.</p>
190 karl 1.1.2.1
191 <p> </p>
192
193 <p> </p>
194
195 <p>---END OF DOCUMENT--</p>
196
197 </body>
198
199 </html>
|
Return to
TheRepositoryasDefaultInstanceProvider.htm
CVS log
Up to [Pegasus] / pegasus / doc / WorkPapers