Design for Verification for Asynchronously Communicating Web Services

1
Design for Verification for Asynchronously
CommunicatingWeb Services

• Aysu Betin-Can, Tevfik Bultan
• University of California Santa Barbara
• Xiang Fu
• Georgia Southwestern State University

2
Overview

• Focus Asynchronously communicating Web Services
• Collection of services working in a collaborative
  manner through asynchronous messaging
• Goal Development of reliable web services in
  Java
• Automatic verification of interaction properties
• Conformance of service implementations to their
  published specifications
• Approach Design-for-Verification
• Peer Controller Pattern
• Assume-guarantee style verification based on this
  pattern

1
3
An Example Composite Web Service
Loan Approval System
Messages request(amount), approval(accept),
risk(level) check(amount), nocheck()
2
4
Introduction

• Web Service characteristics for interoperability
• Loosely coupled interacting services through
  standard interfaces
• Opportunity for modular analysis
• Supporting asynchronous communication
• Undecidability in analysis Fu et al.WWW04
• Standard data transmission via XML
• How to make sure that the composition functions
  correctly?
• Need a model for global behavior and properties
• Conversation The sequence of messages exchanged
  among peers, recorded in the order they are sent
• Does each peer really do what it says?
• Checking conformance to interface

3
5
Outline

• Peer Controller Pattern
• Verifiable composite web service development
• Separation of application logic from
  communication details
• Explicit behavioral interfaces for peers
• Peer interfaces as Finite State Machines
• Modular verification technique
• Interface Verification Conformance of peer
  implementations to their peer interfaces
• Behavior verification Checking properties of
  conversation
• Adapting synchronizability analysis for unbounded
  verification
• Automated BPEL specification generation

4
6
Objectives ofthe Peer Controller Pattern

• Explicit peer interfaces
• required to achieve interoperability
• serve as a behavioral contracts
• specify everything other peers need to know to
  interact with
• should not be affected by the changes in the peer
  implementation that are not relevant to the
  contract
• Separation of the application logic from the
  communication logic
• for standardization of the communication
• for maintainability of the code
• Automatically verifiable implementation

5
7
sendSOAPMessage() receive()Message wrap(Messag
e)SOAPMessage
CommunicationController
msg1()Msg1
Used in actual communication
Used in specification and verification
Used in both
Red Bordered classes are the ones the user has to
implement
8
sendSOAPMessage() receive()Message wrap(Messag
e)SOAPMessage
CommunicationController
msg1()Msg1
Red Bordered classes are the ones the user has to
implement
9
Red Bordered classes are the ones the user has to
implement
10
Peer Interfaces in Loan Approval
LoanApprover
CustomerRelations
?check
Sample Conversation request(amountlarge),check(a
mountlarge), risk(levelhigh),
approval(acceptfalse)
RiskAssessor
11
Modular Verification

• Based on the Peer Controller Pattern
• Exploiting explicit Peer Interface descriptions
• Assume-guarantee style modular verification
• Interface verification
• Conformance of peer implementations to their peer
  interfaces
• Behavior verification
• Checking properties of conversation

9
12
Interface Verification

• Goal Conformance check of a peer implementation
  to its peer interface
• Assumption The composite system of peer
  interfaces functions as desired
• Tool Java PathFinder a program checker for
  Java
• Usage
• Isolation of peers using Peer interfaces and
  message stub
• Look for assertion violations in the call
  sequences
• Advantage
• JPF can verify arbitrary pure Java
  implementations
• Peer stubs abstract asynchronous messaging
• Peer and Message stubs cause significant state
  space reduction

10
13
Interface Verification

• Correctness Criteria
• Call sequence to Communicator is accepted by the
  automata specifying the contract
• Replace the communication and message stubs
• Look for assertion violations
• assertions already in SM
• there is a next state with the transition
• send find a send transition whose guard is
  satisfied
• receive chose one available messages at the
  state
• JPF exhaustively search every possible choice
• No assertion violation means the peer
  implementation behaves as specified.

11
14
Interface Verification performance

• Could we use JPF only?
• JPF works on pure Java code
• How to handle asynchronous communication?
• simulation of JAXM provider and input queues
• JPF ran out of memory without a conclusive result

12
15
Behavior Verification

• Goal Verification of interaction properties
  defined on Conversations
• Assumption Peer implementations obey their peer
  interfaces
• Tool SPIN an explicit and finite state model
  checker
• Usage Automated translation of the peer
  interfaces to Promela
• Advantage
• SPIN is suitable for modeling asynchronous
  message queues
• Peer interfaces are already a model of the system
• no model extraction

13
16
Promela Code for Loan Approval

• do
• state0 -gtif
• approverQ?requestType,msg-gt/receive/
• approverQ?requestType,msg
• requestmsg.amountmsg.requestmsg.amount
• state1
• fi
• state3 -gt if
• riskmsg.levellow -gt/guard//send/
• approvalmsg.accepttrue/update/
• msg.approvalmsg.acceptapprovalmsg.accept
  
• atomic lastmsg.approvalmsg.accept
  approvalmsg.accept
• customerQ!approvalType,msg
• state5
• riskmsg.levelhigh -gt/guard//send/
• approvalmsg.acceptfalse/update/
• msg.approvalmsg.acceptapprovalmsg.accept
  
