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