model pol icies. In add ition, I'RA defines interfaces for an execution engine and their use by a WF!VIS. A detailed d iscussion of the PRA components follows.
Organization Schema and Organization Structure
The PRA organization schema is a set of objects and relationships that can be freely defined, thus enabl ing users to model arbitrary organizations.
Each member of t he set can be instantiated to popu
l ate an organization schema, that is. to produce an organization structure. PRA al lows users to define constraints on the organization structur e to avoi d erroneous structures. For example, if an enterprise has the policy that an employee m ust not report to more than two people, PRA enables the user to define a constrai n t that specifies that one person can be related to only two others through a " reports to" relationship. If a modeler adds a third reporting I ine, the system detects the violated constraint.
Organizational Policy
An organizational policy specifies a set of el igible users for a given workflow, which can be either ele
mentary (a step) or composite. A set of users is not stable and therefore fixed but specified through an expression called an organizational expression. An organizational expression specifies tile selection of users with particular properties from an organiza
tion structure. For example, an expression might enumerate users, select all users able to play a par
ticular role, or select a user related to some other in a specific way. A d d i t ional ly, organizational expres
sions can refer to the history of a workflow or to its
:38
internal data, such as local variables, and thus be dependent on the workflow state. Consequently, the set of users for the same step in two different instances of the same workflow m ight be differ
ent. Consider, for example, the travel expense reim
bursement workflow, with the user selection for the sign step dependent on the authorization level . In two instances o f the workflow, the amou n ts to be reim b ursed m ight differ such that different peo
ple, e.g. , the manager ami the vice president, must execute the two sign steps.
To provide a general mechanism for determ ining a set of el igible users for a workflow, PRA organiza
tional pol icies accom modate operations in addi
tion to executi ng a step or taking responsibility for a composite workflow. Delegating a workflow and undoing a workflow are two examples. To delegate a workflow, an organizational pol icy has to ensure that both the person who delegates the workflow and the person to whom the workflow is assigned are el igible users. The operation of undoing a work
flow (i.e., to u ndo the resu lts achieved thus far) a nd starting aga i n can result in wasted effort and u nre
coverable work. Therefore, a WFMS must carefu l ly choose eligible users for this operation.
To deal with various workflow operations, a PRA organizational pol i cy relates a workflow t ype and one of its operations in a given tlomain tO an organi
zational expression. An organizational pol icy is defined as tl1e tuple <workflow type, operation, domain. organizational expression>. For example, the organizational pol icy for the fi l l step in the travel expense reimbursement example is
<TraveiExpenseReimbursement . F i l l , execute, USA , 'every user who plays the role of em ployee'>. Since an appl icant shou ld be able to undo the step and start again, the WFMS m ust also specify the organ i
zational pol icy <TraveiExpenseReimbursement.Fil l, undo, liSA, · the user who started fil l ' > . ( The next
section describes PRA's formal language for specify
ing organizational policies.)
When a WFMS determines that a workflow in a particular domain is to be executed, it cal ls the policy resolution engine, which looks for the appropriate organizational policy and evaluates its organizational expression. 'fhe engine returns the results of the evaluation, i . e . , the set of el igible users, to the WFMS, which subsequently assigns the workflow to those users. One organizational policy can be reused for several workflow types, domains, etc . , by entering a set in tlw appropriate element of the tuple. For example, if the organizational
Vol. 6 No. 4 Fall /')')4 Digital Technical journal
Policy Resolu tion in Workflow Management Systems
pol icy for the fi l l step of the travel expense reim
bursement workflow is the same in the U.S.
as it is i n Europe, the policy cou ld be modeled as
<TravelExpenseReimbursement.Fi l l , execute, {USA, EUROPE} , 'every user who plays the role of employee '>.
Policy Definition Language
From the organizational viewpoint, the fol lowing elements are necessary to run a workflow: an organi
zation schema together with its instantiation, the organizational policies for this workflow, and the rel
evant organizational expressions. To describe these elements in a formal way, PRA defines a language cal led the Policy Definition Language (PDL), which consists of several parts. The first part enables the definition of an organization schema and its popu la
tion. The second part is concerned with
organiza-ORGANIZATION_TYPE Role
ATTRIBUTES name : String
tiona! expressions. Final ly, the third part supports the definition of organizational policies.
The fol lowing figures illustrate the POL for a sam
ple organization schema and organization struc
ture, some organizational expressions, and some organizational pol icies for the travel expense reim
bu rsement workflow. Figure 5 shows the POL for the organization schema displayed in Figure 2a. The POL for the instantiation d isplayed i n Figure 2b appears i n Figure 6.
The organization schema definition part of the POL looks like a d ata definition language (DOL) in a relational database. Two differences exist, though:
(1) PDL d istinguishes organizational object types from organizational relationship types, and (2) POL al lows complex data types (e.g. , sets as attributes).
If a pol icy resolution engine is bu ilt on top of a rela
tional database, a compi ler or a translator within
authorization_level : set ( task, amount ) ; KEYS name;
ORGANIZATION_TYPE Group
ATTRIBUTES name : String KEYS name;
ORGANIZATION_TYPE User
ATTRIBUTES name : String
office_tel_# : String e_mail : String
absence : {vacation, i l l , busine s s , avai labl e}
KEYS name ;
RELATIONSHIP_TYPE Reports_to FROM User
TO User
ATTRIBUTES kind : { l ine , functional , none }
RELATIONSHIP_TYPE Plays FROM User TO Role
ATTRIBUTES duration_from: date duration_to : date
RELATIONSHIP_TYPE Responsible_for FROM User
TO Group
RELATIONSHIP_TYPE Belongs_to FROM User
TO Group
Note that , for simplicity, we assume user names to be unique . In reality, this is not the case and the modeling must deal with nonunique names .
Figure 5 Policy Definition Language for the Sample Organization Schema Shown in Figure 2a
Digital Technical journal Vol. 6 No. 4 Fall 1994 39
Workflow Models
...j()
Role "Employee" , { }
"Manager" , { ( TravelExpenseReimbursernent . Sign, 1 0 0 0 ) , ( Capi talEquipmentOrder. Sign, 5 0 0 0 ) }
"Financ ialClerk" , { }
"Secretary" , { }
"Engineer" , { }
"VP" , { ( TravelExpenseReimbursement . Sign, * ) , ( CapitalEquipmentOrder . Sign, * ) }
Group "Sales"
"Manufacturing"
"Engineering"
"Administration"
User "Al " , " [ 1 ) 1 2 5 - 5 5 8 9 " ,
"Nina" , " [ 1 ) 1 2 5 - 5 5 9 0 " ,
"Ken', , " ( 1] 1 2 5 - 5 6 0 1 " ,
"al@center . com" ,
"nina@center . com" ,
"ken@center . corn" ,
"Susan" , " [ 1 ) 1 2 5 - 5 6 0 9 " , "susan@center . com" ,
"Matt" , " ( 1 ] 1 2 5 - 4 4 9 9 " , "matt@center . com" ,
"Charles" , " [ l ] 1 2 5 - 4 5 8 0 " , "charles@center . com" ,
"Mike" , " [ 1 ) 1 2 5 - 0 1 0 1 " , "mike@center . com" ,
Repcrts_to "Al " , "Nina " , line
"Ken" , "Nina" , line
"Nina" , "Mike " , line
"Susan " , "Matt'' 1 line
"Charles " , "Matt" , line
"Mat t " , \\Mike " , line
"Mike " , none
Plays "Al " , "Employee" , 0 1 - 0 2 - 8 8 , 0 - 0 - 0 ( * open
"Al " , "FinancialClerk" , 0 1 - 0 2 - 8 8 , 0 - 0 - 0
"Nina" , "Employee" , 0 1 - 02 - 9 0 ,
"Nina" , "Manager" , 0 1 - 0 2 - 9 0 ,
"Ken" , "Employee" , 0 1 - 0 2 - 9 1 ,
"Ken" , "Secretary" , 0 1 - 0 2 - 9 1 ,
" SUsan" , "Employee" , 0 1 - 0 2 - 9 2 ,
"SUsan" , "Secretary" , 0 1- 0 2 - 9 2 ,
"Matt" , "Employee" , 0 1 - 0 2 - 8 8 ,
"Mat t " , "Manager" , 0 1 - 0 2 - 8 8 ,
"Charles " , "Employee" , 0 1 - 0 2 - 8 8 ,
"Charles" , "Engineer" , 0 1- 0 2 - 8 8 ,
"Mike " , "Employee" , 0 1 - 0 2 - 9 0 ,
"Mike " , "'fPII , 0 1 - 0 2 - 9 3 ,
Respons ible_for "Al " , "Sales"
Belongs_to "Al " ,
"Al " , "Manufacturing"
"Al " , "Engineering"
"Mike " , "Sales"
"Mike " , "Manufacturing"
"Mike" , "Engineering"
"Administration"
"Nina " , "Engineering"
"Ken" , "Administration"
"SUsan" , "Administration"
"Matt" , "Engineering"
"Charles" , "Engineering"
"Mike" ,
0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 0 - 0 - 0 12 - 3 1 - 9 7
avai lable avai lable avai lable business avai lable available avai lable
ended . )
Figure 6 Policy Definition Language.: for the Sample Organization Structure (Instantiation) Sbott'JI in fl�r.;ure 2b
l fJI. () .\'u. 4 Tall 199-1 Digital Tecbuical journal
the engi ne translates the organization schema defi
n ition part of PDL into a set of DDL statements.
F igure 7 l ists the organizational expressions required to formul ate the organizational pol icies for the travel expense re imbursement workflow.
Note that the organizational expression for employ
ees selects all users who play the role of employee.
The R ETURNS statement ind icates the search for users. The definition of the plays relationship type i n Figure 5 ind icates that the emp loyee is of the type role. This information is sufficie nt to formu
late a query to the underlying database system in an implementation of a pol icy resolution engine.
The PDL for the organ izational pol icies for the travel expense reimbursement example appears in F igure 8. The WFMS applies the first organizationa l pol icy when assigning the fil l step in a travel expense reimbursement workflow. The policy is valid in three dom ains, USA, EUROPE, and ASLA, for the exe
cute operation, which has no parameters. The pol
icy engine returns a set of all users who are able to play the role of employee. The second pol icy l isted in Figure 8 returns a set of al I users who play the
Policy Resolution in Workflow Management Systems
role of secretary and who report to the same user as the app licanr.
Independent from the travel expense reimburse
ment example are the sample separation of duty and delegation pol icies shown in F igures 9 and 10.
The organizational pol icy that specifies separation of duty ensures that the user who signs the expense for m is d ifferent from the user who fi l ls out the form. The policy that models the delegation opera
tion contains a parameter that specifies to which person the sign step is to be delegated. Only the manager of the applicant can cal l this operation and then only if the p arameter specifies either the next higher manager or the responsible vice presi
dent. The step can be delegated only to one of these two users.
Since the PDL is wel l defined, it can be used not only by designers to model organizations and poli
cies bm also by developers of graphics-oriented tools. Such tools could present graphical symbols to users to be manipu lated . When a user decides to com mit the changes, the tool generates a PDL script, which is fed into the pol icy resolution engine.
ORGANIZATIONAL_EXPRESSION employees ( ) RETURNS User : user
user plays employee
ORGANIZATIONAL_EXPRESSION secretaries ( ) RETURNS User: user
user plays secretary
ORGANIZATIONAL_EXPRESSION rnanager_of (User : a_user) RETURNS User: user
a_user reports_to user
ORGANIZATIONAL_EXPRESSION subordinates_of (User : a_user) RETURNS User: user
user report s_to a_user
ORGANIZATIONAL_EXPRESSION group_of (User : a_user) RETURNS Group : group
a_user belongs_to group
ORGANI ZATIONAL_EXPRESSION VP_responsible_for_group_of ( User: a_user) RETURNS User : user
user plays VP INTERSECTION
user responsible_for group_of ( a_user)
ORGANI ZATIONAL_EXPRESSION executing_agent (Workflow: a_workflow) RETURNS User
( * provided by the historical services of WFMS * )
Figure 7 Organizational Expressions for the Travel Expense Reimbursement Example
Digital Technicaljourual Vol. 6 No. 4 Fall 1994 4 1
Workflow Models
ORGANIZATIONAL_POLICY
WORKFLOW TravelExpenseReimbursement . Fill OPERATION Execute ( )
DOMAIN USA, EUROPE , ASIA
ORGANIZATIONAL_EXPRESSION employees ( )
ORGANIZATIONAL_POLICY
WORKFLOW TravelExpenseReimbursement . Check OPERATION Execute ( )
DOMAIN USA, EUROPE , ASIA ORGANIZATIONAL_EXPRESSION
secretaries ( ) INTERSECTION subordinates_of (
manager_of (
ORGANIZATIONAL_POLICY
executing_agent (
TravelExpenseReimbursement . Fil l ) ) )
WORKFLOW TravelExpenseReimbursement . S ign OPERATION Execute ( )
DOMAIN USA, EUROPE, ASIA ORGANIZATIONAL_EXPRESSION
manager_of ( executing_agent (
TravelExpenseReimbursement . Fil l ) )
ORGANIZATIONAL_ POLICY
WORKFLOW TravelExpenseReimbursernent . Reimburse OPERATION Execute ( )
DOMAIN USA, EUROPE , ASIA ORGANIZATIONAL_EXPRESSION
f inancial_clerks ( ) INTERSECTION
User : user responsible_for group_of (
executing_agent (
TravelExpenseReimbursement . Fi ll ) )
Figure 8 Organizational Policiesjor t!Je Tremel Expense Reimbursement Exanzple
ORGANIZATIONAL_POLICY
WORKFLOW TravelExpenseReimbursement . Sign OPERATION Execute ( )
DOMAIN USA, EUROPE, ASIA ORGANIZATIONAL_EXPRESSION
manager_of ( executing_agent (
TravelExpenseReimbursement . Fi ll ) ) DIFFERENCE
execut ing_agent (
TravelExpenseReimbursement . Fi l l )
Figure 9 Organizational Polhy for the Separation of Duty
Approaches l i ke the ones mentioned earlier in the paper provide a fixed set of types fo r model ing an organi zation or a fixed set of functions, such as
·' role player" or '·supervisor," from which to select
users fo r a workflow. None of these approaches provides a language l i ke PDL that can freely define tbe organ izationa l aspect as the appl ication seman
tics requires.
4 2 Vol. 6 No. 4 Fall 1994 D igital Tee/mica/ journal
Policy Resolu tion in Workflow Management Systems
ORGANIZATIONAL_POLICY
WORKFLOW TravelExpenseReimbursement . S ign OPERATION Delegate {User: a_user)
OOMAIN USA, EUROPE, ASIA ORGANIZATIONAL_EXPRESSION
IF a_user IN {manager_of {
manager_of { executing_agent {
TravelExpenseReimbursement . Fil l ) ) ) OR
VP_responsible_for_group_of { executing_agent (
TravelExpenseReimbursement . Fill ) ) ) THEN
manager_of ( executing_agent (
TravelExpenseReirnbursement . Fil l ) )
F(f?ure 10 Organizational Policy for the Delegate Operation
Policy Resolution Engine
The policy resol ution engine is a mechanism that evaluates organizational policies for a WFMS. Serving as a base service, the policy resoi ution engine manages organizational policies and organ izational expressions, as wel l as the organization schema and its population. The engine also provides i nterfaces for the defin ition, modification , and evaluation of these objects. The interfaces are distinguished by the kind of service they provide. There are basi
cal ly two k i nds of interfaces: evaluation interfaces and management interfaces.
Evaluation Inte1jaces Policy resolution engine cl ients use evaluation interfaces to evaluate organ i
zational policies or organizational expressions when necessary. The engine provides four evalua
tion interfaces: two for organizational policies ("resolve" and "conform to") and two for organi
zational expressions (also "resolve" and "conform to"). The reso lve operation for organizational poli
cies expects a workflow reference and one of its operations as input values. This operation selects an appropriate organizational policy, evaluates it, and returns a set of users eligible to execute the given task of the workflow. The conform to opera
tion for organizational pol icies expects a workflow reference, one of its operations, and a user as input values. This operation resolves the appropriate organizational pol icy for the workflow and checks whether the user is contai ned in the set of results for that organizational pol icy (i.e., if the user con
forms to the policy). If the user is conta ined in the
D igital Techuical]ou1·nal Vol. 6 No. 4 Fall 1994
set of resu lts, the conform to operation returns the va lue " true "; otherwise it returns the va lue " false."
Pol icy resolution engine clients use this operation to validate a request by a user to execute a certain task of a workflow.
The resolve and conform to operations for orga
nizational expressions work analogously. Instead of a workflow reference, the operations expect the name of an organ izational expression as input.
The operations evaluate the named organizational expression and return the set of results, which is used if the resolve operation is called . The con
form to operation returns true and false values as described in the previous paragraph.
Management Interfaces Management interfaces are used to define, modify, or delete orga nizational policies, organizational expressions, or organiza
tion schemas and their populations. These inter
faces look like the fol lowing operations that are provided for organizational policies: create, delete, modify, l ist, get. The create operation creates an organizational policy; the delete operation deletes a policy; the modify operation allows users to change an organizational policy to adjust to new requirements; the list operation returns the identi
fiers of all pol icies; and the get operation returns the complete description of a policy.
Designers do not cal l these management inter
faces directly, since they communicate their changes through user-friendly interfaces or tools.
These tools are either graphics oriented or language oriented. In a graphics-oriented tool, a designer
43
Workflow Models
manipu lates icons and graph ical symbols, which in tu rn results in cal l s to the appropriate management interfaces. Al ternatively, a grap hics tool can ge ner
ate a PDL script accord ing to the manipu lations of a user and submi t t h i s scrip t to the pol icy resol u tion engine. I n this case, the engine interprets the sub
m i t ted script and cha nges its internal state accord
ingly. Language-oriented tools e nable a designer to directly express changes using PDI.. These tools take specifications and translate them into ma nagement interface cal ls. Of course, t hey can also submit the la nguage specifications d i rect l y as Ill) ! . scripts to the policy reso l u t ion engine, as descri bed above.
Legeny Databases Many large enterprises have developed databases that contain some or a l l of the organ izational data the policy resolution engi ne needs to eva l ua te organ i zational policies. These databases, cal led legaqr databases, migh t he self
implemented or based on standards efforts like those re lated to providing directory services on networks, i.e., X.500.-' In ge neraL organizations must deal with one of the fol lowing scenarios:
• No legacy database exists. No existi ng database has to he considered, and the pol icy res o l u t i o n engine can use i ts own database t o build up orga
ni zational knowledge.
• Legacy databases contain a l l relevan t data. To use the pol iq' resol u tion engine, the database m ust provide a sufficiently ex p ressive query i n terface, on top of which queries issued from tile engine can be eval uated . The only add itional information that has to be s to red is organ iza
tional policies and organizational expressions. The organization has to choose whether to extend the legacy databases or to use the da tabase within the pol icv resolution engine.
• A legacy database conta i ns some relevant data.
l n addition to o rganizat ional pol icies and orga
n i zatio nal expressi o ns, organ izational objects and rel ationships must be stored in eit her the legacy database or the database of the pol icy res
o lution engine.
If the releva nt data is s tored i n several databases, the queryi ng i n terface must be built in such a way that the pol icy resolution engine can issue the nec
essary queries, which might span several databases.
Fu rthermore, sem a n t ics i ssues have to be dea lt with in heterogeneous environments_-,_-(,
Arcbitectuml Considemtiolls-Clients of a PoliLy Resolution Engine From an architectural point of view, there are two possible ways to design a pol icy reso lution engine:
1. Incorporate the pol icy resolution engine into a \VF,\1S The engine wou ld be a m od u l e, whose operat ions are h idden by the exported inter
faces of the WFMS. Al l calls to the engine opera
tions wo u ld he made t h rough the i nterface of the WI'NJS.
2. M a ke the p o l icy resol ut ion engine an indepen
dent COI11[10nent. The engine woul d be a server with a W F �IS system as one of its cl ients. All c l ients of the engi ne, i nclud i ng the WF�IS, wou ld be able to directly access t h e exported opera
tions of the engine.
PRA reco m mends t he i mplementation of a pol icy resolu tion engine as an i ndependent base service. whi ch can be used by c l ie nt s other than a WF.\1S For example, an electro n i c m a i l system can be a c l ient of the policy resolution engi ne. Since e lec
tronic m a i l is sem to users, rather than enu merate the electronic mail add resses of the recipients hy hand, organizational expressions can provide the addresses. For example, a m a n ager could send an electron ic mail message to " a l l my subordi n ates" or an engineer could send an electronic mail message to ·'all my col leagues who are engineers." The sam
ple operational express ion shown in Figure 1 1
ple operational express ion shown in Figure 1 1