Web Services: Formal Modeling and Analysis Jianwen Su University of California, Santa Barbara NJU Summer School of Software Engineering 2012/7/23
The Verification Problem Given n a web service/composition/choreography/workflow/… n a goal j do all executions satisfy the goal? ? = Choices for NJU Summer School of Software Engineering 2012/7/23 j and j 2
Outline n Motivations n Transitions systems n BPEL services and compositions n Choreographies (of BPEL services) n Artifact-centric workflow n Concluding remarks ? = NJU Summer School of Software Engineering 2012/7/23 j 3
Software Systems in the Real World n Wide range of applications: v Web stores, e-tailors, … v Accounting, financial systems, … v Automated flight control, … v Patient profiles, cases, care records, … v Governments: local, federal, courts, prisons, … v… n Challenges: v Interoperation & integration NJU Summer School of Software Engineering 2012/7/23 4
Software Systems in the Real World n Wide range of applications: v Web stores, e-tailors, … v Accounting, financial systems, … v Automated flight control, … v Patient profiles, cases, care records, … v Governments: local, federal, courts, prisons, … v… n Challenges: v Interoperation & integration v Design and analysis v Improvements (evolution) NJU Summer School of Software Engineering 2012/7/23 5
Web Services: Standardization n The Web: Flexible human-software interaction n Web services: Flexible software-software interaction v SAAS: Software As A Service n A working definition: software services accessible via standardized protocols n SOA: a potential basis for software system design, interoperation, integration, … v Lots of interest in trade press, academic community, standards bodies, . . . v Applications in e-commerce, telecom, science, cloud, government, education, . . . NJU Summer School of Software Engineering 2012/7/23 6
Fundamental Elements (WS Apps) n Process: a collection of actions to be taken in a meaningful manner (sequential, parallel, conditional, …) n Communication or messages: different software systems need to cooperate, collaborate n Data: follow guide the actions to be taken and processes to n Actors (human, external environment): their reasoning for making decisions may not be captured in the logic specification/running systems NJU Summer School of Software Engineering 2012/7/23 7
Research Challenges (Biz Workflows) n Models: process, data, messages, actors n Analysis and verification n Integration/interoperation n Improvements (biz intelligence, operation optimization, …) n Management of workflows and executions NJU Summer School of Software Engineering 2012/7/23 8
Goals n Focus on analysis & verification problem v Depending on models n. A sampler of verification problems, approaches and results NJU Summer School of Software Engineering 2012/7/23 9
Outline n Motivations n Transitions systems n BPEL services and compositions n Choreographies (of BPEL services) n Artifact-centric workflow n Concluding remarks ? = NJU Summer School of Software Engineering 2012/7/23 j 10
Transition Systems n. A finite transition system (Kripke structure) is a tuple T = (S, I, R, L) where v a finite set of states S v a set of initial states I S v a transition relation R S S v a labeling function L : S 2 P n. P : a set of atomic propositions NJU Summer School of Software Engineering 2012/7/23 11
Example n. P = q 1, q 2, q 3 s 1 TFF L(s 3) = q 1, q 2 s 3 TTF s 0 FFF s 6 TTF s 5 TTT s 2 FTF NJU Summer School of Software Engineering s 4 FTT 2012/7/23 s 7 FFT 12
Runs (Execution Paths) n Given a finite transition system T = (S, I, R, L) n. A run is an infinite sequence of states Z = s 0 s 1 s 2 where for each i 0, (si, si+1) R s 1 TFF s 3 TTF s 0 FFF s 5 TTT s 2 FTF n s 0 s 1 s 2 s 3 s 5 s 1 s 2 s 6 TTF s 4 FTT s 7 FFT … NJU Summer School of Software Engineering 2012/7/23 13
Linear Temporal Logic (LTL) n. A set P of atomic propositions: q 1, q 2, q 3, … connectives: , , n Temporal operators: v X : is true in the next state v G : is true in every state v y U : y is true in every state before the state is true v F : is true in some future state n Logical X: next n Example: G: always U: until F: eventually G (money F food) NJU Summer School of Software Engineering 2012/7/23 14
Semantics of Temporal Operators n Truth value of a formula is defined on runs n Propositional connectives have the usual meaning n Temporal operators: X: next G: always U: until F: eventually G q 1 X q 1 q 1 U q 2 q 1 q 1 F q 1 true U q 1 F q 1 NJU Summer School of Software Engineering G q 1 F q 1 2012/7/23 15
LTL Semantics n. A state is a set of propositions n A run Z=s 0 s 1 s 2 satisfies an LTL formula: v Z = q if s 0 = q or q L(s 0) v Z = if Z Z = y if Z = and Z = y Z = y if Z = or Z = y v Z = X if s 1 s 2 = v Z = G if for each i, sisi+1 = v Z = F if for some i, sisi+1 = v Z = y U if for some i, sisi+1 = and for each j < i, sjsj+1 = y NJU Summer School of Software Engineering 2012/7/23 16
Transition Systems and LTL transition system T satisfies an LTL formula if every run of T satisfies n. A s 1 TFF s 3 TTF s 0 FFF s 6 TTF s 5 TTT s 2 FTF s 4 FTT s 7 FFT n F q 3 G( q 3 X q 3) NJU Summer School of Software Engineering 2012/7/23 17
Verifying LTL Properties given a transition system T, an LTL formula j, determine if j is satisfied by T (i. e. every run of T) n Problem: n. A decision algorithm: 1. Construct a Büchi automaton B j equivalent to j 2. Explore (depth-first search) simultaneously T and B j, v if a repeat is found involving a final state of B j, halt and output “no” (with the found path) Otherwise, output “Yes” (T satisfies j) NJU Summer School of Software Engineering 2012/7/23 18
Büchi Automata is a (finite) set of propositions n A Büchi automaton is a tuple B = (Q, I, d, F) where v Q is a finite set of states v I Q is a (nonempty) set of initial states v F Q is a set of final states P v d Q 2 Q is a transition relation n. P n Essentially nondeterministic finite state automata but accepting infinite words: w v A word in (2 P) is accepted if final states are entered infinitely often The language of B, L(B), is the set of words accepted NJU Summer School of Software Engineering 2012/7/23 19
An Example q 1 , q 2 q 0 NJU Summer School of Software Engineering q 2 q 1 2012/7/23 20
LTL to Büchi Automata Büchi automaton B is equivalent to an LTL formula : an infinite sequence Z satisfies iff Z L(B) n. A each LTL formula , one can construct a Büchi automaton B equivalent to (| |) v Number of states in B is 2 O n For n Emptiness of a Büchi automaton can be determined in O(n) where n is the number of states [Merz MOVEP 2001] NJU Summer School of Software Engineering 2012/7/23 21
Model Checking T : a transition system, : an LTL formula 1. Construct a Büchi automaton B equivalent to 2. Explore (depth-first search) simultaneously T and B , v if a repeat is found involving a final state of B , halt and output “no” (the trace is the counter example) Otherwise, output “Yes” (T satisfies ) n Complexity: O(2 O(| |)|T|) time, PSPACE [Merz MOVEP 2001] NJU Summer School of Software Engineering 2012/7/23 22
Outline n Motivations n Transitions systems n BPEL services and compositions n Choreographies (of BPEL services) n Artifact-centric workflow n Concluding remarks ? = NJU Summer School of Software Engineering 2012/7/23 j 23
Business Process Execution Language n Allow specification of compositions of Web services v business processes as coordinated interactions of Web services n Allow abstract and executable processes n Influences from v Traditional flow models v Structured programming v Successor of WSFL and XLANG n Assumes WSDL ports n OASIS standard NJU Summer School of Software Engineering 2012/7/23 24
Illustrating a BPEL Service receive invoke assign reply NJU Summer School of Software Engineering 2012/7/23 25
![BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Translate each atomic activity to](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-26.jpg "BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Translate each atomic activity to")
BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Translate each atomic activity to a transition system with single entry, single exit receive … operation = "approve" variable = "request" / ? approve_Out invoke operation="approve", invar="request", outvar="aprv. Info" catch faultname="loanfault" . . . handler 1. . . / /catch /invoke request : = approve_Out approve_In : = request; !approve_In loanfault ? approve_Out aprv. Info : = approve_Out handler 1 Treat actions as propositions NJU Summer School of Software Engineering 2012/7/23 26
![BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Control flow constructs: assemble pieces](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-27.jpg "BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Control flow constructs: assemble pieces")
BPEL to Transition Systems [Fu-Bultan-S. WWW ’ 04] n Control flow constructs: assemble pieces of transition systems sequence … activity 1 …/ … activity 2 …/ /sequence activity 1 flow activity 1 … source linkname = “link 1”…/ /activity 1 activity 2 … target linkname = “link 1”/ /activity 2 /flow NJU Summer School of Software Engineering activity 2 activity 1 activity 2 X disallow the orders prohibited by the link 2012/7/23 27
Verifying BPEL Services a BPEL service, P: a set of propositions, : an LTL formula n Determine if every execution of S satisfies n S: n Algorithm: 1. Construct a transition system TS, P 2. Determine if TS, P satisfies n Complexity: O(2 O(| |)|S|) time n Good news but v Control states (flow) only, no variables/data v Single service, no composition NJU Summer School of Software Engineering 2012/7/23 28
Adding Data n BPEL allows variables to hold XML documents n Bad news (folklore): BPEL is Turing (computationally) complete n Immediate consequence: It is undecidable if a given BPEL service satisfies a given LTL formula n One possible restriction: limit variables to v finite domains: the number of possible values is finite NJU Summer School of Software Engineering 2012/7/23 29
Finite Domain Variables n Represent variable contents explicitly through states ? quantity = 1 ? quantity = 2. . . [Fu-Bultan-S. ISSTA ’ 04] ? quantity = 15 m n Transition states increased by n times: n : (max) domain size, m : number of variables m n Complexity of verification: O(2 O(| |)|S|n ) time : LTL formula, S : BPEL service NJU Summer School of Software Engineering 2012/7/23 30
Composition of BPEL Services n Peer to peer Investor report register, ack, cancel Stock Broker accept, reject, bill request, terminate Research Dept. n Mediated or hub-and-spoke Investor NJU Summer School of Software Engineering Mediator Research Dept. 2012/7/23 Stock Broker 31
Synchronous Messaging Model n Two specific actions: v Send a message (!) v Receive a message (? ) synchronization <invoke>: request-response … ? ok !ok … store NJU Summer School of Software Engineering <receive>: response ? authorize !authorize <invoke>: request bank 2012/7/23 32
Product with Synchronous Messaging n Two services requester 2 !e !r 1 !r 2 1 ? a 2 n Their r 1, r 2 e server ? e !a 2 ? a 1, a 2 4 3 !a 1 1 ? r 2 ? r 1 2 synchronous product as a transition system: a 1 12 NJU Summer School of Software Engineering 11 r 1 e 24 2012/7/23 r 2 a 2 13 33
Product with Synchronous Messaging n In general, the composition of k BPEL services with synchronous messaging can be modeled as a transition system with rk states where v r is the (max) number of states in a single service n Complexity v v v of verification: O(2 O(| |)(|S|nm)k) time : LTL formula |S| : size of a BPEL service n : domain size m : number of variables in a BPEL service k : number of BPEL services NJU Summer School of Software Engineering 2012/7/23 34
![Asynchronous Messaging [Bultan-Fu-Hull-S. WWW ’ 03] n Two specific actions: v Send a message](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-35.jpg "Asynchronous Messaging [Bultan-Fu-Hull-S. WWW ’ 03] n Two specific actions: v Send a message")
Asynchronous Messaging [Bultan-Fu-Hull-S. WWW ’ 03] n Two specific actions: v Send a message (!) v Receive a message (? ) invoke : request-response receive : response ? authorize !authorize … ? ok !ok … store invoke : request bank n FIFO queues are used to buffer unconsumed messages v One queue per service for incoming messages NJU Summer School of Software Engineering 2012/7/23 35
Verification is Undecidable n Finite state automata with FIFO queues are Turing complete [Brand-Zafiropulo JACM’ 83] n Immediate consequence: Verification problem is undecidable n One possible restriction: bound queue size NJU Summer School of Software Engineering 2012/7/23 36
Bounded Queues & Finite State Automata n Observation: a bounded length queue has a finite number of states … … !a a … ? b … !b … ? a synchronize … b a !a b … n Asynchronous + bounded queue can be simulated v Note: Only focus on message types not content NJU Summer School of Software Engineering 2012/7/23 37
BPEL with Asynchronous Messaging of states for queues: el, where e : number of message types, l : queue length bound n With message contents: elnl, where n is domain size n Number n Complexity v v v of verification: O(2 O(| |)(|S|nmelnl)k) time : LTL formula |S| : size of a BPEL service n : domain size m : number of variables in a BPEL service k : number of BPEL services NJU Summer School of Software Engineering 2012/7/23 38
Summary of Verifying BPEL Services n Focus on decidability boundary of LTL properties of BPEL + compositions (synchronous, bounded queue asynchronous messaging) n Verification algorithms: map to exiting verifiers v Model checker: SPIN [Fu-Bultan-S. 2003 -4] [Nakajima 2004], [Pistore-Traverso-et al 2005] v Process algebras: LTSA [Foster-Uchitel-Magee-Kramer 2003], CWB [van. Breugel-Koshkina 2004] [Salaun-Bordeaux-Schaef 2004], LOTOS [Ferara 2004][Salaun-Ferara-Chirichiello 2004] v ASM: [Farahbod-Classer-Vajihollahj 2004][Deutsch-Sui-Vianu 2004] [Fahland-Reisig 2005] v… NJU Summer School of Software Engineering 2012/7/23 39
Outline n Motivations n Transitions systems n BPEL services and compositions n Choreographies (of BPEL services) n Artifact-centric workflow n Concluding remarks ? = NJU Summer School of Software Engineering 2012/7/23 j 40
Composition: Common Topologies n Peer-to-peer Investor report register, ack, cancel Stock Broker accept, reject, bill request, terminate Research Dept. n Mediated, or “hub and spoke” Mediator Investor NJU Summer School of Software Engineering Research Dept. 2012/7/23 Stock Broker 41
Orchestration vs Choreography Composition WS-CDL BPEL (Individual) Service Description XML Messaging NJU Summer School of Software Engineering OWL-S Service. Model WSCL WSDL OWL-S Service. Profile SOAP 2012/7/23 42
WS Choreography Definition Language n Specification of choreography n Model complex business protocol (e. g. order management) to enable interoperability n Generate computational logic of individual collaborating participants n Key concepts v Collaborating participants: role, relationship, participants v Information driven collaboration: channel, activities, workunit, choreography n Standardization through W 3 C (Version 1. 0: December 2004) NJU Summer School of Software Engineering 2012/7/23 43
Composition: BPEL and WS-CDL Investor Focus on local actions report register, ack, cancel accept, reject, bill request, terminate Focus on global behaviors Research Dept. BPEL Stock Broker WS-CDL Mediator Investor NJU Summer School of Software Engineering Research Dept. 2012/7/23 Stock Broker 44
Composition: BPEL and WS-CDL Investor Focus on local actions report register, ack, cancel accept, reject, bill Focus on request, terminateglobal behaviors Research Dept. orchestration BPEL Stock Broker Choreography WS-CDL Mediator n For Investor Research Dept. Stock Broker “hub and spoke”, the difference is small For “peer-to-peer”, the concept of choreography is interesting and not well understood NJU Summer School of Software Engineering 2012/7/23 45
Automated Design: Top-down vs Bottom-up Investor report register, ack, cancel Stock Broker accept, reject, bill request, terminate Research Dept. Top-down specification of individual services orchestration Bottom-up e. g. , BPEL specification of global behaviors Choreography e. g. , WS-CDL n Verification and analysis of choreography v Focus on the conversation model NJU Summer School of Software Engineering 2012/7/23 46
Verification of WS Choreography n Verification of choreography of a WS (BPEL) composition Investor report register, ack, cancel Stock Broker accept, reject, bill request, terminate Research Dept. n Services: finite transition systems on messaging actions n Unbounded FIFO queues for messages n Choreography: message sequences (send only) v How to model? n LTL on choreography [Fu-Bultan-S. WWW’ 04, ISSTA’ 04] NJU Summer School of Software Engineering 2012/7/23 47
An Example: Stock Analysis Service (SAS) Three peers: Investor, Stock Broker, and Research Dept n Inv initiates the stock analysis service by sending a register message to SB n SB may accept or reject the registration n If the registration is accepted, SB sends an analysis request to the RD n RD sends the results of the analysis directly to the Inv as a report n After receiving a report Inv can either send an ack to SB or cancel the service n Then, SB either sends the bill for the services to Inv, or continues the service with another analysis request NJU Summer School of Software Engineering 2012/7/23 48
SAS Composition n SAS is a web service composition v a finite set of peers: Inv, SB, RD, and v a finite set of message classes: register, ack, cancel, accept, . . . Investor (Inv) report register ack cancel accept reject bill Stock Broker (SB) request terminate Research Dept. (RD) NJU Summer School of Software Engineering 2012/7/23 49
Asynchronous Messaging n We assume that the messages among the peers are exchanged through reliable and asynchronous messaging v FIFO and unbounded message queues Stock Broker (SB) n Research Dept. req (RD) This model is similar to industry efforts such as v JMS (Java Message Service) v MSMQ (Microsoft Message Queuing Service) NJU Summer School of Software Engineering 2012/7/23 50
![Mealy Service Model [Bultan-Fu-Hull-S. WWW’ 03] n Finite state control n Acts on a](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-51.jpg "Mealy Service Model [Bultan-Fu-Hull-S. WWW’ 03] n Finite state control n Acts on a")
Mealy Service Model [Bultan-Fu-Hull-S. WWW’ 03] n Finite state control n Acts on a finite set of message classes n Transitions are based on receiving a message ? m or sending a message !m !register Investor (Inv) ? accept !ack ? report ? reject ? bill !cancel ? bill NJU Summer School of Software Engineering register, ack, cancel accept, reject, bill report Stock Broker (SB) request, terminate Research Dept. (RD) 2012/7/23 51
Composite Mealy Service Execution Investor Stock Broker Firm !register ? register !accept !request ? accept !ack ? reject ? report !cancel !reject rep acc bill ack reg ? bill ? ack !bill ? cancel !bill ? bill !terminate Research Dept. ? request !report ? terminate NJU Summer School of Software Engineering n Execution req ter halts if v All Mealy services are in final states, and v All queues are empty 2012/7/23 52
Conversations and Conversation Protocols Conversation: a message sequence n A conversation protocol specifies the set of desired register, conversations ack, n cancel Investor (Inv) 1 6 register 3 reject 2 request accept 5 terminate 4 terminate 12 NJU Summer School of Software Engineering report 7 cancel b rt 8 request 9 ill bill ack accept, reject, bill rep o Stock Broker (SB) ack request, terminate Research Dept. (RD) report 11 cancel 2012/7/23 10 53
Conversations of Composite Services n A virtual watcher records the messages as they are sent register Investor (Inv) accept rep ack bill ort Stock Broker (SB) req est u t mi er ate n Research Dept. (RD) Watcher reg acc req rep ack bil ter A conversation is a sequence of messages the watcher sees in a successful run (or enactment) n Conversation language: the set of all possible conversations n What properties do conversation languages have? n NJU Summer School of Software Engineering 2012/7/23 54
Conversation Languages Are Not Regular !a ? b a ? a b !b p 2 p 1 n The set of conversations CL a*b* = anbn Conversation languages are not always regular v Some may not even be context free n Causes: asynchronous communication & unbounded queue n Bounded queues or synchronous: CL always regular n CLs are always context sensitive n NJU Summer School of Software Engineering 2012/7/23 55
Remarks n Communicating finite state machines with queues are computationally Turing complete v Conversation languages tracing execution states n Why regular languages? v They would allow static analysis, e. g. model checking l Testing and debugging in SOA are harder n Queue v. s. no queue: design time decision! NJU Summer School of Software Engineering 2012/7/23 56
Two Key Questions Investor (Inv) report register ack, cancel accept, reject, bill Stock Broker (SB) request, terminate Research Dept. (RD) n Is the composition of (BPEL) services “correct”? v Verify conversations n Automated design of services from the desired conversation protocol? NJU Summer School of Software Engineering 2012/7/23 57
Temporal Properties of Conversations The notion of conversation enables reasoning about temporal properties of the composite web services n Extend LTL extends naturally to conversations v LTL temporal operators X (ne. Xt), U (Until), G (Globally), F (Future) v Atomic properties Predicates on message classes (or contents) v Example: G (accept F bill) n n Verification problem: Given an LTL property, does the conversation language (i. e. every conversation) satisfy the property? NJU Summer School of Software Engineering 2012/7/23 58
Design Scenario 1: Bottom Up n Given a composition of services, does its CL satisfy the LTL properties? Peer A Peer B !msg 1 !msg 3 ? msg 2 ? msg 6 Conversation n Problem: ? msg 4 Peer C ? msg 1 Input Queue ? msg 3 !msg 2 !msg 5 !msg 4 !msg 6 ? msg 5 ? . . . = G(msg 1 F(msg 3 msg 5)) the general case is undecidable [Brand-Zafiropulo JACM’ 83] NJU Summer School of Software Engineering 2012/7/23 59
Design Scenario 2: Top Down n Specify the global messaging behavior explicitly as a conversation protocol n Determine if the conversations allowed by the protocol satisfy LTL properties Conversation Protocol A B: msg 1 B A: msg 2 B C: msg 3 B C: msg 5 C B: msg 4 B A: msg 6 ? = G(msg 1 F(msg 3 msg 5)) A n Problem: realizable B C the conversation protocol may not be NJU Summer School of Software Engineering 2012/7/23 60
Approaches n (Bottom up) verification is undecidable v Approach 1: check if the conversations using bounded queue satisfy LTL property —partial verification v Approach 2: sufficient condition for bounded queue CL = unbounded queue CL —synchronizablility n (Top down) protocol may be unrealizable v Approach 3: sufficient condition for realizability NJU Summer School of Software Engineering 2012/7/23 61
Realizability Problem n Not all conversation protocols are realizable! Projection of the conversation protocol to the peers A B: m 1 C D: m 2 Conversation protocol n !m 1 Peer A ? m 1 Peer B !m 2 Peer C ? m 2 Peer D Conversation “m 2 m 1” will be generated by any legal peer implementation which follows the protocol NJU Summer School of Software Engineering 2012/7/23 62
Another Non-Realizable Protocol A m 2 m 3 A m 1 B m 3 m 1 m 2 C B C m 2 B A m 1 A B Conversation protocol B m 2 B A m 1 A B A C ? m 2 !m 1 !m 2 ? m 1 e e m 3 A C !m 1 ? m 2 ? m 1 !m 2 e e !m 3 e ? m 3 Generated conversation: m 2 m 1 m 3 NJU Summer School of Software Engineering 2012/7/23 63
![A Sufficient Condition for Realizability [Fu-Bultan-S. CIAA ’ 03] n Three parts for realizability](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-64.jpg "A Sufficient Condition for Realizability [Fu-Bultan-S. CIAA ’ 03] n Three parts for realizability")
A Sufficient Condition for Realizability [Fu-Bultan-S. CIAA ’ 03] n Three parts for realizability (contentless messages) v Lossless join Conversation protocol should be equal to the “join” of its projections to each peer v Synchronous compatible When the projections are composed synchronously, there should not be a state where a peer is ready to send a message while the corresponding receiver is not ready to receive v Autonomous Each peer should be able to make a deterministic decision on whether to send or to receive or to terminate NJU Summer School of Software Engineering 2012/7/23 64
Bottom-Up Approach n Given a composition of web services, check if its conversations satisfy some LTL properties n General problem is undecidable due to asynchronous communication (with unbounded queues) n Naïve idea: limit the queue length v Problem 1: only partial verification, unless we are lucky v Problem 2: state size explosion NJU Summer School of Software Engineering 2012/7/23 65
Example 1: Regular CL, Bounded Queues r 1, r 2 e !e ? a 2 ? a 1 !r 2 !r 1 a 1, a 2 requester n Conversation n During ? e !a 1 !a 2 ? r 1 server language is regular: (r 1 a 1 | r 2 a 2)* e every halting run two queues are bounded NJU Summer School of Software Engineering 2012/7/23 66
Example 2: Not Regular, Unbounded !e !r 1 ? a 2 !r 2 ? a 1 r 1, r 2 e ? e !a 1 !a 2 a 1, a 2 ? r 2 requester ? r 1 server Conversation language is not regular n Queues are not bounded n NJU Summer School of Software Engineering 2012/7/23 67
Example 3: Regular, Unbounded !e !r 1 !r r, r 1, r 2 e !r 2 ? a ? r a requester n Conversation n Queues ? e !a ? r 1 ? r 2 server language is regular: (r 1 | r 2 | ra)* e are not bounded NJU Summer School of Software Engineering 2012/7/23 68
Three Examples # of states x 103 1600 1400 1200 Example 1, regular, bounded 1000 800 Example 2, not regular, unbounded 600 Example 3, regular, unbounded 400 200 13 11 9 7 5 3 1 0 queue length Verification of Examples 2 and 3 are difficult even if we bound the queue length n How can we distinguish Examples 1 and 3 (with regular conversation languages) from 2? Synchronizability Analysis n NJU Summer School of Software Engineering 2012/7/23 69
Synchronizability Analysis n A composite web service is synchronizable, if its conversation language does not change v when asynchronous communication with unbounded queues is replaced with synchronous communication or bounded queues n A composite web service is synchronizable, if it satisfies the synchronous compatible and autonomous conditions [Fu-Bultan-S. WWW’ 04] NJU Summer School of Software Engineering 2012/7/23 70
Are These Conditions Too Restrictive? Problem Set Size Synchronizable? #msg #states #trans. Source Name SAS 9 12 15 ISSTA’ 04 yes Cv. Setup 4 4 4 yes IBM Meta. Conv 4 4 6 no Chat Conv. 2 4 5 yes Buy 5 5 6 yes Support Haggle 8 5 8 no Project AMAB 8 10 15 yes shipping 2 3 3 yes BPEL Loan 6 6 6 yes spec Auction 9 9 10 yes 6 7 7 collaxa. com Star. Loan yes (Oracle) Cauction 5 7 6 yes NJU Summer School of Software Engineering 2012/7/23 71
Summary n Verification of choreography is intricate v Choreography of composition may not be regular and does not fall into natural formal language classes v Must be concerned with the realizability problem n Realizability and verification on conversations with Mealy machines [Fu-Bultan-S. 2003 -6] n Realizability on process algebras, choreography languages [many, 2005 -] NJU Summer School of Software Engineering 2012/7/23 72
Outline n Motivations n Transitions systems n BPEL services and compositions n Choreographies (of BPEL services) n Artifact-centric workflow n Concluding remarks ? = NJU Summer School of Software Engineering 2012/7/23 j 73
Workflow (Business Process) n. A bookseller example: Traditional control-centric model Fill Shopping Cart ID Customer NJU Summer School of Software Engineering Shipping Preference Payment Confirmation information 2012/7/23 Archive 74
Workflow (Business Process) n. A bookseller example: Traditional control oriented model n Multiple steps needed for each activity Fill Shopping Cart ID Customer Shipping Preference Payment Confirmation information Archive Ground Credit Air In-stock Handling Check Inventory Back-order Handling Warehouses/ Size New Existing Customer Registration Login Pay. Pal Check In practice, 100 s to 1000 s of nodes Hard to reason, find useful views: missing data NJU Summer School of Software Engineering 2012/7/23 75
Business Intelligence: Data View n Extract-Transform-Load inventory Transactions catalog Transactions workflow activities Data Warehouse Analysis workflow is missing! Transactions NJU Summer School of Software Engineering cust_db 2012/7/23 76
Business Artifacts ! n. A business artifact is a key conceptual business entity that is used in guiding the operation of the business v fedex package delivery, patient visit, application form, insurance claim, order, financial deal, registration, … v both “information carrier” and “road-maps” n Very natural to business managers and BP modelers n Includes two parts: v Information model: data needed to move through workflow v Lifecycle: possible ways to evolve NJU Summer School of Software Engineering 2012/7/23 77
Example: Restaurant Artifacts Create Guest Check Kitchen Order Add Item Open GCs Prepare Receipt Pending KOs Cash Balance Pending Receipts Prepare & Test Quality Closed GCs Payment Paid Receipts Ready KOs Update Cash Balance Deliver Disagreed Receipts Recalculate Receipt NJU Summer School of Software Engineering Archived Receipts Archived GCs 2012/7/23 Cash Balance Archived KOs 78
Example: Restaurant Artifacts GC Create Guest Check Kitchen Order KO Add Item Open GCs Prepare Receipt RC Receipt Pending KOs Cash Balance Pending Receipts Prepare & Test Quality Closed GCs Payment Paid Receipts Ready KOs Update Cash Balance Deliver Disagreed Receipts Recalculate Receipt NJU Summer School of Software Engineering Archived Receipts Archived GCs 2012/7/23 Cash CB Balance Archived KOs 79
Emerging Artifact-Centric BPs customer info cart . . . + Specification of artifact lifecycles Artifacts (Info models) n Informal model [Nigam-Caswell IBM Sys J 03] n Systems: BELA (IBM 2005), Siena (IBM 2007) n Formal models v State machines [Bhattacharya-Gerede-S. SOCA 07] [Gerede-S. ICSOC 07] v Rules [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] NJU Summer School of Software Engineering 2012/7/23 80
A Logical Artifact Model for BPs + Artifacts (info models) + Semantic services (IOPEs) if C enable … Conditionaction n. A variation of [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] n [Hull-S. 09] (in preparation) NJU Summer School of Software Engineering 2012/7/23 81
Verification Problem n Given a workflow and a goal, do all executions of the workflow satisfy the goal? + Artifacts (Info models) + Semantic services (IOPEs) if C enable … ? = Conditionaction [Bhattacharya-Gerede-S. SOCA 07] [Gerede-S. ICSOC 07] [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] [Deutsch-Hull-Patrizi-Vianu ICDT 09] [Vianu ICDT 09] NJU Summer School of Software Engineering 2012/7/23 82
Synthesis Problem n Given a goal and a set of services, construct a set of rules so that every execution satisfies the goal + Artifact (Info model) Semantic services (IOPEs) + Goal (FO) ? if C enable … Conditionaction [Fritz-Hull-S. ICDT 09] (restricted to single artifact, first-order goals) NJU Summer School of Software Engineering 2012/7/23 83
Workflow Schema n. A workflow schema is a triple W = ( G, S, R ) v. G : a set of artifacts classes (artifact schema) v S : a set of (semantic) services v R : a set of condition-action rules NJU Summer School of Software Engineering 2012/7/23 84
A First-Order Logic + Structure n Assuming some first order logic L with a fixed structure v U is the universe n Existence of an infinite set of artifact IDs n Existence of an infinite set of attributes NJU Summer School of Software Engineering 2012/7/23 85
Artifact Classes n An artifact class consists of v a finite set of attributes, of type U or artifacts IDs va finite set of states, initial and final states (transitions not defined) n An artifact is a pair: v a mapping from attributes to U IDs va state Guest. Check Artifact GCID date time Name KOID table# TOTAL Payment ptime Waiting for table NJU Summer School of Software Engineering Seated Ordered 2012/7/23 Delivered Completed 86
Artifacts in a Workflow runtime, each artifact class in G may have a finite set of artifacts n During n The union I of sets of artifacts must be closed under “cross-referencing” NJU Summer School of Software Engineering 2012/7/23 87
(Semantic) Services n. A service has a precondition and effects, conditions on v Attribute values v Defined-ness of attribute values v Equality of artifact IDs v An attribute holds the ID of a newly created artifact SERVICE Seating. Guests WRITE: x: Guest. Check} READ: x: Guest. Check, y: Table PRE-CONDITION: Defined(x. table#) EFFECTS: Defined(y. GCID) - Defined(x. table#) Seated(x) - Defined(x. table#) Waiting 4 table(x) NJU Summer School of Software Engineering 2012/7/23 88
Another Example A 0 A 2 NJU Summer School of Software Engineering s B 0 A<1 0 B 1 A 2 1 B 2012/7/23 89
(Semantic) Services n. A (semantic) service is a tuple (s, R, W, p, r), where vs is a task name v R, W are finite sets of (resp. , read, write) artifacts v p, r are quantifier-free formulas (pre- and postcondition, resp. ) over attributes of artifacts in R, R W, resp. n allow Defined(A) for an attribute A s is the result of executing s on I, I I , if v (I, I ) = p r, and n I v frame conditions are satisfied NJU Summer School of Software Engineering 2012/7/23 90
Condition-Action Rules that define business logic v Invoke a service v Change artifact states are used to organize the processing if Waiting 4 Table(x) enable Seaing. Guest(x) if Defined(x. GCID) Defined(x. GCID. table#) change state to Taken(x) Seated(x. GCID) NJU Summer School of Software Engineering 2012/7/23 91
Condition-Action Rules n. A condition-action rule is an expression of form “if enable s” or “if change state to f” or where v is a (quantifier-free) formula v s is a semantic service v f is a state changing formula n I if r is the result of executing a rule r : if … on I, I I , v I = , and s v I I or I, I only differ on states as specified NJU Summer School of Software Engineering 2012/7/23 92
Workflow Schema n. A workflow schema is a triple W = (G, S, R) v. G : artifact schema v S : a finite set of semantic services v R : a finite set of condition-action rules * n Denote r the closure of NJU Summer School of Software Engineering r R 2012/7/23 93
Verification Problem n Given a workflow and a goal, do all executions of the workflow satisfy the goal? + Artifacts (Info models) + Semantic services (IOPEs) if C enable … ? = Conditionaction [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] [Deutsch-Hull-Patrizi-Vianu ICDT 09] NJU Summer School of Software Engineering 2012/7/23 94
Analysis Problems n An artifact system W = ( G, S, R ) artifacts, services, rules n Completion: Does W allow a complete run of some artifact? n Dead-end: Does W have a dead-end path? n Attribute redundancy: Does W have a redundant attribute? No attribute value comparisons [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] NJU Summer School of Software Engineering 2012/7/23 95
Results n The problems are undecidable Primary reason: workflow language is Turing complete n If we disallow creation of new artifacts v Initial: if each artifact has only initial attributes defined The analysis problems are PSPACE-complete v even for a single artifact [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] n Consider only a single artifact NJU Summer School of Software Engineering 2012/7/23 96
Monotonic Workflow n Once an attribute is assigned a value, it cannot be changed n For monotonic services: Complexity ranging from linear to intractable under various conditions [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] NJU Summer School of Software Engineering 2012/7/23 97
Completion (Monotonic Workflow) n Linear time if v Services are deterministic (single effect) v Preconditions has no negation v Rule conditions are positive and does not check state information n NP-complete if the above conditions are slightly relaxed (single artifact) [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] NJU Summer School of Software Engineering 2012/7/23 98
Dead-End & Redundancy (Monotonic Workflow) 2 if there is a dead end path is Pp -complete, even with various restrictions n Checking redundant attributes is co-NP-complete, even with various restrictions (single artifact) [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] NJU Summer School of Software Engineering 2012/7/23 99
Three Analysis Problems: Review n An artifact system W = ( G, S, R ) artifacts, services, rules n Completion: Does W allow a complete run of an artifact? n Dead-end: Does W have a dead-end path? n Attribute redundancy: Does W have a redundant attribute? n Undecidable in general, PSPACE if no artifact creation, intractable for monotonic workflows [Bhattacharya-Gerede-Hull-Liu-S. BPM 07] n Ad hoc properties, restricted to defined-ness n How to verify LTL properties? [Deutsch-Hull-Patrizi-Vianu ICDT 09] NJU Summer School of Software Engineering 2012/7/23 100
Adding Infinite States to Artifacts n An artifact is a pair: v a mapping from attributes to U IDs va state relation Guest. Check Artifact GCID date time Name KOID table# TOTAL Payment ptime Waiting for table Seated Ordered Delivered Completed Items Item. No Qty cooking. Req Table# NJU Summer School of Software Engineering 2012/7/23 101
Services Can Update State Relations n Model operations on artifacts v updates of the artifact attributes v insertions/deletions in artifact states n Insertions & updates can draw values from … v current artifacts, state relations v external inputs (by programs or humans), computation that returns new values NJU Summer School of Software Engineering 2012/7/23 102
Service Specification Consists of n pre-condition: a Boolean query on current snapshot of artifact system n post-condition : constraints on the updated artifacts n for each state relation, state insertion/deletion rules v specify tuples to add to (remove from) state relations v Defined as queries (over current snapshot) queries, constraints: FO logic formulas NJU Summer School of Software Engineering 2012/7/23 103
LTL(FO) to Express Properties n LTL with propositions replaced by FO formulas (statements on individual snapshots) n Classic LTL temporal operators Xp p holds in next snapshot p. Uq p is true in every snapshot until q is Fp p is eventually true Gp p is always true n Example n The (with slight abuse of notation) : G ( Defined(table#) z Items(z)) domain is dense order without endpoints NJU Summer School of Software Engineering 2012/7/23 104
Verification Problem Guest. Check Artifact ? = GCID date time Name KOID table# TOTAL Payment ptime Items Item. No Qty cooking. Req Table# n In Services general, it is undecidable n Need LTL(FO) [Deutsch-Hull-Patrizi-Vianu ICDT 09] restrictions to turn it into decidable NJU Summer School of Software Engineering 2012/7/23 105
![Guarded FO [Deutsch-Hull-Patrizi-Vianu ICDT 09] n Guarded FO formulas restrict quantifications: x (x) x](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-106.jpg "Guarded FO [Deutsch-Hull-Patrizi-Vianu ICDT 09] n Guarded FO formulas restrict quantifications: x (x) x")
Guarded FO [Deutsch-Hull-Patrizi-Vianu ICDT 09] n Guarded FO formulas restrict quantifications: x (x) x (A(. . . , x, . . . ) (x)) A(. . . , x, . . . ) : x is an attribute value and x cannot appear in any state atoms in n All formulas used to update states are guarded FO n Guarded LTL(FO): only allow guarded FO formulas n Originated from input boundedness of NJU Summer School of Software Engineering 2012/7/23 [Spielmann 2003] 106
Guardedness is a Serious Limitation n Not guarded: G ( Defined(table#) z Items(z)) n Guarded: G ( Defined(table#) Items(fish, 1, x, 12)) NJU Summer School of Software Engineering 2012/7/23 107
![Decidability Result [Deutsch-Hull-Patrizi-Vianu ICDT 09] n It can be decided in PSPACE if a](https://present5.com/presentation/55bede045abe21e4bdcb47d936409c99/image-108.jpg "Decidability Result [Deutsch-Hull-Patrizi-Vianu ICDT 09] n It can be decided in PSPACE if a")
Decidability Result [Deutsch-Hull-Patrizi-Vianu ICDT 09] n It can be decided in PSPACE if a guarded artifact schema satisfies a (guarded) LTL(FO) n Actually complete in PSPACE NJU Summer School of Software Engineering 2012/7/23 108
Summary n Biz workflow a very promising application area for WS— tremendous impact (potentially) n Analysis is hard but could be helped with modeling choices n Artifact-centric workflow models: right intuition and positive experiences in practice (IBM) n “Report on 2009 NSF Workshop on Data Centric Workflows” dcw 2009. cs. ucsb. edu v More than 20 contributors, experts from CS, MIS, digital government, healthcare, scientific workflow NJU Summer School of Software Engineering 2012/7/23 109
Concluding Remarks n WS analysis and verification is important & interesting v Modeling v Design n Current results: a good starting point n SOA themes are yet to emerge, many open issues related to analysis n Dynamic analysis NJU Summer School of Software Engineering 2012/7/23 110
Acknowledgements n Collaborators: v Tevfik Bultan (U C Santa Barbara) v Xiang Fu (Hofstra University) v Richard Hull, Kamal Bhatacharya, Rong Liu (IBM TJ Watson) v Cagdas Gerede (TOBB Univ. of Economics & Tech. ) n Others: v Victor Vianu, Alin Deutsch (UCSD) v Fabio Patrizi (U of Rome) NJU Summer School of Software Engineering 2012/7/23 111
References K. Bhattacharya, C. Gerede, R. Hull, R. Liu, and J. Su: Towards Formal Analysis of Artifact-Centric Business Process Models. BPM 2007: 288 -304 D. Brand P. Zafiropulo: On Communicating Finite-State Machines. J. ACM 30(2): 323 -342 (1983) T. Bultan, X. Fu, R. Hull, and J. Su: Conversation specification: a new approach to design and analysis of e-service composition. WWW 2003: 403 -410 A. Deutsch, R. Hull, F. Patrizi, and V. Vianu: Automatic verification of data-centric business processes. ICDT 2009: 252 -267 A. Deutsch, L. Sui, and V. Vianu: Specification and Verification of Data-driven Web Services. PODS 2004: 71 -82 D. Fahland W. Reisig: ASM-based Semantics for BPEL: The Negative Control Flow. Abstract State Machines 2005: 131 -152 R. Farahbod, U. Glässer, and M. Vajihollahi: Specification and Validation of the Business Process Execution Language for Web Services. Abstract State Machines 2004: 78 -94 A. Ferrara: Web services: a process algebra approach. ICSOC 2004: 242 -251 H. Foster, S. Uchitel, J. Magee, J. Kramer: Model-based Verification of Web Service Compositions. ASE 2003: 152 -163 C. Fritz, R. Hull, and J. Su: Automatic construction of simple artifact-based business processes. ICDT 2009: 225 -238 X. Fu, T. Bultan, and J. Su: Conversation Protocols: A Formalism for Specification and Verification of Reactive Electronic Services. CIAA 2003: 188 -200 X. Fu, T. Bultan, and J. Su: Analysis of interacting BPEL web services. WWW 2004: 621 -630 X. Fu, T. Bultan, and J. Su: Model checking XML manipulating software. ISSTA 2004: 252 -262 C. Gerede and J. Su: Specification and Verification of Artifact Behaviors in Business Process Models. ICSOC 2007: 181 -192 C. Gerede, K. Bhattacharya, and J. Su: Static Analysis of Business Artifact-centric Operational Models. SOCA 2007: 133 -140 M. Koshkina and F. van Breugel: Modelling and verifying web service orchestration by means of the concurrency workbench. ACM SIGSOFT Software Engineering Notes 29(5): 1 -10 (2004) S. Merz: Model Checking: A Tutorial Overview. MOVEP 2000: 3 -38 S. Nakajima: Model-Checking of Safety and Security Aspects in Web Service Flows. ICWE 2004: 488 -501 A. Nigam and N. Caswell: Business artifacts: An approach to operational specification. IBM Systems Journal 42(3): 428 -445 (2003) M. Pistore, P. Traverso, P. Bertoli, and A. Marconi: Automated Synthesis of Composite BPEL 4 WS Web Services. ICWS 2005: 293 -301 G. Salaun, L. Bordeaux, and M. Schaerf: Describing and Reasoning on Web Services using Process Algebra. ICWS 2004: 43 -51 G. Salaun, A. Ferrara, and A. Chirichiello: Negotiation Among Web Services Using LOTOS/CADP. ECOWS 2004: 198 -212 M. Spielmann: Verification of relational transducers for electronic commerce. J. Comput. Syst. Sci. 66(1): 40 -65 (2003) V. Vianu: Automatic verification of database-driven systems: a new frontier. ICDT 2009: 1 -13 NJU Summer School of Software Engineering 2012/7/23 112
Скачать презентацию Web Services Formal Modeling and Analysis Jianwen Su
55bede045abe21e4bdcb47d936409c99.ppt