What is Web Service Choreography?
Whereas Web Service Compositions describe the local process of service orchestration, Web Service Choreography describes the observable interactions between services and their users. Choreography in general terms, and by dictionary definition, explores the wider aspects of interactions, often referenced by a similarity to arranging dance or ballet group sequences. The W3C Web Services Architecture group describe general choreography as “…the sequence and conditions under which multiple cooperating independent agents exchange messages in order to perform a task to achieve a goal state.” Whereas compositions are focused from a single service viewpoint and its interactions, choreography of a group of related services is the interaction to complete a broader scenario. Web Service Choreography is more formally described by the W3C Web Services Choreography Working group as; “….the external observable behaviour across multiple clients (which are generally Web Services but not exclusively so) in which external observable behaviour is defined as the presence or absence of messages that are exchanged between a Web Service and it's clients” (Austin 2004). In a series of scenarios, the messages that flow between web services and clients (which may be web services, but also applications or even human beings) may require a specific set of interactions to occur and to group these interactions for transactional or compensational reasons. Choreography is typically initiated by an external source (a client or service) and ends with a target service or a reply to the source. Such interactions during this choreography poses questions such as; can messages be sent and received in any order?, what are the rules governing the sequencing of messages? And can a global view of the overall exchange of messages be drawn? (i.e. can we verify, modify and monitor the behaviour)?
As BPEL4WS is aimed at addressing the interactions from a local process workflow and fault tolerance perspective, it does not exhibit observable state by which other web service compositions can respond to for a global service responsibility. The element in question is that of impact of state in wider composition invocations. If the composition is invocated from a local “master” controller (as currently modelled by the BPEL4WS invocation engine) state is not transferred between composition engines. The efforts necessary for effective workflow system analysis (Bolcer and Taylor 1998), the exploration of engineering these compositions is troublesome. In addition to state, the impact of introducing dynamic service selection in choreography increases the impact on complex engineering decisions at design time. For example, in a local problem domain, a dynamic discovery of an “Order Books Service” may be satisfied. Yet the same service hosted globally may not take into account local composition behaviour, or indeed, even synchronize with data managed by the local service. These are issues that should be recognized as a web service design compositional constraints and verified appropriately. Implementations for choreography standards are currently in the form of the Web Service Choreography Description Language (WS-CDL) (Kavantzas, Burdett et al. 2004) and the Web Service Choreography Interface (WSCI) (Arkin, Askary et al. 2002). Both of these specifications have been introduced as part of a service-oriented model aligned with the same W3C working groups.
Most recent W3C Choreography forum posts…
