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.