Re: CMPI association provider

If you are constrained to different providers for each class, they still need to know about each other.
There are lots of options.
One way is to have only one of the providers actually store the information, and have the others get it from that one provider.
Another is to run a free copy of MySQL or some other database, to contain all the information.
Another way someone on this group suggested, was to create instances of static classes that were nothing but storage placeholders or flags.
Where their very existence was sufficient to broadcast to the providers, what ever information needed to be shared.
The problem you need to avoid is where the providers don't cross talk, and something happens, like one of the instances pointed to by an association is deleted, without telling the association provider as well.
Since you need nonvolatile storage for data anyway, an actual database may be the best solution.
That was the original CIM model.
Originally providers were only wrappers to hide implementation dependencies of different databases.




________________________________
From: kamal jeera <[email protected]>
To: Kirk Augustin <[email protected]>
Cc: Karl Schopmeyer <[email protected]>; [email protected]
Sent: Wed, February 10, 2010 1:41:49 PM
Subject: Re: CMPI association provider


thanks much Kirk,

I agree that it is much easier all in one type provider [given that we have some samples to look at :)] but my project requirement is one provider per class so i have to stick to it.....

any examples for my type of design?....badly needed help.....I am kinda stuck :(   still researching though....


On Tue, Feb 9, 2010 at 4:09 PM, Kirk Augustin <[email protected]> wrote:

You can register a provider for as many classes as you want.
>So it is up to you.
>When a provider is called you know what is wanted from the provider.
>But I find it easiest to only have a single provider when there are associations between classes, for all the classes.
>Otherwise the providers would need some shared backend data or cross talk.
>
>
>
>
________________________________
From: kamal jeera <[email protected]>
>To: Kirk Augustin <[email protected]>
>Cc: Karl Schopmeyer <[email protected]>; [email protected]
>Sent: Tue, February 9, 2010 3:43:31 PM 
>
>Subject: Re: CMPI association provider
>
>
>
>thanks fellows......
>
>Got another question.....
>
> Class A
>{
> string a;
>}
>Class B
>{
> string b;
>}
>Class AB
>{
> A ref a1;
> B ref b1;
>}
>Relation 1 to many [ A has many B's]
>
>now I have,
>InstanceProviderA for class A and 
>InstanceProviderB for class B
>for associationproviderAB: for associators() fucntion,
>where I have instance of class A and I should return all instances of B.
>I am not sure How to do that? should I call enumrateinstances of instanceproviderB? 
>will that possible as all three are different C files? I mean
>InstanceproviderA.c    ==> made to a.so file
>InstanceproviderB.c    ==> made to b.so file
>AssociationProviderAB.c ==> made to ab.so file.
>[my project requires those all to be different files. In otherewords one provider per class]
>
>I looked few examples, but all they have single provider doing both instance & assocation in single .c file [in that it has access to all the functions.]
>e.g.: 
>1) http://developer.novell.com/wiki/index.php/How_to_Develop_a_CIM_Provider
>2) http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sample/CMPI/FilesAndDirectories/CWS_DirectoryContainsFile.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
>
>any suggestions plz....
>
>
>On Wed, Feb 3, 2010 at 11:27 AM, Kirk Augustin <[email protected]> wrote:
>
>Ah, then I can understand why there could be some choices.
>>I do not always implement associator or reference enumeration normally.
>>That is because the client can instead enumerate all of the expected association and search themselves.
>>I can see how these methods could be handy if you wanted clients to be able to manage the CIMON data integrety, delete instances, clean up hanging ones, etc., but I find it easier to have providers take care of that instead.
>>Since I don't use them in my clients, I can be more careless.
>>But it depends on what the clients you have to support expect?
>>
>>
>>
________________________________
From: kamal jeera <[email protected]>
>>To: Karl Schopmeyer <[email protected]>; Kirk Augustin <[email protected]>
>>Cc: [email protected]
>>Sent: Wed, February 3, 2010 11:03:45 AM
>>Subject: Re: CMPI association provider
>>
>>
>>
>>My bad.  Sorry to both of you karl and Kirk for misguiding/missing info.
>>
>>Kirk,
>>You are right that we need at least enumerate for a class. But if we look at closely other Assocation functions they are nothing but enumerations.
>>	* associatorNames() – enumerate ObjectPaths of Instances associated with an Instance 
>>associators() – enumerate Instances associated with an Instance
>>referenceNames() – enumerate the ObjectPaths of Association Instances that refer to an Instance
>>references() – enumerate the Association Instances that refer to an Instance
>>Karl,
>>
>>I posted wrong link.  Actually I got this from Opengroup.
>>http://www.opengroup.org/onlinepubs/9699949899/toc.pdf
>>[page 55]
>>
>>
>>Let me know what you guys think....  
>>
>>thanks much!
>>Kamal
>>
>>
>>On Wed, Feb 3, 2010 at 7:44 AM, Karl Schopmeyer <[email protected]> wrote:
>>
>>This one is easy.  The second reference (wbemsource) was a group formed several years ago but now inactive.  Use the DMTF profile specifications, they are the specifications to which we work.
>>>
>>>Karl
>>>Thanks for your message at 06:59 PM 2/2/2010, kamal jeera. Your message was: 
>>>
>>>
>>>Hi folks,
>>>> 
>>>>got some questions on CMPI association provider.  But I will stat out with basic question.
>>>> 
>>>>I did searched on the message archive but didn't find the one I was looking for.  So here I am.
>>>> 
>>>>OK, 
>>>> 
>>>>on this document 
>>>>	* http://www.dmtf.org/apps/org/workgroup/applications/metricextensions/download.php/38074/DSP1053_1.0.0.pdf 
>>>>	* [note: may have to sign in before you can access above document] It says required functions as [ on page 27] remember that CIM_MetricDefForME  is an assocation class
>>>>
>>>>Associators 
>>>>
>>>>AssociatorNames 
>>>>
>>>>References 
>>>>
>>>>ReferenceNames 
>>>>
>>>>EnumerateInstances 
>>>>
>>>>EnumerateInstanceNames
>>>>
>>>>on this docment 
>>>>	* http://www.wbemsource.org/uploads/40/3712/CMPI.pdf/ It says required fucntions as [on page 32]
>>>>
>>>>Associators 
>>>>
>>>>AssociatorNames 
>>>>
>>>>References 
>>>>
>>>>ReferenceNames 
>>>>
>>>>I am little bit confused which functions are must ???
>>>> 
>>>>Thanks much.......got others questions as well but will do some more reading....
>>>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
>>>
>>>
>>>
>>
>