I already mentioned in my earlier post “BPMN 2.0 takes dancing lessons – do we need choreographies?” that BPMN 2.0 will come with an additional way of modeling choreographies. The main novelty is that complex interactions and their refinement to message exchanges really move into the center of attention. In the earlier post I already argued why this style of modeling is actually a very good idea. It will likely bring a number of advantages over the old modeling style: choreographies can be created faster, can be understood more easily and modeling errors due to incompatibilities are avoided to a large extent.

On the other hand, this new choreography modeling style is not fully understood yet in terms of the new anomalies it will bring. Contributors to the BPMN 2.0 standard approached me already quite a while ago to have a look at race conditions that might arise in BPMN 2.0 choreographies. In the choregraphy space we are heavily dealing with asynchronous communication and we carefully have to consider what can go wrong if the partners act independently from each other.

This week I gave a presentation at the International Conference on Service-Oriented Conputing, held in Sydney, Australia. I talked about “Non-desynchronizable Service Choreographies” and addressed the following question: Given a BPMN 2.0 choreography (which basically gives the modeler the impression of a fully synchronous world) – does this choreography still make sense when moving to an asynchronous world? Do we introduce race conditions? If so: where? And: how can these race conditions be resolved in realistic scenarios?

To give it a sound mathematical basis we used Petri nets as underlying formalism for the considerations. Most BPMN constructs can easily be mapped to Petri nets and Petri nets are a well-understood formalism that allows very efficient formal verification.

The idea of desynchronizability is as follows:

  1. As input we take an interaction model (e.g. a BPMN 2.0 choreography) that “weakly terminates” (i.e. it is free of deadlocks and livelocks) and that is “realizable” (i.e. there exist a number of partners that collectively behave exactly like specified in the choreography – under the assumption of synchronous communication).
  2. We generate the role projection for all roles involved.
  3. We check whether the asynchronous composition of the role projections still weakly terminates. If yes, the initial choreography is desynchronizable.

While this approach might look like quite straightforward for those familiar with formal verification, it has a number of very positive points to it. First, it always locates the errors in the choreography. Second, it reuses well-known verification techniques that have already been implemented very efficiently.

All the details about this approach can be found in this pdf. You can also check out the implementation in Oryx, our web-based process modeling tool. Modeling BPMN 2.0 choreographies is already integrated into Oryx (although with a slightly different notation than used in the BPMN 2.0 proposal). For such choreographies you can then hit the “desynchronizabiligy checker” button.

Check out this example (Firefox required):Desynchronizability checking with Oryx