CS 290C: Formal Models for Web Software

Lectures 14: Formal Modeling and Analysis of Orchestration and Choreography Specifications

Instructor: Tevfik Bultan

Formal Modeling and Verification of Web services

• There has been a lot of work on formal modeling and verification of web services

• These efforts mostly focused on analyzing composite services specified using orchestration and choreography languages

• For example, there has been work on formally modeling BPEL and WS-CDL specifications as state machines and then automatically verifying their properties using model checking

• I will give an overview of some work in this area

Formal Modeling and Analysis of Orchestration

• Basic Idea:– Automatically convert BPEL specifications to state

machine models– Automatically analyze state machine models using a

verification tool

• This approach has been implemented by developing tools that translate BPEL specifications to Promela

BPEL to State Machine Translation

Each atomic BPEL activities can be translated to a state machine single entry, single exit, and may have several exception

exits Transitions have guards (extended state machine)

<assign … > <copy>

<from = “yes” /><to var = “aprvInfo” part = “accept”

</copy></assign>

[apprvInfo/accept := ‘yes’]

<receive … operation = “approve” variable = “request”

/>

?? approve_In

[request := approve_In]

BPEL to State Machine Translation

<scope> <invoke … operation="approve”, invar="request“,

outvar="aprvInfo” /> <catch … faultname="loanfault“> < ... handler1 ... /> </catch></scope>

handler1

!! approve_In

?? approve_Out

? ? loanfaultloanfault

[approve_In := request]

[aprvInfo :=

approve_Out]

BPEL to State Machine Translation

• Control flow constructs can be handled by composing state machines

<sequence …/>

</sequence …/> <… act2…/> <… act1…/>

act1 act2

fault2fault1

</flow …/>

<flow …/> <… act1 …><… act2 … > act1 act2

product

BPEL to State Machine Translation

• We can translate BPEL specifications to a state machine representation by recursively applying translation rules like we describe above

• However, BPEL specifications do not only have control flow constructs– they can also contain branch conditions and assignment

statements expressed using Xpath– So we have to use an extended state machine

representation which keeps the branch conditions, assignments, etc.

Extended State Machines

• Use an extended state machine model where the transitions can gave guards and updates– Guards and updates are on XML messages and use

MSL and XPath

• MSL for declaring message types– MSL (Model Schema Language) is a compact formal

model language which captures core features of XML Schema

• XPath expressions for guards– XPath is a language for writing expressions (queries)

that navigate through XML trees and return a set of answer nodes

Translating Extended State Machines to Promela

• Translate the extended state machine model to Promela and use the SPIN model checker to verify the properties of the orchestration

• SPIN is a finite state model checker– Need to restrict XML message contents to finite domains

• Translating extended state machine models to Promela– First, translate MSL type declarations to Promela type

declarations– Then, translate XPath expressions to Promela code

Mapping MSL types to Promela

• Basic types – integer and boolean types are mapped to Promela basic

types int and bool – We only allow constant string values and strings are

mapped to enumerated type (mtype) in Promela

• Other type constructors are handled using – structured types (declared using typedef) in Promela– or arrays

Mapping MSL type constructors to Promela

• t [ g ] is translated to a typedef declaration

• g { m , n } is translated to an array declaration

• g1 , g2 is translated to a sequence of type declarations

• g1 | g2 is translated to a sequence of type declarations and an enumerated variable which is used to record which type is chosen

• g1 & g2 unordered type sequence can cause state-space explosion, so it is better to convert them to an ordered sequence after choosing a fixed ordering

Example

Register[ investorID[string] , requestList[ stockID[int]{1,3} ] , payment[ creditCardNum[int] | accountNum[int] ]]

typedef t1_investorID{ mtype stringvalue;}typedef t2_stockID{int intvalue;}typedef t3_requestList{ t2_stockID stockID [3]; int stockID_occ;}typedef t4_accountNum{int intvalue;}typedef t5_creditCard{int intvalue;}mtype {m_accountNum, m_creditCard}typedef t6_payment{ t4_accountNum accountNum; t5_creditCard creditCard; mtype choice;}typedef Register{ t1_investorID investorID; t3_requestList requestList; t6_payment payment;}

XPath to Promela

• Generate code that evaluates the XPath expression

• Traverse the XPath expression from left to right– Code generated in each step is inserted into the BLANK

spaces left in the code from the previous step– A tree representation of the MSL type is used to keep

track of the context of the generated code

• Uses two data structures– Type tree shows the structure of the corresponding MSL

type– Abstract statements which are mapped to Promela code

$request//stockID=$register//stockID[int()>5][position()=last()]

