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

One way it could be possible to make providers more automated is if the CIMOM 
also contained a database for static properties.
This would leave programmers with only the task of filling in code stubs for 
supplying dynamic properties and method calls.

Or perhaps the CIMOM could have built in compatibility with a variety of the 
main database systems available, and all that would have to be done is to 
register a mapping during the automated provider creation stage.
Again there would still likely be some code stubs programmers would have to fill 
out, but a lot of the confusion would be taken out.

Almost all programmers new to CIMOMs already assume it is a database.
They do not understand providers must not be used as the means of data 
persistence.
And currently it is left to them to supply persistent data storage, without 
really helping them accomplish this.
Since this is so essential and basic, and it would be so easy to aid in the 
interface to the database of their choice, it would be nice if this was more 
integrated into some sort of initialization phase of installation or 
configuration.

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




________________________________
From: Karl Schopmeyer <[email protected]>
To: "Chatterjee, Biswapratap" <[email protected]>; 
"[email protected]" <[email protected]>
Sent: Mon, November 22, 2010 10:08:38 AM
Subject: Re: Question for Provider Developers - It is possible to  completely 
automate the process of writing a CMPI provider?

In general, the answer is no. The complete provider generation cannot be 
automated at this point because in addition to the glue component (provider 
infrastructure, object generation, etc.) there is real special intellectual 
property in the relationship between the CIM Instances and the source of data 
and also real provider writer intellectual property in the optimization of the 
provider (ex. design one to handle 100,000 instances in a reasonable time 
frame). 


As Steve noted, we have tools to help with infrastructure creation, cimom 
interface, relationship between the programming language and the model, and even 
management of caching, etc. but that still leaves much territory for the 
provider writer (ex. SimpleWbem and KonkretCMPI). These and other similar tools 
automate the generation of the infrastructure, provide support for some standard 
patterns of provider generation and improve the relationship between the CIM 
Model and the code (ex. create c++ classes for the CIM Class being processed).  
They do not tell the provider writer where to get the data for the instances.

As the profile generation mechanisms are further defined in machine readable 
format (the MRP work) more and more of the provider writing exercise will be 
automatable but since the source of information is still specific to the 
provider, that part will still be coded.  In other words we move bit-by-bit to a 
more functional model of code for providers.

There are particular cases where we will be able to completely automate the 
provider. For example:

1. An association provider that associates one instance of class A with every 
instance of class B.  That is simple but it already defined the logic that every 
instance of Class B is to be associated with each instance of Class A.  It is a 
boundary case for a provider but one that could be defined in a pattern to be 
completely defined as part of provider generation.

2. A provider where the complete data could be defined in terms of mof (i.e. the 
instances).  This could be built completely from the class and instance mof.  
But this is really a static provider and not much different than putting the 
instances in the cim server repository.

Good question in any case and we will get better at automating this process but 
it will be up to the provider writer to glue it all together for a long time.  
We tool writers are trying to make the provider writers job easier and to let 
him concentrate on the part that really brings value (i.e. the system 
engineering part of provider writing (optimizing providers, 
getting/caching/storing data, etc.) rather than the low level infrastructure. 


Karl


Thanks for your message at 11:36 PM 11/21/2010, Chatterjee, Biswapratap. Your 
message was:

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.
> 
Karl Schopmeyer                   Inova Development Inc.
305 Spring Creek Village, Suite 475 -  Dallas TX, 75248 USA
EMAIL: [email protected]       FAX: 1-972-239-0326
Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971