2006
On monday I spoke at the Open.BPM 2006 in Hamburg and exchanged ideas with a bunch of German academics. In contrast to typical Java conferences, ideas are challenged in amusing and heated debates. Great!
Overall, I was reinforced in my current perception of the BPM landscape:
- BPM vendors present process languages to the business users, but no runtime executional model, which causes great fragmentation in the market since no two BPM tools are similar.
- The academic approach is formal, but not very practical. Even while the constructs that they used are very simple, using petri nets or PI-calculus as a basis for process modelling is problematic. E.g. It took me 5 minuts to understand the basics of petri nets and it took me 20 minutes to understand the diagram that modelled a traffic light. That was a real masterpiece :-) But it indicates that creating and reading such models is not trivial.
- So the only way that these two worlds can come together is if they are able to define a rich set of business user constructs that can be translated into the formal semantics of PI-calculus, petri nets or something similar.
- For jBPM, process testability and refactoring over Java and process boundaries have higher priority then reasoning over process diagrams.
The most interesting discussion i had was with Frank Puhlmann of University in Potsdam. He's exploring PI calculus as a foundation for BPM modelling.
Exactly as stated above, Frank's vision is to define a set of coarse grained process constructs that are macro's made up of PI-calculus constructs. That way the coarse grained process constructs are intended for the business user and the translation to PI-calculus constructs can be used by the tools to calculate if the process is sane.
He considered PI calculus as better then petri nets because dynamic behaviour is added. Petri nets are static, whereas PI-calculus introduces a notion of reference that can be passed to other nodes in the graph. Then these references enable nodes to have dynamic bahaviour based on those references.
I think that his approach is challenging and I'm curious to see the results of that work. On the one hand, I would like to know what kind of business user constructs can be defined on top of PI-calculus constructs. Will the resulting process language be powerfull enough ? And on the other hand I'm curious what kind of information can be derived from algoritmic reasoning over PI-calculus constructs. Will it be worth while ? Will this information be interesting to the business user or the develop involved ?
If this approach turns out to be usefull in practice, it would fit really well with our Graph Oriented Programming approach. (Note that we're in the middle of reshaping this to a Process Virtual Machine) Basically what we define is a framework in which it becomes really easy to implement process constructs. So if your process language is made up of constructs that can be expressed in terms of PI-calculus, then all the reasoning could be enabled. Frank's work is based on pre- and postconditions. Which would imply that with each node implementation, the node developer could indicate the pre- and postconditions that are relevant for PI-calculus reasoning. That would make it easier for node implementors then translating their node into PI-calculus constructs.
For the jBPM foundations, testability and refactoring capabilities have a higher priority then reasoning over process models. I'm certain that the former two represent real value to developers that have to make the business processes executable. Also this makes process developement fit right into plain Java development. And reasoning still has to prove itself to be usefull in practice.
Just got back from the WfMC Standards Tutorial in Mainz, Germany. What a collection of Business Process Management (BPM) expertise ! It has been a long time since someone mentioned BPM to me without it being immediatly followed by BPEL. It turned out that the whole day gave a very clear picture that i've been preaching for a while as well: BPEL is good for service orchestration but is has got nothing to do with BPM.
I didn't go there for the tutorial, but more for meeting the people behind the WfMC and get a good feeling about the direction they are heading. Where before I was in doubt wether the organisation was pining away, I now saw that they are more alive then ever.
Updating XPDL 2.0 to make sure that you could get a lossless roundtrip from BPMN is a very clever move. Now THAT is a combination for BPM. For analysing and automating business processes, the featureset of BPEL doesn't even come close to the featureset of XPDL or BPMN. And that is an understatement: It's a different planet in another solar system is probably more appropriate.
This, of course, brings up a more nasty issue, in which WfMC might have done a better job in the past: PUBLIC RELATIONS. The WfMC has been overclassed and bypassed by the marketing around BPEL. With or without WfMC becoming better at markting, I am very confident that public perception of BPM will change quite soon. More and more people are realizing that BPEL is for service orchestration, not BPM. Too bad this often requires a desillusion and a lesson learned the hard way.
This BPEL-BPM link that was at the basis of the hype is now causing quite some controversy. Infoq gives a good summary of recent discussions. Most of this controversy boiles down to the discrepancy of what BPEL actually is (service orchestration) and what has been marketed for (BPM).
So you might got the impression that I don't really like BPEL. And yet... I LOVE BPEL ! There, I said it. I think that BPEL is well conceived, complete and does one thing well: SERVICE ORCHESTRATION. How many specifcations get that kind of credit ? For publishing new services as a function of other services, BPEL is the best technology out there. I even consider it very complete. That is why I'm NOT one of those who claim that BPEL is lacking task management and needs BPEL4People. Forget about BPEL being a solution for BPM. Basically, the lack of task management and perceived need for BPEL4People is only an illusion created by their own marketing efforts of promoting BPEL for BPM.
So if you ever see me bashing BPEL again, remember, it's not BPEL itself that I'm bashing, it's the BPEL-BPM marketing link that I'm trying to get rid of. Real BPM folks get really frustrated with that link. I actually have no idea how it came about that this link turned out more stubborn than a whole bunch of greenpeace activists in a rubber boat. Hopefully, we can drop the 'Real' soon as every business and IT person will start to see the difference.
There is one thing however that I think currently is missing and could be the next step for the WfMC: a conceptual execution model. A very complex term for something that would be same as the relational model for databases. Standardizing process languages presents a unified picture to the business analyst. But as the developer needs to add technical details to that process, a unified view upon the execution model is needed. On the process modelling side, there are indeed a number of metamodels (most notable efforts are the XPDL metamodel and BPDM) that describe the process definition terminology. But there is currently a complete lack of mindshare for the executional metamodel. That is all the data that represents the current state of a process execution and how this data is updated when a process executes. All the engines that I have seen so far just is one of a very few execution models.
There is another area where we (the whole BPM industry) needs to improve. Typically, the initiative to go for BPM technology comes from business management. The approach is that processes are developed with a BPM System (BPMS) and that a link can be made to other software components wherever necessary. I think this approach only works well in a limited number of situations. I am much more in favour of considering processes as a part of your overall software development effort. Process languages are just Domain Specific Languages (DSL) and should be integrated in your plain software development environment.
OK, but where is JBoss jBPM positioned in all of this ? First of all, JBoss jBPM is a platform for process languages. At the base there is a java library to define and execute graphs. The actual process constructs like e.g. send email, user task and update database are defined on top of this. Every process language is made up of a set of such process constructs. And that is what is pluggable in this base library. On top of the JBoss jBPM base library, we have implemented several process languages as a set of process constructs: jPDL, BPEL and SEAM pageflow:
- jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. There is no standard for Java process languages, so it is proprietary.
- BPEL is a service orchestration language. As said before, in BPEL, you can write new services as a function of other services. This is typically a component of an Enterprise Service Bus (ESB).
- SEAM pageflow is a language that allows for the graphically define the navigation between pages in a SEAM web application.
After the kind words for XPDL, Why is there no support in jBPM ? Good question. The answer is that we want XPDL support in the JBoss jBPM platform. It is be relatively easy to implement XPDL on top of our base library. But it didn't yet get any priority yet because of the extra indirection to Java, lack of adoption and its XML schema that is a little to verbose.
Lack of adoption could definitely change after people realize that XPDL is the standard for BPM and BPEL is the standard for service orchestration. Also, I still think a clean compact XML schema is important, but I don't consider this a showstopper any more. That only leaves XPDL language neutrality which, if you're working only on the Java platform, introduces an unecessary indirection. That could in fact also be considered as XML verbosity. So the conclusion is that there is not much left except for market adoption. You can help resolve that part by bugging our sales people and ask them about our XPDL support :-)
Overall, the visit to the WfMC Standards Tutorial was time well spend and I can recommend it to everyone that is involved with BPM in one way or another.
Actions
Filter Blog
By date: