rocess-Aware Information Systems are concerned with the composition and coordination of services and resources within or across various domains. Examples of PAIS’s are Business Process Management (BPM), Business-to-Business (B2B) or Enterprise Resource Planning (ERP). The difference between BPM, B2B or ERP lies not only in the different application domains they target, but also whether the process is controlled by one control domain or more. Service composition can be seen from two main viewpoints: orchestration and choreography.

horeographies specify the observable sequence of messages used by businesses to exchange information with others. Participants in a choreography are peers, there is no center of control. Orchestrations specify the process being followed by an individual business or system within a domain of control. The separation between the internal aspects and the public aspect of system collaboration has two major advantages. First, businesses do not have to disclose their internal processing and data management mechanisms. Second, it decouples the observable sequence of message from its implementation within a domain of control.

The Choreography Description Language (WS-CDL) [15] has recently been adopted as the web service standard for choreography description. A WS-CDL specification describes the observable behavior of collaborations between services. It defines is a global contract between participants in terms of ordering conditions on message exchanges. WS-CDL is not a programming language; it is not executable. The orchestration viewpoint describes the behavior that a service provider performs internally within a collaboration. The Business Process Execution Language (WSBPEL) [16] is a programming language for implementing the execution logic of a business process based on interactions between the process and its partners. A WSBPEL process defines how multiple service interactions with partners are coordinated internally to achieve a business goal. Only one type of choreography can be executed with a single BPEL engine: master-slave choreographies. The BPEL engines controls all message exchanges between partners.

WS-CDL is used at design time to define a mutual contract between services that are under the supervision of different domain controllers. Each party can then use the global definition to build internal solutions that conform to it. Participants can also use the choreography specification to verify internal processes are conforming to a global choreography. At runtime, it can be used to detect exceptions. The implementation of the internal process is decoupled from the global contract, and can evolve independently of the other control domains. Nevertheless, the process of modifying a choreography is very painful. Business analysts of the different organizational domains have to agree on a new global contract before local executable processes can be deployed.

ecentralized compositions implemented using the CDL+BPEL model are very inflexible. The global contract between the different service providers is expressed at a very low level. The contract rules do not define what is allowed within the collaboration or not in terms of collaboration semantics. They are rather expressed in terms of the observable sequence of messages. Once the global view has been agreed on, it is very hard to change it, even if the modification does not violate any essential property of the involved parties.

These restrictions prohibit the establishment of on-demand cross-domain collaboration. Ideally, the contract between participants could be specified in a form that is independent of particular applications. They could specify what kinds of collaborations are allowed between domains independently of the specific message sequences, so that cross-domain applications can evolve without requiring new agreements to be negotiated between parties.

Some service collaborations only make sense in a particular context, and have a short life cycle. It is therefore unpractical to require the involved domain controllers to reach an agreement for the sole purpose of a choreography that has a limited number of users, or a very short life cycle. Hence, there is a need for mechanisms that support dynamic deployment and refinement of distributed collaboration.

On-demand distributed service composition requires some sort of executable choreography language. An executable choreography is not a contract that needs to be agreed on anymore, but it is an executable service composition that is controlled by the partner that initiates the collaboration application. Making choreographies executable requires the capability to delegate control over a business process to the composition partners of the process. In real world scenarios, domain controllers do not want to execute foreign composition logic. As a consequence, service composition are more sequential that they could be, BPEL-based master-slave composition is still the stateof- the-art service composition approach, and RPC is still the most common service interaction mechanism.

The position of the authors is that a flexible solution to distributed composition is mandatory for true on-demand service composition. Service-Oriented Architecture (SOA) is not only about providing resources on demand, but also about resource connectivity and the establishment of service collaborations on-demand. It should be possible to dynamically distribute any service composition that can be defined using the master-slave BPEL approach in a safe way.

Distributed composition requires the contracts between the participant domains to be defined at a higher level of abstraction that leaves more space to the dynamic establishment and refinement of collaborations. The contracts would not be encoded in terms of particular message exchanges, but would tell more about the semantics of the relationships between domains. Business rules would specify what kind of relationships between domains are allowed or are not allowed.