"tom.baeyens(a)jboss.com" wrote : "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. | Yes, the api(s) (and cts) should be the result of this But regarding the supported languages... xpdl is with bull, as is bpel. They already decided on their own api correct? Mainly for backwards compatibility if i'm correct (and maybe the timing). How much are we going to take those into account? "tom.baeyens(a)jboss.com" wrote : | | "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. | Jeff deLong already did some work. I suggest that that is "verplicht leesvoer" (required reading material) for the meeting. But also the other way around. jPDL might have concepts that do not fit in BPMN. Extending it might be needed then. I'm currently also looking at the bpmn spec in more detail then I ever did and I more and more come to the conclusing that if we focus on the basic concepts to much, we might have to change the api again if more complex functionality is needed (intermediate events? and the corresponding triggers) but if someone proves me wrong, I'll be the first to admit that "tom.baeyens(a)jboss.com" wrote : | "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. http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-proc... See level 3 "tom.baeyens(a)jboss.com" wrote : | | "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. | Me neither, can you elaborate? One thing I have not heard people mention but what is a major issue (imo) is backwards compatibility or processdefinition upgrades etc (do we discuss those as well?). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180833#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...