oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Obtaining workflow instance unique ID
Date Fri, 29 Apr 2011 04:42:03 GMT
Hey Cam,

Answers below:

> That is a huge help!  My term serialize (which i might be using in the wrong
> context = probably should be replaced with SEQUENTIAL instead) means running
> 'things' (workflow instances, task instances) in a row instead of in
> parallel.  So with that explained let me copy those questions to the top of
> this email, to see what your answers are:
>>  - You cannot use standard configuration to Serialize Workflows
> spawned from a single Event
> (So if an event spawns 4 workflows they will try to run in parallel by
> default, but can the workflow models be configured to run in a specific
> order?)

You can easily do this in fact it's what the trunk/workflow/engine is good at. You just wire
up a tasks.xml, something like:


  <task id="task1" class="..."
  <task id="task2" class="..."
  <task id="task3" class="..."
  <task id="task4" class="..."

Then you write a workflow document like this:


<cas:workflow id="my.workflow.id" ...
   <task id="task1"/>
   <task id="task2"/>
   <task id="task3"/>
   <task id="task4"/>

Then you wire up an event that kicks of my.workflow.id:


<cas:events ...
  <event name="Event1">
    <workflow id="my.workflow.id"/>


That's it.

>>  - [Can tasks be parallelized/serialized using config?]
> (Same use of serialize here, meaning if a Workflow Model has 3 tasks, will
> the workflow instance try to run all 3 tasks at once, or in sequence.

It'll by default try and run them in sequence. It's controlled by the Workflow Processor Thread.
The default one is an IterativeModel. 

>  What
> is the default behavior?  And can we switch between the two using
> configuration?)

Default is answered above. To switch to something not iterative, you need to do a combination

1. Conditions (to block things from happening in parallel that shouldn't, e.g., Tasks running
that should wait)
2. Special "redirector" tasks that send events back to the workflow manager that kick off
other workflows
3. parallelization on event->workflow kickoff

A combination of 1-3 can achieve pretty much any workflow that we can academically model.

> Thanks Guys.
> -Cameron



Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message