[jbpm-dev] [Design of JBoss jBPM] - Re: meeting context

[kukeltje]

Afaik, but could not find it directly, BPMN is based on structured graphs


Well, we just borrow the terminology (i.e. parallel gateway) and need think about what it means for the implementation. This is exactly the kind discussion I'd like to have. 

anonymous wrote : 
  | In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split: 
  | 

Exactly, hence the need for verification.

They leave it open, we decided to make a choice since it impacted implementation and there have not been real problems regarding this choice

"heiko.braun at jboss.com" wrote : 
  |  What you said about previous discussions is something I don't agree with at all:
  | 
  | anonymous wrote : 
  |   | This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-) 
  |   | 
  | 
  | 
Sorry, this statement was mend solely in the context of the nested fork/join


"heiko.braun at jboss.com" wrote : 
  | Let's put it the other way around: Why do all the vendors support  workflowpatterns.com [1] and BPMN [2] opposed to jbpm? 
  | 
  | [1] http://www.workflowpatterns.com/vendors/
  | [2] http://www.bpmn.org/BPMN_Supporters.htm#current
  | 

Ahh.....this is an interesting one... A really interesting one.... or even two (separate) interesting ones.

Lets get the facts and history straight on the first one.

[1] is 'old' and for the 'original' patterns. That is not very clear to people who are fairly new to these things.

I remember the discussions I had with Tom about the discussions he had with Prof. van der Aalst (I also personally met him twice on workflow non-related events) about the workflow patterns. jBPM 3.0 (look in the source for the pattern tests) engine wise supports them. JPDL language wise not (but most), at least not with writing some small reusable java classes. 

They did not want to evaluate jBPM at that time due to the different views on things. They wanted everything in the 'language' while we said that basic things were supported in the language and less used things were possible in the engine with some small java code. In all these years there has been one pattern users in the  forum asked me about (well actually two, but the implementation in jBPM is 98% the same, two multiple-instance patterns [3], and [4]. In the wiki we've described how that can be achieved in jBPM. Nobody complained. In fact, we are even more flexible, since these multiple instances can easily be assigned to different actors.  But... I won't complain that they did not evaluate us (users in the forum did not, so who am I). We could have implemented language constructs for them, but it was a trade-off between time and the number of times it was requested. Therefore it was not done.

But.. things have changed a little. First of all, on the evaluation pages [5] of the workflowpatterns, they did evaluate jbpm [6]. With some of the patterns they now explicitly that they are supported with some java code. Regarding [3] they state:

"workflowpatterns.com" wrote : 
  | jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language
  | 
This has (in our opinion) never been a problem and the extensibility is part of jBPM thourgh JPDL. 

Regarding [4] they state 

"workflowpatterns.com" wrote : 
  | jBPM does not support this pattern. 
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181067#4181067

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181067