Formal Models for Choreography and Orchestration

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

A B DC

MSC Realizability

• An unrealizable MSC

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


offerProduct

requireProduct


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


check()

:Order

*prepare()

[check=“true”]remove()

:OrderEntryWindow

prepare()

:ReorderItem

:DeliveryItem

needsToReorder()

<<create>>

[check=“true”]<<create>>

[needsToReorder=“true”]

Corresponding Collaboration Diagram


: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


:Customer :Store

1:order

:Shipping :Depot

3:ship

2:orderInfo

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


:Customer :Store

1:order

:Shipping :Depot

3:ship

2:orderInfo


this send eventis not well-informed



: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

orderWindow:OrderEntryWindow

order:Order

macallanLine:OrderLine

deliveryItem:DeliveryItem

macallanStock:StockItem

reorderItem:ReOrderItem

1:prepareOrder

2:prepareOrderLine

3:check

4:remove?

5:needToReorder

6:newReOrder7:newDelivery?

Order Item Example

Formal Models for Choreography and Orchestration

Documents

Transcript of Formal Models for Choreography and Orchestration