News: First preview of jBpm 2.0 available
jBpm is a unique workflow management system (WFMS). jBpm combines a powerfull process definition language with an easy-to-use plain java API. jBpm takes as input formal descriptions of business processes: process archives. Then jBpm manages the executions of these processes.
- Posted by: Tom Baeyens
- Posted on: May 10 2004 08:30 EDT
jBpm is unique in 2 aspects:
1) its process definition language. Its simple and powerfull.
2) the delegation mechanism : jBpm is designed with a minimalistic approach. jBpm has defined a set of interfaces that serve as extension points. This mechanism
is used to couple java-code to process executions, customize runtime behaviour of processes, select actors for tasks and others.
This second version includes major enhancements in the following areas
* minimalistic approach. do only one thing, but do it good.
* deployment in and outside of an ejb-container in a plain J2SE environment
* testability (75% test coverage)
* build scripts
Project : http://jbpm.org
Documentation : http://jbpm.org/2/
Download : at sourceforge
Demo : http://jbpm.org/demo.html
Challenge to the readers: Do you think workflow or business process management is applicable to your project?
- Challenge to the readers by Holger Engels on May 10 2004 12:29 EDT
- First preview of jBpm 2.0 available by Benjamin Mestrallet on May 10 2004 15:09 EDT
- First preview of jBpm 2.0 available: Why not BPML for process de by Richard Berger on May 10 2004 19:58 EDT
- Why not BPML for process definition? by Konstantin Ignatyev on May 11 2004 10:40 EDT
- First preview of jBpm 2.0 available: Why not BPML for process de by Tom Baeyens on May 11 2004 16:37 EDT
- Enterprise ready? by Pavel Tavoda on May 11 2004 03:58 EDT
- Is it a complete BPM tool? by Marco Campelo on May 12 2004 20:34 EDT
Do you think, a procedural process definition language is apropriate for complex business scenarios? I'd prefer a situation-oriented language. Objects for business data. Situations for business flow.
The process definition language of jBpm can best be described as an enhanced type of state diagrams. Extensions to the state diagram language are necessary to include concurrency, state-assignment and integration of programming logic.
Btw : A good process definition language helps to tacle the complexity of business scenarios.
That's exactly my question. Do you think statemachines are powerful enough to model complex business scenarios? I doubt that. Actually I tried it and I failed.
My experience was, that statemachines tend to get too complex. I'd prefer a language with higher level constructs like situations / cases and the possibility to derive a special case from the normal case.
Do you think statemachines are powerful enough to model complex business scenarios? I doubt that. Actually I tried it and I failed. My experience was, that statemachines tend to get too complex.I've had plenty of success with state machines in industry. The complexity problem you describe occurs when a developer fails to normalize his data model. Simple state models tend to emerge when objects are fine grained, with only a few fields to manage. When you reduce the amount of informational state a class must manage, then its state model is simpler. JTable.java is a good example. It's over 6,000 lines long, yet declares only 9 instance fields.
The general strategy is to distribute responsibilities across many small state machines. The alternative, as you found out, is to approach state machines without a methodology, and let them become monolithic piles of behavior.
I'd prefer a language with higher level constructs like situations / cases and the possibility to derive a special case from the normal case.How's that more flexible than state machines? To me case-driven control can only describe a subset of what a state transition table can. And a state machine has helpful lifecycle invariants that case switching lacks.
Congratulation Tom, we will update our workflow service to JBPM as soon as possible.
We truly appreciate the fact that it can now be deployed in non EJB context.
And I looked at your unit tests, well done!
Just curious with BPML out there as a standard for defining processes why you didn't use it? I think it would be awesome to have an open source execution engine for business processes defined in BPML. I only wish I were clever enough to create one :).
XFlow ( http://xflow.sourceforge.net/ ) provides most clear workflow definition language I ever saw:
<node id="StartNode" type="Start"/>
<node id="P1" type="Process"/>
<node id="P2" type="Process"/>
<node id="P3" type="Process"/>
<node id="P4" type="Process"/>
<node id="P5" type="Process"/>
<node id="EndNode" type="End"/>
<transition from="StartNode" to="P1"/>
<transition from="P1" to="P2"/>
<transition from="P2" to="P3">
<rule>[intValue < 10]</rule>
<transition from="P2" to="P4">
<rule>[intValue >= 10]</rule>
<transition from="P3" to="P5"/>
<transition from="P4" to="P5"/>
<transition from="P5" to="EndNode"/>
the problem with that would be that we would not be supporting : WfMC's XPDL, ebXML, BPEL(J), ...
In my opinion, the area of workflow modelling is too immature for effective standardisation. The only valuable reasearch in this area that combines solid foundations with a practical approach is workflow patterns by Wil van der Aalst.
With jBpm we want to show that it is possible to create a simple and yet powerfull process modelling language, packaged in a production-ready piece of software. By spreading it as open source, we want to achieve widespread adoption to influence (and participate) in standardisation.
I would like to know if jBpm:
- Is fully faul-tolerant (can I restart it anytime)?
- Can I hook together into one transaction database operations with event firing for jBpm?
- It's whole status of execution engine stored in database reliable way at consistent points?
"- Is fully faul-tolerant (can I restart it anytime)?"
--> the core of jbpm is a plain java library. the functionality of the library can be deployed in an ejb environment. so fault-tolerancy depends on the environment in which you deploy jbpm.
"- Can I hook together into one transaction database operations with event firing for jBpm?"
--> yep. you can execute custom classes on events during process execution through a command pattern. when jbpm is deployed in a J2EE server you can use the same transaction (using container managed transactions) for your custom operations as for the jbpm updates.
"- It's whole status of execution engine stored in database reliable way at consistent points?"
--> that is jbpm's unique point of view. the process is centered around states. execution moves from one state to another in a transactional way.
--> jbpm itself will not be the bottleneck, since jBpm only manages states and context information. To synchronize that information with the database is not a costly operation. Typically the custom actions that are associated with the process are the most time consuming. BTW: i should give due credit to hibernate for performance because switching from ejb/cmp/cmr to hibernate persistence made the database synchronization twice as fast :-)
So to answer your question : Final releases of jbpm are enterprise ready.
Is it a complete BPM tool?
May I design all my business case using this tool?
And the most important question: Is it like Weblogic Integrator? Is there a GUI available?
Yep, its a complete BPM tool.
There is an open source UI tool in the project. In another initiative, a commercial company is building a professional graphical designer tool for jBpm. A community edition of that tool will be donated to the project in open source.
Note that I always want to put the added value of a graphical designer into perspective. A graphical designer is nice but its added value should not be overestimated. The most important reason for using a workflow management system is that your business analyst and developer talk the same language. The developer does not have to translate the requirements into a technical design. Instead, the developer needs to map the story of the business analyst one-on-one to the process language constructs.