Service Choreography and Orchestration with Conversations

Tevfik Bultan Department of Computer Science University of California, Santa Barbara [email protected]

http://www.cs.ucsb.edu/~bultan

Acknowledgements

• Joint work with – Xiang Fu, Hofstra University – Jianwen Su, University of California, Santa Barbara – Aysu Betin Can, Middle East Technical University • [Bultan, Fu, Hull, Su, WWW’03] Conversation specification • [Fu, Bultan, Su, CIAA’03, TCS’04] Conversation protocols, realizability • [Fu, Bultan, Su WWW’04, TSE’05] Analyzing interacting BPEL processes, realizability • [Fu, Bultan, Su CAV’04] Web Service Analysis Tool (WSAT) • [Betin Can, Bultan, Fu WWW’05] interaction analysis Peer controller pattern for modular

Web Services

• The World Wide Web Consortium (W3C) defines a Web service as –

"a software system designed to support interoperable machine-to machine interaction over a network”

• The basic architecture Service Broker

Search Register Request

Service Requester Service Provider

Response

Web Services Standards Stack

Registry Service Protocol Type Data

Universal Description, Discovery & Integration (UDDI) Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) XML Schema (XSD) Extensible Markup Language (XML)

Search

WSDL Service Requester Service Broker UDDI

Register

WSDL

Request

SOAP

Response

Service Provider

Web Services Characteristics/Goals

• Interoperability – Platform independent (.NET, J2EE) – Service interactions across organizational boundaries • Loose coupling – Standardized data transmission via XML – Interaction based on standardized interfaces such as WSDL • Communication via messages – Synchronous and asynchronous messaging

Basic Usage of Web Services

• What we have so far supports basic client/server style interactions WSDL Service Requester Client

Request

SOAP

Response

Service Provider Server • Example: Amazon E-Commerce Web Service (AWS-ECS) • AWS-ECS WSDL specification lists 40 operations that provide differing ways of browsing Amazon’s product database such as –

ItemSearch, CartCreate, CartAdd, CartModify, CartGet, CartClear

• Based on the AWS-ECS WSDL specification one can implement clients that interact with AWS-ECS

Composing Services

• Can this framework support more than basic client/server style interactions?

• Can we compose a set of services to construct a new service?

• For example: – If we are building a bookstore service, we may want to use both Amazon’s service and Barnes & Noble’s service in order to get better prices • Another (well-known) example: – A travel agency service that uses other services (such as flight reservation, hotel reservation, and car rental services) to help customers book their trips

Composing Services

Two dimensions: 1. Define an executable process that interacts with existing services and executes them in a particular order and combines the results to achieve a new goal •

Orchestration

: From atomic services to stateful services 2. Specify how the individual services should interact with each other. Find or construct individual services that follow this interaction specification •

Choreography

services : Global specification of interactions among

Orchestration vs. Choreography

• Orchestration : Central control of the behavior of a distributed system • Like a conductor conducting an orchestra • Conductor is in charge during the performance • Orchestration specifies an executable process, identifying when and how that process should interact with other services – Orchestration is used to specify the control flow of a composite web service (as opposed to an atomic web service that does not interact with any other service)

Orchestration vs. Choreography

• Choreography : Specification of the behavior of a distributed system without centralized control • Choreographer specifies the behavior of the dancing team • Choreographer is not present during the execution • A choreography specifies how the services should interact – It specifies the legal sequences of messages exchanged among individual services (peers) – It is not necessarily executable • A choreography can be realized by writing an orchestration for each peer involved in the choreography – Choreography as global – Orchestration as local specification behavior specification behavior specification that realizes the global

Orchestration with WS-BPEL

• Web Services Business Process Execution Language (WS-BPEL) is an orchestration language • A WS-BPEL specification describes the execution logic using basic and structured activities – Basic activities:

RECEIVE, REPLY, INVOKE, ASSIGN, THROW, TERMINATE, WAIT, EMPTY RECEIVE, REPLY, INVOKE

– Structured activities:

SEQUENCE, SWITCH, WHILE, PICK, FLOW, SCOPE, COMPENSATE

• WS-BPEL supports messaging (

RECEIVE, REPLY, INVOKE

) and multi threading (

FLOW

)

Choreography with WS-CDL

• Web Services Choreography Description Language (WS-CDL) • WS-CDL specifications describe ``

peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal

.'' • A WS-CDL specification describes the interaction ordering among a set of peers using basic and structured activities – Basic activities:

INTERACTION, PERFORM, ASSIGN, SILENT ACTION, NO ACTION

– Structured activities:

SEQUENCE, PARALLEL, CHOICE, PICK, FLOW, SCOPE, COMPENSATE

Web Services Standards Stack

Choreography Orchestration Service Protocol Type Data

Web Services Choreography Description Language (WS-CDL) Web Services Business Process Execution Language (WS-BPEL) Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) XML Schema (XSD) Extensible Markup Language (XML) WSDL Atomic Service SOAP WS-CDL WS-BPEL Orchestrated Service SOAP SOAP WS-BPEL Orchestrated Service SOAP WSDL Atomic Service SOAP

Asynchronous Messages

• Sender does not have to wait for the receiver – Message is inserted to a message queue – Messaging platform guarantees the delivery of the message • Why support asynchronous messaging?

– Otherwise the sender has to block and wait for the receiver – Sender may not need any data to be returned – If the sender needs some data to be returned, it should wait when it needs to use that data – Asynchronous messaging can alleviate the latency of message transmission through the Internet – Asynchronous messaging can prevent sender from blocking if the receiver service is temporarily unavailable • Rather then creating a thread to handle the send, use asynchronous messaging

Outline

• Motivation: Web Services • Conversations • Realizability • Synchronizability • Web Service Analysis Tool • An Application (Reality Check) • Conclusions

Going to Lunch at UCSB

• Before Xiang left UCSB, Xiang, Jianwen and I were using the following protocol for going to lunch: – Sometime around noon one of us would call another one by phone and tell him where and when we would meet for lunch. – The receiver of this first call would call the remaining peer and pass the information. • Let’s call this protocol the First Caller Decides (FCD) protocol. • At the time we did not have answering machines or voicemail!

FCD Protocol Scenarios

• • • Possible scenario 1. Tevfik calls Jianwen with the decision of where and when to eat 2. Jianwen calls Xiang and passes the information Another scenario 1. Jianwen calls Tevfik with the decision of where and when to eat 2. Tevfik calls Xiang and passes the information Yet another scenario 1. Tevfik calls Xiang with the decision of where and when to eat • Maybe Jianwen also calls Xiang at the same time with a different decision. But the phone is busy.

• Jianwen keeps calling. But Xiang is not going to answer because according to the protocol the next thing Xiang has to do is call Jianwen.

2. Xiang calls Jianwen and passes the information

FCD Protocol: Tevfik’s Behavior

Let’s look at all possible behaviors of Tevfik based on the FCD protocol

Tevfik calls Jianwen with the lunch decision Tevfik is hungry Tevfik calls Xiang with the lunch decision Tevfik receives a call from Xiang telling him the lunch decision that Tevfik has to pass to Jianwen Tevfik receives a call from Jianwen passing him the lunch decision Tevfik receives a call from Xiang passing him the lunch decision

FCD Protocol: Tevfik’s Behavior

Message Labels: !

?

send receive

T->J(D)

Tevfik calls Jianwen with the lunch decision

J->X(P)

Jianwen calls Xiang to pass the decision

!T->J(D) ?J->T(P) !T->X(D) ?J->T(D) ?X->T(P) ?X->T(D) !T->X(P) !T->J(P)

State machines for the FCD Protocol

Tevfik

!T->J(D) ?J->T(P) !T->J(D) ?J->T(D) ?X->T(P) ?X->T(D) !T->X(P) !T->J(P)

Xiang

!X->J(D) ?J->X(P) !X->T(D) ?T->X(P) ?J->X(D) ?T->X(D) !X->T(P) !X->J(P)

Jianwen

!J->T(D) ?T->J(P) !J->X(D) ?T->J(D) ?X->J(P) ?X->J(D) !J->X(P) !J->T(P)

• Three state machines characterizing the behaviors of Tevfik, Xiang and Jianwen according to the FCD protocol

FCD Protocol Has Voicemail Problems

