Wednesday, May 24, 2006

POJO based Orchestration; an introduction to BeanFlow 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 etc. 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! 9:58:37 AM    comment []

Great pictures of the real JavaOne 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 sessions. 8:38:26 AM    comment []