RE: CMPI association provider

Some thoughts:

Most CIM associations are empty with the exception of the two references.

The key of such an association is the two references.

 

If both associated classes each maintain a reference to the other and the association class type, then only a few places actually need coordination.  I think these cases are solved by marking one or the other of the associated class providers as owning the association class.

1)      Enumeration of instances of the association needs to avoid reporting duplicates.  

2)      One or the other needs to service Get/Delete instance.  

3)      *Class operations.

4)      Association class Extrinsic Methods

 

GetInstance, Reference* and Association* operations can be handled from either.

If there are not properties, then ModifyInstance can be rejected by either.

 

George

 

From: Kirk Augustin [mailto:[email protected]] 
Sent: Wednesday, February 10, 2010 5:55 PM
To: kamal jeera
Cc: Karl Schopmeyer; [email protected]
Subject: 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 <http://a.so/>  file
InstanceproviderB.c    ==> made to b.so <http://b.so/>  file
AssociationProviderAB.c ==> made to ab.so <http://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