RE: CMPI Instance Provider Question.....

If a provider were a way of executing arbitrary relational queries against a relational back-end database, all would be well.

But it's not. It's a way of transforming some of the information from what are best thought of as numerous flat-file back-end databases into a network-model database that is built and delivered piecewise on demand. This has no real hope of changing the current reality, which is that....

All real world general-purpose management clients that I've heard of build a database (usually using a relational DB) of the results of a complete system scan, at least once a week. In between, they rely on indications and queries to fill in changes to the underlying world being managed. They have to do this so that arbitrary relational queries against a back-end database are possible. Once you factor in the network latencies involved in all the CIMOMs and providers talking to each other, having your own "back-end database" is the only way to efficiently answer questions like "how many GB worth of LUNs are connected to server X?"

Alan

Alan G. Yoder, MSEE, Ph.D.
Office of the CTO
NetApp



-----Original Message-----
From: Kirk Augustin [mailto:[email protected]]
Sent: Tue 1/19/2010 10:38 AM
To: kamal jeera
Cc: [email protected]
Subject: Re: CMPI Instance Provider Question.....
 
Just an opinion, so ask others as well.
But I would not store anything that you can't get from the actual database.
So what I would do is write out a simple flat sequential file of all the instances.
With each instance, save whatever you would need in order to get the rest from the actual database, such as the database record key values.
And only write out properties to the file, that you can not get from the actual database, such as namespace, class name, etc.
If you duplicate anything from the database, you run the risk of having stale data and not knowing it.

It will be a little confusing, because there will be 3 catagories of values:

A. Those relative only to CIM.  
Such as the namespace, class name, etc.

B. Those relative to CIM and the database.
Instances and properties that show up in the schema or CIM queries but you get from the database.

C. And those relative only to the database.
The keys you need to access a record from the database, but CIM does not need to know about.

You only need to store A and C in your flat file, in order to get B when necessary.

I hope that makes sense.




________________________________
From: kamal jeera <[email protected]>
To: Kirk Augustin <[email protected]>
Cc: [email protected]
Sent: Tue, January 19, 2010 10:13:18 AM
Subject: Re: CMPI Instance Provider Question.....


thanks much for reply...

Is there any sample code for that?

In my case, I have database but it is read only.  System creates the records and saves it in database.
My provider will go after that database and get the data and then should update the class properties.

In that above scenerio, what the best design? any suggestion? should I put the data in a file once I got back from database?

As first step,  Instead of going after the database, I thoghout give static values to the class properties. that is why I was going throught that example....

Any suggestions on those lines are really helpful....

thanks much for your time.....I am bit new to this..

Best,
Kamal


 
On Mon, Jan 18, 2010 at 12:18 PM, Kirk Augustin <[email protected]> wrote:

The sample code is a little simplistic.
>It is best to think of the original CIM model, which is that the provider is a front end for some sort of external database or other enity.
>That is where the existence of instances is actually to be kept.
>The provider is best thought of as transient, and not the real storage.
>Just a go-between.
>So the provider should not really matter what representation it uses, because it gets the actual existence and data from elsewhere.
>If you don't really have a database behind your provider, you still need to create some sort of non-volitile storage, like write data needed to recreate instances off to a file.
>Providers are not persistant, so an array is not sufficient permanent storage.
>
>As far as namespace, I don't see how that is relevant.  
>You expose whatever instances you want.
>The provider only knows about one namespace normally, unless I supposes you could registered the same provider in more than one namespace, or a provider can act as a client and go off to other namespaces to gather data.
>
>
>
>
________________________________
From: kamal jeera <[email protected]>
>To: [email protected]
>Sent: Mon, January 18, 2010 11:44:53 AM
>Subject: CMPI Instance Provider Question.....
>
>
>
>
>Hi fellows,
>
>Got quick question.....
>
>I was going through sample CMPI instance provider, links below:
>
>link: http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sample/CMPI/InstanceProvider/cmpiInstanceProvider.c
>
>direct links for sample code:
>http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sample/CMPI/InstanceProvider/cmpiInstanceProvider.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
>
>You can see that during initialize(), he creates 3 instance.  He creates them root/SampleProvider namespace +  he creates array to hold the instances created 
>
>is that a normal process?  meaning you have to create instances in an array in a namespace?  
>
>I got this question, becasue during enuminstance or getInstance [see the above sample],  I need to go through all instances in namespace right.  so unless I have an array like in the above sample, I just dont know how to traverse that namespace.
>
>Any thoughts?
>
> 
>thanks much....
>kamal
>
>