Dependable Workflow Technology Gerhard Weikum University of the

Dependable Workflow Technology Gerhard Weikum University of the Saarland, Germany weikum@cs. uni-sb. de http: //www-dbs. cs. uni-sb. de/ © Gerhard Weikum 1

Guiding Mottos - 20 Years Ago and Now 1983: „We don‘t know where we are heading, but we want to be there first!“ 2002: „Time to market is everything!“ © Gerhard Weikum 2

Conclusion • Time to market, featurism, and $$$ • Dependability and service guarantees ? ? ? gears to build highly dependable systems • Shift with predictable, guaranteed behavior !!! Dependable workflow technology: • Provably correct behavior • World-wide failure masking Qo. S with • Guaranteed „autonomic“ systems © Gerhard Weikum http: //www-dbs. cs. uni-sb. de/~mlite/3

What I Can Offer • Overview of the area • Relevant foundations • Logic, formal spec, verification • Fault-tolerant computing • Stochastic performance modeling • Interesting research problems What Do You Want? © Gerhard Weikum 4

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration • What Is It All About? • WF Specification Techniques • Statecharts • CTL and Model Checking • Summary and • WF Execution Infrastructure • Failure Handling • Stochastic Modeling • WF System Configuration • Summary and Open Research Issues © Gerhard Weikum Open Research Issues 5

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration What Is It All About? • WF Execution Infrastructure • Failure Handling • Stochastic Modeling • WF System Configuration • Summary and • WF Specification Techniques • Statecharts • CTL and Model Checking • Summary and Open Research Issues © Gerhard Weikum Open Research Issues 6

Workflow Application Example 1: Credit Request Processing Enter Credit Request Check Credit Worthiness Make Decision Check Risk © Gerhard Weikum 7

Workflow Application Example 2: Journal Refereeing Process Choose referees Receive submitted paper © Gerhard Weikum Contact referee 1 Send paper Contact referee 2 . . . Contact referee 3 . . . Remind referee 1 Receive review 1 Make editorial decision Notify author 8

What is Workflow Management? Computer-supported business processes: coordination of control and data flow between distributed - automated or intellectual - activities Application examples: Credit requests, insurance claims, etc. Tax declaration, real estate purchase, etc. Student exams, journal refereeing, etc. Electronic commerce, virtual enterprises, etc. © Gerhard Weikum 9

Workflow Management System Architecture Workflow specification Workflow server . . . © Gerhard Weikum Applications 10

Workflow Management System Architecture Baroque Workflow specification Workflow server Nonscalable performance Failure-prone execution . . . © Gerhard Weikum Applications 11

The Great Vision Make e-Business as simple as amoeba business ! “And, as amoebas, you’ll have no problems recruiting other sales reps . . . just keep dividing and selling, dividing and selling. ” © Gerhard Weikum 12

Business Benefits of Workflow Technology Business process automation (to the extent possible and reasonable) shorter turnaround time, less errors, higher customer satisfaction better use of intellectual resources for exceptional cases Transparency understanding & analyzing the enterprise Fast & easy adaptation Business Process Reengineering (BPR) © Gerhard Weikum 13

Technical Benefits of Workflow Technology Application Integration (by loose coupling of activities) without having to tackle enterprise-wide data integration problems supports incremental long-term migration from stand-alone applications to electronic processes Support for Legacy Applications by wrapping them into business activities Extends Transactions to Long-lived Processes Scalability, Reliability, Availability, Manageability © Gerhard Weikum 14

Workflow Management Systems (WFMS): Products and Research Prototypes • Biz. Talk (MS) Staffware Changeengine / E-Speak (HP) j. Flow / Web. Logic (BEA) In. Concert (Tibco) SAP Workflow • • Wide and Cross. Flow (EU projects) Adept (U Ulm) Wasa (U Muenster)) Opera (ETH Zurich) Mentor-lite (U Saarland) CMI (MCC) Meteor (U Georgia) . . . • • • MQSeries Workflow / Web. Sphere (IBM) + workflow technology embedded in E-Commerce products and ERP systems © Gerhard Weikum 15

Wf. MC Reference Architecture Workflow Management System (WFMS) Administration & Monitoring Tools Process Definition Tools Workflow Engine Workflow Enactment Service Workflow Client Applications © Gerhard Weikum Other WF Enactment Services Invoked Applications 16

