-
15. Re: meeting context
Afaik, but could not find it directly, BPMN is based on structured graphs
Well, we just borrow the terminology (i.e. parallel gateway) and need think about what it means for the implementation. This is exactly the kind discussion I'd like to have.
In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split:
Exactly, hence the need for verification.
They leave it open, we decided to make a choice since it impacted implementation and there have not been real problems regarding this choice"heiko.braun@jboss.com" wrote:
What you said about previous discussions is something I don't agree with at all:
This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-)
Sorry, this statement was mend solely in the context of the nested fork/join"heiko.braun@jboss.com" wrote:
Let's put it the other way around: Why do all the vendors support workflowpatterns.com [1] and BPMN [2] opposed to jbpm?
[1] http://www.workflowpatterns.com/vendors/
[2] http://www.bpmn.org/BPMN_Supporters.htm#current
Ahh.....this is an interesting one... A really interesting one.... or even two (separate) interesting ones.
Lets get the facts and history straight on the first one.
[1] is 'old' and for the 'original' patterns. That is not very clear to people who are fairly new to these things.
I remember the discussions I had with Tom about the discussions he had with Prof. van der Aalst (I also personally met him twice on workflow non-related events) about the workflow patterns. jBPM 3.0 (look in the source for the pattern tests) engine wise supports them. JPDL language wise not (but most), at least not with writing some small reusable java classes.
They did not want to evaluate jBPM at that time due to the different views on things. They wanted everything in the 'language' while we said that basic things were supported in the language and less used things were possible in the engine with some small java code. In all these years there has been one pattern users in the forum asked me about (well actually two, but the implementation in jBPM is 98% the same, two multiple-instance patterns [3], and [4]. In the wiki we've described how that can be achieved in jBPM. Nobody complained. In fact, we are even more flexible, since these multiple instances can easily be assigned to different actors. But... I won't complain that they did not evaluate us (users in the forum did not, so who am I). We could have implemented language constructs for them, but it was a trade-off between time and the number of times it was requested. Therefore it was not done.
But.. things have changed a little. First of all, on the evaluation pages [5] of the workflowpatterns, they did evaluate jbpm [6]. With some of the patterns they now explicitly that they are supported with some java code. Regarding [3] they state:"workflowpatterns.com" wrote:
jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language
This has (in our opinion) never been a problem and the extensibility is part of jBPM thourgh JPDL.
Regarding [4] they state"workflowpatterns.com" wrote:
jBPM does not support this pattern. -
16. Re: meeting context
hmm.... post got cut off... here is the rest:
...
Which is down right incorrect. The difference in the required java code is one line, so at least the statement should have been the same. Just as with the milestone as I demonstrated in my blog. Second thing is that they evaluated 3.1.4 and we are already on 3.2.3, so the evaluation is even old in that regard.
I dare to say that from the control-flow patterns, almost all (and certainly the most used ones) can be easily implemented. And I (as does Tom I'm sure of that) never said or never had the intention that jPDL should not be extended with out of the box support, with real language constructs so without jBPM providing e.g. delegation classes. In fact, jBPM4 is a great moment to supprt more language constructs, certainly with the addition of you and Thomas to the team (remember, for me it just a hobby!!!)
Besides that, they also evaluated the standards and not even those support all of the patterns...
Nice BPMN related article in this regard is from Michael zur Muehlen on "how much BPMN do you need" [7]. If you take the 80/20 rule into account, I think jBPM did great, almost perfect, not with support of BPMN but the tradeoff for the 'patterns'
To make a long story short... it`s all in all not that bad maybe marketing wise, but we can work on that
Ok, now lets switch to BPMN. Up until a year ago, BPMN was not hot (not sure it is now, maybe it skipped the hype state and is going 'mainstream'). Some real business designers supported it. Besides that, there was no executable language so some other suppliers had converters, most one-way, some (limited) round-trip.
jBPM focussed (focusses) not only on the business designers but also at the people implementing the process (a joint-effort). BPMN was just to much overhead with the limited resources. Ok, the graphical representation could (should?) have been used for those parts that are supported in JPDL, but that should have been it.
The eclipse STP-BPMN desiger which is now becomming available might be interesting. Initially with an export function (although that should yield something really usable in the GPD) and maybe they can grow together and JBoss delivers an STP-BPMN-JPDL designer. Heck maybe even JPDL and XPDL grow closer
[3] http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp13.php
[4] http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp14.php
[5] http://www.workflowpatterns.com/evaluations/index.php
[6] http://www.workflowpatterns.com/evaluations/opensource/jBPM.php
[7] http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/
Shoot... I should have made this into a blog entry.... maybe I still will. -
17. Re: meeting context
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.system.project:roadmap-panel
... the remaining work load per individual with this report ...
https://jira.jboss.org/jira/secure/ConfigureReport.jspa?filterid=12312168&mapper=assignees&selectedProjectId=10052&reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&Next=Next
... and recent changes to the project here ...
http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Matrix/changes -
18. Re: meeting context
"heiko.braun@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. -
19. Re: meeting context
"heiko.braun@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. -
20. Re: meeting context
"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@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. -
21. Re: meeting context
"kukeltje" wrote:
Good discussion btw... lets keep it going, maybe the november meeting will be short then and we'll have lots of time to get used to kasteelbier ;-)
maybe we should *start* the meeting with a couple of kasteelbiers :-) -
22. Re: meeting context
"heiko.braun@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. -
23. Re: meeting context
"heiko.braun@jboss.com" wrote:
Let's put it the other way around: Why do all the vendors support workflowpatterns.com [1] and BPMN [2] opposed to jbpm?
[1] http://www.workflowpatterns.com/vendors/
[2] http://www.bpmn.org/BPMN_Supporters.htm#current
Workflow patterns are irrelevant.
Suppose that for every 100 downloads, there is one download done for an evaluation to see if jBPM is what they can use.
That means 200 evaluations per month. I assume that maximum 5 of those ever looked at the jBPM patterns evaluation.
So improving the evaluation experience is much more important then supporting workflow patterns.
Having that said; I do think that the current evaluation does not represents our capabilities properly. We can easily support them all. We should produce our own report in which we show how we support all of them in jBPM 4. But whether it is worth spending that time... i don't know. -
24. Re: meeting context
"thomas.diesler@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.system.project:roadmap-panel
... the remaining work load per individual with this report ...
https://jira.jboss.org/jira/secure/ConfigureReport.jspa?filterid=12312168&mapper=assignees&selectedProjectId=10052&reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&Next=Next
... and recent changes to the project here ...
http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Matrix/changes -
25. Re: meeting context
"thomas.diesler@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.system.project:roadmap-panel
... the remaining work load per individual with this report ...
https://jira.jboss.org/jira/secure/ConfigureReport.jspa?filterid=12312168&mapper=assignees&selectedProjectId=10052&reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&Next=Next
... 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 :-) -
26. Re: meeting context
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. -
27. Re: meeting context
"alejandro" wrote:
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.
Chapter 10 of the BPMN 2.0 draft specifies in about 15 pages the runtime semantics of BPMN. So the committee is clearly not agreeing with your point of view. ;-)
That being said, the specified semantics are described in natural language and thus very unclear and confusing. The execution semantics of an activity are *very* complicated. It is specified by a state diagram that contains no less than 20 nodes. It remains to be seen if such a complicated model will get a lot of supporters/implementers."ronald" wrote:
Afaik, but could not find it directly, BPMN is based on structured graphs
This is not completely true. BPMN allows for unstructured or 'free' graphs, multiple branches of sequence flow ending in random end events, etc. However, the earlier mentioned runtime semantics specify that some of these constructions are invalid (but of course this would only appear at runtime) as you can see in the following exerpt:The Inclusive Gateway is activated if at least one incoming sequence flow has at least one Token and for each empty incoming sequence flow, there is no corresponding Token in the graph anywhere upstream of this sequence flow, i.e. there is no path from a Token to this sequence flow unless the path visits a dominator or postdominator of a non-empty incoming sequence flow of the gateway
Aside from all this, I believe indeed that it would be good to discuss the different concepts as much as possible and see where we can 'borrow' from the spec. I saw that the new Choreography part is entirely optional and that the compliance part is still to be defined (if at all possible). So I am not sure how this is going to look when the spec goes final but I am hopeful that we will be able to comply somehow. -
28. Re: meeting context
I have not been following this dialog too closely, but just want to throw out some first hand experience with BPMN working on a project with a customer that plans to take the BPMN models and map them to jBPM. My role has been to review BPMN diagrams created by a third party subscontractor.
- it is very useful
- it does have a lot of symbols
- even with guidelines, many users (not just business users, but also developer types) use it in a fairly inconsistent manner
It will be a month or two before we map the BPMN diagrams to jPDL; I will let you know how well we do. -
29. Re: meeting context
discuss the different concepts as much as possible and see where we can 'borrow' from the spec.
+1
Discussion needs to start somewhere. The BPMN spec, besides it's limitations and probably justified concerns, is still something that had more people involved then JPDL ever will.
So, going through the core BPMN elements and comparing them to JPDL seems like a reasonable approach to me.