CIMOM refuses EmbeddedObject with unknown class

Johnny,
I think your idea is interesting.

Let me make it more concrete (and modify it a bit): The classes that have
the dynamic set of properties are __MethodParameters, __JobInParameters and
__JobOutParameters, so these would be defined as empty top-level classes,
and they would have one subclass for each extrinsic method that needs Job
Control support. The parameters of these methods will determine the set of
properties in these subclasses. These three top-level classes would be
defined with the Indication qualifier (to allow them having embedded
instances but no keys), and thus they would not inherit from
CIM_ManagedElement (which is only the mother of all non-association and
non-indication classes, and that is not a requirement but just the current
convention in the CIM Schema).

The potential caveat with the idea is whether or not these method-specific
subclasses prevent an implementation of the Job Control Profile that is
stands on its own, independent of these methods.

Jan,
is this something you could try out ?

Regarding the potential caveat: Did you envision an implementation of the
JCP that is independent of the methods that need Job Control support, and
would this approach prevent such an implementation?

Example MOF:

Top level classes:

       [Abstract, Indication, Version("2.36.0")]
   class __MethodParameters {
   };

       [Abstract, Indication, Version("2.36.0")]
   class __JobInParameters {
   };

       [Abstract, Indication, Version("2.36.0")]
   class __JobOutParameters {
   };

Example method (from CIM_EnabledLogicalElement):

       [ValueMap { ... }, Values { ... }]
   uint32 RequestStateChange (

           [In, ValueMap { ... }, Values { ... }]
       uint16 RequestedState,

           [In(false), Out]
       CIM_ConcreteJob REF Job,

           [In]
       datetime TimeoutPeriod);

Example subclasses for this method:

       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeMethodParameters : __MethodParameters {

           [ValueMap { ... }, Values { ... }]
       uint16 RequestedState;

       // probably leaving out CIM_ConcreteJob REF Job

       datetime TimeoutPeriod;
   };


       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeJobInParameters : __JobInParameters {

           [ValueMap { ... }, Values { ... }]
       uint16 RequestedState;

       datetime TimeoutPeriod;
   };


       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeJobOutParameters : __JobOutParameters {

           [ValueMap { ... }, Values { ... }]
       uint32 __ReturnValue;   // this name is required, see
   CIM_ConcreteJob

       // probably leaving out CIM_ConcreteJob REF Job
   };


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-20 19:35 -----

From:	"Hwang, Johnny" <[email protected]>
To:	Andreas Maier/Germany/IBM@IBMDE, Marek
            Szermutzky/Germany/IBM@IBMDE, Kirk Augustin
            <[email protected]>,
Cc:	Jan Safranek <[email protected]>, "[email protected]"
            <[email protected]>, Robert
            Kieninger/Germany/IBM@IBMDE, Vitezslav Crhonek
            <[email protected]>, Karl Schopmeyer
            <[email protected]>
Date:	2013-03-20 19:12
Subject:	CIMOM refuses EmbeddedObject with unknown class



Hello Andreas,

There should be a workaround where even though the spec expects a
weakly-typed EmbeddedObject, the said weakly-typed EmbeddedObject output
should be able to tolerate a strongly-typed Instance, so you can just
create a custom JobControl class that inherits from CIM_ManagedElement,
the mother of all classes, such that the custom class includes all the
fields that you will ever send out to your heart's content, and call that
a day.

Hope this helps =],
Johnny

On 3/20/13 11:03 AM, "Andreas Maier" <[email protected]> wrote:

