CS 290C: Formal Models for Web Software
Lectures 15: Choreography Modeling with
Message Sequence Charts and Collaboration
Diagrams
Instructor: Tevfik Bultan
Formal Models for Choreography and Orchestration
• Existing modeling formalisms for behavior and interaction
modeling have been applied to modeling of choreography
and orchestration
• Some examples are:
– Use of message sequence charts (UML sequence
diagrams) for choreography modeling
– Use of UML collaboration diagrams for choreography
modeling
– Use of process algebras for orchestration modeling
– Use of Petri nets for orchestration modeling
Modeling and Analysis
• Typically this type of modeling languages are supported by
analysis and verification tools
• So using these modeling languages for choreography or
orchestration specification also leads to analysis and
verification tools
Using Message Sequence Charts for Choreography
• An MSC shows a particular sequence of messages
exchanged between a number of processes (or objects)
• MSCs show behavior by showing the ordering of message
exchanges
– This is also what we expect a choreography specification
to do
MSCs
• An MSC shows the
ordering of message
send and receive
events
Seller
MarketPlace
Buyer
offerProduct
requireProduct
• The lifeline represents
the time flow and time
progresses from top of
the page to the bottom
of the page
Lifeline
Message
receive
Message
send
MSC extensions
• MSCs can be extended with more constructs to specify
conditional or iterative behavior
Sequence Diagrams
• Focus of control (or activation)
can be shown in sequence
diagrams as a thin rectangle put
on top of the lifeline of an object
• Shows the period of time during
which the given object is in
control of the flow
– From an implementation point
of view, you can think of it as
showing how long an
activation record stays in the
control stack
• It is optional to use focus of
control rectangles in a sequence
diagram
– use it when it adds to
clarity
:Order
:ProductOrder
*prepare()
:StockItem
check()
Iteration
message
condition
focus of control
or activation
lifeline
[check=“true”]
remove()
MSC Frames
Client
Bank
AccountDB
withdrawal
requestBalance
balance
alt
[balance>=withdrawal]
[else]
insufficientFund
updateAccount
•
Frames can be used to
specify conditional behavior
(as seen in the example),
loops, optional behavior etc.
in sequence diagrams
MSC Realizability
• The realizability problem we mentioned for conversation
protocols also exist for MSCs
• An MSC may not be realizable,
– There may not be any possible implementation for the
peers that strictly conform to the event orderings given
by the MSC specification
MSC Realizability
• An unrealizable MSC
A
B
C
D


MSC Realizability
• There are some results that show that
– Realizability of MSCs can be determined
– For unrealizable MSCs one can determine the implied
scenarios when added to the MSC specfication, makes
the set of MSCs realizable
MSCs and Implied Scenarios
• The scenario specified by one of these MSCs implies the
scenario specified by the other one
Seller
MarketPlace
Buyer
Seller
MarketPlace
offerProduct
Buyer
requireProduct
requireProduct
offerProduct
MSCs and MSC graphs
• MSCs are useful for visualizing message exchanges
• However, sometimes a single MSC may not be able to
express all possible interactions
• There are generalizations of MSCs which allow
combination of MSCs as nodes in a graph
– Individual MSCs are joined with transitions
– When two MSCs are joined with a transition, this means
that after the interaction in the source MSC is finished
the interactions in the destination MSC will be executed
MSC graphs
• An MSC vs an MSC graph
– MSC graphs can specify infinite sequences of
interactions
– For some versions of the MSC graphs the realizability
problem is undecidable
A



B
A

B
MSCs and Choreography
• MSCs can be a useful tool for specification of
choreographies
• After writing some MSC specifications for a choreography,
we can use automated analysis techniques for MSCs to
determine the implied scenarios
– This analysis will identify any interaction sequences that
are not yet specified but implied by the existing
specification
MSC Realizability
• Earlier work on realizability of MSCs and MSC extensions
can be applied to choreography analysis
• If a choreography is specified using an MSC, then these
results can be applied to the MSC specification to
determine the realizability of the MSC specification
An Analysis Tool: LTSA-WS
• LTSA-WS is a model based web service analysis tool
• Supports:
– Specification of choreographies using MSCs
– Specification of orchestrations in a process algebra
called FSP
– Supports BPEL to FSP translation
– Supports synthesis of FSP specifications from MSCs
– Allows the developer to check the correspondence
between the BPEL specification and the MSC
specification
Choreography specification with Collaboration
Diagrams
• It is also possible to use collaboration diagrams for
specification of choreographies
• Collaboration diagrams also specify interactions among
processes but they provide a different perspective
compared to MSCs
Example Sequence Diagram
:OrderEntryWindow
:Order
:ProductOrder
:StockItem
prepare()
*prepare()
check()
[check=“true”]
remove()
needsToReorder()
[needsToReorder=“true”]
<<create>>
:ReorderItem
[check=“true”]
<<create>>
:DeliveryItem
Corresponding Collaboration Diagram
object
:OrderEntryWindow
1:prepare()
link
message
Sequence numbers are used
to show the time ordering among
the messages
sequence number
:Order
1.1:*prepare()
:ProductOrder
:StockItem
1.1.1:check()
1.1.2:[check==true]remove()
1.1.3:[check==true]new
:ReorderItem
1.1.2.1:needsToReorder()
1.1.2.2:new
:DeliveryItem
Collaboration Diagrams and Choreography
• Collaboration Diagrams can also be used as a visual
choreography specification language
• Moreover, collaboration diagrams can be converted to state
machine models and analyzed
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
Specifying Conversations
• There are lots of allowed conversations:
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’,
– 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 wellinformed 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