[Design of JBoss jBPM] - Re: BPMN in jbpm4
by tom.baeyens＠jboss.com
"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#4205514
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205514
15 years, 10 months
[Design of JBoss jBPM] - Re: jbpm 4 - Term
by tom.baeyens＠jboss.com
"camunda" wrote : Feedback about jbpm 4 and discussions will go on in this forum, right? Or PVM?
|
this forum is good. pvm separate forum should be deleted but i assume that it is impossible to (re)move forums.
"camunda" wrote : So I would like to see ProcessInstance and Token again
|
The motivation to unify process instance and token is the simple case without concurrency. When a process has no concurrency, the distinction between process instance and it's root token is artificial and confusing.
On a PVM level, we need to have this unification. The idea was that on the jPDL level, the distinction would be made to have a JpdlProcessInstance and a JpdlExecution. But so far, (ok we're only in alpha 1) there was no need for this separation.
Conceptually, the distinction needs to be there in case of querying.
"camunda" wrote : but I think that would cause a lot refactoring. What are your thoughts? Or is it decided already anyway?
|
I don't think that would cause a lot of refactoring. It's a matter of where and how this separation in the API should show up. This is a work in progress and all feedback is welcome.
For starters: the startExecutionXxx methods should be renamed to startProcessInstanceXxx. But in the services API, I have not yet had a need for a specific ProcessInstance method. So do we introduce a ProcessInstance that extends from Execution and not adds a method ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205507#4205507
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205507
15 years, 10 months
forum refactoring capabilities ?
by Tom Baeyens
Mark,
We have a couple of forums that we'ld like to deprecate. I would assume that
removing forums is not possible as then we would loose the history.
But would it possible to just move all the topics under another forum and then delete
the empty forum ?
--
regards, tom.
15 years, 10 months
