[jbpm-dev] jBPM5 Request for Comments

[Kris Verlaenen]

Eric,

Comments inlined ...

Eric D. Schabell wrote:
> 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.
>   
Right.  If you would look at this using the vision of Drools Flow, the 
integration of the rule engine would almost be at the engine level, like 
you would have an optional rule engine component in there if you need it 
(or even both a process and rule engine next to each other and 
integrated).  So rules would be a natural addition to the processes, and 
as far as the user is concerned, almost in the same engine (and I'm 
explicitly saying "as far as the user is concerned" because both engines 
should be cleanly modularized as well).

> 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:
>
> 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.
>   
It was not my intention to describe it as stateless, as process instance 
migration is all about state.  While I think we cannot provide a simple 
solution that fits all use (which is basically impossible, considering 
the huge amount of research in this area has no simple solution either), 
I hope we can provide support for
 - doing process instance migration in common, simple cases
 - allow plugging in / customizing more advanced strategies

> 2) process instance migration could and should be a target for moving
> from one version of jBPM to the next.
>   
In theory, if you stick to the same process language, I don't think this 
should be different from normal process instance migration?  Or are you 
referring to process instance migration from jPDL to BPMN2? That seems 
practically a very difficult issue.

> 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!)
>   
+1, help is very welcome here

> 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.
>   
Agreed, we need a core first ;)

> 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.
>   
By using a standard and not tightly coupling this to the process engine, 
this is indeed the first ideal candidate for being a separate sub-project.

> 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.
>   
Drools Flow used the Guvnor repository for storing processes (and rules) 
so could be leveraged.  I'm not familiar with the ModeShape project but 
will definitely take a look.

> 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.
>   
Both projects are already reusing the exact same GWT console code (which 
is then simply customized / skinned for each project).

> 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.
>   
We shouldn't underestimate the effort that is still needed to go from 
existing Eclipse tooling efforts to full BPMN2 modeling.  We're also 
looking for collaboration with other interested partners.

> 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?
>   
I don't think there's a conflict, Signavio is commercial company that 
reuses (and contributes to) the Oryx project.

> 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.
>   
Yep.

> 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.
>   
There is a SAM sub-project already out there.

> Usability:
> =======
> Strange mix of stuff here; Domain-specific processes (what for? why?
> let's get normal process engine out there first?)
This allows people to create processes using constructs and nodes they 
are most familiar with, not just the default nodes provided by the 
engine.  I've recently given a presentation on this topic on the Drools 
boot camp, slides can be found here:
https://community.jboss.org/servlet/JiveServlet/download/14964-114-12136/2010-04-19%20Building%20Domain-Specific%20Workflows.odp

> install scripts (already there?), continuous integration (leverage existing setups?),
> documentation (has always been outstanding, should not slip), OSGI
> (what for?).
>   
Most of these are indeed already out there, but important enough to 
mention explicitly.  About OSGI integration, people that are inside an 
OSGI context and want to use a process engine could definitely use some 
OSGI integration (like creating OSGI bundles for the various 
components).  So feedback on whether the community thinks this is 
important or not is welcome.

> 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.
>
> 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 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.
>   
I'm confident we can find a solution where everyone can be happy with if 
we all work together and listen to each other.

Kris