I would treat this as a two part problem... The current model in BES and JSDL is that one JSDL document passed into the CreateActivity yields one EPR to reference/manage it. I don't see any compelling reason to move away from that. To deal with the state representation of the many parameter sweep jobs I would look to use the BES state extension model to capture the details of the number of queued, running or finished parameter sweep tasks WITHIN the running state. I think this would need to be captured in a short profile document along the lines of the HPCBP File Staging extension. If you want to manage each task within an activity there is an undefined Activity port type in the BES specification that you could look to define for individual parameter sweep tasks if you really wanted to... but I'm not convinced of the use case and need for this. Steven
-----Original Message----- From: jsdl-wg-bounces@ogf.org [mailto:jsdl-wg-bounces@ogf.org] On Behalf Of Piotr Domagalski Sent: Tuesday, July 22, 2008 10:32 AM To: jsdl-wg@ogf.org; ogsa-bes-wg@ogf.org Subject: [jsdl-wg] Parameter Sweep and BES Factory
Hi!
I'm just wondering -- is there any agreed view on how Parameter Sweep Extension should interact with BES Factory job submission? My main concern is whether the submission should return an activity that hides all those individual tasks that the parameter sweep produced (say, 1000 jobs from one JSDL...) or should it be possible to somehow treat them individually?
The problem with the former is that it would only be possible to get a some kind of heuristic view of the state of the activity (say, the activity is in running state if at least one of the individual tasks has moved to this state).
The problem with the later is, in my understanding, the fact that the CreateActivity yields one and only one ActivityIdentifier.
-- Piotr Domagalski -- jsdl-wg mailing list jsdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/jsdl-wg