Integration with Internet Technologies XML (eb. XML, . . . ) XML (WSFL, XLANG, . . . ) UDDI HTTP, DHTML © Gerhard Weikum WSDL, SOAP, EJB, CORBA 17

Hard Issues and Research Directions computational complexity Blues problems (NP-complete) business (bureaucratic) complexity Rap problems (e-complete) system complexity Techno problems (DB-complete) semantic complexity Psychedelic problems (AI-complete) © Gerhard Weikum 18

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration • WF Execution Infrastructure What Is It All About? WF Specification Techniques • Failure Handling • Statecharts • CTL and Model Checking • Summary and Open Research Issues © Gerhard Weikum • Stochastic Modeling • WF System Configuration • Summary and Open Research Issues 19

Specification in WFMS Products <flow. Model name="total. Supply. Flow" <service. Provider. Type="total. Supply"> <service. Provider name="buyer" type="buyer" /> . . . <activity name="submit. PO">. . . </activity> <control. Link source="submit. PO" target="process. PO"/> <control. Link source="process. PO" target="process. Payment"/> . . . <data. Link source="submit. PO" target="process. PO"> <map source. Message="purchase. Order" target. Message="purchase. Order"/> </data. Link> . . . graphs. . . and scripts imprecise or ad hoc semantics © Gerhard Weikum 20

Specification Methods Requirements: Solutions: • • Visualization • • Rigorous Semantics Interoperability with other methods & tools Import / export BPR tools WFMS • Wide acceptance & standard compliance Statecharts included in UML industry standard (Unified Modeling Language, OMG 1997)) Refinement & Composability © Gerhard Weikum Statecharts (Harel et al. 1987) (alt. : Petri Net variants, temporal logic, process algebra, script language) 21

Example of Harel-style Activitychart describes process structure • nodes: activities • edges: data flow © Gerhard Weikum 22

Example of Harel-style Statechart describes process behavior • nodes: execution states • edges: control flow • transition labels: • event [condition] / action rules © Gerhard Weikum 23

Refinement of Harel-style Statechart © Gerhard Weikum 24

Example of Workflow-style Activitychart CREDIT_REQUEST_AC DE Customer Data © Gerhard Weikum Customer Data CCW RSK Customer Data DEC ERROR DE: Data Entry CCW: Check Credit Worthiness RSK: Risk Assessment DEC: Decision 25

Example of Workflow-style Statechart CREDIT_REQUEST_SC DE_S [DE_OK and not (Amount < 1000] INIT_S CR_S CCW_S RSK_S [CCW_OK and RSK_OK]] DEC_S [DEC_OK] [DE_OK and Amount < 1000] [DE_NOK or CCW_NOK or RSK_NOK or DEC_NOK or] ERROR_S END_S © Gerhard Weikum 26

More Sophisticated Statechart Example / Budget: =1000; Trials: =1; Select Conf [Found] / Cost: =0 [!Found] Check. Conf. Fee Check Flight Select Tutorials Compute Fee Go [Cost Budget] Check Cost Check Airfare Check Hotel [Cost > Budget [Fok & Eok] & Trials 3] / Cost : = Conf. Fee + Travel. Expenses No Check. Travel Expenses [Cost > Budget & Trials < 3] / Trials++ © Gerhard Weikum 27

E-Commerce Workflow: Activitychart ECommerce_AC Name, Date, Credit. Card. Number, . . . Credit. Card. Check Credit. Card. Number, Amount, . . . Credit. Card. Charge New. Order Notify Order. Number, Email. Address. , . . . Name, Address, Order. Number, . . . Payment @ECommerce_SC © Gerhard Weikum Order. Number, Item. List, . . . Find. Store Acknowledgement Order. Number, Address, . . . Store. ID, Item. List, . . . Check. Store 28

E-Commerce Workflow: Statechart ECommerce_SC INIT_S New. Order_S [Pay. Bill and New. Order_DONE] [Credit. Card. Not. OK and [Pay. By. Credit. Card and Credit. Card. Check_DONE] New. Order_DONE] Credit. Card. Check_S [Credit. Card. OK and Credit. Card. Check_DONE] Shipment_S Notify_INIT_S Delivery_INIT_S Find. Store_S [All. Items. Processed] Notify_S © Gerhard Weikum Notify_EXIT_S [Item. Available and Check. Store_DONE] Check. Store_S [Items. Left and Find. Store_DONE] /fs!(Item. Available) [in(Notify_EXIT_S) and in(Delivery_EXIT_S) and Pay. Bill] Payment_S [Payment_DONE] [Notify_DONE] Delivery_EXIT_S [in(Notify_EXIT_S) and in(Delivery_EXIT_S) and Pay. By. Credit. Card] Credit. Card. Charge_S [Credit. Card. Charge_DONE] EC_EXIT_S 29

