Re: Question for Provider Developers - It is possible to completely automate the process of writing a CMPI provider?

Sounds good but, "data items are populated by a  separate service which monitors 
the state of our device and calls Pegasus when a  change needs to be made", is 
not at all trivial.
It seems to me that this separate device is much more complex than providers 
themselves should be.
And it is sort of backwards.
The whole point of providers is to just act as a go between to allow client 
access to an unknown source of data.
The actual source of data should not be calling Pegasus, but the other way 
around, because Pegasus is not where the data is actually to be stored.
I think that to make providers easier to automate, one would want to make more 
assumptions about the various possible actual databases and persistent storage 
sources for properties, and to allow for the generation and configuration of 
default code to do the dynamic access and mapping.

 Kirk & Trish Augustin
11821 NW McNamee Rd
Portland, OR 97231




________________________________
From: "Dodgson, David S" <[email protected]>
To: Steve Peters <[email protected]>; "Chatterjee, Biswapratap" 
<[email protected]>; Kirk Augustin <[email protected]>; 
"[email protected]" <[email protected]>
Sent: Mon, November 22, 2010 6:35:17 AM
Subject: RE: Question for Provider Developers - It is possible to completely 
automate the process of writing a CMPI provider?

 
I presented a paper at the SNIA Storage Developer Conference  entitled 
"Automatic Generation of SMI Providers".  It describes the method  we use to 
automatically generate a provider based on the .mof files used by the  Storage 
Management Initiative.  The paper is also supposed to be  published with the 
Management Developers Conference that completed last  week.  The SDC 
presentation should be available in one or two  months.
 
In it I describe how we generate our provider from the .mof  files.  We use 
SimpleWBEM along with a number of enhancements we wrote to  do this.  The 
provider handles all data items but functions need to be  coded individually.  
In our case, the data items are populated by a  separate service which monitors 
the state of our device and calls Pegasus when a  change needs to be made.
 
This method may or may not be useful to others depending on  how much 
customization is required.


________________________________
 From: Steve Peters  [mailto:[email protected]] 
Sent: Monday, November 22, 2010  2:22 AM
To: Chatterjee, Biswapratap; Kirk Augustin;  [email protected]
Subject: RE: Question for Provider  Developers - It is possible to completely 
automate the process of writing a CMPI  provider?


             Look at Cimple ( Simple Wbem). This comes very close to a tool to 
write a  provider.
 
                         Steve Peters
                         PMC-Sierra
 

________________________________
 
From:Chatterjee, Biswapratap [mailto:[email protected]] 
Sent: Sunday, November 21, 2010 10:50  PM
To: Kirk Augustin;  [email protected]
Subject: RE: Question for Provider  Developers - It is possible to completely 
automate the process of writing a CMPI  provider?
 
Hi  Kirk,
 
Thanks a lot for  the reply.
 
I exactly thought  in the same lines as you do, but then if the developer also 
had the option to  share some information about its data source (binary from 
where the provider  expects data); like a stub sitting in-between the data 
source and provider  (providing a generic interface to gather data), and a 
mapping document (like an  xls sheet) acting as a meta-information which directs 
the automation process to  generate codes mapping provider properties to the 
data source’s  properties.
 
I don’t know  whether these things are possible. I am just throwing ideas, maybe 
we hit  something. I just want to know the possibilities of such an  idea.
 
Regards,
Biswapratap.
 
From:Kirk  Augustin [mailto:[email protected]] 
Sent: Monday, November 22, 2010 12:04  PM
To: Chatterjee, Biswapratap;  [email protected]
Subject: Re: Question for Provider  Developers - It is possible to completely 
automate the process of writing a CMPI  provider?
 
And I  think the answer is no.

Whenever I need to write a provider, I always  start off with the same boiler 
plate basic provider, but there is no way to  automate the creation of the rest.
Some is hardware specific, data persistent  specific, protocol specific, 
relative to other machines, relative to processes  and their states, etc.
HP had an SDK to make producing a provider much  easily, but there will always 
be a need to write a significant portion of any  provider yourself.
You can automate the created of a provider to satisfy a  schema, but that only 
creates objects with storage space for property  values.   It can't ever fill in 
the property values.  You always  have to write the code to do that.
 
Kirk  & Trish Augustin
11821 NW  McNamee Rd
Portland , OR    97231
 
 

________________________________
 
From:"Chatterjee, Biswapratap" <[email protected]>
To: "[email protected]"  <[email protected]>
Sent: Sun, November 21, 2010 9:36:05  PM
Subject: Question for  Provider Developers - It is possible to completely 
automate the process of  writing a CMPI provider?
Hi  all,
 
This  question has been banging in my head for quite some time. “It is possible 
to completely automate the process of  writing a CMPI provider?”
 
I have  been putting lot of effort in making this possible. Since, I have always  
believed that writing a provider is a repetitive task. If it is a  standard,
then we  have a set of guidelines to write it, we just have to develop an 
intelligent  software who can understand the guidelines on its own and 

automate the process of provider development. The  developer should only worry 
about the schema diagram that abstracts its 

hardware/architecture. Something like – “Draw your  schema and get your provider 
shared object”.
 
If you  feel this is an interesting topic than we can take this discussion to 
the next  level about – “Possible ways to accomplish this  objective”.
 
Waiting  for your replies and ideas ….
 
Regards,
Biswapratap.