pegasus/doc/WorkPapers/provider_interface_proposal.htm - diff

Return to provider_interface_proposal.htm CVS log

Up to [Pegasus] / pegasus / doc / WorkPapers

Diff for /pegasus/doc/WorkPapers/provider_interface_proposal.htm between version 1.1 and 1.2

version 1.1, 2001/05/27 21:08:11

version 1.2, 2001/06/01 08:21:54

Line 8

</head>

<body>

<H1>Expanding the Pegasus Provider Interface Proposal</H1>

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

Mike Brasher, Karl Schopmeyer, Chip Vincent

<H1 align="center">Expanding the Pegasus Provider Interface Proposal</H1>

<b>AUTHORS:</b> Mike Brasher, Karl Schopmeyer, Chip Vincent

22 May 2001

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

S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" -->Thursday, May 31, 2001 02:38 PM<!--webbot

bot="Timestamp" I-CheckSum="62134" endspan -->

</font></p>

<p>Revision Status</p>

<tr>

<td width="25%">Revision</td>

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

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

</tr>

<tr>

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

</tr>

<tr>

<td width="25%">Add comments.</td>

</tr>

<tr>

</tr>

<tr>

</tr>

</table>

<h2>Introduction</h2>

We defined a set of interfaces for Pegasus providers based on the CIM Operations.

We have already defined a set of interfaces for Pegasus providers based on the CIM Operations.

We recognized several limitations in that first set of interfaces, particularly the fact that there was no easy path back to the CIMOM from the provider. The initial interfaces provides a handle to get to the repository but not to put CIM operations back into the CIMOM.

Line 62

Line 101

information for things like system parameters, system state information, etc.

<p>As part of this we also want to create a handle so that CIM Operations can be

effecitively passed from the provider back to the Object Manager.</p>

<p>We propose modifying both the provider context and adding an operational

context parameter.  </p>

<h4>Provider Context</h4>

<p>Today - one parameter, the CIM Repository handle provided with the initialize

as follows:</p>

Line 281

Line 318

</OL>

<h3>Subdivide Provider Interface</h3>

TBD

Today the provider interface consists of all of the possible operations gathered

together.  It has been requested that we break this down into multiple

<h3>Terminate Provider Operation</h3>

interfaces that represent the major catagory of provider

<ol>

<li>Instance Provider</li>

<li>Property Provider</li>

<li>Method Provider</li>

<li>Association Provider</li>

<li>Indication Provider</li>

</ol>

<p>Generally the provider writers feel that they would prefer these simpler

interfaces.  The proposal made by IBM is that the operations be broken up

as follows:</p>

<ol>

<li>Instance Provider - All Instance operations</li>

<li>Property Provider - Get and Set Properyt</li>

<li>Method Provider - Invoke method</li>

<li>Association provider - The association and reference operations</li>

<li>Indication Provider - TBD</li>

</ol>

<p>This implies that a single provider that does all of the above then must set

up interfaces for all of the different provider types.</p>

<p>Today, the current interface has one provider type with all of the operations

built in.  In effect, we view this as our interpretation of the instance

provider.  It provides for instances and those other entities such as

properties, etc.   We can provide either type of interface or both (we

are preparing a separate proposal on a solution to maintaining multiple provider

interfaces.).</p>

<h3>Terminate Provider Operations</h3>

Requirement: We need a way to quies providers - to tell them to stop what they

are doing.  This is probably not very important in the case of simple

responding providers.  They simply respond to requests and await the next

request.  However, providers that do their own monitoring, that establish

and manage separate threads (and in the future remote providers) should be shut

down systematically as part of the shutdown of the CIMOM environment. 

Thus, an additional provider interface is needed that can issue a terminate

command.

<p>

This one is simple. The method name is:

This one is simple. The method name is:</p>

<pre>

Terminate();

</pre>

It will be issued by the Object Manager to all active providers in the process of Object Manager shutdown.

It will be issued by the Object Manager to all active providers in the process of Object Manager

This means that ALL providers must implement this interface just as they must implement the <TT>Initialize()</TT> interface today.

shutdown, possibly operator command, etc..  Note that in the future when

providers are visible through the CIM_Services objects, they could be stopped

through methods attached to the provider CIM_Service objects. This means that ALL providers must implement this interface just as they must implement the <TT>Initialize()</TT> interface today.

Normally the requirement on the provider would be to stop any continuous operations that are in process and then return a response.

At this point we have not proposed any special requirements such as timers for shutdown,etc.

<p>Our proposed behavior is that the provider not return completion on this

request until it has terminated operations and is prepared to be shutdonwn.</p>

<p>QUESTION: Is this a problem?. </p>

<h3>Indication Interface</h3>

We will discuss this as part of another document on indication implementation.

<p>---END OF _DOCUMENT---</p>

</body>

</html>

Legend:

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

No CVS admin address has been configured