[chain] Chain as a mini-workflow engine?

[Jeff Caddel <jc...@cox.net>]

It's striking me that my chain-config.xml files are looking somewhat 
similar to the example workflow xml file over in the sandbox/workflow area.

In addition ComposableRequestProcessor by it's very name has a 
workflow-ish ring to it.

A "ComposableBusinessLogicInvoker" seems like it would fit the bill for 
me very nicely, and would be rapidly closing in on the stated goals for 
the functionality of the sandbox/workflow component.


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: [chain] Chain as a mini-workflow engine?

[mr...@twdata.org]

I thought about that too, but in the end, I think the chain is a little to
inflexible for application workflow.  Most workflows that I deal with are
more than a simple linear execution of actions and while you can get the
chain to branch by manipulating key values in the context, it is kinda
awkward and error prone.

The solution, I feel, is more along the lines of what Alex is putting
forth in his WARS architecture
(http://www.theserverside.com/news/thread.jsp?thread_id=23625),
specifically a clean separation between workflow and actions.  He sees
workflow being able to be implemented multiple ways although his primary
implemention is through a JSR-94-compatible engine.  Personally, I think
the ideal workflow implementation would use Cocoon's flowscript which
takes JavaScript and continuations support and uses them to smoothly
script a complex web transaction possibily involving multiple pages.

Don

> It's striking me that my chain-config.xml files are looking somewhat
> similar to the example workflow xml file over in the sandbox/workflow
> area.
>
> In addition ComposableRequestProcessor by it's very name has a
> workflow-ish ring to it.
>
> A "ComposableBusinessLogicInvoker" seems like it would fit the bill for
> me very nicely, and would be rapidly closing in on the stated goals for
> the functionality of the sandbox/workflow component.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>


> It's striking me that my chain-config.xml files are looking somewhat
> similar to the example workflow xml file over in the sandbox/workflow
> area.
>
> In addition ComposableRequestProcessor by it's very name has a
> workflow-ish ring to it.
>
> A "ComposableBusinessLogicInvoker" seems like it would fit the bill for
> me very nicely, and would be rapidly closing in on the stated goals for
> the functionality of the sandbox/workflow component.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: [chain] Chain as a mini-workflow engine?

["Craig R. McClanahan" <cr...@apache.org>]

Quoting Jeff Caddel <jc...@cox.net>:

> It's striking me that my chain-config.xml files are looking somewhat 
> similar to the example workflow xml file over in the sandbox/workflow area.
> 

There are indeed some overlaps in concept ... after all, I didn't forget
everything I learned from creating [workflow] in jakarta-commons-sandbox before
starting on [chain].

> In addition ComposableRequestProcessor by it's very name has a 
> workflow-ish ring to it.
> 
> A "ComposableBusinessLogicInvoker" seems like it would fit the bill for 
> me very nicely, and would be rapidly closing in on the stated goals for 
> the functionality of the sandbox/workflow component.
> 

The most important feature that [workflow] includes, but is not present in
[chain], is the idea that is formally known as a "continuation" -- you can
describe a single flow of commands that (if you're building a webapp) requires
more than one HTTP interaction with the client.  Without that, [chain] is still
useful to do AOP-ish sorts of things for a single request, but it doesn't
really solve all of the important problems I would consider relevant to a
package named "workflow".

In an ideal world, I'd like to see a single package that incorporated the
concepts of both [chain] and [workflow], but also leveraging the recent
advances in expression languages (employed in JSP 2.0, JSTL, jelly, jexl, et.
al.) instead of trying to invent control flow syntax in XMl like [workflow]
currently does.  I *hope* to have time to work on this sort of thing, now that
JavaServer Faces 1.0 is approaching release.

Craig McClanahan


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org