• When the university installed a voicemail system FCD protocol started causing problems – We were showing up at different restaurants at different times! • Example scenario: – Tevfik calls Xiang with the lunch decision – Jianwen also calls Xiang with the lunch decision • The phone is busy (Xiang is talking to Tevfik) so Jianwen leaves a message – Xiang calls Jianwen passing the lunch decision • Jianwen does not answer (he already left for lunch) so Xiang leaves a message – Jianwen shows up at a different restaurant!

• Message sequence is:

T->X(D) J->X(D) X->J(P)

– The messages

J->X(D)

and

X->J(P)

are never consumed • This scenario is not possible without voicemail!

A Different Lunch Protocol

• To fix this problem, Jianwen suggested that we change our lunch protocol as follows: – As the most senior researcher among us Jianwen would make the first call to either Xiang or Tevfik and tell when and where we would meet for lunch. – Then, the receiver of this call would pass the information to the other peer. • Let’s call this protocol the Jianwen Decides (JD) protocol

State machines for the JD Protocol

Tevfik

?J->T(D) ?X->T(P) !J->T(D) !T->X(P)

Jianwen Xiang

?T->X(P) !J->X(D) ?J->X(D) !X->T(P)

• JD protocol works fine with voicemail!

Conversations

• The FCD and JD protocols specify a set of

conversations

– A

conversation

is the sequence of messages generated during an execution of the protocol • We can specify the set of conversations without showing how the peers implement them – we call such a specification a

conversation protocol

FCD and JD Conversation Protocols

FCD Protocol JD Protocol

T->X(D) T->J(D) J->X(P) J->X(D) X->T(D) X->J(D) T->J(P) J->T(P) J->T(D) X->T(P) X->J(P) T->X(P)

Conversation set: {

T->X(D) X->J(P) , T->J(D) J->X(P) , X->T(D) T->J(P) , X->J(D) J->T(P) , J->T(D) T->X(P) , J->X(D)X->T(P)

}

J->T(D) T->X(P) J->X(D) X->T(P)

Conversation set: {

J->T(D) T->X(P) , J->X(D) X->T(P)

}

Observations & Questions

• The implementation of the FCD protocol behaves differently with synchronous and asynchronous communication whereas the implementation of the JD protocol behaves the same. – Can we find a way to identify such implementations?

• The implementation of the FCD protocol does not obey the FCD protocol if asynchronous communication is used whereas the implementation of the JD protocol obeys the JD protocol even if asynchronous communication used.

– Given a conversation protocol can we figure out if there is an implementation which generates the same conversation set?

Conversations, Choreography, Orchestration

• A conversation protocol is a

choreography

specification – A conversation set corresponds to a choreography – A conversation set can be specified using a choreography language such as WS-CDL – One can translate WS-CDL specifications to conversation protocols • Peer state machines are

orchestrations

– A peer state machine can be specified using an orchestration language such as WS-BPEL – One can translate WS-BPEL specifications to peer state machines

A Model for Composite Web Services

• A composite web service consists of – a finite set of

peers

• Lunch example: T, X, J – and a finite set of

messages

• Lunch example (JD protocol) :

J->T(D) , T->X(P) , J->X(D) , X->T(P)

Peer T

T->X(P) X->T(P)

Peer X

J->T(D) J->X(D)

Peer J

Communication Model

• We assume that the messages among the peers are exchanged using

reliable

and

asynchronous

messaging – FIFO and unbounded message queues Peer J

J->T(D) J->T(D)

Peer T • This model is similar to existing messaging platforms such as – JMS (Java Message Service) – Java API for XML messaging (JAXM) – MSMQ (Microsoft Message Queuing Service)

Conversations

• Record the messages in the order they are sent

T->X(P)

Peer T Peer X Generated conversation:

J->T(D) T->X(P)

Peer J • A

conversation

is a sequence of messages generated during an execution

Properties of Conversations

• The notion of conversation enables us to reason about temporal properties of the composite web services • LTL framework extends naturally to conversations – LTL temporal operators X (neXt), U (Until), G (Globally), F (Future) – Atomic properties Predicates on message classes (or contents) Example: G ( payment  F receipt ) •

Model checking problem

: Given an LTL property, does the conversation set satisfy the property?

Bottom-Up vs. Top-Down

Bottom-up approach • Specify the behavior of each peer – For example using an orchestration language such as WS-BPEL • The global communication behavior (conversation set) is implicitly defined based on the composed behavior of the peers • Global communication behavior is hard to understand and analyze Top-down approach • Specify the global communication behavior (conversation set) explicitly as a protocol – For example using a choreography language such as WS-CDL • Ensure that the conversations generated by the peers obey the protocol

