www sensoriaist eu Choreography Orchestration and Contracts Languages

Plan of the Talk An “open” world of services u Service composition u n

An “open” world of services u Service Oriented Computing is used to design systems

Let us organize problems… u Not only the issue of inter-operability (computing across different

An Example: Web Services -1 - -2 FIND SERVICE PUBLISH SERVICE -3 - SOAP

Buying an electronic ticket u Web search engines u Public advertisements u Friends u…

Buying an electronic ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticket request ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticketing service 1 no ticketing service 2 ticketing service n

Buying an electronic ticketing service 1 ticketing service 2 no ticketing service n

Buying an electronic ticketing service 1 ticketing service 2 request ticketing service n

Buying an electronic ticket [using an orchestrator]

Buying an electronic ticket [using an orchestrator] request orchestrator

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticketing service 2 orchestrator

Buying an electronic ticket [using an orchestrator] ticketing service 1 request orchestrator request ticketing

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticket orchestrator ticketing service

Buying an electronic ticket [using an orchestrator] ticketing service 1 cancel ticketing service 2

Orchestration u The orchestrator provides a new “meta”-service u Central point of coordination: it

Orchestration Languages used to program orchestrators n n n XLANG: proposed by Microsoft in

XLANG: based on -calculus Start; Receive(req 1, req 2); ( ( Invoke(req 1)@srv 1;

WSFL: based on Petri-nets Receive(req 1, req 2) Invoke(req 1)@srv 1 Invoke(req 2)@srv 2

WS-BPEL: join XLANG and WSFL Start; Receive(req 1, req 2); ( ( Invoke(req 1)@srv

WS-BPEL u Join n the WSFL and XLANG approaches Combine Petri-nets and -calculus u

Choreography Languages u Specification language (not executable) u No central point of coordination n

Web Service Choreography Description Language u Describe the interaction among the combined services from

Similar to Specification of Chryptographic Protocols u Protocol for the request to a trusted

WS-CDL u Global view of service interactions Seller Buyer Bank

WS-CDL u Global view of service interactions Seller Request Buyer Bank

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Bank

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Payment

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Confirm

WS-CDL Request. Buyer Seller ; ( Offer. Seller Buyer | Pay. Descr. Seller Bank

BPEL 4 Chor u The WS-BPEL approach to choreography: n n Parallel composition of

Buyer-Seller-Bank example Seller Request Offer Buyer Pay. Descr Confirm Payment Receipt Bank Choreography, Orchestration,

Projection of the Choreography on the Single Participants Buyer: Invoke(Request)@Seller; Receive(Offer); Invoke(Payment)@Bank; Receive(Receipt) Seller:

WS-CDL vs. BPEL 4 Chor u Can we always project a WS-CDL specification in

A Formal Model for WS-CDL u. A global choreography language: H : : =

A Formal Model for BPEL 4 Chor u. A local choreography language: P :

The “canonical” projection u Projection [[ H ]]t of choreography H to participant t

Example u Consider the global choreography: ar s ; bt u u Projection: [

Asynchronous communication u Reconsider the example assuming asynchronous communication [ as ; b u

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming synchronous communication:

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming asynchronous communication:

What about the previous example? u Reconsider the example ar s ; br u

Main results u For n each observation criterion: Sufficient conditions (connectedness, unique point of

Unique point of choice u In n n a choice H+H’ The sender of

Which equivalence between global and local choreographies? u u Synchronous bisimilarity: global transitions are

Example: Receiver bisimilarity u Global choreography: ar s ; bt s u Local choreography:

Contracts [FHRR 04][CCLP 06] u Contract: service “behavioural interface” that describes n n the

Contract Compliance u Verification of correctness of service composition based on their contracts: successful

Service Compliance: Formally u Services are compliant if the following holds for their composition

Example: compliant services u The following pairs of services are compliant: n n n

Directly Checking Conformance w. r. t. Choreography is conformant for participant 1 to public

Compliance-Preserving Contract Refinement ! Choreography projection Contract Part. 1 refines public registry Contract compliant

First Relation: Contract Refinement Choreography Contract Part. 1 refines public registry Contract compliant by

Formally: Subcontract Preorder ≤ between contracts C: n C’ ≤ C means C’ is

Definition of Preorder Induced from Independent Refinement Given a set of compliant contracts C

No maximal subcontract preorder … in general u Consider the system: [a]|[a] we could

Maximal pre-order u It n n n exists changing some assumptions: Limiting the considered

Output persistence u Output persistence means that given a process state P: n If

Example u Given the choreography: Request. Alice Bob; (Accept. Bob Alice + Reject. Bob

“Standard” Contract Compliance u. A n n n second example: S 1: invoke(a); invoke(b)

“Standard” Contract Compliance u. A n n n second example: S 1: (invoke(a); receive(b))*

“Standard” Contract Compliance u. A second example: S 1: (invoke(a); receive(b))* n S 2:

Example: strong compliant services u The following pairs of services are strong compliant: n

“Strong” refinement u It allows also refinement on names already in the interface: Receive(a);

Summary of Results u Refinement with knowledge about other initial contracts limited to I/O

Future work u Apply contract theory to real orchestration languages n JOLIE: Java Orchestration

Related work u Carbone, n n n Honda, Yoshida Global and End-point calculus similar

Related work u Fu, n n n Bultan, Su Service systems with message queues

Related work u Padovani n n et al. Contracts described with an ad-hoc transition

Related work u van n n der Aalst et al. Contracts described with open

References u u u N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G.

Slides: 123

Download presentation

www. sensoria-ist. eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http: //cs. unibo. it/~zavattar Based on joint work with: Department of Computer Science University of Bologna Mario Bravetti, Claudio Guidi, Ivan Lanese, Fabrizio Montesi

Plan of the Talk An “open” world of services u Service composition u n n u Contract-based service discovery n n n u Orchestration (bottom-up) Choreography (top-down) Output persistence Strong Compliance Message Queues Conclusion and future work

An “open” world of services u Service Oriented Computing is used to design systems working in a heterogeneous and open environment where services: n n may appear and disappear may not be realiable/trustworthy can be located worldwide are subject to communication via network that can cause delays, failures, …

Let us organize problems… u Not only the issue of inter-operability (computing across different platforms): n n Loose coupling: computing across enterprise boundaries (when you use a service you must account for possible deviations from the expected behavior) Open endedness: new services can enter, and old ones leave, while computation proceeds (you should dynamically re-build your system at run-time)

An Example: Web Services -1 - -2 FIND SERVICE PUBLISH SERVICE -3 - SOAP n n n WSDL (interface definition language) UDDI (service discovery) SOAP (service invocation protocol)

Plan of the Talk An “open” world of services u Service composition u n n u Contract-based service discovery n n n u Orchestration (bottom-up) Choreography (top-down) Output persistency Strong Compliance Message Queues Conclusion and future work

Buying an electronic ticket

Buying an electronic ticket u Web search engines u Public advertisements u Friends u… or colleagues

Buying an electronic ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticket request ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticketing service 1 no ticketing service 2 ticketing service n

Buying an electronic ticket request ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticketing service 1 ticketing service 2 no ticketing service n

Buying an electronic ticketing service 1 ticketing service 2 request ticketing service n

Buying an electronic ticketing service 1 ticketing service 2 ticketing service n

Buying an electronic ticket [using an orchestrator]

Buying an electronic ticket [using an orchestrator] request orchestrator

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticketing service 2 orchestrator ticketing service n

Buying an electronic ticket [using an orchestrator] ticketing service 1 request orchestrator request ticketing service n ticketing service 2

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticketing service 2 orchestrator ticketing service n

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticket orchestrator ticketing service n ticketing service 2

Buying an electronic ticket [using an orchestrator] ticketing service 1 cancel ticketing service 2 orchestrator cancel ticketing service n

Buying an electronic ticket [using an orchestrator] ticketing service 1 ticketing service 2 orchestrator ticketing service n

Orchestration u The orchestrator provides a new “meta”-service u Central point of coordination: it invokes several “sub”-services u The client of the “meta”-service interacts only with the orchestrator

Orchestration Languages used to program orchestrators n n n XLANG: proposed by Microsoft in 2001 WSFL: proposed by IBM in 2001 WS-BPEL (formerly BPEL 4 WS): proposed in 2002 by a consortium including IBM, Microsoft, SAP, BEA, …

XLANG: based on -calculus Start; Receive(req 1, req 2); ( ( Invoke(req 1)@srv 1; Reply(req 1) ) | ( Invoke(req 2)@srv 2; Reply(req 2) ) ); End

WSFL: based on Petri-nets Receive(req 1, req 2) Invoke(req 1)@srv 1 Invoke(req 2)@srv 2 Reply(req 1) Reply(req 2)

WS-BPEL: join XLANG and WSFL Start; Receive(req 1, req 2); ( ( Invoke(req 1)@srv 1; Send(int. Link); Reply(req 1) ) | ( Invoke(req 2)@srv 2; Recv(int. Link); Reply(req 2) ) ); End

WS-BPEL u Join n the WSFL and XLANG approaches Combine Petri-nets and -calculus u Add mechanisms for event, fault, termination and compensation handling n n Timed events Long-running transactions

Choreography Languages u Specification language (not executable) u No central point of coordination n The composed services interact reciprocally u WS-CDL: proposed by W 3 C in 2004 u BPEL 4 Chor: recently proposed by researchers involved in WS-BPEL

Web Service Choreography Description Language u Describe the interaction among the combined services from a top abstract view Choreography (e. g. WS-CDL) Top abstract view of whole system: each action is a communication involving two of its participants Orchestration (e. g. WS-BPEL) One Party detailed view of the system that orchestrates a part of it by sending (to other parties) & receiving messages

Similar to Specification of Chryptographic Protocols u Protocol for the request to a trusted entity of the creation of a session key: Alice Trent: Trent Alice: Alice Bob: Alice, Bob {KAB}KA , {KAB}KB

Similar to UML Sequence Diagrams

WS-CDL u Global view of service interactions Seller Buyer Bank

WS-CDL u Global view of service interactions Seller Request Buyer Bank

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Bank

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Payment Bank

WS-CDL u Global view of service interactions Seller Request Offer Buyer Pay. Descr Confirm Payment Receipt Bank

WS-CDL Request. Buyer Seller ; ( Offer. Seller Buyer | Pay. Descr. Seller Bank ) ; Payment. Buyer Bank ; ( Confirm. Bank Seller | Receipt. Bank Buyer )

BPEL 4 Chor u The WS-BPEL approach to choreography: n n Parallel composition of abstract WS-BPEL descriptions Abstract WS-BPEL: description of the externally observable message passing behaviour (opacifies internal details)

Buyer-Seller-Bank example Seller Request Offer Buyer Pay. Descr Confirm Payment Receipt Bank Choreography, Orchestration, and Contracts Barcelona - 3. 11. 2008

Projection of the Choreography on the Single Participants Buyer: Invoke(Request)@Seller; Receive(Offer); Invoke(Payment)@Bank; Receive(Receipt) Seller: Receive(Request); (Invoke(Offer)@Buyer | Invoke(Pay. Descr)@Bank); Receive(Confirm) Bank: Receive(Pay. Descr); Receive(Payment); (Invoke(Receipt)@Buyer | Invoke(Confirm)@Seller)

WS-CDL vs. BPEL 4 Chor u Can we always project a WS-CDL specification in an equivalent BPEL 4 Chor one? u Which kind of equivalences are preserved?

A Formal Model for WS-CDL u. A global choreography language: H : : = ar s | 1 | 0 | H; H | H+H | H|H | H*

A Formal Model for WS-CDL u. A global choreography language: H : : = ar s | 1 | 0 | H; H | H+H | H|H | H* r invokes the operation a of s Unsuccessful Successful termination

A Formal Model for WS-CDL u. A global choreography language: H : : = ar s | 1 | 0 | H; H | H+H | H|H | H* Sequence Choice Parallel Repetition

Structured Operational Semantics

A Formal Model for BPEL 4 Chor u. A local choreography language: P : : = a | ar | 1 | 0 | P; P | P+P | P|P | P* S : : = [P]r | S|S

A Formal Model for BPEL 4 Chor u. A local choreography language: P : : = a | ar | 1 | 0 | P; P | P+P | P|P | P* S : : = [P]r | S|S receive on a invoke a at r Unsuccessful termination Successful termination

A Formal Model for BPEL 4 Chor u. A local choreography language: P : : = a | ar | 1 | 0 | P; P | P+P | P|P | P* S : : = [P]r | S|S Sequence Choice Parallel Repetition

A Formal Model for BPEL 4 Chor u. A local choreography language: P : : = a | ar | 1 | 0 | P; P | P+P | P|P | P* S : : = [P]r | S|S Behaviour of participant r Parallel composition of participants

The “canonical” projection u Projection [[ H ]]t of choreography H to participant t as if t=r [[ ar s ]]t = a if t=s 1 otherwise [[H; H’]]t=[[H]]t ; [[H’]]t [[H|H’]]t=[[H]]t | [[H’]]t [[H+H’]]t=[[H]]t + [[H’]]t [[H*]]t=[[H]]t*

Example u Consider the global choreography: ar s ; bt u u Projection: [ as ; 1]r | [ a; 1 ]s | [ 1; bu ]t | [ 1; b ]u u Are n n the two choreographies equivalent? NO But, if r=t…. YES [ as; bu ]r | [ a; 1 ]s | [ 1; b ]u

Asynchronous communication u Reconsider the example assuming asynchronous communication [ as ; b u ]r | [ a ] s | [ b ] u u Communication on a starts before communication on b but could finish after u What we should observe? n Send, Receive, both, …?

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming synchronous communication: observe either send or receive

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming asynchronous communication: observe send

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming asynchronous communication: observe receive

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming asynchronous communication: observe send and observe receive

A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint Assuming asynchronous communication: observe send and receive (no overlap)

What about the previous example? u Reconsider the example ar s ; br u [ as ; b u ]r | [ a ] s | [ b ] u u OK: for synchronous and sender u NO: for receiver, sender-receiver, disjoint

Main results u For n each observation criterion: Sufficient conditions (connectedness, unique point of choice, and causality safe) that guarantee that a global choreography is equivalent to the projected one

Unique point of choice u In n n a choice H+H’ The sender of the initial transitions in H and in H’ is always the same The roles in H and in H’ are the same u Example: if we drop the secondition (ar s + br t ); c s t [ ( as+bt ); 1]r | [ (a+1); ct ]s | [ (1+b); c ]t

Which equivalence between global and local choreographies? u u Synchronous bisimilarity: global transitions are matched by synchronous local transitions Sender bisimilarity: global transitions are matched by local sends, local receives are abstracted away n u Receiver bisimilarity: global transitions are matched by local receives, global sends are abstracted away n u weak w. r. t. local receive transitions weak w. r. t. local send transitions Disjoint bisimilarity: a global transition is matched by subsequent send and receive local transitions

Example: Receiver bisimilarity

Example: Receiver bisimilarity u Global choreography: ar s ; bt s u Local choreography: [ as ]r | [ a; b ]s | [ bs ]t u The two systems are sender bisimilar

Contracts [FHRR 04][CCLP 06] u Contract: service “behavioural interface” that describes n n the signature of the provided operations the correct sequences of invoke and receive public registry Contract: abstract service description Service

Contract Compliance u Verification of correctness of service composition based on their contracts: successful interaction i. e. no deadlock / termination reached public registry Contract: abstract service description public registry … Contract: abstract service description Reciprocal invocations Service … Service

Service Compliance: Formally u Services are compliant if the following holds for their composition P: τ P --->* P’ implies that there exist P’’ and P’’’ s. t. √ τ P’ --->* P’’ ---> P’’’ n i. e. every computation can be extended to reach successful completion of all services

Example: compliant services u The following pairs of services are compliant: n n n C 1 = a+b+c C 1 = a; b C 1 = (a; b )* C 2 = a + b C 2 = a | b C 2 = a; ( b; a )*; b

Directly Checking Conformance w. r. t. Choreography is conformant for participant 1 to public registry Contract is conformant for participant n to compliance guaranteed by conformance … public registry Contract Reciprocal invocations Service … Service

Compliance-Preserving Contract Refinement ! Choreography projection Contract Part. 1 refines public registry Contract compliant by construction … compliance preserved by refinement … projection Contract Part. n refines public registry Contract Reciprocal invocations Service … Service

First Relation: Contract Refinement Choreography Contract Part. 1 refines public registry Contract compliant by construction … compliance preserved by refinement … Contract Part. n refines public registry Contract Reciprocal invocations Service … Service

Formally: Subcontract Preorder ≤ between contracts C: n C’ ≤ C means C’ is a subcontract of C u Preorder C sub-contracts of C subcontract preorder

Definition of Preorder Induced from Independent Refinement Given a set of compliant contracts C 1 C 2 sub-contracts of C 1 C’ 1 sub-contracts of C 2 … Cn subcontract preorder sub-contracts … of Cn … C’ 2 C’n is a set of compliant contracts

No maximal subcontract preorder … in general u Consider the system: [a]|[a] we could have one preorder ≤ 1 for which a + c. 0 ≤ 1 a and one preorder ≤ 2 for which a + c. 0 ≤ 2 a but no subcontract preorder could have a + c. 0 ≤ a u Consequence: no independent refinement!

Maximal pre-order u It n n n exists changing some assumptions: Limiting the considered services (output persistence) Strengthening the notion of compliance (strong compliance) Moving to asynchronous communication (e. g. via message queues)

Output persistence u Output persistence means that given a process state P: n If P has an output action on a and α P-->P’ with α different from output on a, then also P’ has an output on a u This n holds, for instance, in WS-BPEL Outputs cannot resolve the pick operator for external choices (the decision to execute outputs is taken internally)

Example u Given the choreography: Request. Alice Bob; (Accept. Bob Alice + Reject. Bob Alice) The following services can be retrieved: [τ; Request. Bob; (Accept+Reject)]Alice | [Request; (τ; Accept. Alice+τ; Reject. Alice)]Bob [τ; Request. Bob; (Accept+Reject+Retry)]Alice | [Request; (τ; Accept. Alice+τ; Reject. Alice)]Bob

“Standard” Contract Compliance u. A n n n second example: S 1: invoke(a); invoke(b) S 2: receive(a); invoke(c) S 3: receive(c); receive(b) S 1 S 2 S 3

“Standard” Contract Compliance u. A n n n second example: S 1: (invoke(a); receive(b))* S 2: (receive(a); invoke(b))*; receive(c) S 3: invoke(c) S 1 S 2 S 3

“Standard” Contract Compliance u. A n n n second example: S 1: (invoke(a); receive(b))* S 2: (receive(a); invoke(b))*; receive(c) S 3: invoke(c) u But S 3 could wait S 1 indefinitely to S 2 complete its invocation !! S 3

“Standard” Contract Compliance u. A second example: S 1: (invoke(a); receive(b))* n S 2: (receive(a); invoke(b))*; receive(c) n S 3: invoke(c) u But S 3 could wait S 1 u Strong indefinitely to compliance S 2 complete its requires the invocation !! S 3 receptor to be ready n

Example: strong compliant services u The following pairs of services are strong compliant: n n n C 1 = a+b+c C 1 = a; b C 1 = (a; b )* C 2 = a + b C 2 = a | b C 2 = a; ( b; a )*; b

“Strong” refinement u It allows also refinement on names already in the interface: Receive(a); (Receive(b)+Receive(a)) ≤ Receive(a); Receive(b)

Summary of Results u Refinement with knowledge about other initial contracts limited to I/O actions (enough to guarantee that refinements that extend the interface are included) n “normal” compliance: w Uncostrained contracts: maximal relation does not exist w Contracts where outputs are internally chosen (output persistence): maximal relation exists and “I” knowledge is irrelevant w Output persistent contracts where outputs are directed to a location: maximal relation exists and “I/O” knowledge is irrelevant n strong compliance: w Uncostrained contracts (where output are directed to a location): maximal relation exists and “I/O” knowledge is irrelevant n queue-based compliance: w Uncostrained contracts (where output are directed to a location): maximal relation exists and “I/O” knowledge is irrelevant

Future work u Apply contract theory to real orchestration languages n JOLIE: Java Orchestration Language Interpreter Engine (formal semantics defined by the process calculus SOCK) u Contracts with operators for process interruption and compensation n The contract language becomes partially undecidable

Related work u Carbone, n n n Honda, Yoshida Global and End-point calculus similar to our WS-CDL and BPEL 4 Chor Only some of our observation criteria are considered Stronger conditions for projection

Related work u Fu, n n n Bultan, Su Service systems with message queues similar to ours Observe the send event as in our sender observation criterion No refinement

Related work u Padovani n n et al. Contracts described with an ad-hoc transition system (reminiscent of acceptance tree) The absence of maximal subcontract relation solved either with explicit interfaces of filters (cut the additional actions of the refinements)

Related work u van n n der Aalst et al. Contracts described with open workflow nets (similar to petri nets) Same notion of compliance Same definition of subcontract as maximal refinement that preserves compliance Characterization of the refinement for processes without “loops” (make the system infinite due to message queues)

References u u u N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and Orchestration Conformance for System Design. In Coordination’ 06. I. Lanese, C. Guidi, F. Montesi, and G. Zavattaro. Bridging the Gap Between Interaction- and Process-oriented Choreographies. In SEFM’ 08. M. Bravetti and G. Zavattaro. Contract based Multi-party Service Composition. In FSEN’ 07. (full version in Fundamenta Informaticae) M. Bravetti and G. Zavattaro. Towards a Unifying Theory for Choreography Conformance and Contract Compliance. In SC’ 07. M. Bravetti and G. Zavattaro. A Theory for Strong Service Compliance. In Coordination’ 07. (full version in MSCS) M. Bravetti and G. Zavattaro. Contract Compliance and Choreography Conformance in the presence of Message Queues. In WS-FM’ 08 C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. SOCK: a Calculus for Service Oriented Computing. In ICSOC’ 06. F. Montesi, C. Guidi, and G. Zavattaro. Orchestrating Services in JOLIE. In ECOWS’ 07. C. Guidi, I. Lanese, F. Montesi, and G. Zavattaro. On the Interplay Between Fault Handling and Request-response Service Invocations. In ACSD’ 08. C. Guidi, F. Montesi, I. Lanese, and G. Zavattaro. Dynamic Fault-handling for Service Oriented Applications. In ECOWS’ 08. M. Bravetti and G. Zavattaro. On the Expressive Power of Process Interruption and Compensation. In WS-FM’ 08

References u u u N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and Orchestration Conformance for System Design. In Coordination’ 06. I. Lanese, C. Guidi, F. Montesi, and G. Zavattaro. Bridging the Gap Between Interaction- and Process-oriented Choreographies. In SEFM’ 08. M. Bravetti and G. Zavattaro. Contract based Multi-party Service Composition. In FSEN’ 07. (full version to appear in Fundamenta Informaticae) M. Bravetti and G. Zavattaro. Towards a Unifying Theory for Choreography Conformance and Contract Compliance. In SC’ 07. M. Bravetti and G. Zavattaro. A Theory for Strong Service Compliance. In Coordination’ 07. (full version to appear in MSCS) M. Bravetti and G. Zavattaro. Contract Compliance and Choreography Conformance in the presence of Message Queues. In WS-FM’ 08 C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. SOCK: a Calculus for Service Oriented Computing. In ICSOC’ 06. F. Montesi, C. Guidi, and G. Zavattaro. Orchestrating Services in JOLIE. In ECOWS’ 07. C. Guidi, I. Lanese, F. Montesi, and G. Zavattaro. On the Interplay Between Fault Handling and Request-response Service Invocations. In ACSD’ 08. C. Guidi, F. Montesi, I. Lanese, and G. Zavattaro. Dynamic Fault-handling for Service Oriented Applications. In ECOWS’ 08. M. Bravetti and G. Zavattaro. On the Expressive Power of Process Interruption and Compensation. In WS-FM’ 08