/* result of the XPath expression */ bool bResult = false; /* results of the predicates 1, 2, and 1 resp. */ bool bRes1, bRes2, bRes3; /* index, position(), last(), index, position() */ int i1, i2, i3, i4, i5;

i2=1; /* pre-calculate the value of last(), store in i3 */ i4=0; i5=1; i3=0; do :: i4 < v_register.requestList.stockID_occ -> /* compute first predicate */ bRes3 = false; if :: v_register.requestList.stockID[i4].intvalue>5 -> bRes3 = true :: else -> skip fi; if :: bRes3 -> i5++; i3++; :: else -> skip fi; i4++;

:: else -> break; od;

$request//stockID=$register//stockID[int()>5][position()=last()]

i1=0; do :: i1 < v_register.requestList.stockID_occ -> bRes1 = false; if :: v_register.requestList.stockID[i1].intvalue>5 -> bRes1 = true :: else -> skip fi; if :: bRes1 -> bRes2 = false; if :: (i2 == i3) -> bRes2 = true; :: else -> skip fi; if :: bRes2 -> if :: (v_request.stockID.intvalue == v_register.requestList.stockID[i1].intvalue) -> bResult = true; :: else -> skip fi :: else -> skip fi; i2++; :: else -> skip fi; i1++; :: else -> break; od;

Model Checking Using Promela

• Can analyze the SAS example from the previous lecture– 3 peers: Investor, Broker, ResearchDept.

• An error was found in the specification using Spin– Investor Broker: a registerList of stockIDs– Broker ResearchDept.:

• relay request (1 stockID per request)• find the stockID in the latest request, send its

subsequent stockID in registerList– Repeating stockID will cause error.– Only discoverable by analysis of XPath expressions

Orchestration Verification

• What we have discussed was an automated verification approach for orchestrations written in BPEL

• The basic idea is to – represent BPEL specifications as extended sate

machines– generate Promela specifications for these extended

state machines (by bounding the data)– and verify their properties using the Spin model checker

• The question is can we use a similar approach for services which involve interaction among multiple processes (for example an orchestrated service interacting with another orchestrated service)

• Let’s first recall the orchestration vs. choreography issue

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

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

Choreography Specifications & State Machines

• Choreography specifications can also be translated to state machine models like the orchestration specifications

• As we did for BPEL specifications, given a WS-CDL specification– map the basic actions of a choreography (such as an

assignment or message exchange) to transitions of basic state machines

– map control flow constructs to various compositions of state machines

SAS Choreography Model

1

23

4

6

5

7 8

10

9

12 11

register

reject

terminate

accept

request

report ack

request

report

ackcancel

bill cancel

bill

terminate

• State machine representation of the SAS choreography model

Another Issue: Asynchronous Messages

• Remember that one of the goals in web services is to achieve loose coupling among services that interact with each other

• One way to achieve this message-based interactions and asynchronous messaging

• Asynchronous messaging:– Sender does not have to wait for the receiver

• Message is inserted to a message queue• Messaging platform guarantees the delivery of the

message

Asynchronous Messages

• 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

Choreography Analysis

• So, we can assume the following formal model– We have a choreography model which corresponds to a

state machine and characterizes the ordering of interactions (message-exchanges) among different services

– We can also assume that each service participating in a choreography is also specified as a state machine model (maybe extracted from an orchestration specification)

– We also assume that different services participating in the choreography are interacting with asynchronous messages

• Given this framework, some interesting analysis and verification problems arise

Choreography Analysis

• I will explain issues about choreography analysis using an example which describes how two professors and a grad student go to lunch at UCSB

Going to Lunch at UCSB

• Before Xiang graduated from 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

FCD Protocol Scenarios

• 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

Tevfik calls Jianwen with the lunch decision

Let’s look at all possible behaviors of Tevfik based on the FCD protocol

Tevfik is hungry

Tevfik calls Xiang with the lunch decision

Tevfik receives a call from Jianwen passing him the

lunch decision

Tevfik receives a call from Xiang passing him the

lunch decisionTevfik receives a call from Xiang telling him the lunch decision that Tevfik has to pass to

Jianwen

FCD Protocol: Tevfik’s Behavior

!T->J(D)

!T->X(D)

?J->T(P)

?X->T(P)

?X->T(D)?J->T(D)

!T->J(P)!T->X(P)

T->J(D) Tevfik calls Jianwen with the lunch decision

Message Labels:

! send

? receiveJ->X(P)

Jianwen calls Xiang to pass the decision

!T->J(D)

?X->T(D)

!T->J(D)

?J->T(D)

!T->X(P)

Tevfik

!T->J(P)

?J->T(P)

?X->T(P)

!X->J(D)

?T->X(D)

!X->T(D)

?J->X(D)

!X->T(P)

Xiang

