1 / 112

Web Services: Formal Modeling and Analysis

Web Services: Formal Modeling and Analysis. Jianwen Su University of California, Santa Barbara. The Verification Problem. Given a web service / composition / choreography / workflow /… a goal j do all executions satisfy the goal? Choices for and j. ?.  = j. Outline.

kin
Download Presentation

Web Services: Formal Modeling and Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Services:Formal Modeling and Analysis Jianwen Su University of California, Santa Barbara

  2. The Verification Problem Given • a web service/composition/choreography/workflow/… • a goal j do all executions satisfy the goal? Choices for and j ? =j NJU Summer School of Software Engineering

  3. Outline • Motivations • Transitions systems • BPEL services and compositions • Choreographies (of BPEL services) • Artifact-centric workflow • Concluding remarks ? =j NJU Summer School of Software Engineering

  4. Software Systems in the Real World • Wide range of applications: • Web stores, e-tailors, … • Accounting, financial systems, … • Automated flight control, … • Patient profiles, cases, care records, … • Governments: local, federal, courts, prisons, … • … • Challenges: • Interoperation & integration NJU Summer School of Software Engineering

  5. Software Systems in the Real World • Wide range of applications: • Web stores, e-tailors, … • Accounting, financial systems, … • Automated flight control, … • Patient profiles, cases, care records, … • Governments: local, federal, courts, prisons, … • … • Challenges: • Interoperation & integration • Design and analysis • Improvements (evolution) NJU Summer School of Software Engineering

  6. Web Services: Standardization • The Web: Flexible human-software interaction • Web services: Flexible software-software interaction • SAAS: Software As A Service • A working definition: software services accessible via standardized protocols • SOA: a potential basis for software system design, interoperation, integration, … • Lots of interest in trade press, academic community, standards bodies, . . . • Applications in e-commerce, telecom, science, cloud, government, education, . . . NJU Summer School of Software Engineering

  7. Fundamental Elements (WS Apps) • Process: a collection of actions to be taken in a meaningful manner (sequential, parallel, conditional, …) • Communication or messages: different software systems need to cooperate, collaborate • Data: guide the actions to be taken and processes to follow • 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

  8. Research Challenges (Biz Workflows) • Models: process, data, messages, actors • Analysis and verification • Integration/interoperation • Improvements (biz intelligence, operation optimization, …) • Management of workflows and executions NJU Summer School of Software Engineering

  9. Goals • Focus on analysis & verification problem • Depending on models • A sampler of verification problems, approaches and results NJU Summer School of Software Engineering

  10. Outline • Motivations • Transitions systems • BPEL services and compositions • Choreographies (of BPEL services) • Artifact-centric workflow • Concluding remarks ? =j NJU Summer School of Software Engineering

  11. Transition Systems • A finite transition system (Kripke structure) is a tupleT= (S, I, R, L) where • a finite set of states S • a set of initial states I S • a transition relation R  S  S • a labeling function L: S 2P • P : a set of atomic propositions NJU Summer School of Software Engineering

  12. Example • P= {q1, q2, q3} L(s3) = {q1, q2} s1 TFF s3 TTF s6 TTF s0 FFF s5 TTT s2 FTF s4 FTT s7 FFT NJU Summer School of Software Engineering

  13. Runs (Execution Paths) • Given a finite transition systemT= (S, I, R, L) • A run is an infinite sequence of statesZ = s0s1s2   where for each i 0, (si, si+1) R • s0s1s2s3s5s1s2… s1 TFF s3 TTF s6 TTF s0 FFF s5 TTT s2 FTF s4 FTT s7 FFT NJU Summer School of Software Engineering

  14. Linear Temporal Logic (LTL) • A set P of atomic propositions: q1, q2, q3, … • Logical connectives: , ,  • Temporal operators: • Xj: j is true in the next state • Gj : j is true in every state • yUj : y is true in every state before the state j is true • Fj : j is true in some future state X: nextG: alwaysU: untilF: eventually • Example: G(moneyFfood) NJU Summer School of Software Engineering

  15. Semantics of Temporal Operators • Truth value of a formula is defined on runs • Propositional connectives have the usual meaning • Temporal operators: X: nextG: alwaysU: untilF: eventually Fq1trueUq1Gq1Fq1       Xq1 q1 Gq1    q1 q1 q1 q1 q1 q1 q1 q1 q1Uq2 q1 q1 q1 q1 q2       Fq1 q1 NJU Summer School of Software Engineering

  16. LTL Semantics • A state is a set of propositions • A run Z=s0s1s2satisfies an LTL formula: • Z=q if s0=q or q L(s0) • Z= if ZZ=y if Z= and Z=yZ=y if Z= or Z=y • Z=Xj if s1s2= • Z=Gj if for each i, sisi+1= • Z=Fj if for some i, sisi+1= • Z=yUj if for some i, sisi+1= and for each j < i, sjsj+1=y NJU Summer School of Software Engineering

  17. Transition Systems and LTL • A transition system Tsatisfies an LTL formula j ifevery run of T satisfies j • Fq3 G(q3Xq3) s1 TFF s3 TTF s6 TTF s0 FFF s5 TTT s2 FTF s4 FTT s7 FFT NJU Summer School of Software Engineering

  18. Verifying LTL Properties • Problem: given a transition system T, an LTL formula j, determine if j is satisfied by T (i.e. every run of T) • A decision algorithm: • Construct a Büchi automatonBj equivalent to j • Explore (depth-first search) simultaneously T and Bj, • 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

  19. Büchi Automata • P is a (finite) set of propositions • A Büchi automaton is a tuple B = (Q,I, d, F) where • Q is a finite set of states • I  Q is a (nonempty) set of initial states • F Q is a set of final states • dQ2PQ is a transition relation • Essentially nondeterministic finite state automata but accepting infinite words: • A word in (2P)w 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

  20. An Example {q1}, {q2} {q2} {q2} q0 q1 NJU Summer School of Software Engineering

  21. LTL to Büchi Automata • A Büchi automaton Bis equivalent to an LTL formula j:an infinite sequence Z satisfies j iff ZL(B) • For each LTL formula j, one can construct a Büchi automaton Bj equivalent to j • Number of states in Bj is 2O(|j|) • 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

  22. Model Checking T : a transition system, j : an LTL formula • Construct a Büchi automaton Bj equivalent to j • Explore (depth-first search) simultaneously T and Bj, • if a repeat is found involving a final state of Bj,halt and output “no” (the trace is the counter example) Otherwise, output “Yes” (T satisfies j) • Complexity: O(2O(|j|)|T|) time, PSPACE [Merz MOVEP 2001] NJU Summer School of Software Engineering

  23. Outline • Motivations • Transitions systems • BPEL services and compositions • Choreographies (of BPEL services) • Artifact-centric workflow • Concluding remarks ? =j NJU Summer School of Software Engineering

  24. Business Process Execution Language • Allow specification of compositions of Web services • business processes as coordinated interactions of Web services • Allow abstract and executable processes • Influences from • Traditional flow models • Structured programming • Successor of WSFL and XLANG • Assumes WSDL ports • OASIS standard NJU Summer School of Software Engineering

  25. Illustrating a BPEL Service receive invoke assign  reply  NJU Summer School of Software Engineering

  26. BPEL to Transition Systems [Fu-Bultan-S. WWW ’04] • Translate each atomic activity to a transition system with single entry, single exit receive … operation = "approve" variable = "request"/ request := approve_Out ?approve_Out invokeoperation="approve",invar="request", outvar="aprvInfo" catch faultname="loanfault"  ... handler1.../ /catch /invoke approve_In := request; !approve_In loanfault ?approve_Out handler1 aprvInfo := approve_Out Treat actions as propositions NJU Summer School of Software Engineering

  27. BPEL to Transition Systems activity1 activity2 X disallow the ordersprohibited by the link [Fu-Bultan-S. WWW ’04] • Control flow constructs: assemble pieces of transition systems sequence… activity1 …/… activity2 …/ /sequence activity1 activity2 flowactivity1 … source linkname = “link1”…/ /activity1 activity2 …target linkname = “link1”/ /activity2 /flow NJU Summer School of Software Engineering

  28. Verifying BPEL Services • S: a BPEL service, P: a set of propositions,j: an LTL formula • Determine if every execution of S satisfies j • Algorithm: 1. Construct a transition system TS,P 2. Determine if TS,P satisfies j • Complexity: O(2O(|j|)|S|) time • Good news but • Control states (flow) only, no variables/data • Single service, no composition NJU Summer School of Software Engineering

  29. Adding Data • BPEL allows variables to hold XML documents • Bad news (folklore): BPEL is Turing (computationally) complete • Immediate consequence: It is undecidable if a given BPEL service satisfies a given LTL formula • One possible restriction: limit variables to • finite domains: the number of possible values is finite NJU Summer School of Software Engineering

  30. Finite Domain Variables • Represent variable contents explicitly through states • Transition states increased by nm times:n : (max) domain size, m : number of variables • Complexity of verification: O(2O(|j|)|S|nm) timej : LTL formula, S : BPEL service ?quantity ?quantity= 1 ?quantity= 2 . . . [Fu-Bultan-S. ISSTA ’04] ?quantity= 15 NJU Summer School of Software Engineering

  31. Composition of BPEL Services register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. • Peer to peer • Mediated orhub-and-spoke Mediator Investor Research Dept. Stock Broker NJU Summer School of Software Engineering

  32. Synchronous Messaging Model synchronization • Two specific actions: • Send a message (!) • Receive a message (?) store bank <receive>:response <invoke>: request-response ?authorize !authorize … ?ok <invoke>: request !ok … NJU Summer School of Software Engineering

  33. Product with Synchronous Messaging 11 a1 a2 r1 r2 e 12 24 13 • Two services • Their synchronous product as a transition system: requester server 4 2 r1, r2 ?e e !e !r1 !r2 !a1 !a2 1 1 ?a1 a1, a2 ?r2 ?a2 ?r1 3 2 NJU Summer School of Software Engineering

  34. Product with Synchronous Messaging • In general, the composition of k BPEL services with synchronous messaging can be modeled as a transition system with rk states where • ris the (max) number of states in a single service • Complexity of verification: O(2O(|j|)(|S|nm)k) time • j : 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

  35. Asynchronous Messaging [Bultan-Fu-Hull-S. WWW ’03] • Two specific actions: • Send a message (!) • Receive a message (?) • FIFO queues are used to buffer unconsumed messages • One queue per service for incoming messages store bank receive:response invoke:request-response ?authorize !authorize … ?ok invoke:request !ok … NJU Summer School of Software Engineering

  36. Verification is Undecidable • Finite state automata with FIFO queues are Turing complete [Brand-Zafiropulo JACM’83] • Immediate consequence: Verification problem is undecidable • One possible restriction: bound queue size NJU Summer School of Software Engineering

  37. Bounded Queues & Finite State Automata • Observation: a bounded length queue has a finite number of states • Asynchronous + bounded queue can be simulated • Note: Only focus on message types not content … … … !a ?a ?a a … … ?b … b a synchronize !b !a … … b NJU Summer School of Software Engineering

  38. BPEL with Asynchronous Messaging • Number of states for queues: el, wheree : number of message types, l : queue length bound • With message contents: elnl, where n is domain size • Complexity of verification: O(2O(|j|)(|S|nmelnl)k) time • j : 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

  39. Summary of Verifying BPEL Services • Focus on decidability boundary of LTL properties of BPEL + compositions (synchronous, bounded queue asynchronous messaging) • Verification algorithms: map to exiting verifiers • Model checker: SPIN [Fu-Bultan-S. 2003-4] [Nakajima 2004], [Pistore-Traverso-et al 2005] • Process algebras: LTSA [Foster-Uchitel-Magee-Kramer 2003],CWB [vanBreugel-Koshkina 2004] [Salaun-Bordeaux-Schaef 2004], LOTOS [Ferara 2004][Salaun-Ferara-Chirichiello 2004] • ASM: [Farahbod-Classer-Vajihollahj 2004][Deutsch-Sui-Vianu 2004] [Fahland-Reisig 2005] • … NJU Summer School of Software Engineering

  40. Outline • Motivations • Transitions systems • BPEL services and compositions • Choreographies (of BPEL services) • Artifact-centric workflow • Concluding remarks ? =j NJU Summer School of Software Engineering

  41. Composition: Common Topologies register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. Mediator Investor Research Dept. Stock Broker • Peer-to-peer • Mediated, or“hub and spoke” NJU Summer School of Software Engineering

  42. Orchestration vs Choreography WS-CDL Choreography BPEL OWL-S ServiceModel Composition WSCL (Individual)ServiceDescription WSDL OWL-S ServiceProfile SOAP XMLMessaging NJU Summer School of Software Engineering

  43. WSChoreography Definition Language • Specification of choreography • Model complex business protocol (e.g. order management) to enable interoperability • Generate computational logic of individual collaborating participants • Key concepts • Collaborating participants: role, relationship, participants • Information driven collaboration: channel, activities, workunit, choreography • Standardization through W3C (Version 1.0: December 2004) NJU Summer School of Software Engineering

  44. Composition: BPEL and WS-CDL register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. Mediator Investor Research Dept. Stock Broker Focus on local actions Focus on global behaviors BPEL WS-CDL NJU Summer School of Software Engineering

  45. Composition: BPEL and WS-CDL register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. Mediator Investor Research Dept. Stock Broker Focus on global behaviors Focus on local actions orchestration BPEL Choreography WS-CDL • For “hub and spoke”, the difference is smallFor “peer-to-peer”, the concept of choreography is interesting and not well understood NJU Summer School of Software Engineering

  46. Automated Design: Top-down vs Bottom-up register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. • Verification and analysis of choreography • Focus on the conversation model Top-down specification ofindividual services specification ofglobal behaviors orchestration Choreography Bottom-up e.g., BPEL e.g., WS-CDL NJU Summer School of Software Engineering

  47. Verification of WS Choreography register, ack, cancel Investor Stock Broker accept, reject, bill report request, terminate Research Dept. • Verification of choreography of a WS (BPEL) composition • Services: finite transition systems on messaging actions • Unbounded FIFO queues for messages • Choreography: message sequences (send only) • How to model? • LTL on choreography [Fu-Bultan-S. WWW’04, ISSTA’04] NJU Summer School of Software Engineering

  48. An Example: Stock Analysis Service (SAS) Three peers: Investor, Stock Broker, and Research Dept • Inv initiates the stock analysis service by sending a register message to SB • SB mayacceptorrejectthe registration • If the registration is accepted, SB sends an analysis requestto the RD • RD sends the results of the analysis directly to the Inv as areport • After receiving a reportInvcan either send anacktoSBorcancelthe service • Then,SBeither sends thebillfor the services to Inv, or continues the service with another analysisrequest NJU Summer School of Software Engineering

  49. SAS Composition • SAS is a web service composition • a finite set of peers: Inv, SB, RD, and • a finite set of message classes: register, ack, cancel, accept, ... register ack Investor (Inv) Stock Broker (SB) cancel accept reject bill request report terminate Research Dept. (RD) NJU Summer School of Software Engineering

  50. Asynchronous Messaging • We assume that the messages among the peers are exchanged through reliable and asynchronous messaging • FIFO and unbounded message queues Stock Broker (SB) Research Dept. (RD) req req • This model is similar to industry efforts such as • JMS (Java Message Service) • MSMQ (Microsoft Message Queuing Service) NJU Summer School of Software Engineering

More Related