oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Foster <holeno...@me.com>
Subject Re: Workflow Task/Condition Instances...
Date Thu, 08 Nov 2012 02:42:49 GMT
hey chris,

i got the initial changes to Workflow, WorkflowInstance, and WorkflowProcessor in... https://reviews.apache.org/r/7944/
... let me know what you think... lol


On Nov 7, 2012, at 6: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
>> -brian

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