Www.sensoria-ist.eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http://cs.unibo.it/~zavattar.

Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro Department of Computer Science University of Bologna Based on joint work with: Mario Bravetti, Claudio Guidi, Ivan Lanese, Fabrizio Montesi

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

An “open” world of services
Service Oriented Computing is used to design systems working in a heterogeneous and open environment where services: 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…
Not only the issue of inter-operability (computing across different platforms): 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- PUBLISH SERVICE FIND SERVICE WSDL (interface definition language) UDDI (service discovery) SOAP (service invocation protocol) -3- SOAP

Service composition Orchestration (bottom-up) Choreography (top-down) Contract-based service discovery Output persistency Strong Compliance Message Queues Conclusion and future work

Buying an electronic ticket

Web search engines Public advertisements Friends or colleagues …

ticketing service 1 ticketing service 2 ticketing service n

ticketing service 1 request ticketing service 2 ticketing service n

ticketing service 1 ticketing service 2 no ticket ticketing service n

ticketing service 1 request ticketing service 2 ticketing service n

ticketing service 1 ticketing service 2 no ticket ticketing service n

ticketing service 1 ticketing service 2 request ticketing service n

ticketing service 1 ticketing service 2 ticket ticketing service n

Buying an electronic ticket [using an orchestrator]

request orchestrator

ticketing service 1 ticketing service 2 orchestrator ticketing service n

ticketing service 1 ticketing service 2 request request orchestrator request ticketing service n

ticketing service 1 ticketing service 2 orchestrator ticketing service n

ticketing service 1 ticketing service 2 ticket orchestrator ticketing service n

ticketing service 1 ticketing service 2 cancel orchestrator cancel ticketing service n

ticketing service 1 ticketing service 2 ticket orchestrator ticketing service n

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

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

XLANG: based on -calculus
Start; Receive(req1,req2); ( ( Reply(req1) ) | ( Reply(req2) ) ); End

WSFL: based on Petri-nets
Receive(req1,req2) Reply(req1) Reply(req2)

WS-BPEL: join XLANG and WSFL
Start; Receive(req1,req2); ( ( Send(intLink); Reply(req1) ) | ( Recv(intLink); Reply(req2) ) ); End

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

Choreography Languages
Specification language (not executable) No central point of coordination The composed services interact reciprocally WS-CDL: proposed by W3C in 2004 BPEL4Chor: recently proposed by researchers involved in WS-BPEL

Web Service Choreography Description Language
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
Protocol for the request to a trusted entity of the creation of a session key: Alice  Trent: Alice, Bob Trent  Alice: {KAB}KA , {KAB}KB Alice  Bob: {KAB}KB

Similar to UML Sequence Diagrams

WS-CDL Global view of service interactions Seller Buyer Bank

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

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

Offer Buyer PayDescr Payment Bank

Offer Buyer PayDescr Confirm Payment Receipt Bank

WS-CDL RequestBuyerSeller ; ( OfferSellerBuyer |
PayDescrSellerBank ) ; PaymentBuyerBank ; ( ConfirmBankSeller | ReceiptBankBuyer )

BPEL4Chor The WS-BPEL approach to choreography:
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
Request Offer Buyer PayDescr Confirm Payment Receipt Bank Choreography, Orchestration, and Contracts Barcelona

Projection of the Choreography on the Single Participants
Buyer: Seller: Receive(Request); | Receive(Confirm) Bank: Receive(PayDescr);Receive(Payment); |

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

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

A global choreography language: H ::= ars | 1 | 0 | H;H | H+H | H|H | H* r invokes the operation a of s Unsuccessful termination Successful termination

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 BPEL4Chor
A local choreography language: P ::= a | ar | 1 | 0 | P;P | P+P | P|P | P* S ::= [P]r | S|S

