oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OODT-215) Workflow2 Architecture
Date Fri, 15 Jun 2012 04:36:44 GMT

     [ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chris A. Mattmann updated OODT-215:
-----------------------------------

    Fix Version/s:     (was: 0.4)
                   0.5
    
> Workflow2 Architecture
> ----------------------
>
>                 Key: OODT-215
>                 URL: https://issues.apache.org/jira/browse/OODT-215
>             Project: OODT
>          Issue Type: New Feature
>          Components: workflow manager
>         Environment: from JPL's internal JIRA, pre-ASF
>            Reporter: Chris A. Mattmann
>            Assignee: Chris A. Mattmann
>             Fix For: 0.5
>
>         Attachments: WorkflowEngine.png
>
>
> We'll use this issue to keep track of the proposal for a Workflow2 architecture, supporting
more complex workflows (fan-ins and fan-outs) and more fine-grained control of the underlying
control and data flow models. Here is the proposal from Brian and Paul and me:
> In the new workflow model structure, a model has an execution type. cas-workflow will
come standard with 4 workflow execute types implemented, but extendable so that new types
can be added, current types can be extended, and even overriding of current types. The standard
workflow execution types are (keep in mind that a task is considered a workflow of 1 in the
new model):
> 1) Sequential
>     will run all containing workflows in sequence
>     2) Parallel
>     will run all containing workflows in parallel
>     3) Subset-Parallel
>     will run all containing workflows in parallel, but allowing for the case that some
containing workflows may not run
>     4) Ntimes
>     will run all containing workflows in parallel a given number of times determined
by a creation rule interface
> Properties can be added to any given workflow thus allowing for a customizable workflow
type extension point.
> The default type will be 'Sequential' thus allowing for the old workflow structure to
work seamlessly with the new version.
> Example xml:
> <workflow id=""> or <workflow id-ref=""> . . . the former declares that a
workflow is being defined; the latter that a workflow has already been defined and is being
referenced.
>     additional attributes include:
>     execution : valid values, by default, are the standard workflow execution types described
above
>     trans-in : a list of pre-Condition ids that must be met in order for the workflow
to run
>     trans-out : a set of post-Condition ids that must be met for successful completion
of the workflow
>     any attribute in the namespace 'p' : this declares a properties for the workflow
that can be used to customize this workflow model's execution type
>     <task id=""> or <task id-ref=""> . . . same as to the 'workflow' element
except no 'execution' attribute is allowed — tasks are a specific type of workflow that
is execution 'single' (the implied workflow execution type by the 'task' element).
>     also allows for all previously supported child elements allowed in old workflow model
> Comments are of course, welcome.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message