Even Microsoft People Use jBPM

As Hannibal would say: "I love it when a plan comes together". With jBPM being a platform for process languages, we never really fitted into the general accepted approach to Model Driven Architecture (MDA). While we do share many of the same goals like creating a better communication between business people and developers. We always believed that generating code from models was not the challenge. Instead,we always saw integrating the different languages in IDE tooling plugins as the real challenge. Now it seems that strategy is starting to pay off.

Ferran Rodenas gives a very good description of Visual studio and Domain Specific Language (DSL) tools. He's one of the few that can mix and match Microsoft with Java and other technologies. What's nice to see is that he opted for a modified version of our graphical jPDL eclipse designer in favor of a "solution based on DSL tools".

I think this really hits a potential problem with the current generation of Language Workbenches. They focus on building tools on top of a grammar. But more important and more difficult is the integration between all the different Domain Specific Languages (DSL) and general purpose programming languages. For example, think of a jPDL workflow process that refers to your class as a command. Then it would be really helpful if the class renaming refactoring propagated to the process. I'm not sure for all of them, but languages workbenches seem to be focussed more on building new languages and less on integrating the editors that result from that work.

For now, that is why we anticipate that the choice of the actually IDE technology platform (like eclipse) will be much more relevant then the choice of a language workbench. And that's why we keep on focussing to make the jBPM designer reusable and tweakable for all these kind of use cases.

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:

ProcessDefinition processDefinition = new ProcessFactory()
 .initial().behaviour(new WaitState())
   .transition().to("a")
 .node("a").behaviour(new SomeAutomaticActivity())
   .transition().to("b")
 .node("b").behaviour(new SomeHumanTask())
   .transition().to("c")
 .node("c").behaviour(new WaitState())
 .processDefinition();

Execution execution = processDefinition.startExecution();

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:

public interface Binding {
 Object parse(Element element, Parse parse, Parser parser);
}

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 !

Unifying Processes And Rules

In "A Vision for Unified Rules and Processes", Mark Proctor, lead of the Drools rules engine describes how he sees the further integration between rules and processes.

I believe that any company that isn't able to truly unify rules and processes into a single modelling system, how PegaSystems have done, will not be in a suitable position for the future. ... rules and processes must exist as first class citizens within the modelling and execution environment ... we need to make sure that we unify these models and allow it to go to much greater depths. Once rules and processes are fully integrated that modelling environment will benefit from any other declarative systems added, such as our plans to add Complex Event Processing (CEP) to the engine and language - this means we can have rules monitoring streams of data and triggering process milestones.

From a product point of view, I totally agree with Mark. In fact, I met him last week and I was impressed with the productization ideas they had for creating in integrated processes and rules environment.

For instance the Business Rules Management System (BRMS) manages the full lifecycle of rules from sources, over packaging to runtime deployment. The model and tooling that they have layed out would fit perfectly with jPDL processes. Futhermore, it supports both the developer use cases as well as the business user use cases. The drools vision in that respect is fully applicable to jPDL processes.

Similar for the business user test scenarios. Drools has a web UI for creating test scenarios on a business level. While this will not replace software testing based on something like JUnit, it does allow for business users to express basic scenarios. For non complex processes, this vision is also applicable to jPDL processes.

So if you look at it from a product point of view, we agree. The way I see this unification is a drools-jPDL integration is a single download that just can be unzipped to be installed. Integrated BRMS, console and designer. Drools has this approach and jPDL has the same appraoch with the suite distribution package.

But I see the componentization underneath the product quite differently. First of all I think that ruleflow should be merged with jPDL. They fit together and complement each other perfectly. I don't think that ruleflow should be a separate language from jPDL. Ruleflow could be build as a set of nodes build on top of the PVM. These nodes could be added to jPDL. Whenever you use them, you get a dependency on the drools.jar. This is just like with e.g. the beanshell based script node that we have now in jPDL.

Secondly, I don't think we need to integrate jar packages. IMO, "truly unify rules and processes" as Mark Proctor refers to, should be in the productized package that integrates jPDL (incl ruleflow) and drools. There is no need for the jars to merge in order to realize the vision as Mark Proctor describes it.