Analysis of Communication Models in Web Service Compositions Marco Pistore [email protected] University of Trento Joint work with Raman Kazhamiakin.

Analysis of Communication Models in Web Service Compositions

Marco [email protected]

University of Trento

Joint work with Raman Kazhamiakin and Luca Santuari

24.05.2006 WWW'06 - Edinburgh

Context

• ASTRO project ASTRO project • Provide tools that support the design and execution of service compositionsservice compositions

• Component services are stateful and long-running (e.g., WS-BPELWS-BPEL services)

• One of the techniques provided by ASTRO is formal verification formal verification• Formal check of the correctness of the composition behavior correctness of the composition behavior

• Interaction Interaction mechanisms are complex and implementation-dependent• Complex queues and message management mechanisms

• Scenarios with message overpasses and losses are possible

• Diversity of implementations

• Necessity to define an appropriate formal communication modelscommunication models• Tradeoff between expressiveness and complexity of the analysis

1


Motivating example

3


Motivating example: Virtual Travel Agency

• Provide combined flight and hotel booking service• Integrate separate HotelHotel and FlightFlight booking services• Participants are represented with their BPELBPEL specifications

VTAUser

Hotel

Flight

Request

Ack/NAck

Offer/NA

Ticket

Flight Request

Flight Offer/NA

Flight Ack/Nack

Flight Ticket

Hotel Request

Hotel Offer/NA

Hotel Ack/Nack

Hotel Ticket

3


VTA Processes

invoke(Request)

on message (NA)

on message(Offer)

case (NAck) case (Ack)

invoke(NAck)

invoke(Ack)

receive(Ticket)

receive(Request)

on message (F.NA)

on message(F.Offer)

invoke(F.Request)

invoke(NA)

invoke(H.Request)

on message (H.NA)

on message(H.Offer)

invoke(F.NAck)

invoke(Offer)

invoke(NA)

on message (NAck)

on message(Ack)

invoke(F.Ack)

receive(F.Ticket)

invoke(H.Ack)

receive(H.Ticket)

invoke(Ticket)

invoke(F.NAck)

invoke(H.NAck)

receive(F.Request)

case (Not Available)

case (Available)

invoke(F.NA)

invoke(F.Offer)

on message (F.NAck)

on message(F.Ack)

invoke(F.Ticket)

receive(H.Request)


case (Available)

invoke(H.NA)

invoke(H.Offer)

on message (H.NAck)

on message(H.Ack)

invoke(H.Ticket)

4

UserUser

VTAVTA

HotelHotel

FlightFlight


Composition Properties

• The composition is synchronizablesynchronizable• At any moment of time only one component emits a message• The receiver is immediately ready to consume the message

• Synchronous communication modelSynchronous communication model• Components synchronizesynchronize on shared actions• Efficient reasoning techniques• Universally used in verification tools for web service compositions

• The synchronous communication model is adequateadequate for synchronizable compositions

• The presence of queues in the implementation does not add new behaviors

• Not applicable to the wide range of systems• E.g. cancellation cancellation scenarios

5


VTA Processes – Cancellation

invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)

on message (F.Cancel)

on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(Ticket)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)

on message(F.Ticket)

invoke(YES)

invoke(Ticket)

. . . . . .

receive(F.Cancel)

invoke(F.YES)

6

UserUser

VTAVTAFlightFlight



Deadlock?Deadlock?

invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(Ticket)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)


invoke(YES)

invoke(Ticket)

. . . . . .

receive(F.Cancel)

invoke(F.YES)

6

UserUser

VTAVTAFlightFlight



Deadlock?Deadlock?

No!

invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(Ticket)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)


invoke(YES)

invoke(Ticket)

. . . . . .

receive(F.Cancel)

invoke(F.YES)

6

UserUser

VTAVTAFlightFlight


invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(Ticket)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)


invoke(YES)

invoke(Ticket)

. . . . . .

receive(F.Cancel)

invoke(F.YES)


6

UserUser

VTAVTAFlightFlight



• The synchronous communication model is violated• The concurrent emission of messages is possible in the same time point: F.Cancel

and F.Ticket

• The real execution is correct• Engines support non-blocking non-blocking message emissions and message queues• In the scenario, all message are eventually consumed, and cancellation is

performed correctly

• An adequate communication modeladequate communication model is needed to formally verify this scenario!

• AsynchronousAsynchronous orderedordered communication model• Emission and reception of a message do not have to happen at the same timetime• The orderorder of message emission and the order of message reception between two

processes should be the same (no message overpass)• Intuitively: an ordered queue between each pair of processes

7


VTA Processes – Complex Cancellation

invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(NO)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)

on message(F.NO)

invoke(YES)

invoke(Ticket)

. . .

. . .

receive(F.Cancel)

invoke(F.YES)

receive(Ticket)

receive(F.Ticket)

invoke(NO)

invoke(F.NO)

8

UserUser

VTAVTA FlightFlight



invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(NO)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)

on message(F.NO)

invoke(YES)

invoke(Ticket)

. . .

. . .

receive(F.Cancel)

invoke(F.YES)

receive(Ticket)

receive(F.Ticket)

invoke(NO)

invoke(F.NO)

Deadlock?Deadlock?

No!

8

UserUser

VTAVTA FlightFlight



invoke(Ack)

receive(Ticket)

on message(Ack)

invoke(F.Ack)

receive(F.Ack)


on alarm

invoke(F.Ticket)

case(No Cancel)

case(Cancel)

invoke(Cancel)

on message (YES)

on message(NO)

on message(Cancel)

invoke(F.Cancel)

on message (F.YES)

on message(F.NO)

invoke(YES)

invoke(Ticket)

. . .

. . .

receive(F.Cancel)

invoke(F.YES)

receive(Ticket)

receive(F.Ticket)

invoke(NO)

invoke(F.NO)

8

UserUser

VTAVTA FlightFlight



9

• The ordered communication model is violated• The order of emissions of messages F.Ticket and F.NO is different from the order

of receptions

• The real execution is be correct• Engines support message overpasses• In the scenario, all message are eventually consumed, and cancellation is

performed correctly

• Also in this case, an adequate communication modeladequate communication model is needed to model and formally verify this scenario!

• Asynchronous unorderedAsynchronous unordered communication model• No restrictions on the message order• Intuitively, one queue for each message type (very similar to real

implementations)


Our approach

• Define a set ofset of communication modelscommunication models• Different levels of complexity

• Different interaction mechanisms

• Common framework

• Given a certain composition scenario determine an adequate adequate communication model• Represents all real executions of the composition

• Preserves behavioral properties

• IncrementalIncremental analysis process• From simpler to complex communication models

• Check if the communication model is adequate w.r.t. the scenario

• If yes, perform the formal verification against this model

2


Our approach: formal definitions

• Three main ingredients:

• Component services are formally modeled as State Transition Systems

• The modalities of the communications are formalized as a Communication Model

• The composite behavior of the component services according to a specific communication model is formally described as a Global State Transition System

2


From BPEL to STS

• State Transition System State Transition System Σ = ‹S,S0,I,O,R› where• S – finite set of statesstates

• S0 – set of initialinitial states

• I – set of inputinput actions• O – set of outputoutput actions• – transitiontransition relation SOISR

receive(F.Request)


case (Available)

invoke(F.NA)

invoke(F.Offer)

on message (F.NAck)

on message(F.Ack)

invoke(F.Ticket)

PROCESS FlightSTATES {Start, switch_IsAvailable, OUT_FNA, SUCCESSS,…}INPUT FRequest, FNAck, FAckOUTPUT FNA, FOffer, FTicketINIT

state = StartTRANS

