"heiko.braun(a)jboss.com" wrote : So instead of naming it a decision, you could call it exclusive gateway right away. The reason why I prefer BPMN glossary over jBPM terms is that these people did a good job finding terminology and add short, descriptive explanations to the core concepts. | First, I think you overrate the BPMN spec as the final thing that concludes the battles in BPM. Second, API mainly deals mostly with runtime constructs. BPMN deals with process definition constructs. Third, for the simple constructs like exclusive gateway it is possible. But the more complex you go, the harder it will be to map the analysis constructs to implementation constructs. Only if the direction for BPMN 2.0 would be to add exact executable semantics to BPMN, then it would become a viable option to make sure we cover all the constructs. Forth, if BPMN becomes executable, then we should do that as a separate language. (maybe as a jPDL variant, depending on how close it is) If we take BPMN as a basis in the API, then we introduce a mismatch between XPDL and BPEL, both of whom are also supported on the PVM and those also have their own naming scheme. "heiko.braun(a)jboss.com" wrote : | Whereas in the PVM, we still have 3 or 4 kinds of "Executions". | Can you elaborate on this ? Different views on an execution were introduced to provide proper interfaces in each use case. You helped to induce that change. We changed from offering all methods and throw an exception when a user invokes an invalid one, to only offer the appropriote methods in the different use cases of an execution. I don't yet see the relation with this post. "heiko.braun(a)jboss.com" wrote : If we could manage to become explicit in our jBPM4 terminology the same way, then I wouldn't complain. But currently I see a 200 pages document with very precise terminology (BPMN) and a redundant, hard to understand API (PVM) which is only obvious to it's inventor. | | So give me one good reason why we should chose the hard way and try to be superior to the BPMN spec leads and come up with something on our own. Because BPMN is not doing the same thing as what we're doing. We're defining a framework for building state machines and executable process languages. BPMN defines a process modelling notation. Some of the languages that can be implemented on PVM even have a more technical background that is not always related to BPM: pageflow, programmatic state machines, naked BPEL. So that is why I think it is better to have a naming scheme that is neutral to all the targetted specs, patterns and languages out there. The API naming convention is important, but IMHO, there are much more important debates to have: 1) The runtime data structures. Those determine which control flow constructs can be build on it. 2) Do the PVM runtime structures cover the BPMN interpretations. For each possible runtime interpretation of BPMN constructus, can we build executable constructs for it on the PVM. This again boils down to the runtime data structures. When it comes to the power of a BPM/workflow engine, then mostly, your discussing the capabilities of the runtime datastructures. (In)validating those is more important then the API naming scheme. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166911#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...