www sensoriaist eu Choreography Orchestration and Contracts Languages
- Slides: 123
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
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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
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
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 )
WS-CDL Request. Buyer Seller ; ( Offer. Seller Buyer | Pay. Descr. Seller Bank ) ; Payment. Buyer Bank ; ( Confirm. Bank Seller | Receipt. Bank Buyer )
WS-CDL Request. Buyer Seller ; ( Offer. Seller Buyer | Pay. Descr. Seller Bank ) ; Payment. Buyer Bank ; ( Confirm. Bank Seller | Receipt. Bank Buyer )
WS-CDL Request. Buyer Seller ; ( Offer. Seller Buyer | Pay. Descr. Seller Bank ) ; Payment. Buyer Bank ; ( Confirm. Bank Seller | Receipt. Bank Buyer )
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
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
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!
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
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
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
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]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); 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); 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); 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
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
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
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 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 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
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
- Weebly students
- Stomach
- Database applications
- Orchestration designer
- Multi domain service orchestration
- Resiliency orchestration
- Broadband service orchestration
- Oasis tosca
- Orchestration is about codifying tasks
- Hp cloud service automation
- Ibm resiliency orchestration
- Real time interaction management forrester
- Biztalk architecture
- Conversation orchestration
- Container orchestration monitoring
- Business process orchestration
- Tosca cloud
- Tosca orchestration
- Tosca orchestration
- Enfv
- Hp operation orchestration
- Tosca orchestration
- Tosca cloud orchestration
- Tosca orchestration
- Kubeflow architecture diagram
- Jde orchestration resources
- Hedging with forwards
- Research and development contracts
- Water contracts (gets smaller) when it freezes
- Software contracts in professional practices
- Litter picking contracts
- System operation contracts
- International contract law
- Types of contracts
- Mailbox rule contracts
- Mailbox rule contracts
- Parts of agreement
- Blaockchain
- Mailbox rule contracts
- Finance contracts
- Quasi contracts
- Mailbox rule contracts
- Fututes
- Express contract
- Introduction of contract law
- According to integrative social contracts theory
- Mailbox rule contracts
- Contingency contracting aba
- Integrative social contracts theory maintains that
- Ability one source america
- Muscle contracts
- Cross bridge myosin head
- Making smart contracts smarter
- Muscle contracts
- Ind as 11 construction contracts
- Ecm solutions group
- Currency futures contracts sold on an exchange:
- Depolarization of the heart
- Ahs security
- Operation contract uml
- Binary options risk
- Contracts of agency
- Translating contracts
- Common law and civil law
- Hsbc forward contracts
- Forward contracts definition
- Facultative reinsurance slip
- Discipline modern miss
- Utility energy service contracts
- Preincorporated
- Quasi contract in business law
- Voidable contracts
- Cell c phone contracts no credit checks
- What are the essential requisites of a contract
- The formation of the solar system
- Integrated social contracts theory maintains that
- Hot metal contracts as it grows cooler
- Christopher mikaelian
- A contingent contract is
- State of florida dms
- Indiana state contracts
- Wrongful acts that do not involve contracts
- State term contract florida
- Wa des contracts
- Participating contracts
- Ariba contracts module
- Real-time systems and programming languages
- Cs 421 programming languages and compilers
- Languages for life and work
- Media and information languages
- Backend of compiler
- Proto language
- Defence centre for languages and culture
- Difference between strongly and weakly typed languages
- List the primitives that specify a data mining task
- Storyboard about media and information literacy
- Csci3130
- Formal languages and automata theory tutorial
- Cyk algorithm
- Advantages and disadvantages of system software
- Gtg stands for in automata
- Is metaphor a sound device
- Csci 3130
- Formal language
- Real time programming language
- Closure and decision properties of context free languages
- Cfl closed under reversal
- Regular and irregular languages
- Translators and facilities of languages
- Tandem language
- Cs 421 uiuc
- Data mining languages and system architecture
- Cross-lingual name tagging and linking for 282 languages
- Why do individual languages vary among places
- Assembly language list
- Multithreaded languages
- Turing unrecognizable languages
- Christian love language test
- Love language test results
- Love languages descriptions
- Meaning of 5 love languages
- 11 official languages of south africa
- How many languages are there
- Compiled languages