You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Chris A. Mattmann (JIRA)" <ji...@apache.org> on 2011/06/19 02:30:47 UTC
[jira] [Created] (OODT-215) Workflow2 Architecture
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.4
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated OODT-215:
-----------------------------------
Attachment: WorkflowEngine.png
arch figure
> 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.4
>
> 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
[jira] [Updated] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (Updated) (JIRA)" <ji...@apache.org>.
[ 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.5)
0.4
- this will be done by 0.4
> 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.4
>
>
> 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
[jira] [Commented] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290742#comment-13290742 ]
Chris A. Mattmann commented on OODT-215:
----------------------------------------
haha you like that? Maybe I was using FILO prioritizer hahah. As for the queues, yeah one of them might be queue of workflows (the Queue Manager, since I haven't really gone through that one in full yet, which indicates that it's not yet done). But the TaskQuerier and Task Queue I'm pretty sure about, right?
> 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.4
>
> 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
[jira] [Updated] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051622#comment-13051622 ]
Chris A. Mattmann commented on OODT-215:
----------------------------------------
Note, a lot of this work exists already in the wengine-branch, but I'm filing it here so we can track progress amongst it, and the other issues I recently filed.
> 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.4
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OODT-215) Workflow2 Architecture
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann resolved OODT-215.
------------------------------------
Resolution: Fixed
- all done, we are pretty much all there, thanks guys!
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OODT-215) Workflow2 Architecture
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290444#comment-13290444 ]
Brian Foster commented on OODT-215:
-----------------------------------
RE: arch figure ... t1, tN, t2, t3... lol... is that trying to show that is was sorted?... i haven't had a chance to look over all your changes to trunk workflow, but is there really 2 task queues? or is Queue Manager a queue of workflows?
> 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.4
>
> 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