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] [Resolved] (OODT-211) Sub Workflows
Date Wed, 10 Aug 2011 06:25:28 GMT

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

Chris A. Mattmann resolved OODT-211.
------------------------------------

    Resolution: Fixed

With the PackagedWorkflowRepository, this is now easily possible via the use of sequential/parallel
sub-workflows. I expect to turn PackagedWorkflowRepository into the default that ships with
OODT workflow, so that should solve this.

> Sub Workflows
> -------------
>
>                 Key: OODT-211
>                 URL: https://issues.apache.org/jira/browse/OODT-211
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>            Reporter: Paul Ramirez
>            Assignee: Chris A. Mattmann
>             Fix For: 0.4
>
>
> One feature that Chris and I have talked about but never formally captured was having
sub workflows. This was not a necessity on OCO, when the subject was first discussed, just
as the graph based workflow was not. However, I believe it to be a useful concept moving forward
to help cast processing pipelines as workflows. The idea is that any workflow could be seen
as a task within another workflow. This will really help people conceptualize their workflows
and facilitate the ease of maintenance and operations for the person in charge of running
workflows. Currently, when a workflow is stopped how is one to proceed and resolve the issue
that the workflow encounters? Is this an all or nothing proposition? If we had subworkflows
a parent workflow could be blocked because of some subworkflow but instead of rerunning the
whole thing the operator could decide that only a portion of that needs to be rerun (subworkflow).
This brings out one logical case of where and how workflows could be broken down but I'm sure
there are many others; as there are several that I have come across. Moreover, beyond maintenance
and operations this would promote reuse of existing workflows and start to draw a picture
of how different parts of the pipeline are related. This theoretically could cut down on initial
time to set up workflows as parts that were redundant (other than just configuration) could
be partitioned off as their own workflow and reused. Finally, generalizing a workflow as a
task itself would help flush out the concept that conditions that a particular task (workflow)
are waiting on has a bearing in the global context and should be promoted up. This would promote
summarization of information and possibly ease decision making from a user and software prospective.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message