CIMOM refuses EmbeddedObject with unknown class

Marek, Jan,
At this point (with Jim Davis' response to my other mail still
outstanding), my guess is that OpenPegasus will need to special-case class
__MethodParameters. One reason is that its properties are likely to
correspond to the method that was invoked. Which means its declaration
changes every time, but it keeps the same class name. It is therefore not
possible to come up with a statically declared class for that.

One idea is that OpenPegasus would disable its class checking for
EmbeddedObject qualified elements that contain an embedded instance of that
special class.

If that is not possible because OpenPegasus internally depends on class
declarations, then one other idea is that OpenPegasus dynamically creates
an internal representation of the class declaration based on the properties
it finds in the embedded instance of that special class (because that is
supposedly how it works with this class).

I believe there is already a small handful of such cases in the CIM schema,
and tomorrow some vendor could come up with a new one.  Note that the
reason the EmbeddedObject qualifier is used and not EmbeddedInstance, is
that that allows not having to declare the class name in the qualifier.
Ignoring the fact that EmbeddedObject is simply the older one of the two,
one could also argue that the whole intention of the EmbeddedObject
qualifier is that the class is not necessarily declared. If it was declared
one could have used EmbeddedInstance and specify it (arguably that would
not work for polymorphic use of associations because they do not have a
single root class, or esoteric cases of mixes of ordinary classes,
indications and associations).

Bottom line, I think we need to have a discussion as to whether class
checking is a good idea for embedded instances in EmbeddedObject qualified
elements. Is that somehow doable in OpenPegasus ?

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
[email protected], +49-7031-16-3654
________________________________________________________________________
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

----- Forwarded by Andreas Maier/Germany/IBM on 2013-03-19 22:12 -----

From:	Marek Szermutzky/Germany/IBM
To:	Jan Safranek <[email protected]>
Cc:	Vitezslav Crhonek <[email protected]>, Andreas
            Maier/Germany/IBM@IBMDE, [email protected]
            <[email protected]>, Robert Kieninger/Germany/IBM@IBMDE
Date:	13.03.2013 13:31
Subject:	Re: CIMOM refuses EmbeddedObject with unknown class


Hi !

Good to have you on the mailing list and thank you for reporting this
problem. It looks like you are the first one trying to implement Job
control, not too surprising though since the profile only was published in
May 2012. EmbeddedInstance/EmbeddedObject support works well perfectly fine
in OpenPegasus as long as instances are based on a registered class (known
and full defined class).

To be honest ... this arbitrarily generated class "__MethodParameters" was
a big surprise to me. My first reaction was to call it a "dirty trick" and
asking for who introduced that concept of a "virtual" class in the DMTF CIM
Schema definition. ;)
But I understand your situation and that this nothing you chose to do.

Let me try to give you a short description on the background and the reason
this doesn't work right now.
The design approach in OpenPegasus for CMPI is to have instances always be
based on a defined class like programming languages do. There you cannot
create an instance of a class without having the class defined. This has
several advantages, obvious things like type-safety and stability but also
in the area of footprint and performance. What I am trying to say is that
with OpenPegasus 2.12.0 I see no easy circumvention which would allow to
implement the indication that uses "__MethodParameters" (that indication is
an optional feature in Job Control Profile).

I discussed this with one of my fellows (Robert Kieninger), we invented the
SCMO model in OpenPegasus together (we made that "instance based on class
only" design decision). We came to the conclusion that supporting this
"__MethodParameters" needs some code changes and a feature addition to the
Single Chunk Memory Object Model.
We basically would add a flag to our internal representation of classes
which says: "virtual". On these "virtual" classes we would allow
"user-defined properties" to be added, just as "user-defined key
properties". Assuming "__MethodParameters" would be registered with the CIM
Server as an empty class and flagged as "virtual", you now could create
CMPI instances from that class and freely add whatever properties required.
The advantage of such an approach is that we do not lose the performance
advantage existing providers, as well as the type-safety for provider
creating instances for defined classes.

I have not done a full analysis on the necessary code changes (effort?) to
implement support for such "virtual" classes, but I believe this would be
the right solution to the Job Control Profile issue. I do not know the time
frame in which you would need this fixed, but assuming OpenPegasus 2.13
with Release Date of 15 July 2013 is sufficient, can you imagine working
your code and test cases in a way that you would register a class
"__MethodParameters" in OpenPegasus which holds the parameters for all
methods used in your testing (that's the quick hack around the problem I
see) ?

But maybe someone else has a proposal for a quicker solution or
circumvention ?


Putting Andreas Maier (Andy) on CC.
Andy ? Do you think we can find someone in IBM to pick up the work
necessary to implement this "virtual" classes concept in SCMO and CMPI ?


Kind regards,
Marek Szermutzky

Software Engineer / OpenPegasus Maintainer (PMC)
IBM Systems &Technology Group, Systems Software Development / z/OS Capacity
Management and Support
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-5182
E-Mail: [email protected]
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland Research & Development GmbH / Vorsitzende des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294



From:	Jan Safranek <[email protected]>
To:	[email protected]
Cc:	Vitezslav Crhonek <[email protected]>
Date:	13.03.2013 10:22
Subject:	Re: CIMOM refuses EmbeddedObject with unknown class



On 03/13/2013 09:22 AM, Jan Safranek wrote:
> I have a CMPI provider for CIM_MethodResult class under Pegasus 2.12.0.
> It has EmbeddedInstance('CIM_InstMethodCall') property
PostCallIndication.
>
> This CIM_InstMethodCall class has EmbeddedObject property
> MethodParameters and description of the property says:
>
>    The parameters of the method, formatted as an EmbeddedObject (with a
>    predefined class name of "__MethodParameters".
>
> Now if I set the MethodParameters property with CIM instance of
> not-existing "__MethodParameters" class in my provider, Pegasus returns
> CMPI_RC_ERR_NOT_FOUND from
> src/Pegasus/ProviderManager2/CMPI/CMPI_BrokerEnc.cpp:mbEncNewInstance()
>
> If I try to use "CIM_ManagedElement" as classname of the embedded object
> just for testing, Pegasus shows correct property, i.e. these
> EmbeddedInstances and EmbeddedObjects work well for registered classes.

Well, it does not work so well... I can add only properties specified
for CIM_ManagedElement, I cannot add parameters of the method as
properties - the parameter names (=name of __MethodParameters
properties) are different for each method which starts a job.

Am I the first one, who tries to implement job control? How can I return
an output parameter from a method, which created a job, without using
embedded instance? Whole CIM is full of these methods... Do I miss
something?

Jan