Workflow Administration From Organizational Viewpoint • Worklist Management: • Work History Management and Evaluation: © Gerhard Weikum Who is assigned which pieces of work? Which processes are late? Which process types have inherent bottlenecks? How can we improve work effectivity? 30

Worklist Management • Assignment: Work Items Actors • • Static Mapping onto Roles (where a work item is a non-automated activity that is ready to be started) Dynamic Resolution of Roles into Actors (based on competence, availability, experince, etc. ) + additional functions: - enforcing constraints (e. g. , dual control) - monitoring of deadlines and alerting - priority control - load balancing © Gerhard Weikum 31

Worklist Management Implementation Typical solution: worklist manager and worklist DB on server , worklist GUI for clients © Gerhard Weikum 32

Worklist Management Example Find all actors who are capable of performing the role, have the necessary permissions, and are currently available. Among those, assign the work item to the actor with the lowest current workload. © Gerhard Weikum 33

Worklist Management Strategies Parameters to be considered: • organizational structure of the enterprise • actors´ expertise and experience • actors´ availability and load • workflow-instance-specific restrictions Implementation of a worklist strategy: • specifying the strategy as a workflow • implement the activities (queries against organizational databases) • integrate the strategy into the workflow © Gerhard Weikum 34

Integration of Worklist Strategies Rationale: Worklist strategies are workflows themselves! Original specification E 1[C 1] /st!(activity 1) S 1 E 2[C 2] /st!(activity 2) . . . S 2 Work assignment strategy included as nested statechart S 2 E 1[C 1] S 1 © Gerhard Weikum . . . /st!(insert. WL) S 2. 1 . . . Accept. WI /st!(activity 1) S 2. n E 2[C 2] /st!(activity 2) . . . 35

Event Process Chains (EPCs) for Business Process Modeling condition event actor (role) action popular in BPR tools used in SAP Workflow input data function output data © Gerhard Weikum 36

Event Process Chains: Control Flow Constructs function condition 1 event 1 condition 2 event 1 . . . branching event 2 . . © Gerhard Weikum function (forkjoin) split 37

Start Event Process Chains: Simple Example DE DE_OK Amount < 1000 Amount 1000 CCW RSK CCW_OK RSK_OK DEC © Gerhard Weikum DE: Data Entry CCW: Check Credit Worthiness RSK: Risk Assessment DEC: Decision 38

Import from BPR Tools Event process chains (EPCs à la Aris Toolset): © Gerhard Weikum - process decomposed into functions - completed functions raise events that trigger further functions - control-flow connectors 39

Import from BPR Tools (continued) © Gerhard Weikum 40

Automatic Conversion EPC SC © Gerhard Weikum Event process chains can (often) be automatically converted into statecharts 41

Automatic Conversion EPC SC © Gerhard Weikum 42

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration What Is It All About? WF Specification Techniques Statecharts • WF Execution Infrastructure • Failure Handling • Stochastic Modeling • WF System Configuration • Summary and • CTL and Model Checking • Summary and Open Research Issues © Gerhard Weikum Open Research Issues 43

Abstract Syntax of Statecharts (1) A B J C D E G F H K L M State set S State tree (with node types AND or XOR) Transition t: (source, target, [c]/a) Transition set T Variable set V © Gerhard Weikum 44

Abstract Syntax of Statecharts (2) A B C D © Gerhard Weikum XOR J AND F XOR E XOR G XOR H K L XOR M XOR XOR 45

Operational Semantics of Statecharts (1) Execution state of statechart (S, T, V): subset states S of currently active states s. t. • root of S is in states • if s in states and type of s is AND then all children of s are in states • if s in states and type of s is XOR then exactly one child of s is in states Execution context of statechart (S, T, V): current values of variables defined by val: V Dom Configuration of statechart (S, T, V): (states, val) Initial configuration © Gerhard Weikum 46

Operational Semantics of Statecharts (2) Evaluation of expression in configuration: eval (expr, conf) defined inductively Effect of action on context: modification of variable values in val fire(conf) = set of transitions t = (source, target, [cond]/action) with source(t) in states for which eval(cond, conf) = true © Gerhard Weikum 47

