Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition

Gianluigi Zavattarohttp://cs.unibo.it/~zavattar

Department of Computer Science

University of Bologna

Choreography, Orchestration, and ContractsLanguages and Techniques for Service Composition

www.sensoria-ist.eu

Based on joint work with: Mario Bravetti, Claudio Guidi, Ivan Lanese, Fabrizio Montesi

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

Plan of the Talk

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

WSDL (interface definition language) UDDI (service discovery) SOAP (service invocation protocol)

PUBLISHSERVICE

FIND SERVICE

-1--2-

Plan of the Talk

Contract-based service discovery Output persistency Strong Compliance Message Queues

Plan of the Talk

Buying an electronic ticket

Web search engines

Public advertisements

Friends or colleagues

ticketingservice 1

ticketingservice 2

ticketingservice n

ticketingservice 1

ticketingservice 2

ticketingservice n

request

ticketingservice 1

ticketingservice 2

ticketingservice n

no ticket

ticketingservice 1

ticketingservice 2

ticketingservice n

request

ticketingservice 1

ticketingservice 2

ticketingservice n

no ticket

ticketingservice 1

ticketingservice 2

ticketingservice n

request

ticketingservice 1

ticketingservice 2

ticketingservice n

ticket

Buying an electronic ticket[using an orchestrator]

orchestrator

request

ticketingservice 1

ticketingservice 2

ticketingservice n

orchestrator

ticketingservice 1

ticketingservice 2

ticketingservice n

request

orchestrator

ticketingservice 1

ticketingservice 2

ticketingservice n

orchestrator

ticketingservice 1

ticketingservice 2

ticketingservice n

orchestrator

ticket

ticketingservice 1

ticketingservice 2

ticketingservice n

cancel

orchestrator

ticketingservice 1

ticketingservice 2

ticketingservice n

orchestrator

ticket

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);( ( Invoke(req1)@srv1;

Reply(req1) ) |( Invoke(req2)@srv2; Reply(req2) ) );

WSFL: based on Petri-nets

Receive(req1,req2)

Invoke(req1)@srv1 Invoke(req2)@srv2

Reply(req1) Reply(req2)

Receive(req1,req2)

WS-BPEL: join XLANG and WSFL

Start;Receive(req1,req2);( ( Invoke(req1)@srv1;

Send(intLink); Reply(req1) ) |( Invoke(req2)@srv2; Recv(intLink); Reply(req2) ) );

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

Plan of the Talk

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, BobTrent Alice: {KAB}KA

, {KAB}KB

Alice Bob: {KAB}KB

Similar to UML Sequence Diagrams

WS-CDL Global view of service interactions

Seller

SellerRequest

Seller

PayDescr

RequestOffer

Seller

PayDescr

RequestOffer

Payment

Seller

PayDescr

RequestOffer

PaymentConfirm

Receipt

WS-CDL

RequestBuyerSeller ;

( OfferSellerBuyer |

PayDescrSellerBank ) ;

PaymentBuyerBank ;

( ConfirmBankSeller |

ReceiptBankBuyer )

PaymentBuyerBank ;

ReceiptBankBuyer )

WS-CDL

PaymentBuyerBank ;

ReceiptBankBuyer )

WS-CDL

PaymentBuyerBank ;

ReceiptBankBuyer )

WS-CDL

PaymentBuyerBank ;

ReceiptBankBuyer )

WS-CDL

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

Barcelona - 3.11.2008Choreography, Orchestration, and Contracts

Seller

PayDescr

RequestOffer

PaymentConfirm

Receipt

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(PayDescr)@Bank); Receive(Confirm)

Bank: Receive(PayDescr);Receive(Payment); (Invoke(Receipt)@Buyer | Invoke(Confirm)@Seller)

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 ::= ars | 1 | 0 |

H;H | H+H | H|H | H*

H;H | H+H | H|H | H*r invokes the

operation a of s

Successful termination

Unsuccessful termination

H;H | H+H | H|H | H*

Choice

Sequence

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

receive on a

Successful termination

Unsuccessful termination

invoke a at r

Choice

Sequence

Parallel Repetition

P;P | P+P | P|P | P*S ::= [P]r | S|S

Behaviour of participant r

Parallel compositionof participants

The “canonical” projection

Projection [[ H ]]t of choreography H to participant t

as if t=r

[[ ars ]]t = a if t=s1 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: ars ; btu

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

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Assuming synchronous communication: observe either send or receive

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Assuming asynchronous communication: observe send

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Assuming asynchronous communication: observe receive

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Assuming asynchronous communication: observe send and observe receive

Disjoint

Sender Receiver

Sender-receiver

Synchronous

Assuming asynchronous communication: observe send and receive (no overlap)

What about the previous example?

Reconsider the example ars ; bru