Top-Down vs. Bottom-Up

Conversation Protocol

J->T(D) T->X(P) J->X(D)

?

LTL property GF(

T->X(P)



X->T(P)

)

X->T(P)

Peer T

?J->T(D) ?X->T(P) !T->X(P) !J->T(D)

Peer J

!J->X(D)

Peer X

?J->X(D) ?T->X(P)

Input Queue

!X->T(P)

Virtual Watcher ...

?

GF(

T->X(P)



X->T(P)

) LTL property

Conversation Protocols

• Conversation Protocol: – An automaton that accepts the desired conversation set • A conversation protocol is a contract agreed by all peers – Each peer must act according to the protocol • For reactive protocols with infinite message sequences use: – Büchi automata which accept infinite strings • For specifying message contents, use: – Guarded automata – Guards are constraints on the message contents

Synthesize Peer Implementations

• Conversation protocol specifies the global communication behavior – How do we implement the peers?

• How do we obtain the contracts that peers have to obey from the global contract specified by the conversation protocol?

• Project the global protocol to each peer – By dropping unrelated messages for each peer

Question Conversations specified by the conversation protocol

?



Conversations generated by the projected services

If this equality holds the conversation protocol is

realizable

• The JD protocol is realizable • The FCD protocol is not realizable Are there conditions which ensure the equivalence?

Outline

• Motivation: Web Services • Formalizing Conversations • Realizability • Synchronizability • Web Service Analysis Tool • An Application (Reality Check) • Conclusions

Realizability Problem

• Not all conversation protocols are realizable!

A  B:

m1 !m1

?m1

!m2

?m2

C  D:

m2

Conversation protocol Peer A Peer B Peer C Projection of the conversation protocol to the peers Peer D

Conversation “

m2 m1

” will also be generated by all peer implementations which follow the protocol

Another Unrealizable Protocol

A m3 m1 m2 C B m2 A m1 B

B B  A:

m2

A, C A  B:

m1 m3 C

B  A:

m2

A  B:

m1

A  C:

m3 m2 m1 m3 Watcher

Generated conversation:

m2 m1 m3

Realizability Conditions

• • • Three

sufficient

conditions for realizability (no message content)

Lossless join

– Conversation set should be

equivalent

to the join of its projections to each peer

Synchronous compatible

– When the projections are composed synchronously, there should not be a state where a

peer

is

ready to send

a message while the corresponding

receiver

is

not ready to receive Autonomous

– At any state, each peer should be able to do only one of the following:

send

,

receive

or

terminate

(a peer can still choose among multiple messages)

Realizability Conditions

• Following protocols fail one of the three conditions but satisfy the other two A  B:

m1

C  D:

m2

A  B:

m1

C  A:

m2

B  A:

m2

A  B:

m1

A  B:

m1

B  A:

m2

A  C:

m3

Not lossless join Not synchronous compatible Not autonomous

Outline

• Motivation: Web Services • Formalizing Conversations • Realizability • Synchronizability • Web Service Analysis Tool • An Application (Reality Check) • Conclusions

Bottom-Up Approach

• We know that analyzing conversations of composite web services is difficult due to asynchronous communication – Model checking for conversation properties is undecidable even for finite state peers • The question is: – Can we identify the composite web services where asynchronous communication does not create a problem?

• We call such compositions

synchronizable

• The implementation of the JD protocol is synchronizable • The implementation of the FCD protocol is not synchronizable

Three Examples, Example 1

!e

?a

1

!r

1

!r

2

?a

2

r

1 ,

r

2

e !a

?r

1 1

!a

2

?r

2

?e

a

1 ,

a

2 requester server

• Conversation set is regular: (

r 1 a 1

|

r 2 a 2

)*

e

• During all executions the message queues are bounded

Example 2

?a

1

!r

1

!e

?a

2

r

1 ,

r

2

e !a

?r

1 1

!a

2

?r

2

!r

2

a

1 ,

a

2

?e

server requester

• Conversation set is not regular • Queues are not bounded

Example 3

!r

1

?a

!e

!r

2

!r

r

1 ,

r

2

e a

1 ,

a

2

?r

1

