[jbpm-dev] jBPM5 Request for Comments

Fri Apr 23 14:06:55 EDT 2010

Hello Eric!

Am 23.04.2010 14:27, schrieb Eric D. Schabell:
> I have been watching the replies and seeing what the jBPM core
> community developers would be saying before responding with my own
> thoughts on this topic.
>
> My background with jBPM is not well documented here in the forums or
> mailing lists. I have been using jBPM in an enterprise environment
> over the last three years or so as both a developer and lead
> developer. It started on the jBPM v3.1.x community versions and later
> migrated to the current supported jBPM v3.2.x. I also have had
> personal meetings with Tom, Joram and Koen discussing jBPM 3 and jBPM
> 4, be that development questions, use cases from customers or just my
> experiences deploying enterprise solutions into production
> environments. One award winning case was published
> (http://www.schabell.org/2009/11/2009-silver-winner-for-europe-financial.html)
> on the implementations we did with jBPM v3.

Thanks for introducing yourself a bit. You have mentioned that your 
background is not well documentend in the forums and mailings list. Thus 
this helps me a lot to understand your involvement, background and 
experience with the project.

>
> Looking at the various sections presented by Kris in the design
> overview https://community.jboss.org/wiki/jBPM5RequestforComments, I
> will run through each section and give my thoughts:
>
> Architecture:
> =========
> This picture is clear and concise, providing a pretty good idea of
> what the overview is. I miss JBoss Rules / BRMS as a block in the
> Connections side. I feel that Rules is just as important as JBoss ESB
> and you need to provide this to push your own products. On a side
> note, the roadmap needs to come ASAP to provide clarity where the
> focus is. You will see below in my evaluation, there is a focus needed
> on the core functionality to make something that can make it into a
> product.

I completely agree with you in this point and I also see the focus on 
the core functionality.

> Core process engine:
> ===============
> When I look at this component I see many of the existing jBPM 4 branch
> as being a strong candidate to be leveraged along with whatever the
> Drools project has completed. Would be great if they could/would
> compliment each other. I am very happy to see the PVM being the
> leading theoretical foundations for the BPM suite.  Three items are of
> some note:
I am happy to hear this because the PVM could already demonstrate its 
power when using it to start a basic BPMN 2.0 implementation. This 
clearly showed that it is possible and also what can be accomplished.

> 1) process instance migration is mentioned as if it is about stateless
> processes. I do not see how you can manage this at all. If you show me
> a process you think you can migrate, I bet I can break it.
>
> 2) process instance migration could and should be a target for moving
> from one version of jBPM to the next.

 From my point of view you mention two important points which should not 
be forgotten. Process instance migration needs to be target or migrating 
from one version to the next won't be possible.

> 3) jPDLv3 ->  BPMN2 process definition conversion tooling is a must and
> I was pushing this before the split, with project space already setup:
> http://anonsvn.jboss.org/repos/jbpm/projects/migration_tool (current
> leads are more than happy to have someone to help on this conversion
> tool, great place to get your feet wet in open source!)
>
> Finally, this part of the project should have about all the attention
> available to ensure a speedy delivery. This is what is needed to offer
> customers a path into the future of BPM.

You're absolutely right here IHMO and I think this is the way to go. The 
migration tools adds a lot of value to jBPM.

> Human Tasks:
> ===========
> Following a standard makes lots of sense. I do see this as a bit of an
> external project when related to the console and form editor. First
> order of business is having them available.

While I have to admit that I was sceptical at first I agreed with you. 
Using a standard makes sense. I share your point of view when it comes 
to treating these as seperate projects. This also ensures that these 
component is independent of its presentation. There are use cases when 
you don't want to use or you cannot use the included form functionality 
and the console.

> Process repository:
> ==============
> I would assume that this component could also leverage the efforts of
> ModeShape project maybe? Keep work to a minimum by conforming to what
> they recognise as an artefact. Seems also to fall into the category of
> nice to have but not yet essential to initial releases.

I don't have an opinion here (yet) since I do not know the ModeShape 
project. But I am sure I'll have a look at it.

> BPM Console:
> ==========
> Looks like this can and should leverage the jBPM 4.x work, the GWT
> console project, along with whatever Drools project can / has to
> offer. This is nice to have stuff.

I am sure the work can be leveraged since the new console was kept 
independent from the engine so I imagine this can be easily achieved. I 
recall that there have been a lot of request on the forum where 
jBPM3-users have been asking to support the new Console in jBPM3. IMHO 
this shows that the console is a great piece of software and widely 
accepted.

> Eclipse-based process tooling:
> ======================
> To leverage jBPM 4.x existing tooling and Drools project tooling. The
> extra bits mentioned are again fine for later releases.
>
> Web-based process tooling:
> ====================
> Is Oryx / Signavio one team? I was under the impression that Drools
> went one way and jBPM project another... who will win now and what are
> the criteria to be judged?
Oryx is an open-source web-based process modeler. Signavio is the 
commercial offer based on Oryx. Support is available from Signavio GmbH 
(Germany) and additional features.

> Simulation:
> ========
> Very advanced feature that is nice to have (would make Product sales
> easy to visualize and demo's very slick) but nothing to focus on in
> the initial releases I would think. This could be an apart
> sub-project.

Agreed. This is a really a nice to have but should be addressed later as 
you stated.

> BAM / BI:
> ======
> This is a very interesting one, how to provide without dictating what
> a person is to get/use/have in the BAM/BI area. It should be about
> facilitating and ease of customization. Also an apart sub-project and
> not important for the initial releases.

This is indeed a hard question.

> Usability:
> =======
> Strange mix of stuff here; Domain-specific processes (what for? why?
> let's get normal process engine out there first?), install scripts
> (already there?), continuous integration (leverage existing setups?),
> documentation (has always been outstanding, should not slip), OSGI
> (what for?).

Agreed. The "normal" process engine as you call it has priority in my eyes.

> Integration:
> ========
> Every item mentioned here in this section needs to have a block in the
> architecture overview picture. Very good to leverage and use our own
> projects. Make that the easiest path.

Agreed. Nothing to add.

> Final thoughts, I see many panic reactions on the lists/forums with
> regards to jBPM 4. Looking at this overview Kris provides, I expect
> much of the jBPM 4 will function as some sort of base line for further
> development. DroolsFlow will play a role and if more projects are
> leveraged then this overview of a BPM suite on functionality is
> achievable.

I can understand that there a some panic-like reactions. As you stated 
correctly in the forums Red Hat/JBoss never stated that they will 
support jBPM 4.x but I think it was just logical for the community to 
assume that jBPM 4.x will replace 3.x by some time since Tom and Joram 
have been employees at JBoss.

> I think the first steps need to be to ensure that
> customers are taken from jBPM3 to jBPM5. plan this from the beginning.
> Rule #1: nobody gets left behind.
This is related to the migration tool (jPDL -> BPMN2) and the process 
instance migration and I consider this important, too.

> Regards, erics
Thanks for you valueable feedback, Eric. Looking forward to more 
productive discussions on the mailing list.

Best regards
Sebastian

-- 
Sebastian Schneider
e-mail: Sebastian.Schneider at alumni.fh-aachen.de