tl;dr: at https://github.com/nlohmann/service-technology.org
This convoluted title is a result of multiple reviews I have been writing in the past on recent papers in the area of analyzing interacting processes. The problem comes in many forms and gets different names, depending on flavor of it.
- Collaborative processes or process collaboration: just several processes interacting with each other via message or data exchange, the assumption is that all processes are alreay designed to ensure the interaction goes error-free and achieves the desired goals. But that assumption is usually not met intially and the following 2 basic approaches to designing an error-free collaboration have emerged.
- Orchestration: several processes are given that “want” to collaborate or shall be composed to achieve a joint goal/execution, create an “orchestrator” processes that interacts with each of the processes individually and thereby ensures messages are passed between processes in the right order; the orchestrator knows the state of the global conversation between all processes.
- Choreography: several processes are given that “want” to collaborate or shall be composed to achieve a joint goal/execution, design the processes in a way that they can directly interact with each other (without an intermediate orchestrator) and achieve the goal; this may require to modify particular processes (change order of messages exchanged, send an additional message).
In the past these problems were studied under middleware systems (Corba), later then under the Web Services paradigm with BPEL4WS and WS-BPEL, and as collaborative processes under BPMN, and now under the umbrella of micro services and execution of distributed processes via blockchains.
I regularly review every year 2-3 papers in this space not aware of the fundamental problems of distributed behavior on choreographies and orchestrations (looking at you micro-services and blockchains), so this may help to catch up on missing knowlege and be aware of various tools that can already help in solving these problems.
The behavior of an individual process is often modeled with BPMN. The control-flow part of BPMN addresses (in some form) the same use case as Petri nets: modeling distributed behavior. Where you can see Petri nets as bare essence of concepts for distributed behavior (assembler level), BPMN has a sugar coated syntax for composite behavior. That means verification of BPMN is verification of behavioral properties. The standard technique that has extensive tool support are:
Behavior preserving translation from BPMN to Petri nets, see Dijkman, R., M. Dumas and C. Ouyang. “Semantics and analysis of business process models in BPMN.” Inf. Softw. Technol. 50 (2008): 1281-1294. https://www.semanticscholar.org/paper/Semantics-and-analysis-of-business-process-models-Dijkman-Dumas/4d4299bfd0ef670b2f913103b853f6394ed026a7
Or translate to Coloured Petri Nets (+timing and some data aspects kept within the orchestration process), see Meghzili, Said, A. Chaoui, M. Strecker and E. Kerkouche. “An Approach for the Transformation and Verification of BPMN Models to Colored Petri Nets Models.” Int. J. Softw. Innov. 8 (2020): 17-49. https://www.semanticscholar.org/paper/An-Approach-for-the-Transformation-and-Verification-Meghzili-Chaoui/d77b07092a7b7c550fda664ff83660f9060e567d
Then apply standard model checkers for verifying the behavior by checking absence of deadlocks (fast enough for edit-time verification in the editor), see Fahland, Dirk, C. Favre, J. Koehler, Niels Lohmann, H. Völzer and K. Wolf. “Analysis on demand: Instantaneous soundness checking of industrial business process models.” Data Knowl. Eng. 70 (2011): 448-466. https://www.semanticscholar.org/paper/Analysis-on-demand%3A-Instantaneous-soundness-of-Fahland-Favre/995fd8543d1b1547fd3f46a252d2fd2c4f4966f3
Or any linear-time temporal logic property of the behavior you are interested (by specifying LTL formulas over states in the BPMN/Petri net), see Wolf, K.. “Petri Net Model Checking with LoLA 2.” Petri Nets (2018). https://www.semanticscholar.org/paper/Petri-Net-Model-Checking-with-LoLA-2-Wolf/d73ec65c0d5e41016797eb3de71fa896597ab337
But the actual problem lies in analyzing and verifying and reasoning over the distributed compositions of processes, which is inherently a branching-time problem (not a linear-time problem). If you distribute the tasks in your process over multiple components, race conditions creep in and you can end up with non-local, uncontrolled choices and deadlocks. A process X cannot observe the internal steps of process Y, especially not decisions made within Y. X can only observe which messages it receives from Y and then infer in which state Y might be. However, Y may take steps/decisions that are not communicated to X, yet X has to make a decisions between two options and only one of the decisions will be compatible with how X progressed.
Some processes cannot be implemented in a distributed way: here is how to check & prevent these: Decker, G., A. Barros, Frank Michael Kraft and Niels Lohmann. “Non-desynchronizable Service Choreographies.” ICSOC (2008). https://www.semanticscholar.org/paper/Non-desynchronizable-Service-Choreographies-Decker-Barros/479c9e05aaa0ff7bad230b34b957036e2c8d4336
To avoid this during design you can create a top-down step-wise refinement of a global behavioral contract, along the way you use branching-time verification techniques to ensure your local component satisfies the global contract, see Aalst, W. V., Niels Lohmann, Peter Massuthe, C. Stahl and K. Wolf. “Multiparty Contracts: Agreeing and Implementing Interorganizational Processes.” Comput. J. 53 (2010): 90-106. https://www.semanticscholar.org/paper/Multiparty-Contracts%3A-Agreeing-and-Implementing-Aalst-Lohmann/8f97489373828b560aa2513a1f421afb9294f7b9
There’s much more that builds on this branching-time theory for modeling and verifying component behavior and composition:
- deciding and computing valid substitutions of one component by another, see Stahl, C. and K. Wolf. “Deciding service composition and substitutability using extended operating guidelines.” Data Knowl. Eng. 68 (2009): 819-833. https://www.semanticscholar.org/paper/Deciding-service-composition-and-substitutability-Stahl-Wolf/bfaa1aba6c7d54671d1abd89fcb880b12a11ef03
- repairing ill-defined components by finding behaviorally similar components (edit-distance-based) that satisfy the desired properties, see Lohmann, Niels. “Correcting Deadlocking Service Choreographies Using a Simulation-Based Graph Edit Distance.” BPM (2008). https://www.semanticscholar.org/paper/Correcting-Deadlocking-Service-Choreographies-Using-Lohmann/9c40607ff15f0bcde40cf33ec0acf72a714cf0a4
- automated test case generation to run tests against the implementation of your distributed process, see Kaschner, Kathrin and Niels Lohmann. “Automatic Test Case Generation for Interacting Services.” ICSOC Workshops (2008). https://www.semanticscholar.org/paper/Automatic-Test-Case-Generation-for-Interacting-Kaschner-Lohmann/0ff350a679d623f47ae9243ccae9847ee4e662a3
Most of these techniques and solutions rely on two base techniques
- Given a process X (or a partial composition of processes X = X1+…+Xk) construct/synthesize a controller (or partner process) Y that triggers the steps in X or sends/receives messages to trigger steps in X so that X achieves its goal (terminates in a goal state). This is called controller synthesis or partner synthesis and you can synthesize most permissive controllers (that allow as much behavior as possible in X) or specific controllers. Controller synthesis is highly efficient as it can use state-space reduction techniques of modern model checkers to explore only a limited part of the state-space. Controllers of large process compositions can be synthesized in millseconds to seconds, see Lohmann, Niels and D. Weinberg. “Wendy: A Tool to Synthesize Partners for Services.” Fundam. Informaticae 113 (2011): 295-311. https://www.semanticscholar.org/paper/Wendy%3A-A-Tool-to-Synthesize-Partners-for-Services-Lohmann-Weinberg/fb75ab94d2324c773aa1b56876af5059e9e21da5
- Given a process X (or a partial composition of processes X = X1+…+Xk) construct/synthesize a specification S of all controllers/partners for X. The specifiation is the most permissive controller of X annotated with which subsets of behavior are also controllers/partners of X. The specification S is expensive to compute, but after it has been computed all kinds of controllers/partners of X can be derived in linear time from S and it can be checked whether any independenly designed process Y can be composed with X. Lohmann, Niels, Peter Massuthe and K. Wolf. “Operating Guidelines for Finite-State Services.” ICATPN (2007). https://www.semanticscholar.org/paper/Operating-Guidelines-for-Finite-State-Services-Lohmann-Massuthe/4c77ebfb82857802a87d578b3fa83405c33b49e0
All these techniques were implemented in various (efficient) open-source prototype tools presented and hosted on http://www.service-technology.org which is currently offline. The internet archive still has a snapshot https://web.archive.org/web/20181228162401/http://service-technology.org/ but the tools are no longer available.
Luckily, the entire source code repository of all service-technology.org tools has been cloned to GitHub: https://github.com/nlohmann/service-technology.org, making them available to the current generation of research on this topic.







