||Wednesday, May 24, 2006
Distributed systems, highly concurrent software and SEDA
is increasingly becoming the norm. Frequently we need to orchestrate
across multiple asynchronous events/processes and the code can get very
complex very quickly.
The traditional approach up to now is to ditch your programming
language and use a declarative XML language like BPEL to create an
orchestration then use some graphical tooling to create your process.
While that is a totally fine approach; I've hit lots of use cases for
orchestration where there were no web services; it was just POJOs and
events were asynchronous and some form of messaging was used like JMS
or Spring Remoting etc. Or others have hit their heads on the
restrictions that BPEL offers and wanted to add Java inside the BPEL.
e.g. implementing master/slave protocols inside ActiveMQ
is a pure orchestration problem and BPEL just doesn't seem a good fit
since we really just want a pure Java solution; the XML / XPath / WSDL
/ BPEL just adds lots of leaky abstractions we don't really need never
mind the performance hit.
Now I"m not advocating here that we throw BPEL away - its a very useful
way of expressing web service orchestration. Just that there could be
other ways of solving this kind of problem when the world is not just a
sea of web services.
So after a day of brainstorming with Hiram a new small Java library came along - may I introduce you to BeanFlow.
Its a tiny library, just a few classes and only depends on
commons-logging and Java 5. (Yeah we should maybe switch to the JDK's
logging abstraction but it seems like noone uses it)
Basically we started off thinking of the problem in a traditional jbpm, openwfe, OSWorkflow kinda way. Then we kept thinking "Lets make it simpler";
we can use Java code to do boolean logic, handle state, do looping,
call functions, create objects, aggregation and composition. So what is
it about orchestration that doesn't fit with regular Java code?
In the end we boiled it down to just one single concept, joins. Everything else a Java programmer is capable of doing in their sleep.
So we basically started out tackling the join problem; how do you fork
off multiple asynchronous tasks then join on some condition. It turned
out to be really simple to do in regular Java code.
Rather than repeat myself I'd urge you to surf the documentation or the javadoc.
The interesting thing is from this humble base; tackling the join
problem, we ended up writing a traditional Workflow model in 1 class
along with added a number of orchestration features to Tiger's
concurrent packages (java.util.concurrent).
The interesting thing is its up to the implementer of an Activity or
Workflow to decide how to do state management and remoting. e.g.
implement a workflow as a single Entity Bean using JPA to deal with
persistence & caching & transactions. Maybe its a transient
workflow. Or its an itinerary based workflow, where the workflow state
is sent in a message to a remote node which then instantiates the
workflow and executes its next step before progressing to the next node
Its a really simple idea; I kinda can't help think why doesn't everyone
do this. It reminds me a little bit of the dependency injection wave a
few years ago with Pico and Spring; folks often thought, whats the big
deal its just a constructor :). So BeanFlow is so simple, its really no
big deal. But I can't help think that we might start to see more folks
using plain old Java code rather than XML to write more orchestration
logic. BeanFlow rocks! :)
BTW thanks to folks who've given us great feedback on BeanFlow so far -
Rob, Sam, Hani, Gregor, Glen & Euxx. Sam's idea was particularly clever;
use enums for the workflow step value then on startup you can verify
that there is a suitable Java method for each step - such as to catch
this bad workflow with a useful error message early.
Update Great feedback from Euxx on how we could add annotations to the enum of a workflow to further validate allowable transitions. Great idea!
Thanks to Gregor for these great pictures.
For me JavaOne isn't about the sessions or the big announcements; its
hanging out with folks at the Thirsty Bear and the
Tangosol/Solarmetric/BEA/InfoQ party along with the other drinking
© Copyright 2007 James Strachan.