Upload
maria-clark
View
214
Download
1
Tags:
Embed Size (px)
Citation preview
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
24.05.2006 WWW'06 - Edinburgh
Motivating example
3
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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 (Not Available)
case (Available)
invoke(H.NA)
invoke(H.Offer)
on message (H.NAck)
on message(H.Ack)
invoke(H.Ticket)
4
UserUser
VTAVTA
HotelHotel
FlightFlight
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
VTA Processes – Cancellation
Deadlock?Deadlock?
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
24.05.2006 WWW'06 - Edinburgh
VTA Processes – Cancellation
Deadlock?Deadlock?
No!
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
24.05.2006 WWW'06 - Edinburgh
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)
VTA Processes – Cancellation
6
UserUser
VTAVTAFlightFlight
24.05.2006 WWW'06 - Edinburgh
Composition Properties
• 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
24.05.2006 WWW'06 - Edinburgh
VTA Processes – Complex 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(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
24.05.2006 WWW'06 - Edinburgh
VTA Processes – Complex 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(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
24.05.2006 WWW'06 - Edinburgh
VTA Processes – Complex 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(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
24.05.2006 WWW'06 - Edinburgh
Composition Properties
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)
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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 (Not Available)
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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!)
• update the status of the STS
• If the i-th STS performs a TAU action:
• update the status of the STS
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
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
24.05.2006 WWW'06 - Edinburgh
AnyAny questionquestion??
19