[jsdl-wg] Re: Matching JSDL Terms to Other Specs

[Donal K. Fellows]

Andrea Westerinen wrote:
> Donal, I think that your statement is both incorrect and unjustified.  There
> is much value in CIM for both provisioning and runtime management. There is
> complexity there also - since the managed environment is quite complex. If
> you would care to expand further on what is wrong with CIM, I would be happy
> to address the issues with you.
> 
> BTW, as regards the requirements of a Job, these can indeed be
> modeled/associated as instances of SoftwareResource in CIM V2.9.  Just
> because the info is not in JSIM does not mean that it is not in CIM.

I'd like to start by apologizing for being more than a bit sour at the
time. One of my major problems with CIM as a whole is the difficulty of
actually locating the particular relevant classes; it's getting so big
that it is appreciably difficult to discover which bits are relevant to
the particular problem. :^(

However, it is not at all clear to me how a job's requirements, whether
on software, hardware or data staging, can be described flexibly within
the union of CIM 2.9 and JSIM. An example of the sort of problem comes
from the process of describing what processor architecture a particular
job would like to run on; typically, most jobs are not interested in
specifying a processor stepping level(!) and nor do they really care too
much about whether it is the latest-and-greatest. Instead, they just
know that they need, say, the basic 32-bit x86 instruction set. The
problem for CIM is that its default level of description (in the
CIM_Processor.Family enumeration for those people following at home)
appears to be much finer than that, and there is no defined partial
order relation on the enumeration so that automated systems could know
that a "Pentium(R) III" satisfies a requirement for "Pentium(R) brand"
(which itself is not actually what people would want to write but is the
closest that I can spot as I write this) and yet that "68040" wouldn't
(i.e. just using greater-than on the numeric code is clearly wrong.)
This point relating to partial orderings on enumeration types will apply
to virtually anywhere where you've got enumerations that describe both
more and less specific things (which I notice in passing is fairly
common, and for quite understandable reasons) and will definitely affect
anyone wanting to match against an information service using CIM as its
fundamental information model.

In terms of software requirements it's even less clear, particularly
given that transfer of job descriptions between systems is a critical
requirement for the Grid and that serialization of links (such as
associations) is always an "interesting" topic with the OO community in
my experience. I suppose it doesn't help that there isn't yet a tutorial
paper on describing a computational job within CIM; while I'd admit that
such a description may well be possible, knowing what components to use
to do it is non-trivial (which comes back to the point I made earlier
about the size of CIM I suppose. :^)

For what it's worth, my general impression of CIM to date has been that
it is huge and highly capable of describing things once they have been
instantiated. By contrast, JSDL is intended to be much smaller and to
describe templates for causing the instantiation of jobs. Once those
jobs are instantiated of course, they're no longer really accurately
describable in JSDL (though it would be possible to construct a
most-specific JSDL template which might give rise to the same job) but
they may well be described through CIM (that's up to the implementors
and deployers, but none of our business.)

Hmm, I've rambled a bit here. Sorry! :^) The important facets of what
I've said are probably:

   * JSDL and CIM address different stages of the overall job lifecycle
     (and this is probably a good thing).

   * CIM enumerations could do with the possibility of describing a
     partial ordering on their values. I know that adding POs to CIM is a
     fairly big change (if nothing else, a quick search|count indicates
     1051 potential enumerations to specify!) But is immensely valuable
     for when trying to match against the model, and that's a process
     that's critical to template refinement and instantiation (which are
     in turn key uses of JSDL).

   * It's not yet clear how CIM can describe all the aspects of a job,
     and so there's clearly room for tutorial material here. (A
     job-oriented tutorial would also mitigate against size-of-CIM
     concerns, since it'd make it much easier for people to ignore the
     bits they don't need, a bit like how when you're swimming in the
     ocean you don't care how deep it is since you're only using the
     surface. :^)

If you prefer, we can take this discussion off the JSDL mailing list. ;^)

Donal.