A local choreography language: P ::= a | ar | 1 | 0 | P;P | P+P | P|P | P* S ::= [P]r | S|S receive on a Unsuccessful termination invoke a at r Successful termination

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 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
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 Consider the global choreography: ars ; btu Projection:
[ as ;1]r | [ a;1 ]s | [ 1;bu ]t | [ 1;b ]u Are the two choreographies equivalent? NO But, if r=t…. YES [ as; bu ]r | [ a;1 ]s | [ 1;b ]u

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

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

Assuming synchronous communication: observe either send or receive Synchronous Sender Receiver Sender-receiver Disjoint

Synchronous Sender Receiver Assuming asynchronous communication: observe send Sender-receiver Disjoint

Synchronous Sender Receiver Assuming asynchronous communication: observe receive Sender-receiver Disjoint

Synchronous Sender Receiver Assuming asynchronous communication: observe send and observe receive Sender-receiver Disjoint

Synchronous Sender Receiver Assuming asynchronous communication: observe send and receive (no overlap) Sender-receiver Disjoint

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

Main results For 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 In 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 Example: if we drop the second condition (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?
Synchronous bisimilarity: global transitions are matched by synchronous local transitions Sender bisimilarity: global transitions are matched by local sends, local receives are abstracted away weak w.r.t. local receive transitions Receiver bisimilarity: global transitions are matched by local receives, global sends are abstracted away 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
Global choreography: ars ; bts Local choreography: [ as ]r | [ a;b ]s | [ bs ]t The two systems are sender bisimilar

Contracts [FHRR04][CCLP06]
Contract: service “behavioural interface” that describes the signature of the provided operations the correct sequences of invoke and receive public registry Contract: abstract service description Service

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

Service Compliance: Formally
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’’’ i.e. every computation can be extended to reach successful completion of all services τ τ √

Example: compliant services
The following pairs of services are compliant: C1 = a+b+c C2 = a + b C1 = a;b C2 = a | b C1 = (a; b )* C2 = a;( b;a )*;b

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

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

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

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

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

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

Maximal pre-order It 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 Output persistence means that given a process state P: 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 This holds, for instance, in WS-BPEL Outputs cannot resolve the pick operator for external choices (the decision to execute outputs is taken internally) α

Example Given the choreography:
RequestAliceBob; (AcceptBobAlice + RejectBobAlice) The following services can be retrieved: [τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

RequestAliceBob; (AcceptBobAlice + RejectBobAlice) The following services can be retrieved: [τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob [τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

RequestAliceBob; (AcceptBobAlice + RejectBobAlice) The following services can be retrieved: [τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob [τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob [τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;τ;AcceptAlice]Bob

“Standard” Contract Compliance
A second example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b) S1 S2 S3

A second example: S1: (invoke(a);receive(b))* S2: (receive(a);invoke(b))*;receive(c) S3: invoke(c) S1 S2 S3

A second example: S1: (invoke(a);receive(b))* S2: (receive(a);invoke(b))*;receive(c) S3: invoke(c) S1 But S3 could wait indefinitely to complete its invocation !! S2 S3

A second example: S1: (invoke(a);receive(b))* S2: (receive(a);invoke(b))*;receive(c) S3: invoke(c) S1 But S3 could wait indefinitely to complete its invocation !! Strong compliance requires the receptor to be ready S2 S3

Example: strong compliant services
The following pairs of services are strong compliant: C1 = a+b+c C2 = a + b C1 = a;b C2 = a | b C1 = (a; b )* C2 = a;( b;a )*;b

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

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

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

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

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

Related work Padovani 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 van 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 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 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

Www.sensoria-ist.eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http://cs.unibo.it/~zavattar.

Similar presentations

Presentation on theme: "Www.sensoria-ist.eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http://cs.unibo.it/~zavattar."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Www.sensoria-ist.eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http://cs.unibo.it/~zavattar.

Similar presentations

Presentation on theme: "Www.sensoria-ist.eu Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition Gianluigi Zavattaro http://cs.unibo.it/~zavattar."— Presentation transcript:

Similar presentations

About project

Feedback