Decentralized Workflow Control and Conflict of Interest Vijay Atluri Soon Ae Chun Pietro Mazzoleni

Our Contributions Decentralized WF Control Contribution Part I: Decentralized WF Control Model Join Relations SELF describing Workflow, WFMS Stub WF partition, dependency splitting, dependency evaluation Contribution Part II: Conflict of Interest problem in Decentralized control COI model for decentralized WF Restrictive partition Secure WFMS stub

Centralized Workflow Management gateway Enter Input spec XEROX buy computer bs buy printer Bf or p>$400 IT Agent bs bs IT Agent Bs and Date <3/21/01 Bs and p<=$400 buy printer external CD writer buy computer bs Notify DELL HP PANASONIC DELL GEATWAY HP XEROX PANASONIC Performance bottleneck do not scale well not suitable if systems are inherently autonomous and distributed

Decentralized Workflow Management IT agent Gateway XEROX 1 Enter Input Date/destination 5 3 Reserve airline Rent A car bs bf or p>$400 bs bs 7 4 Bs and Date <3/21/01 Reserve Airline 6 Rent a car bs Reserve a hotel 2 Bs and p<=$400 Notify DELL HP PANASONIC IT agent GATEWAY XEROX DELL 3 5 6 7 5 6 7 3 5 HP PANASONIC 2 7 4 6 4 6 7 6 7

Our Contribution Part 1: WF Model Join Relations Decentralized WF Control Model SELF describing Workflow, WF partition dependency splitting, dependency evaluation WFMS Stub

Workflow Model Task structure: Inter-task dependencies Workflow can be defined as a pair (G, J) where G=(T,D) is a directed graph with T as a node set for tasks t1, t2, ..tn in the workflow and D as an edge set with dependencies, ti tj and J is a set of join relations among dependencies, j1,j2..jp in ab ex cm b a c fl su e Task structure: -a set of visible execution states {initial, executing, done, aborted, success, failed} -a set of task primitives {begin, abort, finish, commit, evaluate} Inter-task dependencies -Control-flow (state) dependencies -Value dependencies -External dependencies <head, d, tail, pr> e.g. <ti, c, tj, begin> Join Relations <head, d, head, pr> e.g. <ti, de, ti, begin> Begin on commit dependency (ti c tj) abort dependency (ti a tj) ti can begin only if tj's output is x ti can begin only at 9:00am or after 24hrs after the completion of tj

