[Design of JBoss jBPM] - Re: meeting context
by alex.guizar＠jboss.com
First and foremost I believe that evaluating and incorporating BPMN terminology and semantics into the product is generally positive. People at conferences and courses often ask about it and it would be good to have a concrete story to tell.
That said, BPMN is far from feature complete. Even if it provides a visual notation and semantics it does not (and should not) define an execution model. Hence BPMN should be an influence and not an objective.
Second, regarding the API, I believe that making it useful for any process language is an exercise best suited for research rather than practical applications. The differences between process languages are being somewhat downplayed to the point of calling them dialects. For example, you do not normally interact with a BPEL process through an API to begin with. You interact it through the WSDL interfaces defined by the process author.
However, a generic API to cover the common subset of all process languages is certainly desirable and in fact already exists in the PVM.
I think the meeting should be about the specific API to cover the features of our preferred process language.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181317#4181317
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181317
17 years, 5 months
[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
17 years, 5 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
17 years, 5 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
17 years, 5 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"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
|
Indeed we need to go over those concepts and establish a common vocabulary.
But the complexity of the process constructs does not have to influence the client APIs (and service APIs).
The concepts that are exposed in the Activity API do have a direct impact on what kind of process constructs you can build. That exposes e.g. the tree of executions to an activity implementation.
"kukeltje" wrote : Basic things I did do with 'the api' are
| - start a process
| | - end a process
| | - signal process to continue (either via default or supplied transition)
| | - set a variable
| | - read variable
| | - get a tasklist
| | - end a task
| | - get basic properties of a task/node/.... in a process instance (e.g. task.hasEnded())
| | - ...
| |
This lists indeed the typical basic client API operations. This is the most important interface to get right as this is the first interface that every project using jBPM will be using. And it is unrelated to the complexity of the process constructs.
The client API can be developed in the simple-to-complex fashion. Adding new capabilities typically does not influence the previous features that you've build.
The event listener API is used in most projects and activity API is only used rarely by our users. But i agree that even for those API's it would be good if we could keep them minimal and stable.
For the activity API, the simple-to-complex development strategy does not prevent big changes to the public API. Different forms of concurrency might lead to a different structure of the runtime data. (e.g. changing the tree of executions in a map of activity instances). Such changes have a big impact on the whole activity API and when such a change happens, you'll need to rewrite all the activities.
It is in that context that I have been building the PVM over the last two years: shaping the runtime data structure and verifying that all kind of process constructs can be build on top of it.
But no matter how long I worked on it and how much of these discussions I already had with the Bull people, I still think it is good to have these concepts reviewed and challenged in the group.
The discussions on process constructs should however not take up the full team meeting. Our history shows that out-of-the-box support for the different patterns/constructs has not been a critical success factor. Still I want to improve a on that. (we basically only miss the concurrency pattern that ronald mentions: unstructured forks and joins, which is easy to implement)
As mentioned before, apart from the process constructs capabilities, there are the rest of the API concepts like ProcessEngine, Configuration, event/signal/log,and so on. Those things can even more use a good review and debate.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181177#4181177
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181177
17 years, 5 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : 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'.
|
I agree with easy to use and easy to learn.
But I also think that correctness is always in the eye of the beholder. Meaning that everyone that is involved with some process engine has a certain background and sees certain use cases it. That background and target use cases determine what is considered as correct. I don't think we'll be able to find BPM concepts that are considered worldwide and generally correct.
So we need to make our background as explicit as we can. We need to define our targets and use cases as clear as we can. If we agree on those, then our conclusions and the BPM concepts we consider good should be close enough to have fruitful discussions in the meeting.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181171#4181171
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181171
17 years, 5 months