What I've been doing with GRAM is to add an extension element to JobDescription instead of JobDefinition which is an array of JobDescription elements. This allows for the top-level JobDescription to act as a defaults document. This is useful if you're doing things like parameter sweeps. The executable, directory, etc can be specified once and only those items that differ between subjobs are specified explicitly in the subjob JobDescription elements. I also think the ID attribute is perhaps redundant. JobIdentification has a JobName element that seems like it should be sufficient for uniquely identifying a subjob. Or is this not how the authors envisioned JobName's use? I'm wondering if such extensions are really within scope of the JSDL specification, though. It seems more like an application-specific extension. Perhaps the workflow elements should be in a WorkflowApplication extension to the top-level Application element, and then the POSIXApplication extension would be specified for the subjob JobDescription elements. This would ruin using the top-level JobDescription element for subjob defaults (doing both would be too confusing), but I'm ok that. Peter On Jul 30, 2006, at 6:35 AM, Alexander Papaspyrou wrote:
Hi Michel, all,
Michel Drescher schrieb:
NOTE: The multi job extension requires two backwards compatible changes to the JSDL v1.0 schema itself: a) jsdl:JobDescription gets an "id" attribute of type xsd:ID b) jsdl:JobDefinition allows more than one jsdl:JobDescription element.
sounds decent to me. We are doing exactly that with a home-brew XML dialect in D-GRID (http://www.d-grid.de/) for what we call workflows -- which is pretty much the same as dependent jobs.
I will update/create the necessary specification documents after the next round of rotten eggs. ;-)
No eggs today ;)
Interesting. I used to think in terms of doing job dependencies like you illustrate in example2, but recently I've been considering treating a job (or rather the outcome of that job) as a resource in itself. This would mean that, once a job has been labelled, all the other things need to do to depend on it (i.e. follow in the job-graph) is to put a reference to that job in their Resources element. I don't know whether this would permit the definition loops, but maybe loops are only ever useful for things like parameter sweeps anyway. (Need more real use-cases to decide that!)
Hm, I'd separate these (as Michel suggested for the bi-directional deps further down) to keep it simple. The "output from A is input for B" could for the moment be handled by the service which gets the JSDL and orchestrates the execution.
Eventually we decided that this type of model is very much compatible to human brains, but (unfortunately) not to relatively dumb computer brains.
I agree, since this needs deeper thought.
It doesn't solve the other thing that ought to be expressed though. It is sometimes *really* useful to be able to specify that two jobs must execute at the same time (otherwise the job engine might just run the
Agreed, this should be added with the deps extension.
a) Rename jobgroup:Dependencies to jobgroup:Constraints b) Have an abstract element named jobgroup:COnstraint c) Use XML Schema substitution groups for types of constraints: c.1) jobgroup:Dependency for unidirectional dependencies c.2) jobgroup:Coupling for jobs that need to co-execute.
Any more suggestions?
What about a single dependency type with attributes like "before", "after", "togetherwith", "whenfailed" and so on? The attributes could then be externalized to an enumeration and extended over time without breaking the core.
Comments, eggs and/or tomatoes?
Greetings, Alexander
-- Dipl.-Inform. Alexander Papaspyrou | 44221 Dortmund, NRW (Germany) Robotics Research Institute | phone : +49(231)755-5058 Information Technology Section | fax : +49(231)755-3251 Dortmund University | web : http://www.irf.de/