This comment was published in The Server Side web page (http://www.theserverside.com) in response of some comments asking about the differences and the overlap between two projects from JBoss: jBPM and Drools low. The Drools team saw my comments on the site and invited me to publish them here. It’s my experience and the reason why I have chosen Drools over jBPM to work with every day and contribute as a community member.
Here is the link to the comment and the article.
I hope that gives to all you guys a simple and not biased developer perspective.
Here is my comment:
Hi guys,
Regarding the Drools vs jBPM discussion, I can share my recent experiences making the shift from jBPM to Drools. I started with jBPM about a year and a half ago, at the beginning it seemed to be a decent framework, very process centric and developer oriented. When I started to play with rules and delegating the business decisions to the inference engine, I started to notice that I needed to learn another set of very different of API, and that these two frameworks didn’t integrate very well.
When I decided to get involved with the Drools project, about 8 months ago, I realized that the integration proposed for version 5.0 was what I, as a developer, was looking for years. A whole environment that allows me to model different business situations with an unified set of APIs and merging three of the hot topic today: BPM, Business Rules and Complex Event Processing, all in one! And since it’s not easy to define all my business logic using only one of those, it’s promising to see I’m now allowed to combine (and integrate!) them whenever necessary.
The other thing that really attracts me is the fact that the tooling created by the Drools team is great, very extensible and easy to use, with a lot of extra features compared with the jBPM tooling. In my opinion, the most useful features are:
1) A powerful set of nodes to model your business processes
2) An easy way to create your domain-specific processes. I created a lot of new domain-specific nodes in a very short period of time. And these can be used inside the graphical tooling immediately.
3) Nice debugging tools, you can follow your process (and rules) step by step, simulating your execution.
4) The real possibility to support and plug in new languages. I have participated in the OSWorkflow migration tool, and I see that is very easy to create support for different languages. This is so cool that it would also allow you to run jBPM3 defined processes with RuleFlow.
5) A lot more extra features like a human task management component based on WS-HumanTask, reporting, etc.
So far I only mentioned the technical advantages that we discovered making the switch from jBPM to Drools, but there is another mayor thing that pushed me towards Drools, and that is the fact that the group of core developers are really open to new ideas (that is very cool, in not every project you can find that) and let the community members share their personal experiences and contribute with them on an every day basis.
It is also important to mention that the Drools project seems to be be evolving at a much faster rate than jBPM, which seems to have been frozen for about 3 years now. From what I’ve seen, they are working in version 4 of their framework, without adding new functionality compared to version 3.
I hope that my experience helps you to choose the right tool for your situation, I have already chosen, and that is why I try to contribute every day to this nice framework and promote it to succeed, because it makes the life of the developer easier. And that is all we want !!
Greetings
