Thursday, 22 November 2007

Workflow In Java *Is* Sexy !

Ever since Marc Fleury started to wiggle with the foundations of the software industry, most people know that open source software doesn't just fall out of the sky. A good idea is not enough. It takes passionate people who believe they can make a difference. A project may start out as a hobby, but combining a day time job with after hours hobby rarely is sustainable for a longer period of time. That is in summary the idea behind Professional Open Source.

With the JBoss jBPM project, we are now having a kind of a luxury problem: The rate at which we can hire people from our community is greater then the number of contributors that join the project. Last night I talked about it to Stephan Janssen, the BeJUG chairman. Stephan suggested that maybe workflow is not sexy compared to hot technologies like Rich Internet Application (RIA) technologies and scripting languages.

That reminded me that BPM and orchestration still have a bad reputation in the developer community. Looking at all the other workflow technologies out there, I can't really argue with that perception. But in case of JBoss jBPM, it should be fairly easy to to show that our project is steaming hot and sexy! Especially when looking forward to what is coming in the next major version.

I'll start with the nittypittylittlelightest form of workflow ever and then build up to pure play BPM product features. In essence, the core of JBoss jBPM is a simple Java library to define and execute state machines. That is called the Process Virtual Machine. This already enables the simplest form of workflow in plain Java like this:

What is really cool and sexy about our new PVM is that we have extracted the programming model for the nodes in a workflow in a NodeBehaviour interface. The NodeBehaviour interface looks something like this

public interface NodeBehaviour {

/** called when an execution arrives in a node. */void execute(ExecutionController execution);

/** called when an execution, positioned in this node * receives an external trigger. */void signal(ExecutionController execution, String signal);}

With this API it becomes childsplay to implement any kind of state machine behaviour for your specific use case. Furthermore, you'll be able to create custom extensions to process languages like jPDL, BPEL or XPDL this way.

At the next level, XML parsing is added. I admit, this is the least sexy of all, but the point I'll make is that the XML parsing is also pluggable for each node. That is still a little bit sexy, no ? Each process language needs it's own parser. The parsers we build for the process languages are based on JAXP so there are no extra library dependencies introduced outside of the Java 5 JVM. Each process language will have it's parser that walks the main structure of the process XML document. Then to parse the nodes, a Binding interface is used like this:

A node type now is made up of the runtime behaviour and the binding parser.

(btw, I hope that the language workbenches become mature soon on the Java platform. Instead of XML, I would much rather use a custom syntax language that has the look and feel of the Java programming language. But currently, that turns out to be harder for the graphical designer and the node pluggability)

Next is persistence. The sexy thing about our persistence is that in the PVM we'll support all forms of process persistence. As you saw above, processes can be created and executed without any relation to persistence.

Alternatively, you can read the process from an XML resource and save the state in your domain model object like for example an Order. A hibernate custom type that we supply takes care of converting the Execution field value into a state string, corresponding to the current node name. This is limited to a single path of execution, but it avoids the complete workflow database. The state is actually saved into your own domain model.

In case you do want the full workflow database to store the processes and executions, then we can easily link between your domain model objects (like e.g. an Order, Account or Customer) persisted with Hibernate and the process Execution.

For the process languages we support out of the box, we'll have hibernate mappings that store the process definitions and executions. But another sexy thing about the new PVM persistence is that you'll be able to add a new node with parser and complex configuration properties and keep the database schema stable.

Do you see it coming ? We're working towards easy customization of process languages. Development teams will rarely build a complete process language from scratch. But with the new PVM, they'll be able to take for example jPDL and extend it with their own custom node types very easily, without any deployment hassle.

Supporting this whole range of persistence options is IMO the most sexy of all! This is the main reason why BPM, workflow, orchestration and pageflow now all have different runtime engines. So with the new PVM, we'll be able to support the full deployment axis. This includes the different forms of persistence in both standard java and enterprise java. Apart from the deployment axis, there is the process language axis. So that gives some background into why this multitude of languages and runtime engines exist and how we're going to consolidate that.

Then on top of the XML and persistence, we're building out the usual BPM tooling like designers, web & administration consoles, business activity monitoring and so on. Since those tools are typically the only interface offered to developers, I can understand the bad reputation that BPM still has with developers. I hope that this post showed you that workflow can be sexy also for Java developers.

I can understand that in 5 years from now, workflow systems will be as boring as database systems. But in the meantime, building out the concepts and techniques behind those indispensable systems is ultimately sexy for clever developers.

So if you're looking for a sexy project to contribute to, look no further. JBoss jBPM is it !

8 comments:

Hi, Yes, Years, Workflow, but why workflow cannot be hot and sexy?IMH, Tek and UI is the keys.For jbpm, who oriented? IMH, programmer or developer, but who use the products or final products? End users.Okay, what about UI? user and developer UI? same or difference?IMH, The same, so serviceR can talk about a process of workflow with his customer without trouble and barrier.osworkflow just for programmer, jbpm, I not truely try it, so I cannot say more about it.And I not get all means of this article of yours, Yes, I would read it again later.Maybe when that, We can talk more.

Working for more than a year on an Orchestration system using jBPM under the hood, and fighting over and over with the difficulties of customization, it sounds like we should have waited more than a year for the PVM to be ready.Is this PVM you`re talking about a forthcoming reality, or it`s is something not to be seen in a near future?Is there a way to see work in progress?

PVM is being developed in our svn at https://svn.jboss.org/repos/jbpm/tempranillo/pvm/trunk

It's being developed in collaboration with the Bull teams so the next versions of Bonita and Orchestra will be based on that PVM as well.

Please let us know what kind of difficulties in customization you had with jBPM. So that we can do our best to make it easier in the new version based on the PVM.

My current estimation is that before the summer, the jPDL product based on PVM will have a similar feature set as the current. Starting from early next year, I hope to start releasing alphas and betas with parts of the functionality.

I have worked with BPEL extension for over a year as well and have customized JBPM to fit our needs. But most of them are related to orchestrations and nothing in the base engine with couple of small exceptions. On BPEL side however, I have added support for dynamic url, soap headers, http headers to name a few that are required by real world web services. Will BPEL extension get ported to PVM as well?

About Me

I'm founder and CEO of Effektif and on a quest to simplify process management and collaboration on the cloud. Before Effektif, I founded the open source BPM engines jBPM and Activiti. In this blog I share my thoughts on processes, collaboration and how those match on the cloud.