Operational Semantics of Statecharts (3) for transition t: • a = lca (source(t), target(t)) • src(t) = child of a in subtree of source(t) • tgt(t) = child of a in subtree of target(t) when t fires: • set of left states source*(t): • src(t) is in source*(t) • if s in source*(t) then all children of s are in source*(t) • set of entered states target*(t): • tgt(t) and target(t) are in target*(t) • if s in target*(t) and type of s is AND then all children of s are in target*(t) • if s in target*(t) and type of s is XOR then exactly one child of s with initial transition is in target*(t) © Gerhard Weikum 48

Operational Semantics of Statecharts (4) For a given configuration conf = (states, val) a successor configuration conf‘ = (states‘, val‘) is derived by selecting one transition t from fire(conf) with the effect: • states‘ = states – source*(t) target*(t) • val‘ captures the effect of action(t) and equals val otherwise The operational semantics of a statechart (S, V, T) is the set of all possible executions along configurations conf 0, conf 1, conf 2, . . . with • initial configuration conf 0 and • confi+1 being a successor configuration of confi © Gerhard Weikum 49

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration What Is It All About? WF Specification Techniques Statecharts CTL and Model Checking • WF Execution Infrastructure • Failure Handling • Stochastic Modeling • WF System Configuration • Summary and Open Research Issues © Gerhard Weikum Open Research Issues 50

Guaranteed Behavior and Outcome of Mission-critical Workflows Crucial for workflows in banking, medical applications, electronic commerce, etc. • Safety properties (invariants): nothing bad ever happens • Liveness properties (termination, fairness, etc. ): something good eventually happens Mathematical model Finite-state automaton Formalization of properties Temporal logic Verification method Model checking © Gerhard Weikum 51

Mapping Statecharts into FSAs Represent SC configurations as states of a finite state automaton: Step 1: abstract conditions on infinite-domain variables into Boolean variables formal mapping: 1: val B 1 B 2 . . . Bm Step 2: capture set of active SC states (along SC hierarchy and in components) by powerset automaton 2: states 2 S =: Z Step 3: encode SC context into extended state space of FSA by an injective mapping 3: Z B 1 B 2 . . . Bm Z’ such that there is a transition from z 1 to z 2 in the FSA iff 3 -1(z 2) is a possible successor configuration of 3 -1(z 1) in the SC © Gerhard Weikum 52

Example: From SC To FSA (1) / Budget: =1000; Trials: =1; Select Conf [Found] / Cost: =0 [!Found] Check. Conf. Fee Check Flight Select Tutorials Compute Fee Go [Cost Budget] Check Cost Check Airfare Check Hotel [Cost > Budget [Fok & Eok] & Trials 3] / Cost : = Conf. Fee + Travel. Expenses No Check. Travel Expenses [Cost > Budget & Trials < 3] / Trials++ © Gerhard Weikum 53

Example: From SC To FSA (2) 1 Select. Conf, !Fok, !Eok, !Bok, Tok 4 3 . . . Check. Conf. Fee, Check. Travel. Expenses, F, !Fok, !Eok, Bok, Tok Check. Cost, F, Fok, Eok, Bok, Tok 8 5 Go, F, Fok, Eok, Bok, Tok 6 9 Check. Cost, F, Fok, Eok, Bok, !Tok Check. Cost, F, Fok, Eok, !Bok, !Tok No, F, Fok, Eok, !Bok, !Tok 7 2 Check. Cost, F, Fok, Eok, !Bok, Tok No, !Fok, !Eok, !Bok, Tok © Gerhard Weikum 54

CTL: Computation Tree Logic propositional logic formulas quantifiers ranging over execution paths modal operators referring to future states all next: exists next: all globally: AX p EX p AG p all finally exists (inevitably): globally: AF p EG p exists finally (possibly): EF p combination: EF AG p © Gerhard Weikum 55

Critical Properties of the Example Workflow formalized in CTL (Computation Tree Logic) Can we ever exceed the budget ? not EF ( in(Go) and !Bok ) AG ( not in(Go) or Bok ) Do we always eventually reach a decision ? AF ( in(Go) or in(No) ) Can the trip still be approved after a proposal that would have exceeded the budget ? EF ( (in(Check. Cost) and !Bok) => ( EF (in(Go)) ) ) © Gerhard Weikum 56

