[jbpm-dev] [Design of JBoss jBPM] - Re: Defining the API Mission

tom.baeyens@jboss.com do-not-reply at jboss.com
Thu Jul 17 04:06:53 EDT 2008


"estaub" wrote : I understand that we don't want to try to morph BPMN into an executable language, but I don't understand your objection to using it as a conceptual basis for the API.  
  | 

Decade ago it was XPDL, Yesterday BPEL, today BPMN and tomorrow it might be BPDM.

None of the standardization efforts take into account the dual nature of BPMN.  We bring a completely different vision.  We're the only ones (ok i'm biased) that accept the different nature of analysis and implementation.  I think we are far ahead in terms of dealing with the differences between analysis and implementation.

The standards and the bigger part of the market today still think of BPM in terms of analysts that create executable diagrams.  Then they think in terms of a monolithic system in a specific environment like e.g. an ESB.  I don't have fate in what came out of committees with this background so far.

In other words, the BPM space today is not mature at all so it's not good to focus on one of the attempts on the way to maturity.

So I will not take a name only because it is BPMN.  For each concept, we need to find an appropriate and unambiguous name.  Is that the same name as in BPMN, the better.

Another point is that the API mainly exposes runtime datastructures and only to a lesser extend the process definition datastructures.  The standards are only taking into account the process definition data structures.

We will be the ones that show how analysis diagrams can be made executable in a realistic setting.  And we're going to bring those ideas to the masses.  I don't think its appropriate to focus on one of the specifications that doesn't see our realistic and practical approach to BPM.

"estaub" wrote : Do you see a lot of mismatch between BPMN and JPDL? Or does it seem arcane?  Or something else?
  | 

On the surface, the resemblance is there.  But the more you go into the details, the bigger the differences.  ...and that is for good reason.

BPMN is focussed on analysis.  It doesn't have exact execution semantics.  And adding those would be a flaw IMO as analysts should be able to model freely without being constraint by the runtime execution of that diagram.  Introducing different levels into BPMN could be a viable strategy.

So as it is today, there is a lot of mismatch between BPMN and jPDL.  BPMN is for analysts (human-to-human communication).  jPDL is an executable process language (human-to-computer communication aka software) If BPMN would be changed so that it fits onto jPDL, then BPMN would become less suitable for analysts.

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

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



More information about the jbpm-dev mailing list