[ 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 (ars + brt ); c st

[ ( 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

Global choreography: ars ; bts

Local choreography: [ as ]r | [ a;b ]s | [ bs ]t

The two systems are sender bisimilar

Plan of the Talk

Contracts [FHRR04][CCLP06]

Contract: service “behavioural interface” that describes the signature of the

provided operations the correct sequences

of invoke and receive

Contract:abstract service

description

Service

public registry

Contract Compliance Verification of correctness of service

composition based on their contracts: successful interaction i.e. no deadlock / termination reached

Contract:abstract service

description

Service

…Contract:

abstract service description

Service …

public registry public registry

Reciprocal invocations

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

Choreography

Directly Checking Conformance w.r.t. Choreography

Contract

public registry

Contract

public registry

Service Service …Reciprocal invocations

is conformant for participant 1 to

is conformant for participant n tocompliance

guaranteed by conformance

Choreography

Compliance-Preserving Contract Refinement !

Contract

public registry

Contract

public registry

Contract Part. 1 Contract Part. n…refines refines

compliance preserved by refinement

compliant by construction

projection projection

Choreography

First Relation: Contract Refinement

Contract

public registry

Contract

public registry

Contract Part. 1 Contract Part. n…refines refines

compliance preserved by refinement

compliant by construction

Formally: Subcontract Preorder

sub-contracts

subcontractpreorder

Preorder ≤ between contracts C: C’ ≤ C means C’ is a subcontract

Definition of Preorder Induced from Independent Refinement

C1 C2 Cn

Given a set of compliant contracts

is a set of compliant contracts

subcontractpreorder

sub-contracts

of C2 …sub-contracts

of C1 sub-contracts

C’1 C’2 C’n…

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 havea + c.0 ≤ a a + c.0 ≤ a

Consequence: no independent refinement!

Plan of the Talk

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:RequestAliceBob; (AcceptBobAlice +

RejectBobAlice)

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

Example

Given the choreography:RequestAliceBob; (AcceptBobAlice +

RejectBobAlice)

[τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

Example

Given the choreography:RequestAliceBob; (AcceptBobAlice + RejectBobAlice)

[τ;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)

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

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

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: Uncostrained contracts (where output are directed to a location):

maximal relation exists and “I/O” knowledge is irrelevant

Plan of the Talk

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 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

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 Applications. In ECOWS’08. M. Bravetti and G. Zavattaro. On the Expressive Power of Process Interruption

and Compensation. In WS-FM’08

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

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

Service Oriented Applications. In ECOWS’08. M. Bravetti and G. Zavattaro. On the Expressive Power of Process Interruption

and Compensation. In WS-FM’08

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

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

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

Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition

Documents

Transcript of Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition

Orchestration, Choreography and Collaboration in Web ...ontolog.cim3.net/file/resource/presentation/MonicaMartin_20050526… · Orchestration, Choreography and Collaboration in Web

Reasoning Tasks and Mediation on Choreography and Orchestration in WSMO

Chapter XII Web Service Orchestration and Choreography · 2014-04-02 · Web Service Orchestration and Choreography: Enabling Business Processes on the Web applications or services

and Choreography

Deciding Choreography Reliazability

Web Services Business Process Execution Language€¦ · Web viewWS-BPEL is an orchestration language, not a choreography langauge. ... Rebased on Word template of WS-BPEL 2.0 specification.

Choreography Revisited

Multimedia Choreography

CS 290C: Formal Models for Web Software Lectures 16: Choreography and Orchestration Modeling with Process Algebras Instructor: Tevfik Bultan

DELIGHTS · 2020. 12. 22. · 3 NUTCRACKER DELIGHTS Choreography Wayne Eagling Based on a concept by Toer van Schayk and Wayne Eagling Music Pyotr Ilyich Tchaikovsky Reduced Orchestration

Web Service Orchestration and Choreography: A …wpage.unina.it/rcanonic/didattica/at/documenti/wsOrchestration.pdf · Orchestration and Choreography Before introducing the standards,

API Orchestration & Choreography Why it Matters for ...

Michael Klein, Choreography

UX Choreography

VM-FLOW: Using Web Services Orchestration and Choreography ... · sents a Virtual Marketplace infrastructure, called VM-Flow, which supports Dynamic Virtual Enterprises, is workflow-based

Choreography in Theatre. The Follies, the beginning of modern Choreography.

Orchestration Choreography: describes a transaction ... · Choreography: describes a transaction without the assumption of central control. Choreography Choreography Monday, April

Part I Business Process Management (BPM) · 2004. 2. 23. · BPEL WS-CHOR BPM WS-CAF 38 Registry BPM = protocol://Collaboration(Choreography) + (Orchestration*) + (Task*) View ERP

Real-time WebServices Orchestration and Choreographyceur-ws.org/Vol-601/EOMAS10_paper13.pdf · Real-time WebServices Orchestration and Choreography Kawtar Benghazi, Manuel Noguera,

CS 290C: Formal Models for Web Software Lectures 14: Formal Modeling and Analysis of Orchestration and Choreography Specifications Instructor: Tevfik Bultan.

Part I Business Process Management (BPM) · 2004. 2. 23. · BPEL WS-CHOR BPM WS-CAF 38 Registry BPM = protocol://Collaboration(Choreography) + (Orchestration) + (Task) View ERP