CTL Syntax Definition: An atomic CTL formula is a propositional logic formula over elementary propositions (i. e. , Boolean variables). The set of CTL formulas is defined inductively: • Every atomic CTL formula is a formula. . • If P and Q are formulas then EX (P), AX (P), EG (P), AG (P), EF (P), AF (P), P, P Q, P Q and P Q are formulas. . © Gerhard Weikum 57

CTL Semantics (1) Definition: Consider a set P of elementary propositions. A Kripke structure M over P is a 4 -tuple (S, s 0, R, L) with • a finite state set S, • an initial state s 0 S, • a transition relation R S S, • a function L: S 2 P that assigns true propositions to each state. © Gerhard Weikum 58

CTL Semantics (2) Definition: The interpretation of formula F over elementary propositions P is a mapping onto a Kripke structure M=(S, s 0, R, L) over propositions P such that the truth value of subformulas p, p 1, p 2 of F in state s, denoted M, s |= p, is defined as follows: (i) M, s |= p with propositional formula p holds iff p L(s); (ii) M, s |= p holds iff M, s |= p does not hold; (iii) M, s |= p 1 p 2 iff M, s |= p 1 and M, s |= p 2; (iv) M, s |= p 1 p 2 iff M, s |= p 1 or M, s |= p 2; (v) M, s |= EX p iff there exists t S with (s, t) R and M, t |= p; (vi) M, s |= AX p iff for all t S with (s, t) R M, t |= p holds; (vii) M, s |= EG p if there exists t 1, . . . , tk S with t 1=s, (ti, ti+1) R for all i and tk=tj for some j: 1 j<k or tk has no successors, such that M, ti |= p for all i; (viii) M, s |= AG p iff for all t S with (s, t) R+ M, t |= p holds; (ix) M, s |= EF p iff there exists t S with (s, t) R+ and M, t |= p; (x) M, s |= AF p iff for all t S with (s, t) R+ there exists t’ S with a) (t, t’) R+ or b) (s, t’) R+ and (t’, t) R+, such that M, t’ |= p holds. © Gerhard Weikum 59

CTL Semantics (3) Definition: A Kripke structure M = (S, s 0, R, L) is a model of formula F if F is true in s 0, denoted M, s 0 |= F. A formula is satisfiable if it has at least one model, otherwise it is unsatisfiable. A formula is valid (or called a tautology) if every Kripke structure over the elementary propositions of F is a model of F. © Gerhard Weikum 60

Model Checking For CTL formula F and transition system (Kripke structure) M check if M is a model of F by inductively marking all states of M in which subformula q of F holds with the label q. Let q be a subformula of F, let p, p 1, p 2 direct subformulas of q, and let P, P 1, P 2 be the sets of states of M with labels p, p 1, p 2, resp. (i) q is an elementary proposition (Boolean variable): (ii) label all states s with q L(s) with label q (ii) q is of the form p: label S – P with label q (iii) q is of the form p 1 p 2: label P 1 P 2 with label q (iv) q is of the form p 1 p 2: label P 1 P 2 with label q (v) q is of the form EX p: label all predecessors of P with label q (i. e. , all s S for which there exists x P with R(s, x) ) (vi) q is of the form AX p: label s with q if all successors of s are labeled with p © Gerhard Weikum 61

Model Checking: EF Case (vii) q has the form EF p: solve recursion EF p p EX (EF p). (fixpoint computation Q = P pred(Q) ) Q : = P; Qnew : = Q pred(Q); while not (Q = Qnew) do Q : = Qnew; Qnew : = Q pred(Q); od; © Gerhard Weikum 62

Model Checking: EG Case (viii) q has the form EG p: solve recursion EG p p EX (EG p) : Q : = P; Qnew : = Q ; repeat for each s in Q do if s has successors and no successor of s is in Q then Qnew : = Q - {s}; fi; od; until (Q = Qnew); © Gerhard Weikum 63

Model Checking: AG Case (ix) q has the form AG p: solve recursion AG p p AX (AG p) Q : = P; repeat Qnew : = Q; for each s in Q do if s has successors and one successor of s is not in Q then Q : = Q - {s} fi; od; until (Q = Qnew); Alternatively, because of AG p EF ( p): compute state set Q’ labeled EF ( p) and label S – Q’ with label q. © Gerhard Weikum 64

Model Checking: AF Case (x) q has the form AF p: solve recursion AF p p AX (AF p) Q : = P; repeat Qnew : = Q; for each s in pred(Q) do if all successors of s are in Q then Q : = Q {s}; fi; od; until (Q = Qnew); Alternatively, because of AF p EG ( p): compute state set Q’ labeled EG ( p) and label S – Q’ with label q. © Gerhard Weikum 65

Model Checking: Example 1 AG ( not in(Go) or Bok ) 1 Select. Conf, !Fok, !Eok, !Bok, Tok 3 . . . Check. Conf. Fee, Check. Travel. Expenses, F, !Fok, !Eok, Bok, Tok 2 No, !Fok, !Eok, !Bok, Tok Label with Bok : with in(Go) : with ( Bok in(Go)) : with AG ( Bok in(Go)) : © Gerhard Weikum 4 Check. Cost, F, Fok, Eok, Bok, Tok 5 Check. Cost, F, Fok, Eok, Bok, !Tok 6 Check. Cost, F, Fok, Eok, !Bok, !Tok 7 Check. Cost, F, Fok, Eok, !Bok, Tok 8 Go, F, Fok, Eok, Bok, Tok 9 No, F, Fok, Eok, !Bok, !Tok 3, 4, 5, 8 8 1, 2, 3, 4, 5, 6, 7, 9 1, 2, 3, 4, 5, 6, 7, 8, 9 66

Model Checking: Example 2 AF (in(Go) in(No)) 1 Select. Conf, !Fok, !Eok, !Bok, Tok 3 . . . Check. Conf. Fee, Check. Travel. Expenses, F, !Fok, !Eok, Bok, Tok 2 No, !Fok, !Eok, !Bok, Tok Label with in(Go) : with in(No) : with in(Go) in(No) : with AF (in(Go) in(No)) : © Gerhard Weikum 4 Check. Cost, F, Fok, Eok, Bok, Tok 5 Check. Cost, F, Fok, Eok, Bok, !Tok 6 Check. Cost, F, Fok, Eok, !Bok, !Tok 7 Check. Cost, F, Fok, Eok, !Bok, Tok 8 Go, F, Fok, Eok, Bok, Tok 9 No, F, Fok, Eok, !Bok, !Tok 8 2, 9 2, 8, 9 2, 4, 5, 6, 8, 9 67

Model Checking: Example 3 EF ( (in(Check. Cost) and !Bok) => ( EF (in(Go)) ) ) 1 Select. Conf, !Fok, !Eok, !Bok, Tok 3 . . . Check. Conf. Fee, Check. Travel. Expenses, F, !Fok, !Eok, Bok, Tok 2 No, !Fok, !Eok, !Bok, Tok 4 Check. Cost, F, Fok, Eok, Bok, Tok 5 Check. Cost, F, Fok, Eok, Bok, !Tok 6 Check. Cost, F, Fok, Eok, !Bok, !Tok 7 Check. Cost, F, Fok, Eok, !Bok, Tok Label with in(Go) : with EF (in(Go)) : with not in(Check. Cost) or Bok : with (in(Check. Cost) and !Bok) => ( EF (in(Go)) : with EF ( (in(Check. Cost) and !Bok) => ( EF (in(Go)) ) ) : © Gerhard Weikum 8 Go, F, Fok, Eok, Bok, Tok 9 No, F, Fok, Eok, !Bok, !Tok 8 1, 3, 4, 5, 7, 8 1, 2, 3, 4, 5, 7, 8 68

Guaranteed Behavior of Workflows Leverage computer-aided verification techniques for finite-state concurrent systems Efficiency gain with encoding of FSM as OBDD Further requirements: - User-friendly macros for CTL - More expressive logic - Adding assertions on behavior of invoked apps - Adding real-time (clock variables) Preserving guaranteed behavior in distributed, failure-prone system environment System guarantees © Gerhard Weikum 69

Outline Part A: WF Specification and Verification Part B: WF System Architecture and Configuration What Is It All About? WF Specification Techniques Statecharts CTL and Model Checking Summary and • WF Execution Infrastructure • Failure Handling • Stochastic Modeling • WF System Configuration • Summary and Open Research Issues © Gerhard Weikum Open Research Issues 70

Summary and Open Research Issues Formal specification and verification methods are crucial if we want to have high confidence in the correctness of workflow models Statecharts and model checking are a good example Interesting research topics for graduate students: Formal semantics of XML-based workflow spec languages and automatic translation between languages Comprehensive, user-friendly workflow verification workbench Extended model checking or combinations with theorem proving & constraint solving for enhanced verification • • Comprehensive framework for correctness-preserving run-time modifications of workflow specifications © Gerhard Weikum 71