!X->J(P)

?J->X(P)

?T->X(P)

!J->T(D)

?X->J(D)

!J->X(D)

?T->J(D)

!J->X(P)

Jianwen

!J->T(P)

?T->J(P)

?X->J(P)

State machines for the FCD Protocol

• 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 Problem 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

?X->T(P)?J->T(D)

!T->X(P)

Tevfik XiangJianwen

?T->X(P)?J->X(D)

!X->T(P)

!J->T(D) !J->X(D)

State machines for the JD Protocol

• JD protocol works fine with voicemail!

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

T->J(D)

T->X(D)

X->J(P)

X->T(D) X->J(D)J->T(D)

J->X(D)

J->X(P)T->J(P) J->T(P)

T->X(P)

X->T(P)

FCD Protocol

J->T(D) J->X(D)

T->X(P) X->T(P)

JD Protocol

FCD and JD Conversation Protocols

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) }

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

T->X(P)

X->T(P)

J->X(D)J->T(D)

Peer T

Peer J

Peer X

• 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)

Communication Model

• We assume that the messages among the peers are exchanged using reliable and asynchronous messaging– FIFO and unbounded message queues

• 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)

J->T(D)Peer J Peer TJ->T(D)

Conversations

• Record the messages in the order they are sent

Generated conversation:

• A conversation is a sequence of messages generated during an execution

T->X(P)

J->T(D)

Peer T

Peer J

Peer X

T->X(P)J->T(D)

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

ConversationProtocol GF(T->X(P) X->T(P))

? LTL property

InputQueue

...Virtual Watcher?

LTL property

Peer T Peer XPeer J

J->T(D) J->X(D)

T->X(P) X->T(P)

GF(T->X(P) X->T(P))

!J->T(D)

!J->X(D)

?X->T(P)

?J->T(D)

!T->X(P)

?T->X(P)?J->X(D)

!X->T(P)

Top-Down vs. Bottom-Up

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

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?

Conversations generated by the projected services

Conversations specified by the conversation protocol

?

Realizability Problem

• Not all conversation protocols are realizable!

AB: m1

CD: m2

Conversation protocol

Conversation “m2 m1m2 m1” will also be generated by all peer implementations which follow the protocol

!m1 ?m1 !m2 ?m2

Peer A Peer B Peer C Peer D

Projection of the conversation protocol to the peers

Another Unrealizable Protocol

m3

m1

m2

m2 m1 m3

m1

m2

m3AB: m1BA: m2

AC: m3

BA: m2

AB: m1

A

B

C

m1m2

m3

Watcher

A B

C

Generated conversation:

B A, C

Three Unrealizable Protocols

AB: m1

CD: m2

AB: m1BA: m2

AC: m3

BA: m2

AB: m1

• Following conversation protocols are unrealizable

AB: m1

CA: m2

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

requester server

!r2

?a1 ?a2

!e

!r1

• Conversation set is regular: (Conversation set is regular: (rr11aa11 | | rr22aa22)* )* ee

• During all executions the message queues are bounded

r1, r2

a1, a2

e ?r1

!a1 !a2

?r2

?e

Example 2

• Conversation set is not regularConversation set is not regular• Queues are not bounded

requester server

!r2

?a1 ?a2

!e

!r1

r1, r2

a1, a2

e ?r1

!a1 !a2

?r2

?e

Example 3

• Conversation set is regular: (Conversation set is regular: (rr11 | | rr22 | | rara)* )* ee

• Queues are not bounded

requester server

!r2

?a !r

!e!r1

r1, r2

a1, a2

e

?r1 ?r2

?e

?r !a

State Spaces of the Three Examples

0

200

400

600

800

1000

1200

1400

1600

1 3 5 7 9 11 13

Example 1

Example 2

Example 3

queue length

# o

f st

ates

in

th

ou

san

ds

• 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

Realizability and Synchronizability Checking

• It turns out we can automatically check these conditions• Synchronizability can be checked by comparing the

behavior of synchronously communicating system with the system communicating with 1-bounded buffers– If synchronous communication and 1-bounded

communication give the same behaviors then the system is sycnrhonizable

• Realizability can be checked by using synchronizability– A conversation protocol is realizable if its projection is

synchronizable and all messages are eventually received

Implementation and Results

• Implemented using CADP toolbox– Automatically generate a LOTOS specification for the

conversation protocol– Generate determinized projections (in LOTOS)– Check equivalence of the 1-bounded asynchronous

system and the conversation protocol• Checked realizability of

– 9 web service choreography specifications• 8 are realizable

– 9 collaboration diagrams• 8 are realizable

– 86 Singularity channel contracts• 84 are realizable

• Realizability check takes about 14 seconds on average