Join Relations AND/OR split AND Join bs bs flight<$200 reserve hotel bs flight<$200 Reserve Hilton reserve flight reserve flight bs rent a car Country Hill AND Join flight>=$200 Reserve Hotel Reserve Flight Book the trip AND (Hilton.price + Country.price < $400 Hotel Hilton Country Hill Book the hotel (Hiton.double>= 3 OR Country.double>=3) AND (Hiton.single>= 4 OR Country.single>=4) AND

Dependency/Preconditions Dependency expressions in d in ti tj are Pre(tj) Pre_begin(tj): < t1, commit ^ price >$200, tj, begin> Pre_commit(tj): < t1, success ^ price >$200, tj, commit> Pre_abort(tj): < t1, abort, tj, abort> d buy HDisk buy CPU bc ^ price>$200 Pre_begin(tj) = (ti.state = commit ^ t1.price>$200) bs t1 t3 (t1.price + t2.price >$200) t2 bs Pre_begin(t3) = (ti.state = s ^ t2.state=s ^ t1.price+t2.price>$200)

Our Approach to Decentralized Workflow Management Self-describing Workflow Workflow Stub WFMS server (A0) t2 bs t1 t4 self describing workflow WFMS stub bs t3 bf (t1, A1, Input (t1), t2 bs t1 t4 bs t3 bs WFMS Stub WFMS Stub (t2, A2, Input (t2), A2 (t2) t2 WFMS Stub A1 (t1) A4 (t4) (t3, A3, Input (t3), (t4, A4, Input (t4), WFMS Stub t4 t4 t3 bs A3 (t3)

Decentralized Workflow Control Model Self Describing Workflow: Workflow Partition with instance information <ti, PRE(ti), OutState(ti), Pi> ti = task, agent A(ti), activities, input, output PRE(ti)= preconditions for ti’s transition operation OutState = control,value, external dependency state for ti from previous task tj (tj ti) Pi= workflow partition where ti is the initial task

WFMS Stub Receives the self-describing workflow, extract task Partition remaining workflow Evaluate precondition Execute task Split dependency into immediate and deferred preconditions Evaluate immediate precondition adjust OUTSTATE (with signals) Construct self-describing workflow for each partition forwards each self-describing wf to the subsequent task agents

WFMS Stub: Case 1 tj can start in parallel with ti (ti tj) c c xxx audio card speakers xxx 1. A(ti) does not evaluate dependency(tj) 2. Partition Pj and forward SELF(Pj) to A(tj) 3. Execute ti 4. Evaluate dependency 5. Send OutState(ti) with signals to A(tj)

Workflow Partition for A(ti) Given Pi, For each tj which has outgoing edge from ti Pj = a connected path from j P1 2 4 5 1 3 P2 : 2 P3: 3 4 5 SELF(P2) =<t2, A(t2), Pre(t2), OutState(t1)>

WFMS Stub: Case 2 ti have to evaluate PRE(tj) (dependency) before sending SELF(Pj) bs bs audio card speakers xxx Pj 1. if Pre_begin(ti)=true, Execute ti 2. Partition Pj 3. Precondition Splitting =PRE(tj) 4. Evaluate immediate dependency 5. if PRE_begin(tj)=true forward SELF(Pj) to A(tj) else NO forward SELF(Pj)

Dependency/Precondition Splitting bs t1 t3 (t1.price + t2.price >$200) t2 bs Pre_begin(t3) = (ti.state = s ^ t2.state=s ^ t1.price+t2.price>$200) (Hiton.double>= 3 OR Country.double>=3) AND (Hiton.single>= 4 OR Country.single>=4) (CPU.price +HD.price < $400 Immediate v. Deferred Preconditions AND OR OR t1.double>= 3 t2.double>= 3 t1.single>= 4 t2.single>= 4

Dependency/Precondition Splitting 1. Immediate Evaluation only: Pre(tj) =( ti.state=s) 2. Deferred Evaluation only: PRE(t3) = t1.price+t2.price>$200 3. Split: partial evaluation at ti, rest in tj PRE(t3) = (ti.state = s ^ t2.state=s ^ t1.price+t2.price>$200) PRE(t3) =(Hiton.double>= 3 OR Country.double>=3) AND (Hiton.single>= 4 OR Country.single>=4) Why splitting and immediate evaluation? 1. WF control semantics mandates it. (Control flow) 2. Evaluate only if needed (one OR operand can be skipped) 3. Reduce amount of information (evaluated truth value v. expressions) among task agencies 4. Reveal only need-to-know information

Dependency/Precondition Splitting AND OR OR t1.double>= 3 t2.double>= 3 t1.single>= 4 t2.single>= 4 X R R X Immediate Precondition (t1): ( t1.double >= 3 OR X ) AND (t1.single>=4 OR X) Deferred Precondition(t1) (t1.singal1 OR t2.double>=3) AND (t1.signal2 OR t2.single>=4) Immediate Precondition (t2): ( X OR t2.double ) AND (X OR t2.single>=4) Deferred Precondition(t2) (t1.double OR t2.signal1) AND (t1.single>=4 OR t2.signal2)

Dependency/Precondition Evaluation Immediate evaluation at t1 AND OR OR t1.double>= 3 X t1.single>= 4 X OutState(t1) ={ t1.signal1=F, t1.signal2=F} U OutState(t1) Deferred Evaluation at t3 (t1.singal1 OR t2.double>=3) AND (t1.signal2 OR t2.single>=4) Wait results from t2, and evaluate the whole deferred expression

WFMS Stub: Case 3 ti have to wait for a PRE_commit(ti) to complete execution c audio card speakers xxx Pj 1. Partition Pj 2. Precondition Splitting =PRE(tj) 3. execute ti until done 4. Wait until Deferred_PRE= true 5. If no error, commit(ti) 6. Evaluate Immediate dependency 7. forward SELF(Pj) to A(tj)

Our approach to Decentralized Control (So far and future) WF Model Join Relations Decentralized WF Control Model SELF describing Workflow, WF partition dependency splitting (immediate v. deferred) dependency evaluation (signal OutStates) WFMS Stub Need to address Dynamic changes/dynamic customizations handle failure, recovery, compensation

Our Contribution Part 2: Conflict of Interest problem in Decentralized control COI model for decentralized WF Restrictive partition Secure WFMS stub

Conflict of Interest Problem Execution agents are in conflict of interest one agent can manipulate control or value dependencies in Workflow for its advantage e.g. price is lowered to $400 at DELL ==> disadvantage against GATEWAY and consumer Simple partition algorithm wouldn’t do gateway Enter Input spec XEROX buy computer bs buy printer Bf or p>$400 IT Agent bs bs IT Agent Bs and Date <3/21/01 Bs and p<=$400 buy printer external CD writer buy computer bs Notify DELL HP PANASONIC

No Conflict of Interest problem in Centralized Control gateway Enter Input spec XEROX buy computer bs buy printer Bf or p>$400 IT Agent bs bs IT Agent Bs and Date <3/21/01 Bs and p<=$400 buy printer external CD writer buy computer bs Notify DELL HP PANASONIC DELL GEATWAY HP XEROX PANASONIC No Conflict of Interest problem arises in centralized Management The control/value dependencies or destination of its output is unknown to a particular A(ti)

Chinese Wall Policy Objective: prevent information flows that cause conflict of interest for individual consultants Brewer and Nash Model Read Rule Discretionary access Mandatory access denial r X consultant Bank B Bank A r Insurance Oil B

X Chinese wall policy Read Rule: S can read O only if O is within the wall or O is outside the wall Write Rule: S can write O only if S can read O by BN Read rule no object can be read which is in the different company set to the one for which write access is requested w Bank A Oil A Consultant A r X r Oil B Consultant B w

Conflict of Interest Task Agents COI group1 COI group2 COI group n Continental Delta Holiday Inn Marriot Avis Hertz

Chinese Wall Security Model for Decentralized Workflow Object: sensitive v. non-sensitive object sensitive: dependency, Outstate that changes execution flow ( e.g. sensitive(d1) = price) Non-sensitive: output(ti) gateway Enter Input spec XEROX buy computer bs buy printer Bf or p>$400 IT Agent bs bs IT Agent Bs and Date <3/21/01 Bs and p<=$400 buy printer external CD writer buy computer bs Notify DELL HP PANASONIC Subject: task execution agent, S COI(S) = conflict of interest class S belongs to COI(DELL) = GATEWAY, COMPAQ, ... O  S ==> O  COI(S)

Chinese Wall Security Model for Decentralized Workflow Read/Evaluate Rule: S can read dependency O if O  S or O COI(S) Subject can read and evaluate dependency object of its own company, or any dependency that does not belong to the same COI class as S’s company e.g. (bf OR p>$400) belongs to both DELL and GATEWAY. BOTH can’t read this object, hence can’t evaluate it Write/Partition Rule S can write if S can read Subject is not allowed to construct SELF with sensitive objects that belongs to the same COI class e.g. DELL can’t construct SELF WF for GATEWAY.

Our Approach: Restrictive Partition partition Pj does not contain any sensitive object O  COI (A(tj)) 3 5 TA2 2 SAME COI 4 6 7 4 6 7 TA 4 3 5 TA 3

Critical Partition: non-adjacent tasks SAME COI 3 5 Critical Partition 2 4 6 7 Bf or price > $400 4 6 7 TA 4 TA 3 3 5 TA4 4 6 TA6 6 signal 7 Bf or price > $400

Critical Partition -adjacent tasks 3 5 2 SAME COI 4 6 7 Critical Partition 4 6 7 TA 4 TA 3 3 5 2 3 5 2 Bf or price > $400

Secure WFMS Stub at A(ti) Given SELF(ti) extract ti Pj = Restrictive Partition of Pi Restrictive dependency splitting Construct SELF(Pj) CASE 1: tj can be parallel with ti, forward SELF(Pj) Evaluate DEFERRED_PRE(begin), execute ti Evaluate IMMEDIATE_PRE(ti), send DEFERRED_PRE(commit) CASE 2: Evaluate DEFERRED_PRE(begin), execute ti send SELF(Pj) CASE 3: ( ti was in parallel with previous task) execute ti until done wait until signal is received if (DEFERRED-PRE(commit)=true) then finish up ti

Working on AND join -- sensitive dependency splitting 3 5 6 7 1 2 4

Related Work Cryptography: Onion Ring: Mobile code security, distributed computing A message for each execution agent is encrypted with the agent’s key Assumes static execution path => can’t work workflow: dynamic execution state and results into account P m1 m2 m3 host1 host1 host1 Key(A) Key(B) Key(C) Encrypted control information and destination: wouldn’t be able to evaulate control info or destination

Related work: Static distribution of control flow EXOTICA/Flowmark (Mohan & Alonso 1995): decomposition of workflow is done centrally distributed partitions in designated hosts statically h1 h2 h3 For different workflow or different partitioning of workflow, need to configure the hosts differently Do not address COI problem

METEOR2(ORBWork, WEBWork): (Sheth et al: 1997) Related Work METEOR2(ORBWork, WEBWork): (Sheth et al: 1997) Workflow code generator reads workflow specification and creates task manager routines which contain the scheduling logic Each task manager is aware of its immediate successors and capable of activating the follow-up task managers once the task it controls terminates Designer Automatic code generation TM TM TM task task task TM task Task Manager code can be cracked for control and value dependency Do not address COI problem

Architecture Composition Generation Agency 1 Task Execution Agent Workflow Interface Customized Worflow generator WFMS Stub Form & Service Agency 1 Task Execution Agent Interoperability WFMS Stub Local DB Agency N Composition Generation

Architecture Agency 1 Task Execution Agent Local DB Interoperability Workflow Interface Customized Worflow generator WFMS Stub Form & Service Agency 1 Task Execution Agent Interoperability WFMS Stub Local DB Agency N

References Brewer & Nash1989 Sandu1992 Alonso, Mohan & et al. 1995 Sheth et al. ORBWORK, 1997 A. Myers: Jflow: Practical mostly-static information flow control, 1999