A Tool for Choreography Analysis Using
Collaboration Diagrams
Tevfik Bultan
Chris Ferguson
Xiang Fu
University of California
Santa Barbara
University of California
Santa Barbara
Hofstra University
Outline
• Modeling Service Interactions as Conversations
• Specification of Conversations Using Collaboration Diagrams
• Analyzing Collaboration Diagrams
• Collaboration Diagram Extensions
• Tool Architecture and Experiments
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”
• Web services support basic client/server style interactions
WSDL
Request
Service
Requester
Client
SOAP
Response
Service
Provider
Server
Service Interactions
• One of the main goals of service oriented computing is to facilitate
integration and composition of services
• Modeling, specifying and analyzing interactions among services are
crucial problems that need to be addressed in order to achieve this goal
• Different service developers that want their services to take part in a
composition have to agree on how services will interact with each other
• Web Service-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.”
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
An Example
• Assume four peers (individual services):
– Customer, Store, CDSupplier, BookSupplier
• Workflow:
– Customer sends an order to the Store
– Store checks the availability of the CDs and the books in the order
by sending a cdInquiry message to CDSupplier and a bookInquiry
message to BookSupplier
– CDSupplier and BookSupplier send the cdAvailability and
bookAvailibility back to the Store
– Store sends orderReply to the Customer
A Model for Composite Web Services
• A composite web service consists of
– a finite set of peers
• Customer, Store, CDSupplier, BookSupplier
– and a finite set of messages
• Customer  Store: order
• Store  CDSupplier: cdInquiry
• Store  BookSupplier: bookInquiry
• CDSupplier  Store: cdAvailability
• BookSupplier  Store: bookAvailability
• Store  Customer: orderReply
Asynchronous Communication Model
• We assume that the messages among the peers are exchanged using
reliable and asynchronous messaging
– FIFO and unbounded message queues
Customer
order order
Store
Modeling Interactions as Conversations
• A conversation is the global sequence of messages recorded in the
order they are sent [Bultan, Fu, Hull, Su WWW’03]
order
Customer
Store
cdAvailability
cdInquiry
CDStore
Conversation
order
cdInquiry
cdAvailability
…
Specifying Conversations
• There are lots of allowed conversations for our simple example:
order
cdInq
cdAvail
order
bookInq
bookAvail
order
bookInq
cdInq
order
cdInq
bookInq
…
…
…
…
• There are also lots of un-allowed conversations:
order
cdAvail
cdInq
order
bookInq
cdAvail
bookInq
cdInq
cdAvail
…
…
…
Specifying Conversations via Collaboration Diagrams
:Customer
must
precede
sequence
message
label
1/A1:cdInquiry
1:order
A2,B2/2:orderReply
:CDSupplier
A2:cdAvailability
:Store
1/B1:bookInquiry
:BookSupplier
B2:bookAvailability
More On Collaboration Diagrams
must
precede
sequence
label
message
A2, B2 / 2 : orderReply
asynchronous
communication
conditional
send
cdInquiry [has CD]
synchronous
communication
order*
iterative
send
Dependency Among Message Send Events
• Message send events are ordered based on two rules
– Implicit: The sequence labels that have the same prefix must be
ordered based on their sequence number
– Explicit: The events listed before “/” must precede the current event
initial event
1:order
1/A1:cdInquiry
1/B1:bookInquiry
A2:cdAvailability
B2:bookAvailability
A2,B2/2:orderReply
final event
1:order
{1,2,A1,A2,B1,B2}
1/A1:cdInquiry
1/B1:bookInquiry
1:order
A2:cdAvailability
B2:bookAvailability
A2,B2/2:orderReply
{2,A1,A2,B1,B2}
A1:cdInquiry
Automata
(Conversation Protocol)
Construction
B1:bookInquiry
{2,A2,B1,B2}
A2:cdAvailability
{2,A1,A2,B2}
B2:bookAvailabililty
B1:bookAvailability
A1:cdInquiry
{2,B1,B2}
{2,A2,B2}
A2:cdAvailability
{2,A1,A2}
B2:bookAvailability
B1:bookInquiry
A1:cdInquiry
{2,B2}
{2,A2}
:Customer
A2:cdAvailability
B2:bookAvailability
1:order
A2,B2/2:orderReply
{2}
1/A1:cdInquiry
A2:cdAvailability
:CDSupplier
2 : orderReply
:Store
1/B1:bookInquiry
:BookSupplier
B2:bookAvailability