>
>@Kirk:
>   The special thing with this class __MethodParameters is that it is
>   required to be supported for an implementation of the DMTF Job Control
>   Profile, and that its properties by definition are dynamic. I am not
>   asking for any kind of general support for "virtual" or "dynamic"
>   classes, I am just interested to solve the problem for the Job Control
>   Profile, and hence, for this one class. In the way this class is used
>in
>   the model of the Job Control Profile, it is the provider that
>determines
>   which properties the embedded instances have, and not the client. So I
>   don't think we are opening any doors to external (client-based)
>   manipulation in any way.
>
>   While the provider will control the set of properties in the embedded
>   instance of class __MethodParameters, CIMOMs like OpenPegasus that
>   perform checking of instances against loaded classes, will have to add
>   some support to tolerate that. Currently, OpenPegasus does not tolerate
>   that.
>
>   Other CIMOMs that do not have such checking, do tolerate that already
>   today (there is a number of them). So the strong checking model
>   OpenPegasus employs is not the only valid way to build CIMOMs. I'm not
>   suggesting to give up on the checking, don't get me wrong. In fact, I
>   think that is one of the great sides of OpenPegasus. But if that
>   prevents us from implementing a standard DMTF profile, we need to fix
>   something.
>
>   Actually, I scanned the CIM Schema and I found three classes that have
>   this special behavior of a dynamic set of properties:
>      __MethodParameters - mentioned in CIM_InstMethodCall
>      __JobInParameters and __JobOutParameters, mentioned in
>      CIM_ConcreteJob
>   All three cases are related to the Job Control Profile, and in all
>three
>   cases, the set of properties will be set by the provider, not by the
>   client.
>
>@Marek:
>   I would definitely argue against an automatic approach where any
>unknown
>   class can be used in an embedded instance, or any class can have
>dynamic
>   properties. That completely defeats the purpose of today's checking.
>
>   A registration based approach (as I imagine it) would allow upon
>   registration of a class to state that the class has a dynamic set of
>   properties, and OP would determine the set of classes that are to be
>   treated specially based on the registration information instead of
>   having the set of special class names hard coded. That would probably
>be
>   an improvement over hard coding the class names, but given that today
>we
>   have only three well known class names, I suggest we start small by
>hard
>   coding the class names. If vendor extension schemas need additional
>such
>   classes, or if the CIM schema adds more such classes, we can still add
>   support for registration to OP at a later point in time.
>
>   Not sure what a configuration based approach would be. Did you envision
>   a control switch that enables and disables the special behavior for the
>   hard coded set of class names ? Or to specify the set of class names
>   with dynamic properties in configuration information ? I would not be
>   too thrilled about the latter, and it is not clear to me that we need
>   such a control switch either.
>
>   I'd like to put a fourth approach on the table: Given that the CIM
>   Schema every now and then seems to have a need for classes with dynamic
>   set of properties, and the current text-based way of describing this is
>   not machine readable, we could make it machine readable by adding a
>   class qualifier (in DSP0004) that expresses that the class has a
>dynamic
>   set of properties. The CIMOM would then have a normal class definition
>   loaded, and would inspect the qualifier value and enable the dynamic
>   behavior based upon that. The nice thing would be that the CIMOM does
>   not need to invent new controls in the provider registration or
>   configuration, that it would be prepared for any new such classes in
>the
>   future, and that it would be very explicit and controlled.
>
>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-20 18:26 -----
>
>From:		 Kirk Augustin <[email protected]>
>To:		 Marek Szermutzky/Germany/IBM@IBMDE, Andreas
>            Maier/Germany/IBM@IBMDE,
>Cc:		 Jan Safranek <[email protected]>,
"[email protected]"
>            <[email protected]>, Robert
>            Kieninger/Germany/IBM@IBMDE, Vitezslav Crhonek
>            <[email protected]>
>Date:		 2013-03-20 16:32
>Subject:		 CIMOM refuses EmbeddedObject with unknown class
>
>
>
>An embedded object must have an existing instance provider registered for
>that class, or else it can not be supported.
>If you try to create a virtual or dynamic class, you will allow an
>anything
>goes environment where sites can be externally manipulated in undesirable
>ways.
>The original definition was to simply map calls to providers.
>If one wants to virtualize what goes on between client and provider, that
>should be up to the provider author, not the CIMOM, in my opinion.
>
>
>Kirk  Augustin
>11821 NW McNamee Rd
>Portland, OR 97231
>
>
>HM: 503-289-4356
>From: Marek Szermutzky <[email protected]>
>To: Andreas Maier <[email protected]>
>Cc: Jan Safranek <[email protected]>; "[email protected]"
><[email protected]>; Robert Kieninger <[email protected]>;
>Vitezslav Crhonek <[email protected]>
>Sent: Wednesday, March 20, 2013 2:49 AM
>Subject: Re: CIMOM refuses EmbeddedObject with unknown class
>
>Thank you Andy for your perspective on this topic, greatly appreciated by
>me.
>
>
>On the EmbeddedObject qualifier there is no "class checking" for existence
>of the class when registering MOF today.
>In CMPI we have no mechanism to create an "EmbeddedObject", we only can
>create Instances (no class support).
>
>Well ... DSP0201 writes on the topic EmbeddedObject: "The value must be a
>valid INSTANCE element, defining a single CIM instance of a CIM class or a
>valid CLASS element."
>Which effectively means there always should be at least a class name, even
>if the class is not registered/defined in CIM Server.
>
>As I tried to describe in my last comment, we can build special support
>for
>"dynamic" / "virtual" classes in OpenPegasus where instances would allow
>user-defined keys and properties (minimum requirement: a valid class
>name).
>Another step to take could be to assume unknown classes automatically as
>being a "dynamic/virtual" class, effectively using an empty representation
>class and going from there.
>
>Not sure if it is preferable to have this as an automatism or require
>special registration or configuration.
>
>I will gladly listen to what the users/exploiters want: automatic,
>configured or by registration ?
>So, please speak up! ;)
>
>
>
>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:        Andreas Maier/Germany/IBM
>To:        Marek Szermutzky/Germany/IBM@IBMDE, Jan Safranek
><[email protected]>
>Cc:        Vitezslav Crhonek <[email protected]>,
>[email protected] <[email protected]>, Robert
>Kieninger/Germany/IBM@IBMDE
>Date:        19.03.2013 22:26
>Subject:        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
>
>
>
>
>