What is the best way to model a name/value pair in CIM?

Klaus Kaempf kkaempf at suse.de
Mon Feb 25 20:54:41 UTC 2013


* John Dennis <jdennis at redhat.com> [Feb 25. 2013 20:06]:
> On 02/25/2013 01:14 PM, Klaus Kaempf wrote:
> >
> >can you be more specific about what you're trying to accomplish ?
> >Do you have an example ?
> 
> Certainly. The CIM provider is an interface to an existing RPC based
> API. In that API some of the methods accept a "dictionary" of
> optional parameters used to control the behavior of the methods. The
> set of valid keys in that dictionary is subject to extension.

Try to find a model of what is managed through this RPC API. If you
focus too much on the API, you're modelling the API instead of
managing the underlying resource.

One approach to capture the api via CIM is a method provider, offering
many methods, one for each behaviour of the api. Maybe the method
signatures can then be expressed via CIM types.

I personally dislike method providers since they inherently have side
effects. A much better approach is to follow the REST principle and
base the model on create-read-update-delete of instances.

Compared to writing a provider, good modeling is very hard. It's like
designing a database scheme while keeping the right normal form.

> Some of the results from the RPC are name/value pairs. Once again,
> they are not fixed, they are subject to extension. The idea was to
> define a CIM class which along with other properties would also
> define a property which was a set of key/value pairs.
[...]
> 
> >>Is the best approach to define a new class that has just a name and
> >>value property?
> 
> Then why not just answer, yes that is the correct approach?

Its a possible approach, esp. for the rpc api results. The purpose of
a CIM model is to express the semantics of whatever is being modeled.
A class with name and value properties does not capture this.


Hth,

Klaus
-- 
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany


More information about the openlmi-devel mailing list