Implementation with Finite State Machines
Store
Customer
?order
!cdInquiry
?orderReply
!bookInquiry
!order
!bookInquiry
!cdInquiry
?cdAvailability
?bookAvailability
!bookInquiry
CDSupplier
!cdAvailability
!cdInquiry
?cdAvailability
?bookAvailability
?cdInquiry
?bookAvailability
BookSupplier
?cdAvailability
!orderReply
!bookAvailability
?bookInquiry
Realizability of Collaboration Diagrams
• Not all collaboration diagrams are realizable!
• It is possible to specify interactions that cannot be realized by any peer
implementation
• This is a problem!
– Assume that we want to specify how several services should interact
with each other
– If we write a specification that is not realizable
• the implementation will not be faithful to the specification no
matter what we do
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
:Store
:Store
2:orderInfo
2:ship
:Shipping
:Customer
:Depot
3:ship
:Shipping
:Depot
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
2:bill
:Store
:Customer
:Store
3:bill
2:orderInfo
:Accounting
:Accounting
A Sufficient Condition for Realizability
• We call a send event e well informed
– If e is an initial event
– Otherwise, let e’ be an immediate predecessor of e
• If e’ is a synchronous send or not conditional or iterative
– sender for e should be either the receiver or sender for e’
• If e’ is an asynchronous send and conditional or iterative
– sender for e should be the sender for e’ and the receiver for e
should be the receiver for e’
– e should not be conditional or iterative,
– e and e’ should not send the same message
• A collaboration diagram is realizable if all its events are well-informed
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
:Store
:Store
2:orderInfo
2:ship
:Shipping
:Customer
:Depot
3:ship
:Shipping
this send event
is not well-informed
:Depot
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
2:bill
:Store
this send event
is not well-informed
:Customer
:Store
3:bill
2:orderInfo
:Accounting
:Accounting
Collaboration Diagram Extensions
• Collaboration Diagram Sets
– The conversation set if the union of the conversation sets of each
collaboration diagram in the collaboration diagram set
• Collaboration Diagram Graphs
– Conversation set is obtained by concatenating the conversation sets
of different collaboration diagrams according to the collaboration
diagram graph
Collaboration Diagram Sets
• Collaboration diagram sets are more expressive than individual
collaboration diagrams
1:x
2:y
:P
:Q
PQ: x
PQ: z
3:z
PQ: y
2:x
3:y
:P
:Q
PQ: z
PQ: x
PQ: y
1:z
Corresponding conversation protocol
This collaboration diagram set specifies a
set of interactions that cannot be specified
by any single collaboration diagram
Collaboration Diagram Graphs
• Collaboration diagram graphs are more expressive than collaboration
diagram sets
PQ: x
1:x
:P

:Q
2:y
QP: y
Corresponding conversation protocol
This collaboration diagram graph specifies
a set of interactions that cannot be specified
by any collaboration diagram set
Analyzing Collaboration Diagram Extensions
• Realizability of collaboration diagram sets and collaboration diagram
graphs cannot be determined using the well-informed event rule we
discussed earlier
• However, collaboration diagram sets and collaboration diagram graphs
can be converted to conversation protocols
• We can use the earlier results on realizability of conversation protocols
to determine realizability of collaboration diagram sets and collaboration
diagram graphs
A Tool for Analyzing Collaboration Diagrams
Promela
Translator
Collaboration
Diagrams
LTL Model
Checking
with SPIN
Dependency
Graph
Constructor
Automata
Constructor
Peer
Synthesizer
Realizability
Analyzer
Conversation
Protocol
Translator
Realizability
Analysis
with WSAT
• The tool is implemented as an Add-In to Sparx Systems Enterprise
Architect UML Editor
Experiments
Problem Instance
Realizability 1
Realizability 2
States
Factory Manager
YES
NO
383
Order Item
NO
NO
42 (after fix)
Purchase Order
YES
NO
246
Company Store
YES
YES
22
Information Exchange
YES
YES
50
Voting Booth
NO
NO
59 (after fix)
Causality Model
YES
NO
116
Order Item Example
orderWindow:
OrderEntryWindow
1:prepareOrder
order:Order
2:prepareOrderLine
5:needToReorder
3:check
macallanLine:
OrderLine
macallanStock:
StockItem
4:remove?
7:newDelivery?
deliveryItem:
DeliveryItem
6:newReOrder
reorderItem:
ReOrderItem
Conclusions
• Collaboration diagrams are an appropriate specification mechanism for
service conversations
– There are conditions which guarantee realizability of collaboration
diagrams
• Collaboration diagrams can be generalized to collaboration diagram sets
and collaboration diagram graphs
– Results on realizability of conversation protocols can be used to
determine realizability of collaboration diagram sets and
collaboration diagram graphs
• We implemented these results in a collaboration diagram development
tool
THE END
Related Work
• Message Sequence Charts (MSC)
– Realizability [Alur, Etassami, Yannakakis ICSE 00, ICALP 01]
– Implied scenarios [Uchitel, Kramer, Magee ACM TOSEM 04]
• Modeling agent conversations with Dooley graphs [Parunak, ICMAS 96]
• Conversation protocols [Fu, Bultan, Hull, Su WWW 03] [Fu, Bultan, Su,
TCS 04, IEEE TSE 05]
• Modeling services using UML diagrams
– [Benatallah, Sheng, Dumas, IEEE IC 03]
– [Skogan, Gronmo, Solheim IEEE EDOCC 04]
– [Blake ICWS 06]
– …
1:x
:P
1:y
:Q
2:y
:P
:Q
2:x
3:z
:R
:R
An unrealizable Collaboration Diagram Set which consists of
realizable collaboration diagrams.
1:y
1:x
:P
:Q
2:y
:R
:P
3:z
:Q
2:x
An unrealizable Collaboration Diagram Set which consists of
realizable collaboration diagrams.
:R
1:x
:P
2:x
:Q
:P
2:y
:R
:Q
1:y
:S
:R
:S
A realizable Collaboration diagram set which consists
of unrealizable collaboration diagrams