You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by James Strachan <ja...@gmail.com> on 2006/05/14 04:31:20 UTC
[Heads up] ServiceMix BeanFlow library available
For some time I've wanted a really simple way to use Java code to
handle asynchronous flows of events cleanly without resorting to using
XML with things like BPEL; particularly for implementing protocols
like master/slave or electing a leader and so forth. BPEL is great at
orchestrating web services; sometimes you've just got a few simple
POJOs to orchestrate (such as running tasks etc)
We've now got a simple little Java library called BeanFlow; I've made
a stab at documenting it...
http://servicemix.org/site/beanflow.html
its not intended to compete with BPEL; its more for when developers
are happy to let regular Java code to do most of the work and just
need some of the workflow concepts like fork, join, suspend and so
forth into the Java programming language itself.
I've been quiet surprised by (i) how small it is and (ii) how simple
and reusable it is. It currently integrates quite nicely with Java 5
features like Executor, Runnable and Callable/Future as well as having
a more traditional workflow-like model.
As usual, feedback is most welcome.
--
James
-------
http://radio.weblogs.com/0112098/
Re: [Heads up] ServiceMix BeanFlow library available
Posted by Jamie McCrindle <ja...@gmail.com>.
On the subject of general purpose workflow, the eclipse guys seem to
be up to something interesting over here:
http://www.eclipse.org/proposals/jwt/ as they seem to be trying to
abstract the process definition language from the workflow engine.
hopefully for BpmScript or BeanFlow, it won't be too stuck on XML :)
cheers,
j.
On 5/22/06, James Strachan <ja...@gmail.com> wrote:
> On 5/18/06, Jamie McCrindle <ja...@gmail.com> wrote:
> > hiya,
> >
> > (james, correct me where i'm wrong)
> >
> > i haven't had a chance to play with BeanFlow but it looks pretty neat.
> > here are some more fundamental differences between the two:
> >
> > - Java (BeanFlow) vs. Javascript (BpmScript)
> > - Workflow classes (BeanFlow) vs. Continuations (BpmScript)
>
> Agreed. The motivation of BeanFlow was really to act as a simple
> Java-centric alternative to BPEL for orchestrating of asynchronous
> events. BpmScript is cool too though.
>
>
> > The rest of the things that BpmScript has at the moment (e.g. process
> > versioning, jms and hibernate persistence implementations, management
> > console, worklist support, etc.) could be built on top of BeanFlow.
> >
> > for what it's worth, my opinion would be: Java is better to program in
> > than Javascript. Continuations are a more natural way to write
> > programs compared to Workflow classes.
> >
> > What this does highlight, though, is that it would be awesome to have
> > a general purpose set of interfaces for managing workflow processes,
> > so you could choose between BeanFlow, BPEL, BpmScript etc. but some of
> > the higher level management remains the same e.g. starting, stopping,
> > deploying and monitoring of processes and process instances.
>
> Agreed!
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [Heads up] ServiceMix BeanFlow library available
Posted by James Strachan <ja...@gmail.com>.
On 5/18/06, Jamie McCrindle <ja...@gmail.com> wrote:
> hiya,
>
> (james, correct me where i'm wrong)
>
> i haven't had a chance to play with BeanFlow but it looks pretty neat.
> here are some more fundamental differences between the two:
>
> - Java (BeanFlow) vs. Javascript (BpmScript)
> - Workflow classes (BeanFlow) vs. Continuations (BpmScript)
Agreed. The motivation of BeanFlow was really to act as a simple
Java-centric alternative to BPEL for orchestrating of asynchronous
events. BpmScript is cool too though.
> The rest of the things that BpmScript has at the moment (e.g. process
> versioning, jms and hibernate persistence implementations, management
> console, worklist support, etc.) could be built on top of BeanFlow.
>
> for what it's worth, my opinion would be: Java is better to program in
> than Javascript. Continuations are a more natural way to write
> programs compared to Workflow classes.
>
> What this does highlight, though, is that it would be awesome to have
> a general purpose set of interfaces for managing workflow processes,
> so you could choose between BeanFlow, BPEL, BpmScript etc. but some of
> the higher level management remains the same e.g. starting, stopping,
> deploying and monitoring of processes and process instances.
Agreed!
--
James
-------
http://radio.weblogs.com/0112098/
Re: [Heads up] ServiceMix BeanFlow library available
Posted by Jamie McCrindle <ja...@gmail.com>.
hiya,
(james, correct me where i'm wrong)
i haven't had a chance to play with BeanFlow but it looks pretty neat.
here are some more fundamental differences between the two:
- Java (BeanFlow) vs. Javascript (BpmScript)
- Workflow classes (BeanFlow) vs. Continuations (BpmScript)
The rest of the things that BpmScript has at the moment (e.g. process
versioning, jms and hibernate persistence implementations, management
console, worklist support, etc.) could be built on top of BeanFlow.
for what it's worth, my opinion would be: Java is better to program in
than Javascript. Continuations are a more natural way to write
programs compared to Workflow classes.
What this does highlight, though, is that it would be awesome to have
a general purpose set of interfaces for managing workflow processes,
so you could choose between BeanFlow, BPEL, BpmScript etc. but some of
the higher level management remains the same e.g. starting, stopping,
deploying and monitoring of processes and process instances.
cheers,
jamie.
On 5/17/06, bgoetzmann <bg...@sophia.symag.com> wrote:
>
> Thank you James.
> How BeanFlow compares to BpmScript (except for the language used) ?
> --
> View this message in context: http://www.nabble.com/-Heads-up-ServiceMix-BeanFlow-library-available-t1614778.html#a4427008
> Sent from the ServiceMix - User forum at Nabble.com.
>
>
Re: [Heads up] ServiceMix BeanFlow library available
Posted by bgoetzmann <bg...@sophia.symag.com>.
Thank you James.
How BeanFlow compares to BpmScript (except for the language used) ?
--
View this message in context: http://www.nabble.com/-Heads-up-ServiceMix-BeanFlow-library-available-t1614778.html#a4427008
Sent from the ServiceMix - User forum at Nabble.com.
Re: [Heads up] ServiceMix BeanFlow library available
Posted by James Strachan <ja...@gmail.com>.
On 5/24/06, Holger Hoffstaette <ho...@wizards.de> wrote:
>
> Hi James,
>
> I also looked at BeanFlow and like the basic idea very much, except for
> the String constants; I guess that's the price of simplicity.
FWIW thats recently been changed to use enums - which we now
auto-check that match against valid method names in your class.
There's been good feedback lately on improving this further; Eugene
commented on annotating the enumerations to declare the transitions
declaratively...
http://jroller.com/page/eu?entry=coding_workflow_in_java_with
and I've just got an email from Brian Goetz I'm digesting where he
uses the enums to avoid reflection...
> My first idea was, however, to use this for multithreaded test case
> construction! :) These are always a total bear as you probably know.
Totally! Actually doing distributed integration tests (in multiple
threads or JVMs with remoting) is a real big use case for me - its
been a constant itch.
BTW have you seen the unit test case helpers...
http://incubator.apache.org/servicemix/maven/servicemix-beanflow/apidocs/org/apache/servicemix/beanflow/util/package-summary.html
You can create a concurrent test case with sync() methods quite easily now...
https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-beanflow/src/test/java/org/apache/servicemix/beanflow/util/ParallelBeanWithSyncs.java
> Unfortunately it turns out that only very coarse-grained scenarios could
> be modeled; for some things I'd need much better control over the timers:
> exact-start, better scheduling precision, better exception
> handling/collecting/correlation via the thread group etc.
> Maybe you have more ideas in that direction?
Agreed. Note that it should be possible to write any kind of precise
timer based Activity; the first class we've written, TimedActivity is
pretty simple :). We've only just got the basics of BeanFlow going -
I'm sure we can add everything you need pretty easily.
One of the core features of BeanFlow is to be able to use regular
object orientation design strategies (composition, aggregation,
inheritence etc) to be able to build up very complex workflows from
simple components. So I'm sure we can extend out to tackle the most
challenging of orchestrations.
> I have an (arguably
> untypical) test case that really cooks my noodle any time I look at it
LOL! :)
> and
> if BeanFlow could be used to correctly model & execute that it could
> become an awesome basis for MT test modeling and execution. Drop me a line
> if you're interested.
I'm definitely interested! Ultimately I'd like to use BeanFlow to
create concurrent/distributed integration/system test cases which are
pretty complex so I think we're on the same page.
--
James
-------
http://radio.weblogs.com/0112098/
Re: [Heads up] ServiceMix BeanFlow library available
Posted by Holger Hoffstaette <ho...@wizards.de>.
Hi James,
I also looked at BeanFlow and like the basic idea very much, except for
the String constants; I guess that's the price of simplicity.
My first idea was, however, to use this for multithreaded test case
construction! :) These are always a total bear as you probably know.
Unfortunately it turns out that only very coarse-grained scenarios could
be modeled; for some things I'd need much better control over the timers:
exact-start, better scheduling precision, better exception
handling/collecting/correlation via the thread group etc.
Maybe you have more ideas in that direction? I have an (arguably
untypical) test case that really cooks my noodle any time I look at it and
if BeanFlow could be used to correctly model & execute that it could
become an awesome basis for MT test modeling and execution. Drop me a line
if you're interested.
Holger
Re: [Heads up] ServiceMix BeanFlow library available
Posted by James Strachan <ja...@gmail.com>.
BTW I've finally completed the documentation...
http://incubator.apache.org/servicemix/beanflow.html
and ended up blogging about it today...
http://radio.weblogs.com/0112098/2006/05/24.html#a563
It'd be good to create an example using JPA along with an itinerary
based workflow example (where the workflow state travels to each node
etc).
On 5/14/06, James Strachan <ja...@gmail.com> wrote:
> For some time I've wanted a really simple way to use Java code to
> handle asynchronous flows of events cleanly without resorting to using
> XML with things like BPEL; particularly for implementing protocols
> like master/slave or electing a leader and so forth. BPEL is great at
> orchestrating web services; sometimes you've just got a few simple
> POJOs to orchestrate (such as running tasks etc)
>
> We've now got a simple little Java library called BeanFlow; I've made
> a stab at documenting it...
> http://servicemix.org/site/beanflow.html
>
> its not intended to compete with BPEL; its more for when developers
> are happy to let regular Java code to do most of the work and just
> need some of the workflow concepts like fork, join, suspend and so
> forth into the Java programming language itself.
>
> I've been quiet surprised by (i) how small it is and (ii) how simple
> and reusable it is. It currently integrates quite nicely with Java 5
> features like Executor, Runnable and Callable/Future as well as having
> a more traditional workflow-like model.
>
> As usual, feedback is most welcome.
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
James
-------
http://radio.weblogs.com/0112098/