Ian Foster wrote:
Like Steven Newhouse, I'd like to urge caution on the workflow issue. There are so many research projects, standards activities, and industry initiatives in this area, and workflow is such a broad area, that we could easily spend a lot of time to little purpose.
I think the one thing that would really make a big difference is a special version of the general workflow problem: co-scheduled activities. This is an important area because it affects how you discover and book resources for jobs, and many of the most interesting computational applications that I've seen have been coupled jobs (e.g. where you hook an oceanographic model to a climate model to make better predictions about the global climate, or a local weather model to a hydrographic model to a series of engineering models to work out which bridges over a river are likely to be washed out by a predicted flash flood). The distinguishing thing about these applications is that they are made up out of components that need to be run together (I suppose we could come up with other examples too, such as coordinating scheduling with other resources for things like computer-aided surgery) and yet this is an area which is not as widely tackled as other parts of the overall workflow space. So if we concentrate on how to do this specific part, we get a big gain without treading on too many people's toes; they'll all still be able to use their favourite orchestration and coordination services to run things. The other key thing here is that very often you want to have co-scheduling, but you (the user) don't actually want to pick a specific time; so long as the timeslices of the apps are coordinated, the times themselves are far less important. (I can remember trying to do demos of coupled applications without such a coupled reservation system; it all failed completely, which was supremely embarrassing!) I also think it also fits well with JSDL's step-by-step bottom-up mission. Donal.