oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Barkstrom <brbarkst...@gmail.com>
Subject Re: Workflow Task/Condition Instances...
Date Thu, 08 Nov 2012 18:53:30 GMT
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

> 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message