[jsdl-wg] JSDL vs NorduGrid xRSL: a comparison (fwd)

[Donal K. Fellows]

Oxana Smirnova wrote:
>>  a) This should be possible through either the existing subelements of
>>     the POSIXApplication element, or through extension. However I'd love
>>     to see more input from you on this as part of the development of the
>>     next version of the spec.
> 
> There are several elements that can be easily added; runtimeenvironment 
> is just one of them. What is this group's criteria for an element to be 
> added to the specs? What kind of arguments should I present to support 
> each case? Would it be sufficient to tell that few hundred users find it 
> convenient, and so do Grid m/w developers and site owners?

On one level, it'd be more relevant to us if the concept was of use to
multiple grid middleware or job management systems. There is no need for
standardization of the term if all those few hundred users are using the
same system. :^)

On the other hand, I'm sure I do not understand what you mean by runtime
environment. While I have my own interpretations of the term, the way
you talk about it does not match up at all with any way I would so I
suspect you're talking about something different. We need your help here!

>>  b) This should be done by wrapping the JSDL singletons inside some
>>     larger XML dialect that describes the relationship of the basic jobs
>>     to each other. Although we want to support workflows, we've always
>>     pushed the workflow bit of it out of scope so we can get agreement
>>     on the rest of everything. :^)
> 
> I don't think that describing several jobs in one script has anything to 
> do with workflow. It's up to the workload management system to interpret 
> it, but for the user's convenience it would be nice to include into JSDL 
> a possibility to specify several jobs. No need for a "larger XML 
> dialect", just one more super-element. Here's a use case: I want to 
> submit 10000 jobs that differ only in one input parameter. I have a tool 
> that generates JSDL; and I'd hate to fill my disk with 10000 small 
> files. You are not going to create a dedicated workgroup to produce a 
> two-line spec that describes JSDL concatenation, are you?

Ah, but that fits more with the concept of a service description; having
a job running service that can take a vector of JSDL documents makes
sense (and is a use case that perhaps ought to be forwarded to the Basic
Execution Service WG) but that is completely external to the concept of
a JSDL document. And anyway, there's no need to standardize everything
(as I said before).

>>  c) I think we're punting this one out to WS-Agreement (over a space of
>>     JSDL terms). It gets really complicated otherwise as you start to
>>     try to describe spaces of coupled terms...
> 
> Eh, nobody promised it's going to be easy :-) I understand that XML is 
> just a markup language, not quite suited for task definition, because 
> task description normally includes conditions "if then else", relations 
> "and", "or", and negations "not". For example, "buy X amount of apples 
> if they are red, else buy Y amount of pears and Z amount of bananas". 
> This is a  single task, these are not separate jobs. It does not 
> describe workflow, because it does not specify in which shop these 
> apples or pears should be purchased (doesn't even say it should be the 
> same one), or when, and not even the price. JSDL presently can't 
> describe such a job. I don't even see how two separate job descriptions 
> can be merged by another *XML* dialect into one - XML is not really made 
> for it. In real life, I've had plenty of jobs like "if a site has 
> outbound connectivity, stage in this, else stage in something 
> different". Globus' RSL allows this, and I'm sure it's a part of job 
> description, not workflow.
> It is an instruction for the execution site, not for the workload 
> manager/broker.

We have been through many iterations on this topic. Initially, we had a
complex combinatorial language for doing this. It was a mess. We then
switched to profiles for doing this (look them up in previous versions
of the spec if you're interested) which were much simpler, but they too
were removed on the grounds that they were also hard to specify
accurately. Where we are now is at the point where we are leaving that
sort of thing to some other specification, such as WS-Ag over a space of
terms defined by JSDL. Given that it appears that this will actually be
sufficient to describe such things, why should we *independently*
develop our own language for doing preferencing? That would feel like a
horrible case of Not Invented Here, and would be poor use of our time.
And JSDL as it stands is going to be useful for many people, even if it
won't solve your particular problem without extension of some kind.

Of course, it might actually be the case that in the future we should
return to the concept of a preferencing language so that your
requirements could be addressed within JSDL itself. The development of
standards is in reality an ongoing process, and not a simple target.

Donal.