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.