Service Choreography and
Orchestration with Conversations
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
bultan@cs.ucsb.edu
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] Peer controller pattern for modular
interaction analysis
Web Services
• The World Wide Web Consortium (W3C) defines a Web service as
– "a software system designed to support interoperable machine-tomachine interaction over a network”
• The basic architecture
Service
Broker
Search
Register
Request
Service
Provider
Service
Requester
Response
Web Services Standards Stack
Registry
Universal Description, Discovery & Integration (UDDI)
Service
Web Services Description Language (WSDL)
Protocol
Simple Object Access Protocol (SOAP)
Type
XML Schema (XSD)
Data
Extensible Markup Language (XML)
Service
Broker
UDDI
Register
Search
WSDL
WSDL
Request
Service
Requester
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
Request
Service
Requester
Client
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: Global specification of interactions among
services
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 behavior specification
– Orchestration as local behavior specification that realizes the global
specification
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 multithreading (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
Web Services Choreography Description Language (WS-CDL)
Orchestration
Service
Web Services Business Process Execution Language (WS-BPEL)
Web Services Description Language (WSDL)
Simple Object Access Protocol (SOAP)
Protocol
Type
XML Schema (XSD)
Extensible Markup Language (XML)
Data
WSDL
WS-BPEL
SOAP
Atomic
Service
Orchestrated
Service
SOAP
SOAP
WS-CDL
WS-BPEL
Orchestrated
Service
WSDL
SOAP
SOAP
Atomic
Service
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
T->J(D)
Message Labels:
!
?
Tevfik calls Jianwen with the lunch decision
send
receive
J->X(P)
Jianwen calls Xiang to pass the decision
!T->J(D)
?J->T(P)
!T->X(D)
?X->T(P)
?J->T(D)
!T->X(P)
?X->T(D)
!T->J(P)
State machines for the FCD Protocol
Tevfik
Xiang
!T->J(D)
?J->T(P)
!T->J(D)
?X->T(P)
!X->J(D)
Jianwen
?J->X(P)
!X->T(D) ?T->X(P)
?J->T(D)
?X->T(D)
?J->X(D)
!T->X(P)
!T->J(P)
!X->T(P)
?T->X(D)
!X->J(P)
!J->T(D)
?T->J(P)
!J->X(D)
?X->J(P)
?T->J(D)
!J->X(P)
?X->J(D)
!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)
Jianwen
?X->T(P)
Xiang
?J->X(D)
!J->T(D)
?T->X(P)
!J->X(D)
!T->X(P)
• JD protocol works fine with voicemail!
!X->T(P)
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
JD Protocol
FCD 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)
X->J(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)
J->X(D)
J->T(D)
X->T(P)
T->X(P)
X->T(P)
T->X(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)
T->X(P)
Peer T
Peer X
X->T(P)
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
Peer T
T->X(P)
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)
J->X(D)
?
T->X(P)
Peer T
?X->T(P)
LTL property
GF(T->X(P)  X->T(P))
X->T(P)
Peer X
Peer J
!J->T(D)
?T->X(P)
?J->X(D)
?J->T(D)
!T->X(P)
Virtual Watcher
!J->X(D)
!X->T(P)
... ?
GF(T->X(P)  X->T(P))
LTL property
Input
Queue
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
Peer A
Conversation
protocol
Peer B
Peer C
Peer D
Projection of the conversation
protocol to the peers
Conversation “m2 m1” will also be generated by all peer
implementations which follow the protocol
Another Unrealizable Protocol
m1
A
B
m2
m3
B
BA: m2
m2
A
m1
B
m3
C
C
m2
m1
m3
A, C
AB: m1
Watcher
BA: m2
AB: m1
AC: m3
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
BA: m2
AB: m1
AB: m1
BA: m2
CD: m2
CA: m2
AB: m1
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
r1, r2
!e
?a1
?a2
!r1 !r2
e
!a1
!a2
?r1
a1, a2
requester
?r2
?e
server
• Conversation set is regular: (r1a1 | r2a2)* e
• During all executions the message queues are bounded
Example 2
r1, r2
!e
?a1
?a2
!r1
!r2
e
a1, a2
requester
• Conversation set is not regular
• Queues are not bounded
!a1
!a2
?r1
?r2
?e
server
Example 3
!e !r
2
!r1
r1, r2
e
?a
!r
?r
?r1
a1, a2
requester
• Conversation set is regular: (r1 | r2 | ra)* e
• Queues are not bounded
!a
?r2
?e
server
# of states in thousands
State Spaces of the Three Examples
1600
1400
1200
1000
Example 1
Example 2
Example 3
800
600
400
200
13
11
9
7
5
3
1
0
queue length
• 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 synchronizable if its conversation set does
not change
– when asynchronous communication is replaced with synchronous
communication
• 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
Analysis
Back End
Intermediate
Representation
Guarded
automata
GFSA to Promela
Synchronizability
Analysis
GFSA
parser
Guarded
automaton
(synchronous
communication)
GFSA to Promela
skip
Conversation
Protocol
(top-down)
Verification
Languages
(bounded queue)
Realizability
Analysis
fail
success GFSA to Promela
(single process,
no communication)
Promela
Are These Conditions Too Restrictive?
Problem Set
Source
Name
ISSTA’04
SAS
CvSetup
MetaConv
IBM
Chat
Conv.
Buy
Support
Haggle
Project
AMAB
BPEL
shipping
Loan
spec
Collaxa.
com
Auction
StarLoan
Cauction
#msg
9
4
4
2
5
8
8
2
6
Size
#states
12
4
4
4
5
5
10
3
6
Pass?
#trans.
15
4
6
5
6
8
15
3
6
yes
yes
no
yes
yes
no
yes
yes
yes
9
6
5
9
7
7
10
7
6
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. Use of design patterns that facilitate automated verification
2. Use stateful, behavioral interfaces which isolate the behavior and
enable modular verification
3. Use an assume-guarantee style modular verification strategy that
separates verification of the behavior from the verification of the
conformance to the interface specifications
4. Use a generic model checking technique for interface verification
5. 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: Checks if each peer behaves according to its
interface
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
Thread
Peer
Thread
WSAT
State
Machines
Promela
Translation
Synchronizability
Analysis
Composite
Service
Peer
State
Machine
Conversation
Verification
Interface
Verification
Spin
Java
Path Finder
Peer
Code
Promela
Modular Design / Modular Verification
Peer Modular Interface Verification
Peer 1
Peer 2
Peer n
Peer n
interface
Peer 2
interface
interface
Peer 1
Composite Service
Interface
Machine
Interface
Machine
Interface
Machine
Conversation Behavior
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
T (sec)
M (MB)
Customer
8.86
3.84
Loan
Approver
9.65
4.7
Risk
Assesor
8.15
3.64
Behavior Verification
• Sample Property: Whenever a request with a small amount is sent,
eventually an approval 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] Realizability of
MSCs and MSC Graphs
– [Uchitel, Kramer, Magee ACM TOSEM 04] Implied Scenarios in
MSCs
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] Modeling conversations with Collaboration
diagrams
• [Yu, Wang, Gupta, Bultan FSE’08] Modular verification of interacting
BPEL processes
• 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