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/