?r

!a

?e

?r

2 requester

• Conversation set is regular: (

r 1

• Queues are not bounded |

r 2

|

ra

)*

e server

State Spaces of the Three Examples

1600 1400 1200 1000 800 600 400 200 0 1 3 5 7 9 11 queue length 13 Example 1 Example 2 Example 3

• Verification of Examples 2 and 3 are difficult even if we bound the queue length • How can we distinguish Examples 1 and 3 (with regular conversation sets) from 2?

–

Synchronizability Analysis

Synchronizability Analysis

• A composite web service is not change

synchronizable

if its conversation set does – when

asynchronous

communication communication is replaced with

synchronous

• If a composite web service is synchronizable we can check the properties about its conversations using synchronous communication semantics – For finite state peers this is a finite state model checking problem

Synchronizability Analysis

Sufficient

conditions for synchronizability: • A composite web service is synchronizable, if it satisfies the

synchronous compatible

and

autonomous

conditions • Connection between realizability and synchronizability: – A conversation protocol is realizable if its projections to peers are synchronizable and the protocol itself satisfies the

lossless join

condition

Outline

• Motivation: Web Services • Formalizing Conversations • Realizability • Synchronizability • Web Service Analysis Tool • An Application (Reality Check) • Conclusions

Web Service Analysis Tool (WSAT)

Web Services

BPEL (

bottom-up

) Front End BPEL to GFSA Conversation Protocol (

top-down

) GFSA parser

Intermediate Representation

Guarded automata Analysis Synchronizability Analysis

skip

Guarded automaton Realizability Analysis

fail

Back End GFSA to Promela (

synchronous communication)

GFSA to Promela (

bounded queue) success

GFSA to Promela

(single process, no communication) Verification Languages

Promela

Are These Conditions Too Restrictive?

Problem Set Source ISSTA’04 Name SAS IBM Conv.

CvSetup MetaConv Chat Support Project BPEL Buy Haggle AMAB shipping spec Loan Collaxa.

com Auction StarLoan Cauction #msg 9 4 4 2 5 8 8 2 6 9 6 5 Size #states 12 4 4 4 5 5 10 3 6 9 7 7 #trans.

15 4 6 5 6 8 15 3 6 10 7 6 Pass?

yes yes no yes yes no yes yes yes yes yes yes

Outline

• Motivation: Web Services • Formalizing Conversations • Realizability • Synchronizability • Web Service Analysis Tool • An Application (Reality Check) • Conclusions

Checking Service Implementations

• People write web service implementations using programming languages such as Java, C#, etc.

– Then automatically generate specifications (such as WSDL) Synchronizability Analysis • Synchronizability analysis works on state machine models • How do we generate the state machines from a given Java implementation?

Checking Service Implementations Written In Java

Design for Verification Approach

1.

2.

3.

4.

5.

Use of design patterns that facilitate automated verification Use stateful, behavioral interfaces which isolate the behavior and enable modular verification Use an assume-guarantee style modular verification strategy that separates verification of the behavior from the verification of the conformance to the interface specifications Use a generic model checking technique for interface verification Use domain specific and specialized verification techniques for behavior verification

Peer Controller Pattern

• Eases the development of web services • Uses Java API for XML messaging (JAXM) – Asynchronous communication among peers • Supported by a modular verification technique –

Behavior Verification:

Checks properties of conversations of a web service composed of multiple peers • assuming that peers behave according to their interfaces –

Interface Verification:

interface Checks if each peer behaves according to its

Peer Controller Pattern

ApplicationThread

Communicator

PeerServlet CommunicationInterface CommunicationController StateMachine sessionId ThreadContainer

used at runtime used at interface verification used both times Red Bordered classes are the ones the user has to implement

Verification Framework

Composite Service Thread Peer State Machines Synchronizability Analysis WSAT Promela Translation Conversation Verification Promela Peer State Machine Interface Verification Java Path Finder Peer Code Spin

Modular Design / Modular Verification

Peer Modular Interface Verification Composite Service Interface Machine Interface Machine Conversation Behavior Interface Machine Modular Conversation Verification

Behavior Verification

• Uses WSAT for synchronizability analysis • Uses Spin model checker for conversation verification – Automated translation to Promela using WSAT • Spin is a

finite state

