BPMN in jbpm4

[camunda]

Hi.

Currently I port a sample process to jbpm4, so I play around with it a bit. I also prepare a blog entry for demonstrating it.

First of all: Nice looking Designer! Good job :-))

But I have some issues and questions with the BPMN used in jbpm 4:

Violation of Spec
- Multiple leaving flows in a activity with XOR semantic. This is not BPMN, BPMN has AND semantic but allows for conditions on the outgoing flows. The behaviour implemented makes sense if you know jPDL, but it is not correct BPMN. I think this is somehow problematic
- End which terminates Executiuon only. For this end the End-Event should be used, not the Termination-Event (which is only a signle circle). With the termination event BPMN specifies that the whole process instance is terminated.

Missing stuff
A lot of stuff is still missing: Attached events, Pools, Lanes, a lot of events (like message, compensating, ...).

The question here is: To what extend will the missing features be implemented? Is this one of the goals? Or not? I am not currently up to date here, maybe I had to leave Antwerp to soon :-/

Will spec-conformability be targeted? Or is BPMN more for nice looking diagrams and marketing?

Would be interessting to hear some oppinions and directions, because these are things people start asking me, and as giving BPMN trainings and working together with research on BPMN topics we (camunda) are in duty to know correct BPD's and not misusing BPMN as drawing tool ;-)

Thanks a lot and have a nice weekend
Bernd

[camunda]

Some additional remarks on the GPD (I think they are already on your list, I just wanted to write it down here, since I made these notes):

- line break should be supported in activities to allow to model from left to right
- Labels should be shown on Gateways (to see the condition)
- Free labels would be quite nice as well :-)
- Drawing a flow to an activity itself is not possible at the moment (or I was too dumb for it)
- XML-View as tab in GPD is really missing!
- Property Editing is still missing

And for flows one additional remark: default and conditional flows could also be visualized according to BPMN spec, that would be really cool :-)

Cheers
Bernd

[thomas.diesler]

Thanks for your feedback - this is good work.

[heiko.braun]

I just had a meeting with Tom. We decided on the following approach to get from concept to notation:

1.) Does the concept exist in BPMN with exact same semantics, then use the BPMN notation for it.
2.) If there is no precise fit, then we chose a proprietary notation that clearly distinguishes between jPDL and BPMN
2.1) leverage the BPMN extension points whereever possible to achieve 2.)

[tom.baeyens]

"camunda" wrote:
- Multiple leaving flows in a activity with XOR semantic. This is not BPMN, BPMN has AND semantic but allows for conditions on the outgoing flows. The behaviour implemented makes sense if you know jPDL, but it is not correct BPMN. I think this is somehow problematic

as heiko already indicated. we'll be fixing spec violations like this one. if you have good suggestions on how we could represent a wait state best in bpmn, or how we could best use bpmn-extension pluggability to indicate that we're doing something jPDL-specific, let us know.

"camunda" wrote:
End which terminates Executiuon only. For this end the End-Event should be used, not the Termination-Event (which is only a signle circle). With the termination event BPMN specifies that the whole process instance is terminated.

good point. we'll fix it. koen didn't have the option yet to put distinct icons on different configurations of the same activity.

"camunda" wrote:
Missing stuff
A lot of stuff is still missing: Attached events, Pools, Lanes, a lot of events (like message, compensating, ...).

The question here is: To what extend will the missing features be implemented? Is this one of the goals? Or not? I am not currently up to date here, maybe I had to leave Antwerp to soon :-/

extending to what heiko already said:
* jpdl 4 will be an improved version of jpdl 3. this will make sure we capture the value of jpdl and extend on it.
* for each jpdl construct we'll search for the exact matching BPMN construct.
* if no proper match exist, we'll clearly indicate that this construct is not BPMN and that it is jPDL specific
* we'll also plan to go over the BPMN constructs and see if we can easily find or build a suitable match in BPMN to extend the BPMN coverage.

"camunda" wrote:
Will spec-conformability be targeted? Or is BPMN more for nice looking diagrams and marketing?

of course spec conformity is the target... but whether we will reach 100% remains questionable.

at this stage marketing is an important driving factor. to adopt it for jPDL. in teh BPMN 2.0 spec committee, they are working out exact execution semantics and a file format.

after jBPM 4 goes GA, we have to make a choice between 2 directions: further move away from jPDL and make it fully executable BPMN 2.0.

or we can decide to go for BPMN 2.0 as a separate process language.

i am pretty confident that BPMN as it is today, can not be made as usable as jPDL for the use cases that we target. over the last two years, bruce silver has pointed out on numerous occasions that people (even bpmn software vendors) do not get the full details of the spec. michael zur muehlen has pointed out that only the first 9 out of 40 bpmn concepts are actually used in practice. further more, the scope of BPMN at this stage is still pretty vague as it includes things like choregraphy.

the process on how we deal with bpmn in jbpm 4 is outlined above. that will make sure that we don't loose the jPDL audience we have today and help to make inroads in the levels where BPMN is a marketing checkmark. after jBPM 4 GA we'll have to choose.

(side note: given the focus on executability and file format in bpmn 2.0 committee, i am certaint that bpmn is intended and going to deprecate bpel over time)

bpmn as a spec is definitely of another kind to us then bpel. bpmn has the potential to become mainstream sustainable process modelling notation. but it will require that a limited intro level is established. sort of like the HTTP GET as the 10% of the spec that covers the 90% of all HTTP operations.

we always knew that bpel only remained hyped till the ora's and ibm's give up their marketing to push their shitty technological choices. once that marketing effort disappears, bpel will be legacy.

