[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"thomas.diesler(a)jboss.com" wrote : Yes, a good result of the meeting would be a set of API interfaces/classes that everybody can agree on plus a set of CTS test cases that exercises the API.
|
| The 1-Jan-2009 jBPM4 release should then provide an implementation of that agreed API.
|
| In Jan we meet again and set the scope for 1-Mar and so on ...
|
| If we can stay focused on correctness and ease of use of the API it will be possible to move quickly and enlarge the scope of functionality for given release cycles. This will hopefully rather sooner than later lead to a jBPM4 release that can replace the current jBPM3 product.
|
| The replacement criteria (and I say it again) is a product that passes the CTS through the API. The functional scope of that product must be at least that of jBPM3.
|
| Key to good progress is to stay focused on what can actually get achieved in a given release cycle plus delivery on an unconditional basis.
|
| A good indicator of this "we will deliver as promised" principal, is the upcoming jBPM-3.3.0.GA release. The team succeeds if promised functionality is unconditionally available by a certain date, sufficiently documented and properly integrated in automated QA.
|
| You can monitor progress on the JIRA road map panel
|
| https://jira.jboss.org/jira/browse/JBPM?report=com.atlassian.jira.plugin....
|
| ... the remaining work load per individual with this report ...
|
| https://jira.jboss.org/jira/secure/ConfigureReport.jspa?filterid=12312168...
|
| ... and recent changes to the project here ...
|
| http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Matrix/changes
|
|
I agree 100%
Staying focussed on the core functionality without diverting into all kinds of nice cool things which are not crucial for the next release will be hard for me.
But I have full faith that you will be our Moses that leads us to the promised land :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181191#4181191
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181191
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently? The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API.
|
indeed. the crucial factor here is the runtime data structure which is exposed in the activity API.
FWIW, jPDL 3 now has only 1 fork/join strategy and that is not the most common one. The motivation for the jPDL 3 fork-join design was that it also could handle nested fork/join combinations.
The most common fork join is one which just counts the tokens/executions in the join. In that case the unstructured fork/join combination (as ronald indicated graphically) works, but then nested fork/joins become a problem.
So my current intention is to have multiple types of forks and joins in jPDL4. We also might spend some time thinking if we can combine both forms. I have some ideas, but it's not all clear to me whether to what extend this is possible.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181185#4181185
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181185
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"kukeltje" wrote : Maybe we should have two api's per 'language', one basic that is common across process/workflow languages and an advanced one specifically for a language. For jpdl, the advanced api can be the jbpm api that is currently there. I'm just not sure though how pageflow, threadcontrol will fit in thebasic api (terminology wise) if that is a goal at all.
|
"heiko.braun(a)jboss.com" wrote : Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
|
| - One for building a process model from XML descriptors
| (Similar to what's in the PVM already)
| - One for invoking on it (Client API)
| - One for extending the engine capabilities (i.e. new node types)
| - One to solve integration problems (TX, persistence, etc)
|
I think it is possible to have 1 API for all PDLs. Which would be a real achievement, given the diversity of languages that we try to cover. Let's discuss the tradeoffs in the meeting.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181179#4181179
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181179
16 years, 3 months