Service choreography

Service choreography is a form of service composition in which the interaction protocol between several partner services is defined from a global perspective.The idea underlying the notion of service choreography can be summarised as follows:'Dancers dance following a global scenario without a single point of control' Service choreography is a form of service composition in which the interaction protocol between several partner services is defined from a global perspective.The idea underlying the notion of service choreography can be summarised as follows: That is, at run-time each participant in a service choreography executes its part according to the behavior of the other participants. A choreography's role specifies the expected messaging behavior of the participants that will play it in terms of the sequencing and timing of the messages that they can consume and produce. Choreography describes the sequence and conditions in which the data is exchanged between two or more participants in order to meet some useful purpose. Service choreography is better understood through the comparison with another paradigm of service composition: service orchestration. On one hand, in service choreographies the logic of the message-based interactions among the participants is specified from a global perspective. In service orchestration, on the other hand, the logic is specified from the local point of view of one single participant, called the orchestrator. In the service orchestration language BPEL, for example, the specification of the service orchestration (e.g. the BPEL process file) is a workflow that can be deployed on the service infrastructure (for example a BPEL execution engine like Apache ODE). The deployment of the service orchestration specification transforms a workflow into a composite service. In a sense, service choreography and orchestrations are two flips of the same coin. On one hand, the roles of a service choreography can be extracted as service orchestrations through a process called projection. Through projection it is possible to realize skeletons, i.e. incomplete service orchestrations that can be used as baselines to realize the web services that participate to the service choreography. On the other hand, already existing service orchestrations may be composed in service choreographies. Service choreographies are not executed: they are enacted. A service choreography is enacted when its participants execute their roles. That is, unlike service orchestration, service choreographies are not run by some engine on the service infrastructure, but they “happen' when their roles are executed. This is because the logic of the service choreography is specified from a global point of view, and thus it is not realized by one single service like in service orchestration. The key question which much of the research into choreography seeks to answer is this: Suppose a global choreography is constructed that describes the possible interactions between the participants in a collaboration. What conditions does the choreography need to obey if it is to be guaranteed that the collaboration succeeds? Here, succeeds means that the emergent behaviour that results when the collaboration is enacted, with each participant acting independently according to its own skeleton, exactly follows the choreography from which the skeletons were originally projected. When this is the case, the choreography is said to be realizable. In general, determining realizability of a choreography is a non-trivial question, particularly where the collaboration uses asynchronous messaging and it is possible for different participants to send messages simultaneously. In the ambit of the specifications concerning Web services, the following specifications have focused on defining languages to model service choreographies: Moreover, the OMG specification BPMN version 2.0 includes diagrams to model service choreographies.