[Design of JBoss jBPM] - Re: meeting context
by heiko.braun＠jboss.com
anonymous wrote :
| ... can you elaborate?
|
Let's take a different angle: This is not about the process definition language. (It's going to be pluggable anyway, right?)
Building an API doesn't necessarily mean throwing away what's there, it could as well mean refactoring the existing one.
The API will have core elements and terminology. Each core elements has associated semantics which lead to implementation detail. We want the API to be correct, easy to use and easy to learn.
The process of finding these core elements (or core concepts) and establishing names for them is important to get one step closer to 'correctness'.
The well known list of 'basic concepts', which Thomas suggested, is merely a collection of core elements that will lead to both a meaningful set of API that can represent of large number of use cases to begin with, but at the same time covers critical areas of the engine implementation. At least that's the idea. If the list is incomplete or the terminology is somehow misleading then make suggestions how it could be changed.
Again this doesn't necessarily mean we ditch the existing jBPM4 code base, it's merely a process of verification.
If the current code base would already have a precise and 'to the point' API, then we wouldn't need to do it.
Here's how I can picture the meeting:
We go through the list of core elements and for each of those we'll first discuss correctness and importance of that element in a BPM world and then secondly match it with jBPM4 elements. Either the BPMN expression is wrong to begin with or unnecessary for jBPM4 (no use case) then we can ditch it right away. But if it turns out to be important then it will either have a representation in jBPM4, just differently named or it requires changes to the code base.
But we'll start with a small set, and then gradually increase to the API until it is feature complete. In the beginning, the API would allow you todo everything jBPM4 is currently capable of, but sooner or later it will.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180960#4180960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180960
17 years
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"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#4180833
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180833
17 years
[Design of JBoss jBPM] - Re: meeting context
by camunda
For me, the most important point is really to sync everybody, so that we know in which direction we are heading (with jBPM4, PVM, BPEL, API-Proposal, BPMN, ...).
And I would like to discuss some of the proposals made here. For me, the strength of jBPM is simplicity, but beeing powerful at the same time. A lot of projects I have been in or at least know embed jBPM in their architectures/applications. For me it is crucial to conserve this! Some discussions or proposals in the direction BPMN/API were too abstract and theoretical in my opinion. jBPM has a long history, a bunch of experience and had some nice pragmatical approaches. That should be considered when discussing jBPM 4. There is a reason why the people like jBPM :-)
BPMN is indeed an important notation. But I would see the way to go more in a BPMN -> jPDL or a BPMN -> PVM mapping. The latter may be already close to an Executable BPMN. By the way: Executable BPMN is still heavily under research and not yet usable in practice. Good to keep up to date, but really rely on it completely is not the right track in my eyes. And at least it should be done during a real life project, not developed in the lab! My vote: The core engine should kept a simple state machine as it is now.
And I think these thoughts, where I know we have different opinions on the table ;-), need to be discussed first in the meeting, since that's the basis for everything else!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180817#4180817
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180817
17 years
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"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#4180793
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180793
17 years