-
15. Re: Defining the API Mission
Quoting Bruce Silver:
BPMN is a modeling notation more than just a diagram, since each element has defined process semantics, abstracted from implementation details but BPMN has no official XML schema, i.e. no interchange format.
[...]
Bottom line is that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models not diagrams, models that is independent of implementation architecture.
Taken from:
http://www.brsilver.com/wordpress/2007/03/21/the-real-issues-with-xpdl-bpel-and-bpmn/ -
16. Re: Defining the API Mission
BPMN is a vendor specification. It addresses BPM requirements from the perspective of those vendors who wrote it, not necessarily from the perspective of users. Even if significant research has gone into it, that does not mean it addresses the needs of the jBPM community.
There are many elements in BPMN 1.1 that have neither been implemented nor requested in jPDL. Examples include the message flow, lanes within pools, and several event triggers and gateway types. Plus, BPMN defines the model semantics but does not address the execution. It is like having the Java Language Spec without the JVM Spec. Some vendors, e.g. Intalio, use BPEL as the execution spec. However, BPEL addresses orchestration, not workflow, and does not really fill the bill.
I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion. -
17. Re: Defining the API Mission
"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. -
18. Re: Defining the API Mission
"heiko.braun@jboss.com" wrote:
Quoting Bruce Silver:
BPMN is a modeling notation more than just a diagram, since each element has defined process semantics, abstracted from implementation details but BPMN has no official XML schema, i.e. no interchange format.
[...]
Bottom line is that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models not diagrams, models that is independent of implementation architecture.
Taken from:
http://www.brsilver.com/wordpress/2007/03/21/the-real-issues-with-xpdl-bpel-and-bpmn/
I agree. BPMN is indeed the only standard that has a real focus on the BPM community.
But Bruce's opinion is just one in a very crowdy and dissonant metal rock band.
http://blog.lombardicto.com/
http://www.brsilver.com/wordpress/2008/07/14/manchurian-candidate-in-the-bpmn-battle/
http://www.infoq.com/news/2008/07/BPMNDebate
http://www.infoq.com/news/2008/05/BPMN20
http://www.column2.com/2008/03/the-great-bpmn-debate/
So my conclusion is that BPM landscape is not mature at all and the current standards are not viable candidates to limit ourselves to. -
19. Re: Defining the API Mission
"alex.guizar@jboss.com" wrote:
BPMN is a vendor specification. It addresses BPM requirements from the perspective of those vendors who wrote it, not necessarily from the perspective of users. Even if significant research has gone into it, that does not mean it addresses the needs of the jBPM community.
There are many elements in BPMN 1.1 that have neither been implemented nor requested in jPDL. Examples include the message flow, lanes within pools, and several event triggers and gateway types. Plus, BPMN defines the model semantics but does not address the execution. It is like having the Java Language Spec without the JVM Spec. Some vendors, e.g. Intalio, use BPEL as the execution spec. However, BPEL addresses orchestration, not workflow, and does not really fill the bill.
I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion.
great concrete explanation of my high level fluffy talk :-)
+1 -
20. Re: Defining the API Mission
i didn't yet get to mention my view on how we should support BPMN.
I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer.
That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable.
After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team.
That is the bigger picture in which I see the value of a BPMN to jPDL export functionality. -
21. Re: Defining the API Mission
To add to Tom's latest comment: one of the JBDS developers (Grid Qian) is currently investigating the possibilities for an export wizard from the STP BPMN designer to jPDL that is consumable by the GPD.
Regards,
Koen -
-
23. Re: Defining the API Mission
Heiko,
I think you should check out Toms' blog. It contains several topics on BPMN related 'issues' that can give you at least the basic understanding on GPD vs BPMN.
Discussing it afterwards (in a new topic?) would be good. -
24. Re: Defining the API Mission
That shoud have been: GPD (jPDL, executable) vs BPMN (XMI, analysis)
-
25. Re: Defining the API Mission
"estaub" wrote:
Tom,
... Do you see a lot of mismatch between BPMN and JPDL?
In response to my own question... YES! The mismatch in naming of workflow elements is nearly as bad as it can get, and there are few elements that simply map one-to-one. Furthermore, the graphical elements are often "overloaded" with very different semantics, depending on context or attributes. Examples:BPMN "task" = JPDL "node"
BPMN "parallel gateway" = JPDL "fork" or "join" or both, depending on the transitions in or out.
BPMN "sub-process" = loop, ForEachForkActionHander, or super-state, depending on attributes
-Ed -
26. Re: Defining the API Mission
Hi guys,
wow, a lot of content (an me beeing to busy to really joing that interesting discussion :-/)...Thats why I don't think we should pursue of making BPMN executable. It creates the false illusion that analysis models automagically can be made executable. That is a false promise that many BPM vendors promote and that gives BPM its bad reputation. We get our recognition from being more modest but honest.
I agree with it. Basically I think making BPMN executable or supporting Round-Tripping and all that is in the state of research. Interesting to keep up, but to early to really go for it. Would be very interesting for a Master Thesis or the like (camunda would volunteer for funding and supervise such a thesis ;-)). But I think, executing BPMN is not really the best try, better generate a execution language out of it.
And for now I would definitely keep the GTD (okay, get rid of some bugs ;-)), the people like jBPM because it is relatively easy.I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion.
Agreed. It should be obvious to center on our experiences with jBPM up to 4...
I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer.
That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable.
Agreed. This would be also a very interesting move forward! Very, very interesting!After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team.
In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.
I do not really agree on this. I think, there could be more support than just one way generation. Even with UML there are tools that can at least keep traces between analysis and execution model. You can even set traces between use cases and classes. This can be very helpful if used (there you are right, not used very often).
With BPM I see tools today which can link process landscapes to analysis models, which can link to implementation models. This has a real value.
Supporting a roundtrip or maybe even share a same model (and have analysis and execution as different "views") is a interesting vision. I have the feeling it can be reached somehow, but it is still a stony path. So I wouldn't concentrate on this goal too early or at least with a clear focus on research. Shouldn't hinder the further development of jBPM itself! Again: I (or say we as camunda) would be interested in joining research activity in that field. We are very active in the field of BPMN and currently involved in some activities around it.
Workflow-Patterns: I wouldn't do too much effort in this, I see it a lot in universities, thesis and that stuff, but rarely in real life projects or evaluations.
Another thought: I get the feeling that currently a lot of experiences and thoughts of jBPM are not taken completely into account for some definitions.
Cheers
Bernd -
27. Re: Defining the API Mission
I have been working on a mapping (manual) from BPMN to JPDL as part of our Service Oriented Application Development Methodology. It is actually not that bad from a manual perspective.
-
28. Re: Defining the API Mission
Hi Jeff,
is it possible to provide some thoughts/material on this? If not in public, maybe at leas tin privat (bernd.ruecker@camunda.com)?
Cheers
Bernd -
29. Re: Defining the API Mission
Certainly, I will send out my description via email to yourself and the others participating in this discussion. I will also send the Eclipse projects BPMN models and associated JPDL models. I have been creating these examples in the Ganymede JEE version with SOATools BPMN Editor and JPDL Designer 3.1.3.sp2 nodeps (3.1.3 is not supported in Ganymede and I was was worried about conflict so I just used nodeps version. Seems to work for the most part, a few little quirks).
I would be very interested in feedback from you guys as well.
Jeff