if bpmn does make that distinction --chances are significant for that-- then i'm convinced bpmn can end up being sustainable. bruce silver already introduced the notion of levels of bpmn. so the idea is on the table.

in conclusion, we'll be examining to what extend we can comfortably fit BPMN on top of jPDL in this jBPM 4 GA iteration. after the GA and once BPMN 2.0 is out, we'll have more experience and info if we can sustain that the combined BPMN-jPDL route or if we have to split both of them in dedicated languages.

[brittm]

That's a good explanation Tom. Much appreciated.

[heiko.braun]

in conclusion, we'll be examining to what extend we can comfortably fit BPMN on top of jPDL in this jBPM 4 GA iteration. after the GA and once BPMN 2.0 is out, we'll have more experience and info if we can sustain that the combined BPMN-jPDL route or if we have to split both of them in dedicated languages.

right, this will help identifying the differences which is necessary to move on.

[tom.baeyens]

* if no proper match exist, we'll clearly indicate that this construct is not BPMN and that it is jPDL specific

i've been searching a bit into the most recent version of the spec and i can't find a real extension solution in the spect to do that.

i can only find how to add custom properties to bpmn elements. but not how we could indicate that we're overriding the default bpmn behaviour.

we're looking for extensibility on the graphical notation level. and it seems that that is exactly what is been blocked in the spec.

for example, the wait state that bernd mentioned. does anyone have an idea how we can model the jpdl state behaviour correctly in bpmn ?

or do you know of sections in the spec that would allow us to indicate that we're overriding the default AND-split for the outgoing transitions ?

[kukeltje]

Toms' remarks/explanation should be made into a blog-entry since it is very interesting info for others and one of the major (visible) changes to jBPM 4

[koen.aers]

Clearly we need to discuss what we need to do to support the jPDL specific constructs in a diagram with BPMN look and feel. At the moment I see a two imminent examples of these problems:

1) Multiple outgoing sequence flow from nodes:
As Bernd states in jBPM these have XOR semantics while in BPMN outgoing sequence flow in nodes have AND semantics. On the other hand, BPMN has the conditional sequence flow construct. If you think about it, the outgoing sequence flow in a jPDL state is conditional (i.e. the token is propagated along the sequence flow with the name you give when issuing the continuation signal, otherwise the default flow is chosen). Following the BPMN logic, outgoing sequence flow from jPDL nodes with XOR behaviour should have a diamond at the start and the default flow should have a transversal line. The BPMN spec does not mandate that the condition is given explicitly, so in this case the condition is implied by the implementation of the jPDL node (in this case the wait state).

2) Superstates
The BPMN concept that most closely resembles superstates is the expanded subprocess. But this interferes of course with the jPDL process nodes and subprocesses. There is AFAICS no way of getting a sequence flow to connect a node with some other node inside the expanded subprocess. Any ideas here would be more than welcome.

Of course other issues exist, mostly related to terminology clashes. The most obvious clashes that I can see right now are:

1) signal: in jPDL this is an event that continues the process; in BPMN it is a flare that is visible to all the processes
2) event: in jPDL this is a hook into the execution of a process, subscribers can listen to these events and perform some processing accordingly; in BPMN this is a first class citizen (a node in the diagram) that indicates e.g. the reception of a message or the raising of an exception.
3) task: in jPDL tasks are related to human tasks; in BPMN tasks are atomic activities

Undoubtedly I forget a lot of other stuff, feel free to add and/or react and provide us with suggestions.

I will create a wiki page where we can describe the issues that come up along with their solution.

Regards,
Koen

[kukeltje]

1) Creative.... and I think it can be defended if is is just explained in enough detail in the docs.

2) First of all, I did not use superstates once (did not have the real need), secondly and IANAE, BPMN has the notion of embedded and reusable subprocesses (the latter are renamed to call activity if I am informed correctly). Though there is no relation between the type and the way they should be displayed, I think that can be leveraged:
- collapsed can be either subprocess or superstate.
- expanded inline: superstate
- 'new tab/page': the content of the subprocess node

Where e.g. a doubleclick on a collapsed one opens it expanded inline or on a new tab...

Bruce Silver writes about this in http://www.brsilver.com/wordpress/2008/09/15/concepts-and-terminology-in-bpmn-20/

Regarding the connection of a sequenceflow into a node I have no clear picture yet... if I find the time I'll try to read about it.

Terminology wise:

1) & 2) Yes, I agree and it might be nothing more than 'getting used to' or pose a real problem. Not sure yet

3) I often 'abused' the task node, since in many of the processes I worked on could be either 'signalled' via an incomming b2b message or a from a form on a web page that was completed by a human. So this to me is no problem... this 'abuse' will continue I think after reading about the private, abstract, global processes and the B2B arena.

[camunda]

Hi all!

I am very glad to hear that the direction is to go without spec violations :-)

I think first go for jbpm 4 GA and then see what BPMN 2.0 and executable BPMN really brings. I could image that splitting jbpm into 2 languages (jPDL and xBPMN) could make sense, but we will see... For marketing it is obviously a good move to support BPMN, I also got some interested feedback on jbpm 4 supporting it. This could really boost the project further (I hope).

And I would appreciate a blog post from Tom on the thoughts he mentioned as well :-)

For the detail problems: Implementing outgoing XOR by using conditional flows is a valid option. This also has the advantage, that the default flow is clearly marks (something I miss in jbpm 3).

As far as I know graphical extensions are limited to the attached data objects and additional icons in activities. But I wouldn't have a problem with it, if the extensions are clearly different from BPMN standard. The only downside of it is, that the diagram couldn't be transfered to another tool, but this isn't possible anyway and not targeted by jbpm I think.

Cheers
Bernd