Since Edward called "to get a rise out of other folks", I think I'll rise my hand too :-)
To put my words in perspective, I have a lot at stake in jBPM: I'm the senior architect at a consultancy/software house that has one big product in production (4y/man in the making) based on jBPM 3, another implementation ongoing, and several pilot projects with jBPM4 and Drools Flow.
Regarding the very interesting points raisen by Edward, I'll add my respectful opinion:
> 1.) Open persistence
While I agree with Edward on the value of an open relational schema for reporting and similar tools, I think the choosen path is more valuable. If you have needs for an open schema, you'll almost always better served if you design it yourself. With some interceptors in the right places (jBPM4 seems to have the right hooks to plug them in) you can keep your report schema aligned with the engine's data, without disturbing it too much. Even jBPM3's very open and flexible schema is not good enough with some kind of processes (I have some 150+ nodes, 200+ variables, very long financial processes to manage), so you'll end up with something custom anyway. If you design it flexible enough, however, you could come up with an interesting extension.
> 2.) Isolated or collaborative custom nodes.
There already is an interesting practice coming out of Drools Flow about Domain Specific Processes, so Edward's needs will be served by that tooling, probabily.
> 3.) Custom Decision Handlers.
Due to point 4, there should be little need for these. If you have a decision to make, is far better to have it documented with a rule instead than in code. I can tolerate MVEL-based decision evaluators, if they don't get too big. If you have to check with external data and services, you better bring that data in the process first (and deal with what happens if you can't get it) and decide on it afterwards.
> 4.) Use of rules for decisions.
Drools wins in this field, hands down. With Guvnor and the BRMS infrastructure, you can have documented, readable and managed (versioned & avalaible in a repository) decision rules/conditions in a language far more flexible and expressive than Java code. Anything you ask for (connection, services) should not be included in the decision conditions or can be brought in with little integration effort.
> 5.) A roadmap for web services.
Web services are a separate integration issue. And if what you need is orchestrating webservices, you are better served with BPEL.
The focus on BPMN2 is really the top priority for jBPM5: we have real competition on that. Combining BPMN2 and rules may be the best differentiator between jBPM5 and other offerings.
Just my opinion. Edward's concerns are just as valid, of course. I've just represented another point of view.
Michele
--
Michele Mauro
Senior Architect
Visionest S.r.l. - The Business Innovator
www.visionest.comVia G.B. Ricci 6/A
35131 Padova - Italy
E-mail:
michele.mauro@visionest.com
Mobile: +39 349 2222319
Phone: +39 049 8210229
Fax: +39 049 8774924