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
QoS 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
Contact
referee 1
Send
paper
Contact
referee 2
...
Contact
referee 3
Receive
submitted
paper
© Gerhard Weikum
...
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
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
• MQSeries Workflow /
• Wide and CrossFlow
•
•
•
•
•
•
WebSphere (IBM)
BizTalk (MS)
Staffware
Changeengine / E-Speak (HP)
jFlow / WebLogic (BEA)
InConcert (Tibco)
SAP Workflow
•
•
•
•
•
•
(EU projects)
Adept (U Ulm)
Wasa (U Muenster))
Opera (ETH Zurich)
Mentor-lite (U Saarland)
CMI (MCC)
Meteor (U Georgia)
+ workflow technology embedded
in E-Commerce products
and ERP systems
© Gerhard Weikum
15
WfMC 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
(ebXML, ...)
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
<flowModel name="totalSupplyFlow"
<serviceProviderType="totalSupply"
>
<serviceProvider
name="buyer" type="buyer" />
...
<activity name="submitPO">
...
</activity>
<controlLink source="submitPO"
target="processPO"/>
<controlLink source="processPO"
target="processPayment"/>
...
<dataLink source="submitPO"
target="processPO">
<map
sourceMessage="purchaseOrder"
targetMessage="purchaseOrder"/>
</dataLink>
...
graphs ...
...and scripts
imprecise or ad hoc semantics
© Gerhard Weikum
20
Specification Methods
Requirements:
•
•
Visualization
Refinement &
Composability
Solutions:
Statecharts (Harel et al. 1987)
(alt.: Petri Net variants,
temporal logic, process algebra,
script language)
•
•
Rigorous Semantics
Interoperability with
other methods & tools
Import / export
BPR tools  WFMS  WFMS
•
Wide acceptance &
standard compliance
Statecharts included in
UML industry standard
(Unified Modeling Language,
OMG 1997))
© Gerhard Weikum
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
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
CheckConfFee
Check
Flight
Select
Tutorials Compute
Fee
[Found]
/ Cost:=0
[!Found]
Go
[Cost  Budget]
Check
Cost
Check
Airfare
Check
Hotel
Check
Hotel
[Cost > Budget
[Fok & Eok] & Trials  3]
/ Cost :=
ConfFee +
TravelExpenses
No
CheckTravel
Expenses
[Cost > Budget &
Trials < 3] / Trials++
© Gerhard Weikum
27
E-Commerce Workflow: Activitychart
ECommerce_AC
Name, Date, CreditCardNumber, ...
CreditCardCheck
NewOrder
CreditCardNumber, Amount, ...
CreditCardCharge
Notify
OrderNumber, EmailAddress., ...
Name, Address,
OrderNumber, ...
OrderNumber,
ItemList, ...
Payment
@ECommerce_SC
© Gerhard Weikum
FindStore
Acknowledgement
OrderNumber, Address, ...
StoreID,
ItemList, ...
CheckStore
28
E-Commerce Workflow: Statechart
ECommerce_SC
INIT_S
[CreditCardNotOK and
CreditCardCheck_DONE]
[PayByCreditCard and
NewOrder_S
[PayByBill and
NewOrder_DONE]
CreditCardCheck_S
NewOrder_DONE]
[CreditCardOK and
CreditCardCheck_DONE]
Shipment_S
[Notify_DONE]
Notify_INIT_S
Delivery_INIT_S
FindStore_S
[AllItemsProcessed]
Notify_S
Notify_EXIT_S
[ItemAvailable and
CheckStore_DONE]
[ItemsLeft and
FindStore_DONE]
/fs!(ItemAvailable)
CheckStore_S
Delivery_EXIT_S
[in(Notify_EXIT_S) and
in(Delivery_EXIT_S) and
PayByBill]
Payment_S
[Payment_DONE]
© Gerhard Weikum
[in(Notify_EXIT_S) and
in(Delivery_EXIT_S) and
PayByCreditCard]
CreditCardCharge_S
[CreditCardCharge_DONE]
EC_EXIT_S
29
Workflow Administration
From Organizational Viewpoint
• Worklist Management:
Who is assigned which pieces of work?
• Work History Management and Evaluation:
Which processes are late?
Which process types have inherent bottlenecks?
How can we improve work effectivity?
© Gerhard Weikum
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
E1[C1]
/st!(activity1)
S1
E2[C2]
/st!(activity2)
S2
...
Work assignment strategy included as nested statechart
S2
E1[C1]
S1
© Gerhard Weikum
AcceptWI
/st!(activity1)
.../st!(insertWL)
S2.1
...
...
S2.n
E2[C2]
/st!(activity2)
...
35
Event Process Chains (EPCs)
for Business Process Modeling
condition
event
actor
(role)
popular in BPR tools
used in SAP Workflow
input
data
action
function
output
data
© Gerhard Weikum
36
Event Process Chains: Control Flow Constructs
function
condition 1

event 1

