formal models for choreography and orchestration
Post on 31-Dec-2015
44 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
• The lifeline represents the time flow and time progresses from top of the page to the bottom of the page
MarketPlace BuyerSeller
offerProduct
requireProduct
Lifeline
Message send
Message receive
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
:ProductOrder :StockItem
check()
:Order
*prepare()
Iteration
[check=“true”]
remove()messagecondition
focus of controlor activation
lifeline
MSC Frames
Bank AccountDBClient
withdrawal
requestBalance
balance
alt
[balance>=withdrawal]
[else]
updateAccount
insufficientFund
• 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
• 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
MarketPlace BuyerSeller
offerProduct
requireProduct
MarketPlace BuyerSeller
offerProduct
requireProduct
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
A B
A B
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
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
:ProductOrder :StockItem
check()
:Order
*prepare()
[check=“true”]remove()
:OrderEntryWindow
prepare()
:ReorderItem
:DeliveryItem
needsToReorder()
<<create>>
[check=“true”]<<create>>
[needsToReorder=“true”]
Corresponding Collaboration Diagram
:ProductOrder :StockItem
:Order
:OrderEntryWindow
:ReorderItem
:DeliveryItem
1:prepare()
1.1:*prepare()
1.1.1:check() 1.1.2:[check==true]remove()
1.1.2.1:needsToReorder()
1.1.2.2:new
1.1.3:[check==true]new
message
object
link sequence number
Sequence numbers are usedto show the time ordering amongthe messages
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:
• There are also lots of un-allowed conversations:
cdInqorder cdAvail …bookInqorder bookAvail
bookInqorder cdInq
…
cdInqorder bookInq
……
cdAvailorder cdInq
bookInqorder cdAvail
cdInqbookInq cdAvail
……
…
1:order
:Store
:CDSupplier
:Customer
:BookSupplier
A2,B2/2:orderReply1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
Specifying Conversations via Collaboration Diagrams
messagesequencelabel
mustprecede
More On Collaboration Diagramssequencelabel
mustprecede
A2, B2 / 2 : orderReply
message
asynchronouscommunication
synchronouscommunication
cdInquiry [has CD]
conditionalsend
order*iterativesend
1:order
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
A2,B2/2:orderReply
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
final event
A1:cdInquiry B1:bookInquiry
{1,2,A1,A2,B1,B2}
{2,A1,A2,B1,B2}
1:order
{2,A2,B1,B2} {2,A1,A2,B2}
{2,B1,B2} {2,A1,A2}
A2:cdAvailability
{2,A2,B2}
B1:bookAvailability
{2,B2}
{2}
B2:bookAvailabililty
{2,A2}
2 : orderReply
A1:cdInquiry
A1:cdInquiry
B1:bookInquiry
B2:bookAvailability A2:cdAvailability
A2:cdAvailability B2:bookAvailability
Automata (Conversation Protocol)Construction
1:order
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
A2,B2/2:orderReply
1:order
:Store :CDSupplier
:Customer
:BookSupplier
A2,B2/2:orderReply
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
Store
CDSupplier
?cdInquiry
!cdAvailability
!cdInquiry !bookInquiry
?order
?cdAvailability
!cdInquiry!bookInquiry
?cdAvailability
!bookInquiry
?bookAvailability
?bookAvailability
?bookAvailability
!cdInquiry
?cdAvailability
!orderReply
BookSupplier
?bookInquiry
!bookAvailability
Customer
!order
?orderReply
Implementation with Finite State Machines
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
:Customer :Store
1:order
:Shipping :Depot
2:ship
Realizability of Collaboration Diagrams
:Customer :Store
1:order
:Shipping :Depot
3:ship
2:orderInfo
RealizableNot Realizable
Realizability of Collaboration Diagrams
RealizableNot Realizable
:Customer :Store
:Accounting
2:bill
1:order
:Customer :Store
:Accounting
3:bill
1:order
2:orderInfo
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
:Customer :Store
1:order
:Shipping :Depot
2:ship
Realizability of Collaboration Diagrams
:Customer :Store
1:order
:Shipping :Depot
3:ship
2:orderInfo
RealizableNot Realizable
this send eventis not well-informed
Realizability of Collaboration Diagrams
RealizableNot Realizable
:Customer :Store
:Accounting
2:bill
1:order
:Customer :Store
:Accounting
3:bill
1:order
2:orderInfo
this send eventis not well-informed
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
:P :Q
1:x
2:y
:P :Q
2:x
3:y
3:z
1:z
This collaboration diagram set specifies a set of interactions that cannot be specified by any single collaboration diagram
PQ: x
PQ: y
PQ: z
PQ: z
PQ: x
PQ: y
Corresponding conversation protocol
:P :Q1:x
2:y
PQ: x
QP: y
Collaboration Diagram Graphs
• Collaboration diagram graphs are more expressive than collaboration diagram sets
This collaboration diagram graph specifies a set of interactions that cannot be specified by any collaboration diagram set
Corresponding conversation protocol
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
RealizabilityAnalyzer
DependencyGraph
Constructor
AutomataConstructor
ConversationProtocol
Translator
CollaborationDiagrams
Realizability Analysiswith WSAT
PromelaTranslator
LTL Model Checkingwith SPIN
PeerSynthesizer
A Tool for Analyzing Collaboration Diagrams
• 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
top related