Start – [IN FRequest] -> switch_IsAvailableswitch_IsAvailable – [TAU] -> OUT_FNAswitch_IsAvailable – [TAU] -> OUT_FOffer…

11


Communication Model

• A communication model Δ is defined by a set of queues

‹Q1, Q2, …, Qn›

where each queue Qi has associated:

• A set of messages Mi

• A (finite or infinite) bound Bi on the messages it can contain

• Synchronous communication model:• A single queue with bound 1

• Ordered asynchronous communication model:• One unbounded queue for (the messages exchanged between) each pair

of services

• Unordered asynchronous communication model:• One unbounded queue for each message type

12


Communication Model

• A communication model Δ is defined by a set of queues

‹Q1, Q2, …, Qn›

where each queue Qi has associated:

• A set of messages Mi

• A (finite or infinite) bound Bi on the messages it can contain

• Other communication models are possible:• One queue per process (locally ordered model): see paper• Mixed synchronous and asynchronous communications (e.g., manage

only tickets/cancellations as asynchronous communications)• Mixed bounded/unbounded queues• …

12


Global State Transition System

12

• A Global State Transition System (GSTS):• defines the composite behavior of the system.

• is parametric wrt a communication model Δ

• A GSTS is a tuple G = ‹GS,GS0,A,T›, where:• GS are the global states; each state has the form

gs = (<s1,s2,…,sn>, <q1, q2, …, qm>), where:

• si is the state of the i-th component STS

• qj describes the content of the j-th queue

• GS0 are the initial global states

• A are the input-output actions

• T GS x A x GS is the transition relation


GSTS: transitions

12

• The transition relation T GS x A x GS is defined as follows:• If the i-th STS performs an output:

• update the status of the STS

• add the emitted message to the associated queue

• If the i-th STS performs an input:

• consume a message from the associated queue (the queue has to be non-empty!)


• If the i-th STS performs a TAU action:



Translation

Implementation

W1

.

.

.

.Wn

Com

pon

en

t S

erv

ices

BP

EL2

STS

Tra

nsla

tion Σ1

.

.

.

.Σn

STS

Com

posit

ion

STS

to N

uS

MV

/Sp

in

Global STS

Communication Model

NuSMV/Spin

Valid

ity A

naly

sis

Validity Counterexample

Property Counterexample

VER

IFIC

ATIO

N

Valid

Verification Properties

16


Experiments

• Instances of VTA Case Study• Different communication models• Different verification properties: deadlock, LTL properties

• (F User.state = SUCCESS) ↔ ((F Hotel.state = SUCCESS) & F (Flight.state = SUCCESS))

17

Example 1 Sync. 0.5 sec 1 sec (Valid) 0.5 sec 0.5 sec

Example 2 Sync. 2 sec 4 sec (Invalid) − −

Ordered 4 sec 3 sec (Valid) 3 sec 2 sec

Example 3 Sync. 4 sec 5 sec (Invalid) − −

Ordered 8 sec 7 sec (Invalid) − −

Unordered 11 sec 6 sec (Valid) 5 sec 4 sec

InstanceInstance ModelModel TranslationTranslation ValidityValidity DeadlockDeadlock LTLLTL


Conclusions

• An unified frameworkunified framework for the analysis of Web service compositions under different communication models is presented

• The framework allows for validationvalidation of the composition against communication model and for verificationverification of the valid composition

• A prototype tooltool based on the framework is implemented

• Future works:• Better support for datadata (application of “knowledge level” and “abstraction

based” reasoning techniques)• ConformanceConformance problem: verify a WS-BPELWS-BPEL process against a WS-CDLWS-CDL

choreography specification

18


AnyAny questionquestion??

19

Analysis of Communication Models in Web Service Compositions Marco Pistore [email protected] University of Trento Joint work with Raman Kazhamiakin.

Documents

message f

message cancel

message ticket

message ack

message queues

message overpasses

cancel case

ticket case