∀workflow instance wi, ti1, ti2∈Iwi, and (wi.w, Tmet)∈MET, If ti1.tk, ti2.tk∈Tmet, ti1.eu ≠ ti2.eu.
In a delegation, SOD also holds. For a task instance ti which is being delegated, a user executing a task instance mutually-exclusive to ti can not be the delegatee of ti. Taking a set of candidate delegatees and a task instance as the input parameters, Algorithm 3 eliminates the users violating instance SOD from the candidate delegatees.
Algorithm 3 Removing Users Involved in Mutually-Exclusive Tasks - RUMET Input: the candidate user set CUS, and
the target task instance ti Pre-Condition: CUS⊆U User Set RUMET { 01: ∀ i∈Iti.wi\{ti} {
02: if ( ∃met∈MET, met.w == ti.wi.w, i.tk, ti.tk∈Tmet ) 03: remove i.eu from CUS;
04: }
05: return CUS;
}
To show the correctness of Algorithm 3, we prove that the following lemma holds.
Lemma 6
Algorithm 3 follows the SOD constraints defined in Definition 19.
Proof:
By way of contradiction (B.W.O.C), we assume that a user u∈RUMET(CUS, ti) is now executing ti’ which is mutually-exclusive to ti. Let a workflow instance wi1 contains ti’ and ti.
With the assumption, ti’.tk and ti.tk are mutually-exclusive to each other, and ti’.eu = u. Since ti.wi = wi1 and ti’∈Iti.wi, ti’ is selected at line 1. On the other hand, by definition 11, there exists met∈MET that met.w = ti.wi.rws = ti’.wi.rws = wi1.rws and ti’.tk, ti.tk∈Tmet. Therefore, the expression at line 2 is true for ti’ and ti’.eu is removed from the result set at line 3. Thus, u is not included in the result set and the assumption is contradicted. Algorithm 3 follows SOD constraints defined in Definition 19. □
Intuitively, an unavailable user can not be the delegatee of any delegation, and a task instance should not be delegated to the user currently executing it. Concluding these two issues and the algorithms described in this section, the algorithm removing inappropriate users from a set of candidate delegatees is constructed as follows.
Algorithm 4 Removing Inappropriate Users - RIU Input: the candidate delegatee set CDS, and
the delegating task instance dti
Algorithm 4 first removes the unavailable users from the input set at line 2. At line 3, the algorithm invokes Algorithm 2 and Algorithm 3 to remove the users causing delegation loop or violating SOD. After removing the current executing user of dti, Algorithm 4 returns the result set at line 4.
3.3.3 Delegation from System Request
When a suspended task instance is nearly timed out, the system might need to spontaneously request a delegation for the task instance. We assume that a suspended task instance is emergent, and need to be delegated automatically if the proportion of its remaining active interval is less than an enterprise policy named the Emergent Execution Ratio (EER), a real number ranged from 0 to 1. To automatically delegate the emergent task instance, WfMS needs first decide an appropriate delegatee.
The role hierarchy indicates the organization lines of authority and responsibility [15], and can be used for exploration of possible candidate delegatees. Along with the role hierarchy, a task instance can be delegated upward or downward. When a task instance of daily works is being delegated, the system gathers the users playing lower roles related to the offered role of the instance as candidate delegatees. On the other hand, for the instances of the tasks related to decision making, the system commits an upward discovery from the offered role in the role hierarchy for the candidate delegatees. Besides, the users playing roles closer to the offered role in the role hierarchies are considered as better candidates in delegatee decision. Based on Definition 15, the algorithm discovering the role hierarchy for the candidate delegatees is constructed as follows.
Algorithm 5 Discovering the Role Hierarchy - DRH Input: the delegating task instance dti
Candidate Delegatee Set DRH { 01: if( dti.tk.type == Approval ) p = 1;
02: else if( dti.tk.type == Workflow ) p = -1;
03: m = 0;
04: US = Ø;
05: loop { 06: GR = Ø;
07: ∀r∈R, DisRH(dti.ar, r) == p*m 08: add r to GR;
09: if ( GR == Ø ) return Ø;
10: ∀r∈GR, r.etd⊇TD{dti.ai}
11: US = US∪Ur; 12: US = RIU ( US, dti );
13: if ( US == Ø ) m = m + 1;
14: else break;
15: }
16: return US;
}
At line 1 and 2, according to the class of the dti’s task, the algorithm decides the direction to explore the role hierarchy. Algorithm 5 commits an upward discovery for the tasks typed
“Approval” or a downward discovery for the tasks typed “Workflow”. From line 5 to 14, the algorithm does a breadth first search in the role hierarchy. At line 9, empty GR set represents that all roles connected to the offered role along with the designated direction in the role hierarchy are explored, and no proper delegatee is found. Therefore, Algorithm 5 returns Ø as the result. If GR is not empty, the users playing roles in GR is gathered into user set US and filtered with Algorithm 4. If US set is not empty after the removal of conflict users, the algorithm returns US as the result set. Otherwise, the discovery continues with further distances.
With Algorithm 5, the algorithm for delegation requested by the system is described as Algorithm 6. WfMS tracks the status of the executing task instances, and invokes algorithm 6 whenever an emergent task instance is found. Algorithm 6 acquires the candidate delegatees by exploring the role hierarchy with Algorithm 5 at line 2. Exception is raised if Algorithm 5 returns no candidates. Otherwise, Algorithm 6 randomly chooses a delegatee from the candidate delegatees and invokes Algorithm 1 to delegate the emergent task instance.
Algorithm 6 Delegation from System Request - DSR Input: the delegating task instance dti
Pre-Condition: dti.s = Suspended, E(dti.ai) > ctime
( E(dti.ai) - ctime ) / (E(dti.ai) - S(dti.ai) ) < EER DSR {
01: CDS = DRH(dti);
02: if( CDS == Ø ) EXCEPTION( NO_PROPER_DELEGATEE );
03: else {
04: randomly choose a user u from CDS;
05: DA( dti, u, [ctime, E(dti.ai)] );
06: } }
3.3.4 Delegation from User Request
Many modern enterprises adopt user-authorized delegation as the primary delegation methodology. The RBAC-based studies like [20], [22], [18], and [23], also describes how roles and permissions are delegated under user authorization.
With our framework, a user can authorize two types of delegation. First, a user may delegate task instances currently allocated to him. Second, a user may delegate the task instances going to be allocated to him during a specific period.
To request a delegation, the delegator fills in an authorization form which designates the delegating subject, the delegatee and the activation duration of the delegation. For the first type of delegation, the delegator designates a task instance residing in his work list as the delegating subject. The duration to authorize the delegation must be contained by the active interval of the delegating task instance. For the second type of delegation, the delegator designates an executable task by any of the roles he playing as the delegating subject. The duration to authorize the delegation must be contained by the effective duration of the role.
Figure 11 The Process for Delegation from User Request
After accomplishing the authorization form, the delegator user submits the form to request the approval from his supervisor and the designated delegatee. If the delegation is approved, for the first type of delegation, the designated task instance is delegated to the delegatee user with algorithm 1 immediately. For the second type of delegation, the approved form is put into Forthcoming Delegation Table (FDT). According to the form, the task instances of the designated task which is allocated to the delegator in the specified duration are delegated to the designated delegatee. Figure 11 represents the process of delegation from user request, the authorization form is defined in Definition 20, FDT is defined in Definition 21, and finally, Algorithm 7 shows how WfMS handles the second type of delegation.