Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oodt.apache.org
Received-SPF: pass (athena.apache.org: domain of brbarkstrom@gmail.com
 designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9ECD1EC8-6282-47B4-BFB7-4EBA4E2E55FB@gmail.com>
References: <603BE2EF-F263-4FFA-9A95-E33229E92CC8@me.com>
	<F7FB192A-4FBD-43E5-BAF4-7FA638260B4F@me.com>
	<9ECD1EC8-6282-47B4-BFB7-4EBA4E2E55FB@gmail.com>
Date: Thu, 8 Nov 2012 13:53:30 -0500
Message-ID: 
 <CAOG8ptUDVVZrzsbJUU9fj0eb+gnvQEkBTOAv54uM6LJLpLnjrw@mail.gmail.com>
Subject: Re: Workflow Task/Condition Instances...
From: Bruce Barkstrom <brbarkstrom@gmail.com>
To: dev@oodt.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb2066ee2fc2d04ce005961

--e89a8fb2066ee2fc2d04ce005961
Content-Type: text/plain; charset=ISO-8859-1

You might consider building the graph in advance and use
it for planning purposes.

Bruce B.

On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
<chris.mattmann@gmail.com>wrote:

> Hey Brian,
>
> That sounds Perfect! I like the idea of simply creating a RunnableInstance
> and think it fits the architecture well!
> +50 to proceed down that path.
>
> Cheers,
> Chris
>
> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>
> >
> > hey chris,
> >
> > I think i work this out... i'm gonna create a RunnableInstance class...
> this will then hold the state, start/end times, type (TASK or CONDITION),
> and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
> >
> > -brian
> >
> > On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >
> >> hey chris,
> >>
> >> so i'm going through this WorkflowProcessor stuff and finishing it
> up... I'm trying to make it so that WorkflowProcessor is used by all
> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
> Workflow, and then a WorkflowProcessor is response for analyzing that
> WorkflowInstance and determining what to run next in the Workflow... in
> this process i've notices that we really don't have any
> "WorkflowInstance-like" class for Tasks and Conditions... A
> WorkflowTaskInstance is actually the runnable task/condition job... I know
> this would be a big structural change, but i think WorkflowTaskInstance and
> WorkflowConditionInstance should be similar to WorkflowInstance (it should
> hold the state, times, etc... for a task/condition)... then possibly
> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> interface, or something like that, which CAS-PGE and all other runnable
> tasks would implement instead... then i've already created a version of
> WorkflowInstance which would hold the WorkflowTaskInstances and
> WorkflowConditionInstance for it's task, preConds, and postConds... this
> way when one loads a WorkflowInstance they would have access to all the
> state, times, etc.. of everything in that workflow... this makes is very
> easy to create a WorkflowProcessor which then is stateless and when given a
> WorkflowInstance can easy determine what is the next thing to run or what
> state the workflow is in... this new design i working toward also ditches
> the whole WorkflowProcessorListener interface stuff, which i never liked in
> the first place, but just never came up with something better.
> >>
> >> -brian
> >
>
>

--e89a8fb2066ee2fc2d04ce005961--