[jbpm-dev] Proposal for jBPM5 first release

[Michele Mauro]

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.com
Via G.B. Ricci 6/A
35131 Padova - Italy
E-mail: michele.mauro at visionest.com
Mobile: +39 349 2222319
Phone: +39 049 8210229
Fax: +39 049 8774924
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20100527/a58d80d0/attachment.html