It could be asked this question: Communicating processes have an analogy to communicating programs. In the eighties there have been quite some publications about this, including Milners Pi calculus. So how is the relation of BPMN choreography and this?
My answer would be, that the Pi Calculus is a Low Level desription calculus for processes that communicate with each other, messages and message channels. This serves the simulation and analysis. The choreography model and the collaboration model are more like a notation with metamodel covering the processes and the messages, but not the message channels. It is more for modeling than for analysis, although the model can be input to the analysis and the simulation.
Also every BPMN choreography model or collaboration model can be mapped to a Pi Calculus description, but not vice versa. Pi calculus is more general and has no notation. BPMN is guiding the modeling process and therefore easier to understand.
When one want to use the BPMN choreography model or collaboration model as input to a pi calculus conversion or a simulation and analysis, the quality of service contract needs to be specified before.
http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/quality-of-service-contracts/
(1) speaks also about Quality of Service Contracts. In my understanding these questions need to be answered: Is the service synchronous or asynchronous. If it is asynchronous, are there queues (serialization contexts) or not? If there are queues, which type of queues like exactly once in order (EOIO) or Exactly Latest (EL). Also the question is relevant which granularity do the queues have.
Why is this relevant? Why can this not merely be ignored as a technical detail of the implementation?
It can not be ignored at the time of design of a contract, because it determines the possible situations (states of the process) that may occur and that need to be resolved in the design of the contract which implies the ability to design choreographies.
To make an example. If it is only possible to update a sales order synchronously, then the contract needs not to be designed in a way to deal with a concurrent asynchronous cancellation of a previous sales confirmation, that might have happened in an asynchronous update scenario. And the resolution is not merely a technical resolution, but the resolution is better done on the business level – as for example discussed in (2). Therefore the QoS Contract implies needed resolutions on the business level – that need to be designed into the behavioral contract and into the syntactical contract.
Bibliography
1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).
Social Links