CIM Provider HOWTO Document

John Dennis jdennis at redhat.com
Mon Apr 8 14:38:11 UTC 2013


On 04/08/2013 10:28 AM, Jan Safranek wrote:
> On 04/08/2013 03:59 PM, John Dennis wrote:
>> On 04/08/2013 04:51 AM, Roman Rakus wrote:
>>> On 04/05/2013 08:47 PM, John Dennis wrote:
>>>> On 04/05/2013 07:35 AM, Roman Rakus wrote:
>>>>> I'm confused in section where you are describing structures and
>>>>> array of
>>>>> structures. I think this is where Embedded Instances take place.
>>>>> However, the KonkretCMPI does not support embedded instances.
>>>>
>>>> Hello Roman:
>>>>
>>>> I'm not familiar with embedded instances. Can you elaborate or provide a
>>>> pointer to documentation?
>>>>
>>>> Thanks.
>>>>
>>> I can't find much in documentation. Just in CIM Metamodel (CIM
>>> Infrastructure Specification) [1] are few words about Embedded Objects.
>>>
>>> Embedded object is qualifier. For example you can have parameter of
>>> method with this qualifier. Such parameter will be embedded object
>>> (instance or class). The type of parameter is string. When we talk about
>>> instances - this string is encoded (embedded) instance of some class.
>>> There are functions in CMPI to create instance from this string
>>> representation.
>>>
>>> I have never used this. But I think it could help to encapsulate
>>> definition of parameter and passing it, but with need of such definition
>>> in model.
>>
>> Ah, O.K. yes this now rings a bell with me and I did momentarily
>> consider this as an option.  My understanding is it amounts to
>> formatting the data in MOF syntax and passing it as a string. One then
>> parses the MOF formatted string.
>>
>> My take on this is:
>>
>> * It's very awkward to use, it's not a friendly API scheme.
>>
>> * I didn't find any support for parsing MOF syntax in any of the
>> libraries a provider links with.
>
> It's not MOF formatted string, it's CIM object instance encoded in XML
> as string-value of a property.
>
> On server (CIMOM) side, this is automatically handled and translated
> into CMPI_instance property, on client side, pywbem handles it
> transparently too.

Thank you Jan, great information!

Is this supported on all the CIMOM's we're interested in?

Is there client support for generating the XML?

> And it's quite often used when specifying 'SettingData'. Application,
> i.e. CIM client, creates a CIM_SettingData instance, fills its
> properties and passes it as EmbeddedInstance to a method, which creates
> something.
>
> For example, CIM_FileSystemConfigurationService.CreateFileSystem +
> CIM_FileSystemSetting.
>
> Actually, subclassing CIM_SettingData might be the magic key-value
> structure you were looking for. Only list of keys and possible values
> must be known and defined in *SettingData MOF file. Adding new keys in
> new version is perfectly valid, it does not need to be rock stable.
>
>
>> Thus at the moment it doesn't seem like a viable option and even if we
>> grow support for parsing MOF syntax I'm not sure one would want to
>> design an API around passing MOF snippets.
>>
>>> [1]
>>> http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_3.0.0.pdf
>>>
>>>
>>
>>
>


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/


More information about the openlmi-devel mailing list