model checker – We have to bound the channel sizes, session numbers, message types • Synchronizability analysis – Enables us to verify web services efficiently by replacing communication channels with channels of size 0 (i.e., synchronous communication) – The verification results hold for unbounded channels

Interface Verification

• If the call sequence to the Communicator class is accepted by the state machine specifying the interface, then the peer implementation conforms to the behavior in the contract • Uses JPF model checker • Isolated check of individual peer implementations – CommunicationController is replaced with CommunicatorInterface – Drivers simulating other peers are automatically generated • State Space reduction – Usage of stubs – Each session is independent • just need to check each peer for one session

Examples

• We used this approach to implement several simple web services – Travel agency – Loan approver – Product ordering • Performance of both interface and behavior verification were reasonable

Interface Verification Interface Verification with JPF for Loan Approver

Threads Customer Loan Approver Risk Assesor T (sec) 8.86

9.65

8.15

M (MB) 3.84

4.7

3.64

Behavior Verification

• Sample Property: Whenever a

request

eventually an

approval

with a small amount is sent, message accepting the loan request will be sent.

• Loan Approval system has 154 reachable states – Queue lengths never exceed 1 • Behavior verification used less than 1 sec and 1.49 MB • SPIN requires restricted domains – Have to bound the channel sizes  bounded message queues • In general there is no guarantee these results will hold for other queue sizes – Using synchronizability analysis we use queues of size 0 and still guarantee that the verification results hold for unbounded queues!

Related Work

• Specification approaches that are similar to conversation protocols – [Parunak ICMAS 96] Visualizing agent conversations: Using enhanced Dooley graphs for agent design and analysis.

– [Hanson, Nandi, Kumaran EDOCC’02] Conversation support for business process integration

Related Work

• Message Sequence Charts (MSC) – [Alur, Etassami, Yannakakis ICSE’00, ICALP’01] MSCs and MSC Graphs Realizability of – [Uchitel, Kramer, Magee ACM TOSEM 04] MSCs Implied Scenarios in

Related Work

• Verification of web services – Petri Nets • [Narayanan, McIlraith WWW’02] Simulation, verification, composition of web services using a Petri net model – Process Algebras • [Foster, Uchitel, Magee, Kramer ASE’03] Using MSC to model BPEL web services which are translated to labeled transition systems and verified using model checking – Model Checking Tools – … • [Nakajima ICWE’04] Model checking Web Service Flow Language specifications using SPIN • See the survey on BPEL verification – [Van Breugel, Koshkina 06] Models and Verification of BPEL http://www.cse.yorku.ca/~franck/research/drafts/

Related Work

• Modeling Choreography & Orchestration – Process algebras, synchronous communication • [Busi, Gorrieri, Guidi, Lucchi, Zavattaro ICSOC’05] • [Qiu, Zhao, Chao, Yang WWW’07] – Activity based (rather than message based) approaches • [Berardi, Calvanese, DeGiacomo, Hull, Mecella VLDB’05]

Current and Future Work

• Dealing with message content and data manipulations – Symbolic analysis and/or automated abstraction • [Fu, Bultan, Su ICWS’04, JWSR] presents some symbolic analysis algorithms but not implemented • [Bultan, Fu, SOCA 2007] diagrams Modeling conversations with Collaboration • [Yu, Wang, Gupta, Bultan FSE’08] BPEL processes Modular verification of interacting • Analyzing realizability of Singularity channel contracts • Generating extra messages to achieve choreography conformance • Analyzing choreographies with dynamically created channels

Conclusions

Applying the results I presented in practice can happen in two ways: • Developing tools for languages that support these concepts – Such as WS-CDL, WS-BPEL – This is the approach we used in building WSAT • Using design patterns that enable extraction of analyzable models – Such as the peer controller pattern – Using the peer controller pattern, we can isolate the interaction behavior, leading to efficient analysis of the interaction behavior – However, interface verification is very hard

Conclusions

• Choreography specification and analysis is an interesting problem • If people really start building systems based on choreography specifications then the problems I discussed will need to be addressed – However, it is not clear to me if the Web services framework will achieve wide adoption – It is possible that WSDL and SOAP will be the only commonly used ones (i.e., the simple client/server model) • Still, choreography specification and analysis problem is likely to resurface in distributed systems in some other context – For example, see Singularity channel contracts

THE END