condition 2
event 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
L
F
G
K
H
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
E
XOR
© Gerhard Weikum
XOR
J
AND
F
XOR
D
XOR
XOR
G
K
L
XOR
M
XOR XOR XOR
H
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
conf0, conf1, conf2, ... with
• initial configuration conf0 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
• 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  B1  B2  ...  Bm
Step 2:
capture set of active SC states (along SC hierarchy and in components)
by powerset automaton 2: states  2S =: Z
Step 3:
encode SC context into extended state space of FSA
by an injective mapping 3: Z  B1  B2  ...  Bm  Z’
such that there is a transition from z1 to z2 in the FSA
iff 3-1(z2) is a possible successor configuration of 3-1(z1) in the SC
© Gerhard Weikum
52
Example: From SC To FSA (1)
/ Budget:=1000;
Trials:=1;
Select
Conf
CheckConfFee
Check
Flight
Select
Tutorials Compute
Fee
[Found]
/ Cost:=0
[!Found]
Go
[Cost  Budget]
Check
Cost
Check
Airfare
Check
Hotel
Check
Hotel
[Cost > Budget
[Fok & Eok] & Trials  3]
/ Cost :=
ConfFee +
TravelExpenses
No
CheckTravel
Expenses
[Cost > Budget &
Trials < 3] / Trials++
© Gerhard Weikum
53
Example: From SC To FSA (2)
4
1
SelectConf,
!F,!Fok,!Eok,
!Bok,Tok
3
...
CheckConfFee,
CheckTravelExpenses,
F,!Fok,!Eok,
Bok,Tok
CheckCost,
F,Fok,Eok,
Bok,Tok
8
5
Go,
F,Fok,Eok,
Bok,Tok
6
9
CheckCost,
F,Fok,Eok,
Bok,!Tok
CheckCost,
F,Fok,Eok,
!Bok,!Tok
No,
F,Fok,Eok,
!Bok,!Tok
7
2
CheckCost,
F,Fok,Eok,
!Bok,Tok
No,
!F,!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(CheckCost) 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, PQ, 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, s0, R, L) with
• a finite state set S,
• an initial state s0  S,
• a transition relation R  S  S,
• a function L: S  2P 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, s0, R, L) over propositions P
such that the truth value of subformulas p, p1, p2 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 |= p1  p2 iff M,s |= p1 and M,s |= p2;
(iv) M,s |= p1  p2 iff M,s |= p1 or M,s |= p2;
(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 t1, ..., tk S with t1=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, s0, R, L) is a model of formula F
if F is true in s0, denoted M,s0 |= 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, p1, p2 direct subformulas of q,
and let P, P1, P2 be the sets of states of M with labels p, p1, p2, resp.
(i) q is an elementary proposition (Boolean variable):
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 p1  p2: label P1  P2 with label q
(iv) q is of the form p1  p2: label P1  P2 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
SelectConf,
!F,!Fok,!Eok,
!Bok,Tok
3
...
CheckConfFee,
CheckTravelExpenses,
F,!Fok,!Eok,
Bok,Tok
4
CheckCost,
F,Fok,Eok,
Bok,Tok
5
CheckCost,
F,Fok,Eok,
Bok,!Tok
6
CheckCost,
F,Fok,Eok,
!Bok,!Tok
7
CheckCost,
F,Fok,Eok,
!Bok,Tok
8
Go,
F,Fok,Eok,
Bok,Tok
9
No,
F,Fok,Eok,
!Bok,!Tok
2
No,
!F,!Fok,!Eok,
!Bok,Tok
Label
with Bok :
with in(Go) :
with in(Go) :
with (Bok  in(Go)) :
with AG (Bok  in(Go)) :
© Gerhard Weikum
3, 4, 5, 8
8
1, 2, 3, 4, 5, 6, 7, 9
1, 2, 3, 4, 5, 6, 7, 8, 9
1, 2, 3, 4, 5, 6, 7, 8, 9
66
Model Checking: Example 2
AF (in(Go)  in(No))
1
SelectConf,
!F,!Fok,!Eok,
!Bok,Tok
3
...
CheckConfFee,
CheckTravelExpenses,
F,!Fok,!Eok,
Bok,Tok
4
CheckCost,
F,Fok,Eok,
Bok,Tok
5
CheckCost,
F,Fok,Eok,
Bok,!Tok
6
CheckCost,
F,Fok,Eok,
!Bok,!Tok
7
CheckCost,
F,Fok,Eok,
!Bok,Tok
8
Go,
F,Fok,Eok,
Bok,Tok
9
No,
F,Fok,Eok,
!Bok,!Tok
2
No,
!F,!Fok,!Eok,
!Bok,Tok
Label
with in(Go) :
with in(No) :
with in(Go)  in(No) :
with AF (in(Go)  in(No)) :
© Gerhard Weikum
8
2, 9
2, 8, 9
2, 4, 5, 6, 8, 9
67
Model Checking: Example 3
EF ( (in(CheckCost) and !Bok) => ( EF (in(Go)) ) )
1
SelectConf,
!F,!Fok,!Eok,
!Bok,Tok
3
...
CheckConfFee,
CheckTravelExpenses,
F,!Fok,!Eok,
Bok,Tok
4
CheckCost,
F,Fok,Eok,
Bok,Tok
5
CheckCost,
F,Fok,Eok,
Bok,!Tok
6
CheckCost,
F,Fok,Eok,
!Bok,!Tok
7
CheckCost,
F,Fok,Eok,
!Bok,Tok
8
Go,
F,Fok,Eok,
Bok,Tok
9
No,
F,Fok,Eok,
!Bok,!Tok
2
No,
!F,!Fok,!Eok,
!Bok,Tok
Label
with in(Go) :
with EF (in(Go)) :
with not in(CheckCost) or Bok :
with (in(CheckCost) and !Bok) => ( EF (in(Go)) :
with EF ( (in(CheckCost) and !Bok) => ( EF (in(Go)) ) ) :
© Gerhard Weikum
8
1, 3, 4, 5, 7, 8
1, 2, 3, 4, 5, 8
1, 2, 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