CIMOM refuses EmbeddedObject with unknown class

@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