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

[Andrea Westerinen]

Replies inline... Andrea 

> -----Original Message-----
> From: Donal K. Fellows [mailto:donal.k.fellows at manchester.ac.uk] 
> Sent: Wednesday, December 01, 2004 2:21 AM
> To: Andrea Westerinen
> Cc: 'JSDL WG'; cgs-wg at gridforum.org
> Subject: Re: [jsdl-wg] Re: Matching JSDL Terms to Other Specs
> 
> 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. :^(

<arw> Totally understand your statement here.  That is why DMTF is working
on 2 things - profiles (sets of classes with explanations (ie, patterns) to
solve specific management problems) and a simplified model in CIM V3
(release planned for 1H2005).

> 
> 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.

<arw> Actually, I would not associate a specific processor (which is what
CIM_Processor describes) with a Job's requirements.  That is why I
referenced SoftwareResource as a way to describe what is needed - that could
then be tied to an actual system and its components (if desired) using the
LogicalIdentity association.  The SoftwareResource describes what is needed
by the software in terms of files, memory, ... and the LogicalIdentity can
tie that to actual "stuff" when the software is executing.

> 
> 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. :^)

<arw> Sounds like a Job Profile is key for the DMTF to create very soon.  I
will take that message back to the System/Devices WG and help with the task.

> 
> 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.)

<arw> I think that CIM can do (and has done) both - but you are right to
want to separate the description of needs from the actual implementation.
And, it is right to question what seems too hard to do - since that is valid
feedback and will lead to a better model.

> 
> 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).

<arw> I agree that JSDL and JSIM address different stages, but CIM is meant
to address both stages.  That said, I acknowledge that CIM has more work to
do in the "describing what a job needs" category.

> 
>    * 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).

<arw> Agree - this is something being investigated for CIM V3.

> 
>    * 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. :^)

<arw> Agree!

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

<arw> According to Ali, we have to keep it here :-).

> 
> Donal.
>