choreography, orchestration, and contracts languages and techniques for service composition
DESCRIPTION
www.sensoria-ist.eu. Choreography, Orchestration, and Contracts Languages and Techniques for Service Composition. Gianluigi Zavattaro http://cs.unibo.it/~zavattar. Department of Computer Science University of Bologna. - PowerPoint PPT PresentationTRANSCRIPT
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
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)
SOAP
PUBLISHSERVICE
FIND SERVICE
-1--2-
-3-
Plan of the Talk
An “open” world of services Service composition
Orchestration (bottom-up) Choreography (top-down)
Contract-based service discovery Output persistency Strong Compliance Message Queues
Conclusion and future work
Plan of the Talk
Buying an electronic ticket
Buying an electronic ticket
Web search engines
Public advertisements
Friends or colleagues
…
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
request
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
no ticket
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
request
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
no ticket
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
request
Buying an electronic ticket
ticketingservice 1
ticketingservice 2
ticketingservice n
ticket
Buying an electronic ticket[using an orchestrator]
Buying an electronic ticket[using an orchestrator]
orchestrator
request
Buying an electronic ticket[using an orchestrator]
ticketingservice 1
ticketingservice 2
ticketingservice n
orchestrator
Buying an electronic ticket[using an orchestrator]
ticketingservice 1
ticketingservice 2
ticketingservice n
request
request
request
orchestrator
Buying an electronic ticket[using an orchestrator]
ticketingservice 1
ticketingservice 2
ticketingservice n
orchestrator
Buying an electronic ticket[using an orchestrator]
ticketingservice 1
ticketingservice 2
ticketingservice n
orchestrator
ticket
Buying an electronic ticket[using an orchestrator]
ticketingservice 1
ticketingservice 2
ticketingservice n
cancel
cancel
orchestrator
Buying an electronic ticket[using an 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) ) );
End
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(req2)
WSFL: based on Petri-nets
Receive(req1,req2)
Invoke(req1)@srv1 Invoke(req2)@srv2
Reply(req1) Reply(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) ) );
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
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
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
Buyer
Seller
Bank
WS-CDL Global view of service interactions
Buyer
SellerRequest
Bank
WS-CDL Global view of service interactions
Buyer
Seller
PayDescr
RequestOffer
Bank
WS-CDL Global view of service interactions
Buyer
Seller
PayDescr
RequestOffer
Bank
Payment
WS-CDL Global view of service interactions
Buyer
Seller
PayDescr
RequestOffer
Bank
PaymentConfirm
Receipt
WS-CDL
RequestBuyerSeller ;
( OfferSellerBuyer |
PayDescrSellerBank ) ;
PaymentBuyerBank ;
( ConfirmBankSeller |
ReceiptBankBuyer )
RequestBuyerSeller ;
( OfferSellerBuyer |
PayDescrSellerBank ) ;
PaymentBuyerBank ;
( ConfirmBankSeller |
ReceiptBankBuyer )
WS-CDL
RequestBuyerSeller ;
( OfferSellerBuyer |
PayDescrSellerBank ) ;
PaymentBuyerBank ;
( ConfirmBankSeller |
ReceiptBankBuyer )
WS-CDL
RequestBuyerSeller ;
( OfferSellerBuyer |
PayDescrSellerBank ) ;
PaymentBuyerBank ;
( ConfirmBankSeller |
ReceiptBankBuyer )
WS-CDL
RequestBuyerSeller ;
( OfferSellerBuyer |
PayDescrSellerBank ) ;
PaymentBuyerBank ;
( ConfirmBankSeller |
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
Buyer
Seller
PayDescr
RequestOffer
Bank
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*
A Formal Model for WS-CDL
A global choreography language:H ::= ars | 1 | 0 |
H;H | H+H | H|H | H*r invokes the
operation a of s
Successful termination
Unsuccessful termination
A Formal Model for WS-CDL
A global choreography language:H ::= ars | 1 | 0 |
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
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
A Formal Model for BPEL4Chor
Choice
Sequence
Parallel Repetition
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 BPEL4Chor
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 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
A lattice of possible observation criteria
Disjoint
Sender Receiver
Sender-receiver
Synchronous
Assuming synchronous communication: observe either send or receive
A lattice of possible observation criteria
Disjoint
Sender Receiver
Sender-receiver
Synchronous
Assuming asynchronous communication: observe send
A lattice of possible observation criteria
Disjoint
Sender Receiver
Sender-receiver
Synchronous
Assuming asynchronous communication: observe receive
A lattice of possible observation criteria
Disjoint
Sender Receiver
Sender-receiver
Synchronous
Assuming asynchronous communication: observe send and observe receive
A lattice of possible observation criteria
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
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
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
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
Service Service …Reciprocal invocations
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
Service Service …Reciprocal invocations
Contract Part. 1 Contract Part. n…refines refines
compliance preserved by refinement
compliant by construction
Formally: Subcontract Preorder
C
sub-contracts
of C
subcontractpreorder
Preorder ≤ between contracts C: C’ ≤ C means C’ is a subcontract
of C
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
of Cn
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
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
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)
The following services can be retrieved:[τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob
[τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob
Example
Given the choreography:RequestAliceBob; (AcceptBobAlice + RejectBobAlice)
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
“Standard” Contract Compliance
A second example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)
S1
S2
S3
“Standard” Contract Compliance
A second example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)
S1
S2
S3
“Standard” Contract Compliance
A second example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)
S1
S2
S3
“Standard” Contract Compliance
A second example: S1: (invoke(a);receive(b))* S2:
(receive(a);invoke(b))*;receive(c) S3: invoke(c)S1
S2
S3
“Standard” Contract Compliance
A second example: S1: (invoke(a);receive(b))* S2:
(receive(a);invoke(b))*;receive(c) S3: invoke(c)S1
S2
S3
But S3 could wait indefinitely to complete its invocation !!
“Standard” Contract Compliance
A second example: S1: (invoke(a);receive(b))* S2:
(receive(a);invoke(b))*;receive(c) S3: invoke(c)S1
S2
S3
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
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
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
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
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