First look at jBPM4 Alpha1

[thomas.diesler]

First of all, congratulation for getting out the long awaited release - well done.

I got the download from SF, installed the GPD, read the docs, had a look at the API and generally tried a few things - here my impressions. May it be helpful ;-)

The new graphical designer (GPD) looks really nice. It finally adopts the BPMN standard for its graphical elements, which looks really nice.

There is the notion of start event, and end event, a few gateway types and a significant number of tasks.

What is a little bit confusing is some inconsistency in the terminology that is being used in the GPD, the docs and the API. BPMN talks about exclusive, inclusive, parallel and complex gateways. These have a specific semantics and everybody who knows BPMN would also know their semantics. GPD on the other hand talks about exclusive, fork, join

The jbpm4 docs sais

(BPMN note: when we mention activities here, we are not only refering to BPMN activities, but also to BPMN events and BPMN gateways.)

If possible, I would not do that. An activity is an activity (namely a task or a sub-process), an event is an event, a gateway is a gateway.

jBPM4 allows multiple outgoing flows on a task. This combines the notion of task with the notion of gateway. It is however not clear what type of gateway is being combined here and if we assume that it is an exclusive gateway, it not clear whether the full functional set of an exclusive gateway is also available on the task.
Can every task have multiple outgoing flows?

I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR)

The docs talk about "end state" - this should be "end event" - cancel and error are "event details" that if attached to an end event are called "result"

Generally, I'd recommend not to invent new terminology for a concept in the BPMN editor that already has a "standard" name in BPMN. Also don't use existing BPMN terminology to mean something different.

The API combines the notion of ProcessInstance with that of Token in a single interface and calls it "Execution". This will not allow these two concepts to evolve independently for example when you want to add state independently to the ProcessInstance and the Token. It is generally better to model a concept like ProcessInstance as such and call it by it's name. If you cant do much (yet) with a ProcessInstance you will have a short method list, which is ok.

The GPD elements in the process definition should be defined in their own namespace

Instead of

 <start g="32,22,80,40">

jBPM should have

 <start gpd:g="32,22,80,40">

This allows GPD metadata to evolve independently of the process definition itself and also makes it clear that 'g' is a presentational and not a functional element.

During GPD installation, the license text is missing.

This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality.

Thanks for Alpha1, I'm looking forward to stuff to come.

[kukeltje]

Thomas,

Good review. I tend to agree with most of what you write although I've only downloaded it yesterday, so I did not try much yet.

I definately agree on the namespace thing ;-) and regarding terminology, I tend to agree as well but with some small remarks.

BPMN terminology is not always 1-1 mappable on jBPM terminology, or e.g. a drop-in replacement. Therefor I think it should be introduced slowly and since it will not be 100% BPMN, there will be discrepancies. The join/fork comment I agree with (although it takes getting used to, so initially we should mention the 'old' term i
n braces as wel), regarding the events etc, lets introduce them slowly and see where it leads us.

On thing I think differently about though

I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR)

I think that not doing this would result in a lot of misunderstanding with the current users. They are so accustomed to having this that if we have the intention to support this condensing, we should do it now. It should be a little more explained then I agree what the behaviour is.