"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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205514#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...