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

"heiko.braun(a)jboss.com" wrote : AFAIK the meeting is about the API and CTS, right? | That is a part of it. The first goal is to synchronize the whole team on the goals and strategy of jBPM 4 so that we're all aiming for the same thing. "heiko.braun(a)jboss.com" wrote : | - ProcessEngine, Process, ProcessDefinition | - StartEvent (None, Signal, Message) | - Task (None, Send, Receive) | - EndEvent (None, Signal, Message) | - Gateway (Inclusive, Exclusive, Parallel) | - Process, Activity Properties | - Process, Activity Assignments | - Signal, Message | - SequenceFlow | We can compare those concepts to jPDL, see how it is different. If the BPMN concept is different, we can see to what extend we want to support it in the jPDL language. "heiko.braun(a)jboss.com" wrote : This however is not married to BPMN it merely borrows terminology. Why? | Becasue BPMN terminology is very precise and avoids redundancy. | Existing jBPM/jPDL terminology is even more precise as that is executable. BPMN terminology is only described in words in the spec. "heiko.braun(a)jboss.com" wrote : All of these items do have associated semantics and it should be our first task to make sure everyone has same understanding of what this actually means. | The whole team already knows the exact semantics of jPDL. We should go over the BPMN concepts and see how we want to support this in jPDL. "heiko.braun(a)jboss.com" wrote : Starting off with the jbpm4 code base and API doesn't work because a successful discussion with all participants requires a certain level of abstraction. | i don't get this argument. "heiko.braun(a)jboss.com" wrote : We need to talk about what should be there instead of what is possible with the current implementation. | agreed! "heiko.braun(a)jboss.com" wrote : Once we agree on how these basic concepts relate to each other | (and I hardly believe that we manage to so in 3 days) then we could move on to topics that build upon that: | | Process dialects | - handling multiple process dialects | - extending process dialect elements | - extending the core engine capabilities | | Embeddability | - transactions | - persistence | - security | I don't see how we can split the discussion like that. I realize that for us, jBPM 3 to jBPM 4 is in incremental change, whereas for you and Thomas it is a lot of concepts and design decisions in one package. Every decision can be challenged. Even the decisions that potentially take away our foundations and cause us to review all the design decisions again. So far I have seen a lot of new and good ideas, but none of those challenge the basic fundamentals of the approach we took. So starting jBPM 4 development from scratch is something that I do not consider opportune. This can, of course, change when our approach is challenged (technically, conceptually or in any other way). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180793#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...