July 2008 - jbpm-dev - Jboss List Archives

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

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : Quoting Bruce Silver: | | anonymous wrote : | | 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-bp... | | 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-... 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164951#4164951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164951

17 years, 3 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

"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

17 years, 3 months

1
0
0 / 0

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

by alex.guizar＠jboss.com

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

17 years, 3 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

Quoting Bruce Silver: anonymous wrote : | 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-bp... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164837#4164837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164837

17 years, 3 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

anonymous wrote : I understand that we don't want to try to morph BPMN into an executable language ... Why shouldn't we? What's the problem with BPMN? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164836#4164836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164836

17 years, 3 months

1
0
0 / 0

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

by estaub

"tom.baeyens(a)jboss.com" wrote : | Using BPMN is not a good idea. Most importantly is that we use names that are as clear as possible. Tom, 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. Do you see a lot of mismatch between BPMN and JPDL? Or does it seem arcane? Or something else? Thanks, -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164827#4164827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164827

17 years, 3 months

1
0
0 / 0

[Fwd: Re: Project roles and responsibilities]

by Thomas Diesler

Folks, I laid out the Mission of the API effort in http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIMission The terminology that we can use to discuss the abstract API constructs is nicely defined by the BPMN standard. Here I put together a glossary of terms http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMNGlossary Much research has been done in BPM patterns that users of a BPM engine expect. These patterns I put together here http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMPatterns Of status of current support for these patters through the API is documented here http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedPatterns All this work really servers just a single purpose, which is to * clearly define what our mission is * lay out the path to follow in order to achieve that mission * have time bound milestones along the path (i.e. the release cycle) I hope that clarifies the BPM product direction and is an adequate basis from which individual tasks can be derived. cheers -thomas

17 years, 3 months

3
3
0 / 0

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

by jbarrez

Wow Tom, seems like vacation has recharged your batteries ;-) You do have some valid points though, and if all the ideas in this thread become reality...it will simply rock View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164668#4164668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164668

17 years, 3 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : How is the correctness of the API verified? That's what I'm now doing on the PVM. I don't think that is possible without actually building all the different patterns/features. Without enough coverage of the patterns implemented, you cannot know whether the runtime datastructure is rich and simple enough to handle all the cases. That describes the work I have been doing in PVM. This iterative incremental approach cannot start from zero. The first iteration of the PVM API will definitely have to cover jPDL 3 concepts and feature capabilities. They might not all have to be implemented in full, but for sure, the runtime data structure must be able to handle all forms of process concurrency that we have in mind, sub process execution, timers and asynchronous continuations. All of those have a big impact on the API and you can't build a stable subset if you don't have proof on how you're going to deal with those features later on. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164661#4164661 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164661

17 years, 3 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : What is expected to be stable, what is not? API is one part. DB and process XML are two other very important aspects of stability/migration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164660#4164660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164660

17 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev July 2008