1. 1 modeling BPEL4WS composition for verification: communication models Theoretical level : message alphabet over queues Practical level : number of queues functions for manipulating queues controls on fireable transitions Hierarchy : 1. synchronous model 2.locally ordered asynchronous model 3.mutually ordered asynchronous model 4.unordered asynchronous model = Most General model

2. 2 Synchronous model the most restrictive model rendezvous communications : the sender can send the message only when the receiver is ready to receive one queue of size 1 each peer interacts with their partners through this queue enabled actions : output : the queue must be empty the receiver must be ready to receive input : the queue must contain the message tau : the queue must be empty

3. 3 VTA Flight Hotel User 1 Synchronous model

4. 4 Locally ordered asynchronous model each process has its own queue for receiving messages as many queues as the number of processes enabled actions : output : always enabled input : the queue must contain the message at the top of the queue tau : always enabled

5. 5 VTA Flight Hotel User Locally ordered asynchronous model

6. 6 Mutually ordered asynchronous model two queues for each communication channel one queue for each way of communication no matter how many operations the channel supports unique channel between a pair of interacting peers enabled actions : output : always enabled input : the queue must contain the message at the top of the queue tau : always enabled

7. 7 VTA Flight Hotel User Mutually ordered asynchronous model

8. 8 Unordered asynchronous model equivalent to the Most General model as many queues as the number of message types each queue can store only a message type enabled actions : output : always enabled input : the queue must contain the message at the top of the queue tau : always enabled

9. 9 VTA Flight Hotel User User request VTA reply Flight reply VTA to Flight request VTA to Hotel request Hotel reply Unordered asynchronous model

10. 10 CheckAdequacy algorithm Objects: States : stack of global states of the DFS path Visited : set of completely visited global states Transitions : set of transitions Incomplete : set of termination states with non-empty queues Unbounded : set of marked states that demonstrate unboundedness Methods: fireable() : returns a set of fireable transitions according to the firing conditions of the current model fireableInGeneral() : returns a set of fireable transitions according to the firing conditions of the Most General model isEmptyChannels(s) : returns true if all the queues of s are empty

11. 11 CheckAdequacy algorithm updateModel() : lead the system from the current model to the next updates the model ID creates a brand new queue structure for every already visited state maps each message of the old queue(s) to the new queue structure checkUnboundednessRelation(s,States) : checks the States set for a global state where the unboundedness relation holds, that is : it has the same control state of s, and the content of the queues is the same of s, or it is growing and the content of the queues of s is the prefix of its queues

12. 12 CheckAdequacy algorithm procedure checkAdequacy(s) begin push(s,States); current_state := s; Fireable := fireable(current_state); FireableInGeneral := fireableInGeneral(current_state); while !(Fireable  FireableInGeneral) updateModel(); if(Fireable ≠ )  transition t  Fireable do add(t,Transitions); target_state:= transition.target; if (target_state  States  Visited) if(checkUnboundednessRelation(target_state,States)) add(target_state,Unbounded) else checkAdequacy(target_state);

13. 13 CheckAdequacy algorithm else if( (target_state  States) && ! isEmptyChannels(target_state) add(target_state,Incomplete); else if(Fireable  ) if(! isEmptyChannels(target_state)) add(target_state,Incomplete); add(target_state,Visited); pop(States); end