RE: Workflow

["Bivens, Hugh P" <hpbiven@sandia.gov>]

Tomasz, my comments are inline.

GCEers, see 

http://vir.sandia.gov/~hpbiven/ggf/draft-bivens-grid-workflow.pdf 

and 

http://vir.sandia.gov/~hpbiven/ggf/gale-hpdc-10.pdf

if you're not sure what we are talking about.


> 1. Do we really want to use the term "workflow"? During our meeting in
>   San Diego I got impression that majority was against it, as this
>   term is being used in a somewhat different sense outside our
>   community. Within my framework (Mississippi Computational Web
>   Portal - MCWP) I use the term complex task. Even you use this term
>   in your abstract: " (...) a standard for the sequencing of complex
>   high-performance computational tasks within a Grid".


Yes, I think we do want to call this workflow. I find it very convenient to
use workflow terminology (process, activities, workflow description
language) to describe GALE. Very precise definitions already exist. For
example, see

http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf

Workflow to some people, however, implies very complex e-business
transactions. GALE is a very specialized and simplified workflow definition
language, and does not offer most of the features of a "mature" workflow
definition language. I think a lot of those features are just not necessary,
or at least I haven't had a requirement to use them yet, and just lead to a
standard that is much harder to implement.    
  
> 2. Is the "sequencing" not too restrictive? I am hoping for a standard
>   that describes a computational graph (as AVS or other visualization
>   packages often implement). Let's assume that the complex task is
>   composed of "modules" or "atomic tasks". It seems to me that
>   sequencing means processing one module after another. Can't we
>   generalize it to more complex graph? Such as results of one modules
>   can be feed to several modules running concurrently, or one module
>   being feed with data coming from two or more modules (or being
>   dependent on them in any other way)? Actually you admit this
>   problem in section 6.

True, GALE is strictly serial dependencies now, and I think the work that
you and others have done would be very useful. 
 
> 
> 3. It seems to me you are suggesting an enumeration of "atomic tasks":
>   computation, resource query, data transfer, ..., etc. Again, is it
>   not too restrictive? Actually I have several problems with that.

> ...

When I started designing GALE I struggled a lot with whether to define a
general task or activity. One of my design goals was to be able to create a
"grid script" that non-IT specialists would be able understand. To me, that
meant defining specific activities like DataTransfer and Computation. Most
of our users will never see the XML, but like always there are those that
hate GUIs and prefer commandline tools and editing text files directly.

I agree that we need a more sophisticated transition mechanism based on
events.



> 
> I would appreciate your comments on my thought about complex task
> descriptor. To be a little more constructive, I am appending  task
> descriptors that I used in my work a couple years ago, and intend to
> use in the near future while developing MCWP. Again, do not look at it
> as the mature draft of the standard, but rather a bunch of ideas to be
> considered.
> 
> Tomasz
>  
>  
>  
> 
>