Personally I think there is a little to much emphasis on BPMN and the workflow patterns, unless it really is the intention to support them (both the patterns and bpmn)
According to http://is.tm.tue.nl/research/patterns this is the old site and contains older patterns.
The newer site http://www.workflowpatterns.com/patterns/control contains many more patterns. The older ones are already supported by jBPM as you can see in the testcases. I started working on the newer ones about a year ago, but stopped after a published report about limited support in jBPM. Tom has a different opinion about the way they should be supported compared to the authors of the (academic) papers.
So we should either put a lot of effort in the patterns to get jBPM on http://www.workflowpatterns.com/vendors or pay less attention to them.
The same is true regarding BPMN.
We will look at various options of bringing the aspect of execution to the BPMN model. Ultimately we will have BPMN conform process model that can somehow be executed on the ProcessEngine
If this really is the case, JBoss should put it's foot where it's mouth is and act on it. Just stating it gives a bad impression and unrealistic expectations. So a 'roadmap' for this is important.
But besides this 'comment' I think the additional work you (and Heiko) do is great.
The older ones are already supported by jBPM as you can see in the testcases.
Personally I think there is a little to much emphasis on BPMN and the workflow patterns, unless it really is the intention to support them (both the patterns and bpmn)should not have been in the post. After re-reading the wiki pages and looking at the sourcecode, I now get the real intention.
I haven't been able to take a look at the source, but supporting BPMN certainly is interesting since I get this question sometimes.
Making BPMN executable is something that is discussable... but as I said I haven't checked the source so I'd like to wait until then ;-)
Personally I think there is a little to much emphasis on BPMN and the workflow patterns
The situation with jbpm-3.2.3.GA and below is that there is no stable public API defined for it. As a result, application code depends on implementation detail that might change without prior notice between releases.
To fix this we are going to define a BPM API which is going to be the standard of how you work with BPM in JBoss.
i don't see this as a problem that needs to be fixed.
all the architectural set up is required and will be kept. there are only 2 things missing and that need to be added in another iteration:
1) is a session facade that sits in front of the object model. it will be based on commands and we should be able to cover 95% of the API use cases with that.
2) the domain model itself needs to get interfaces so that implementation methods don't have to be exposed. currently this is done in the pvm (still completing the test suite update of that refactoring). i have established 3 separate interface views on the domain model: the external client api, the activity implementation api and the event listener api. These 3 views are mainly realized by 3 different types of executions that are used, exposing only the appropriate methods.
The API closely follows the BPMN 1-1 Specification. Doing so we leverage an established standard to describe Business Processes. The ProcessEngine executes that model.
Using BPMN is not a good idea. Most importantly is that we use names that are as clear as possible. We can use names from any process language or modelling notation, as long as it is unambiguous. In many cases, we'll need to establish our own names cause there is no standard with a proper name for it (mainly the runtime execution concepts) or the standards use the term in different ways. It's very hard to find unambiguous names in workflow land. I have already tried to do this in PVM, but I'm sure that improvements can be made.
Ultimately we will have BPMN conform process model that can somehow be executed on the ProcessEngine
No. We'll provide a single direction BPMN to jPDL export functionality.
http://processdevelopments.blogspot.com/2008/05/big-problems-ahead-for-bpmn-20.html explains how I see the analysis to implementation iterative process: An analyst can optionally produce an analysis diagram (BPMN) as input for the software automation requirements. Then the developers build an executable process that looks exactly like the analysis diagram. (sometimes business analysts are also capable of drawing the diagram part of an executable process) But once all tech details are added, an executable process is a piece of software and should be under control of developers. The added value comes from the fact that the developers how have a process based on a diagram that analysts can understand. The iterative development should only take place on the executable process. I don't think it is feasible/desirable to create round tripping between different analysis and implementation models.
Thats why I don't think we should pursue of making BPMN executable. It creates the false illusion that analysis models automagically can be made executable. That is a false promise that many BPM vendors promote and that gives BPM its bad reputation. We get our recognition from being more modest but honest. The real value lies in building a process language that is very flexible in terms of diagram. Meaning that developers always need to be able to build an executable process that looks exactly like the analysis diagram.
Closely linked to BPMN 1-1 is a set of standard BPM Patterns.
They're not closely linked.
But You have convinced me that it might be worth while reviving the BPM patterns examples. I had given up on those as they are not clearly defined and the creators of the patterns were always finding new problems with the reports we created without being clear upfront.
What we surely can do is just post our own report, even if their validation might come to different results.
Relevance of BPM patterns has declined in the last years. 3-4 years ago it was a hot topic. So we should only do it if we can do it with minimal effort.
There are a number of BPMN editors available that allow you to draw BPMN conform process models.
* SOA Tools BPMN Editor
* Intalio Designer
We'll use the eclipse STP BPMN editor and add an export functionality to it.
What is expected to be stable, what is not?
API is one part. DB and process XML are two other very important aspects of stability/migration.
How is the correctness of the API verified?
That's what I'm now doing on the PVM. I don't think that is possible without actually building all the different patterns/features. Without enough coverage of the patterns implemented, you cannot know whether the runtime datastructure is rich and simple enough to handle all the cases. That describes the work I have been doing in PVM.
This iterative incremental approach cannot start from zero. The first iteration of the PVM API will definitely have to cover jPDL 3 concepts and feature capabilities. They might not all have to be implemented in full, but for sure, the runtime data structure must be able to handle all forms of process concurrency that we have in mind, sub process execution, timers and asynchronous continuations. All of those have a big impact on the API and you can't build a stable subset if you don't have proof on how you're going to deal with those features later on.
Wow Tom, seems like vacation has recharged your batteries ;-)
You do have some valid points though, and if all the ideas in this thread become reality...it will simply rock
Using BPMN is not a good idea. Most importantly is that we use names that are as clear as possible.
I understand that we don't want to try to morph BPMN into an executable language, but I don't understand your objection to using it as a conceptual basis for the API. Do you see a lot of mismatch between BPMN and JPDL? Or does it seem arcane? Or something else?
I understand that we don't want to try to morph BPMN into an executable language ...
Why shouldn't we? What's the problem with BPMN?