Mailing-List: contact commits-help@oodt.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oodt.apache.org
Date: Wed, 10 Aug 2011 06:25:28 +0000 (UTC)
From: "Chris A. Mattmann (JIRA)" <jira@apache.org>
To: commits@oodt.apache.org
Message-ID: 
 <1982401132.23056.1312957528029.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2047021410.18595.1308443087381.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (OODT-211) Sub Workflows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/OODT-211?page=3Dcom.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 us=
e of sequential/parallel sub-workflows. I expect to turn PackagedWorkflowRe=
pository into the default that ships with OODT workflow, so that should sol=
ve 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 capture=
d was having sub workflows. This was not a necessity on OCO, when the subje=
ct 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 ta=
sk within another workflow. This will really help people conceptualize thei=
r workflows and facilitate the ease of maintenance and operations for the p=
erson 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 work=
flow 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 h=
ow workflows could be broken down but I'm sure there are many others; as th=
ere are several that I have come across. Moreover, beyond maintenance and o=
perations this would promote reuse of existing workflows and start to draw =
a picture of how different parts of the pipeline are related. This theoreti=
cally could cut down on initial time to set up workflows as parts that were=
 redundant (other than just configuration) could be partitioned off as thei=
r own workflow and reused. Finally, generalizing a workflow as a task itsel=
f 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 e=
ase 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