Service choreography

This article may be confusing or unclear to readers. Please help clarify the article. There might be a discussion about this on the talk page. (April 2010) (Learn how and when to remove this message)

Service choreography in

That is, at run-time each participant in a service choreography executes its part according to the behavior of the other participants.[2] 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.^[3]

Choreography describes the sequence and conditions in which the data is exchanged between two or more participants in order to meet some useful purpose.^[4]

Service choreography is better understood through the comparison with another paradigm of service composition:

In a sense, service choreography and orchestrations are two sides of the same coin. On one hand, the roles of a service choreography can be extracted as service orchestrations through a process called projection.[6] 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.^[7] 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.^[8] 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

• Pi calculus
• Web Service Choreography Interface (WSCI) is an XML-based specification that was put forward to the
  Web Service Choreography Description Language (WS-CDL)

Moreover, the

• Let's Dance[10]
• BPEL4Chor^[11]
• Chor^[12][13]

Moreover, a number of service choreography formalisms have been proposed based on:

• Petri Nets, for example Interaction Petri Nets^[14] and Open Workflow Nets^[15]
• Finite-State Machines^[16]
• Guarded Automata^[17]
• Timed Automata^[18]
• Pi calculus^[19][20][21]
• Process calculi^[22][23]

Web service choreography (WS-Choreography) is a specification by the

The main effort to get a choreography, The W3C Web Services Choreography Working Group, was closed on 10 July 2009[24] leaving WS-CDL as a Candidate Recommendation.

"Many presentations at the W3C Workshop on Web services of 11–12 April 2001 pointed to the need for a common interface and composition language to help address choreography. The Web Services Architecture Requirements Working Draft created by the Web Services Architecture Working Group also lists the idea of Web service choreography capabilities as a

The problem of choreography was of great interest to the industry during that time; efforts such as WSCL (Web Service Conversation Language) and WSCI (Web Service Choreography Interface) were submitted to W3C and were published as Technical Notes. Moreover, complementary efforts were launched:[25]

• BPMN
• BPSS by ebXML [2]
• WSFL by IBM
• XLANG by Microsoft
• BPEL4WS
  by IBM, Microsoft and BEA

The academic field has put forward other service choreography languages, for example Let's Dance,[10] BPEL4Chor^[11] and MAP.^[19]

Service choreographies specify message-based interactions among participants from a global perspective. In the same way as

• Interaction modelling: the logic of the choreography is specified as a workflow in which the activities represent the message exchanges between the participants
  Web Service Choreography Description Language (WS-CDL) and Let's Dance^[10]
  )
• Interconnected interfaces modelling: the logic of the choreography is split across its participants through the roles they play (i.e. their expected messaging behavior). The roles are connected using message flows, channels, or equivalent constructs[28] (this is for example the case of BPEL4Chor^[11])

There are several active research projects on the topic of service choreography.

• CHOReVOLUTION: Automated Synthesis of Dynamic and Secured Choreographies for the Future Internet
• CRC: Choreographies for Reliable and efficient Communication software
• SwarmESB - a light, open source, ESB or message hub for node.js
• PrivateSKY - experimental development in public-private partnership for local cloud platforms with advanced data protection features

• Choreographic programming - A programming paradigm where programs are choreographies.
• BPEL
  - Business Process Execution Language, OASIS standard
• Executable choreography
• Service composability principle
• W3C