On 8/24/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Just on a side note, will try to take a depper look at this mail later.
While I think the beanflow concept is cool and very usefull, I think there
are some design problems.
I have tried to fix http://issues.apache.org/activemq/browse/SM-439
without luck. If you could have a look ;)
Will do :)
I think the main problem in beanflow is that the workflow is controlled
from the inside and not managed controlled by an engine.
Agreed. In my mail I was kinda just thinking of using one or two
interfaces from BeanFlow (just the Activity interface really) and then
allowing an engine to do all the work rather than writing BeanFlow
workflows.
This would also enable using persistence so that flows could
be used transactionally. For example, if you want to include
the whole flow inside a transaction, you can obiously not spawn
a thread and perform a join later. The different steps in the flow
have to be performed sequentially.
Agreed!
The flow could be described using annotations (so quite static)
or maybe dynamically using an injected interface which would
allow to fork / join tasks, while keeping these tasks under
the control of the engine.
Btw, I love the @Join("a and b") annotation.
I have previsouly thought to a less powerfull
@Join(steps = { "a", "b" }),
but you could not have some magical expressions, like
@Join("a + b + c >= 2")
which should be the same as
@Join("quorum(a, b, c)")
:)
Nice! :)
I guess we could have a kinda SQL 92 type join language (like JMS
selectors) which allows a few functions like quorum and so forth.
--
James
-------
http://radio.weblogs.com/0112098/
