[
https://issues.apache.org/jira/browse/OODT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Foster updated OODT-491:
------------------------------
Attachment: NewWorkflowModel.patch.txt
okay chris so i've taken a look over the current wengine port to trunk code
state… and hear me all the way out on this, i think by the time you make it to
the end of this comment you will agree with me (i hope… lol)… i think the
wengine port stuff in trunk is still missing a lot of stuff to make it work… i
also think the WorkflowProcessor part of the port is making the trunk messy
(i.e. for one ParentChildWorkflow is causing unwanted instanceof checking which
also makes for confusing code)… kinda showing now why i decided to write
WEngine as a separate component… i think a lot of good changes have come out of
the attempt of this wengine port: separation of Runner, allowing for the
workflow engine to not get held up by stalled workflows, CAS-CLI was ironed out
and refactored into it's own component based on it's original use in winging
there are several others… so here is what i am proposing:
I think for now let's use the WEngine WorkflowProcessor stuff to add design
improvements to the current Workflow model to incorporate the features which
WEngine WorkflowProcessor provided but with a deferent model approach… I have
attached a patch which modifies the struct class Workflow to allow for this
integration and also introduces the idea (which Chris and i talked about a long
time ago) of chaining workflows… this is basically how I see it working: We
will introduce the idea of a WorkflowLink, which will be a wrapper around a
Workflow which will attach Events to a Workflow (a wait for Event, a trigger on
success Event, and a trigger on failure Event)… currently all the trunk
workflows will translate easily to this model as just a workflow chain with 1
WorkflowLink (with a wait for Event)… this bring me to the next point, these
WorkflowLinks will be added to a WorkflowChain which will handle figuring out
which WorkflowLinks should be run next given a fired Event. This will keep the
trunk workflow completely Event driven like it has always been and will not
require WorkflowProcessor based changes to poke holes in the client and server
XML-RPC classes which are currently missing to make the WorkflowProcessor stuff
work… i believe we should be able to rewrite the XML parser for the WEngine
workflow configuration to build the model i've created in the patch attach if
current when users what to port there stuff to this new model… anyway, let me
know what you think
> Finish line tasks for Wengine integration
> -----------------------------------------
>
> Key: OODT-491
> URL: https://issues.apache.org/jira/browse/OODT-491
> Project: OODT
> Issue Type: Umbrella
> Components: workflow manager
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Fix For: 0.5
>
> Attachments: NewWorkflowModel.patch.txt
>
>
> The final tasks to wrap up wengine integration into trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
