BPM and workflow comes in many shapes and forms. jBPM 4 is a major step towards providing a single BPM solution that can be used for these different forms of BPM and workflow, in different Java environments. It can be used as a standalone server or embedded into any Java application. jBPM 4.0.0.Alpha1 is the first release of jBPM 4 and it leverages the new Process Virtual Machine which supports multiple process languages. The most notible improvements in jBPM 4 are: * Much improved docs, including a split between user guide and developers guide * BPMN based graphical designer in eclipse * Command based services as the primary client API * Decoupled activity implementation API * Multiple execution modes * Improved multiple language support * Easy addition of custom activities * DB evolution improvements * DB partitioning per process language Download Documentation Forum Enjoy and let us know what you think of it. -- regards, Tom Baeyens Founder and lead of JBoss jBPM

The improved user guide - by itself - is a great reason to check out this new release of jBPM. It's a great intro for any interested in separating the hype of BPM from what programmers need to know.

I like the Java process definitions. They look like Camel's route definitions and the combination of jBPM workflow with Camel EIP looks promising. A Camel route could be a jBPM ExternalActivity. I'd like to have the ability to transform BPMN diagrams to Java process definitions and round tripping would be really sweet. This would support a division of labor of initial modeling by analysts and implementation by developers. CompositeNode looks like a nice analyst level abstraction developers can fill in with Activity nodes.

I'd like to have the ability to transform BPMN diagrams to Java process definitions and round tripping would be really sweet.

In the BPM world, there are a lot of candidates for round tripping and mappings of all sorts. But think of this in the same way as you would think of round tripping between Java code and C++ code. In theory it should be possible. But in practice it is not really achievable. Certainly not in a way that is comfortable for both types of users. With jBPM we took a different path: We don't focus on mappings, import nor export. Our strategy is 1) to build the right executable language for the job. 2) to make sure that developers find it easy to use the executable process langauge (embeddability) 3) that business people can collaborate with developers around a common diagram: the diagram of the executable process So the PVM component is the bare bones process execution technology on top of which multiple process languages can be build. Very diverse languages (jPDL, BPEL, XPDL, Pageflow,...) have been build on the PVM. regards, Tom Baeyens Founder and lead of JBoss jBPM

Is the model nothing but an artifact? I've been a bpm consultant and analysts do not want to work with me all the way to an executable model. They want to work with me as far as their differing abilities will take them and then they want to hand it off. As a developer, I want to start from where we left off and I want to define the process in Java, not XML. So, to define the process in Java, do I have to hand code everything?

Congratulations on the release! Looks very interesting, and I can't wait to try it out.

i want to know the roadmap.

I will try it and use it in my new project.