
Thanks Donal. A couple of comments:
I think that what would be far more useful would be to merge this with some of the EMS scenarios to form a combined OGSA Parameter Space Exploration use-case. But that's a lot of work to do since it looks like the compute and the data people are failing to see eye-to-eye (again).
If we are failing to see eye-to-eye, that's an argument for making this use case (and other similar ones) a high priority for both compute and data people. I hope we can address some of these issues on Monday.
I believe that some of the things I've been thinking about for the EPS spec are likely to be useful in the selection of Data-related resources. All that changes really (at the interface level) are the input request language and the candidate description language.
This seems entirely plausible. Our Data Architecture document makes the point that services such as deployment, reservation, scheduling etc. should be generic enough to handle many different types of resources (including computation, data & network). Although I do know of people in the data world who believe that some of the issues are substantially different for computation & data; perhaps it would be sensible to arrange a brainstorming meeting on this topic.
Service instances are chosen (including any deployment) before the commencement of the scenario. A question they don't address is whether moving the computation to the data would be better.
This is just one scenario; we could develop another where the computation is moved to the data. From our point of view, when the instances are chosen is of little interest, provided the deployment is managed as necessary.
There is a post-processing phase to be applied to the output data which the scenario does not properly highlight.
We'd be happy to correct this.
A more sensible structure might involve some kind of Orchestration service (e.g. based on workflows) to control the parameterized input data creation
I believe a later version of this scenario does suggest the use of workflows. We'd be happy to work more closely on this. Best wishes, Dave.