• atomic lastmsg.approvalmsg.accept
  approvalmsg.accept customerQ!approvalTyp
  e,msg
• state5

• define size 5
• mtype requestType, approvalType, nocheckType,
• checkType,riskType //message names
• /data domains/
• mtype undef1,small,large//amount domain
• mtype undef2,low,high//level domain
• /message types/
• typedef approval bool accept
• typedef request mtype amount
• typedef risk mtype level
• ....
• message lastmsg//holds the last send message
• /channels/
• chan customerQsize of mtype,message
• chan approverQsize of mtype,message
• chan assessorQsize of mtype,message
• proctype CustomerRelations()...
• proctype RiskAssessor()...

16
17

• Sample Property Whenever a request with a small
  amount is sent, eventually an approval message
  accepting the loan request will be sent.
• Loan Approval system has 154 reachable states
• because each queue length never exceeds 1.
• Behavior verification used lt1 sec and 1.49 MB
• SPIN requires restricted domains
• Have to bound the channel sizes ? bounded message
  queues
• Problem No guarantee these results will hold for
  other queue sizes

17
18

• SPIN runs out of memory for message queue size
  15!!!
• reachable state space is infinite
• Absence of error for queue size 15 does not
  ensure freedom of bugs!
• Not only unbounded queues, but also efficiency
• Solution Adapting synchronizability analysis

18
19
Unbounded Behavior Verification

• Model checking a composite web service that
  communicates asynchronously with unbounded queues
  is undecidable Fu et al. CIAA03
• Automated Synchronizability analysis
• A composite web service is synchronizable, it
  generates the same conversation set both under
  asynchronous and synchronous communication Fu et
  al WWW04
• Generate Promela with synchronous communication
  semantics
• No message buffering
• Reduced state space hence improved efficiency
• Enables Unbounded behavior verification

19
20
BPEL Generation

• A benefit of explicit peer interfaces
• Automated generation from Peer interfaces
• Mappings of send and receive transitions to BPEL
  activity blocks
• Main activity block is the state machine
• Nondeterminism reflected
• via opaque assignments

21
Transition Mappings

• ltsequencegt
• ltreceive partnerLink"RiskAssessor"
  portType"ns2ApproverPT"
• operation"ns2risk" variable"risk"gt
• lt/receivegt
• ltassigngtltcopygt
• ltfrom expression"'3'"/gt
• ltto variable"state"/gt
• lt/copygtlt/assigngt
• lt/sequencegt

21
22
Transition Mappings

• ltcase condition"getVariableData('risk',
  'level')'low'"gt
• ltsequencegt
• ltassigngtltcopygt
• ltfrom expression"'true'"/gt
• ltto variable"approval" part"accept"/gt
• lt/copygtlt/assigngt
• ltinvoke partnerLink"CustomerRelations"
• portType"ns1CustomerPT"
• operation"ns1approval"
• inputVariable"approval"gt
• lt/invokegt
• ltassigngt ltcopygt
• ltfrom expression"'5'"/gt ltto
  variable"state"/gt
• lt/copygt lt/assigngt
• lt/sequencegt
• lt/casegt

22
23
Summary

• Verifiable Design Pattern
• Modular Verification Approach
• interaction behavior
• peer implementation conformance
• Modularity in verification improves the
  efficiency
• Using state machines and stubs at interface
  verification
• Adapting synchronizability analysis at behavior
  verification
• Reasonable amount of time and memory, which
  otherwise too large for a Java model checker to
  handle
• Automated BPEL generation from peer interfaces

23
24
(No Transcript)
25
Java Code Excerpts

• public class CommunicatorStub implements
  LoanApprover
• private SM sm
• private ApprovalMessage aproval
• private RequestMessage request
• public CommunicatorStub()
• smnew SM(..)
• GuardedUpdate gcnew GuardedUpdate()
• public boolean guard()
• return last_risk.level()Low
• public boolean update()
• return approval.accepttrue
• SendTransition trans
• new SendTransition(approval,3,5,gc)
• sm.addTransition(trans)
• ReceiveTransition rtrans
• new ReceiveTransition (request,0,1)
• sm.addTransition(rtrans)

• public class ApproverServlet extends PeerServlet
  implements LoanApprover
• public void init(ServletConfig servletconfig)
  throws ServletException
• super.init(servletconfig)
• urn"urnLoanApprover"
• public CheckMessage check(int sessionId)
• return new CheckMessageImpl(this,sessionId)
• public NoCheckMessage nocheck(int sessionId)
• return new NoCheckMessageImpl(this,sessionId)
  
• public ApprovalMessage approval(int sessionId)
• return new ApprovalMessageImpl(this,sessionId)
  

8
26
Peer Controller Pattern

• Asynchronous communication with JAXM
• through provided helper classes
• Customized messages with control data
• Peer Interface
• Forms the behavioral contract of the peer
• Defines the acceptable call sequences to
  Communicator
• Implemented as a nondeterministic Finite State
  Machine
• Message sequencing order
• Conditions on message contents via Guarded
  commands for send transitions

6
27

• Implemented a synchronizability analyzer
• Automated synchronizability check on the peer
  interfaces
• These 2 examples are synchronizable
• Client-Supplier example has 68 states with
  synchronous communication
• Loan Approval has

19