a money
Fig.7.Descriptionofanaccount.
x x
y y
"A";"B"
at home at work
yacc:deposit(1) xacc:deposit(1) acc:withdraw(1)
[x,acc]
acc:open(a) acc:new account
init
["A",3];["B",3]
[x,a]
x y
accounts [x,acc]
[x,xacc];[y,yacc]
Fig.8.Descriptionofperson.
two instances will be stored as part of the tokens in place accounts.
Com-munication with the net instances occurs as before via named, parameterised
synchronouschannels.
PresentingFigures7and8completesourbriefoverviewofthecapabilitiesof
referencenets.Itshouldbementioned,nally,thatreferencenetsallowforJava
annotations (objects and methods) as net inscriptions, resulting in a exible
modelling language for workows. The reference net tool Renew (REference
NEtWorkshop),extendedinasuitableway,willthenprovideuswitharuntime
environmentforworkowprocesses.
3 Workow Specications using Reference Nets
Theaimofaworkowspecicationistounambigouslydescribethecontrol ow
as wellasthe tasks that together implementabusiness process. Tasksare the
atomicworkitems thatneedto becompleted in orderto successfullycomplete
thebusinessprocess.Controlowistheco-ordinationprocessthatcontrolsthe
order of tasks to be performed, including dependencies betweenthe tasks and
theirpossiblyvarious outcomes.
Petrinets, and referencenets in particular, are averynaturalapproach to
describethecontrolowin aworkow:Theirstrengthisindeedthedescription
oftheowofinformationthroughthenet'sstructureand,bytheringrulesof
transitions, todescribedependenciesbetweenvariousevents.Eventhoughitis
fairlyevidentthattaskswillbesomehowrelatedtotransitions,astransitionsare
theactionsinaPetrinetspecication,theatomicityoftransitionsisslightlytoo
strictformappingtasksontotransitionsdirectly.Wewillclarifythisstatement
subsequently,which will leadto the denition of ataskobject, which wethen
willmap ontoanetstructureformed bythreetransitions.
Before discussing its formalisation, we rst have to clarify what the basic
ingredientsofataskarein aworkow.Incrudeterms:ataskisanatomicunit
of work that will be completed by an individual. Its support can range from
completelymanual(nosupportat all)tocompleteautomation(noinvolvement
of anindividual but onlysoftware).Theresult ofatask canbe either positive
or negative. In the positive case, the task will be completed, usually creating
some kindof output which will then be provided to control the workow and
subsequenttasks.Inthenegativecase,thetaskwillbeterminatedunsuccessfully,
a case in which the state of the workow has to be reset to the one prior to
theattempt of performingthetask. So, eventhough atask is atomicwithin a
workow,ithassomestructurefrom themodellingpointofview.
Wewill thereforemodelataskusingthree transitionsrepresentingentering
the task as well as either success or failure of completing a task. Firing the
entry transition will create an instance of a task-related object, which could
include instantiation of a sub-net, creating e.g. a sub-workow, instantiation
of a software object needed to deal with the task, and extension of a to-do
list of work items. Whenthetask is completed,its resultwill tellwhether the
the durationbetween entering and leavingthetask. We hencehaveinherently
solvedanadditionalrequirementformodellingtasks:performingtasksrequires
time. Thelowerpartof Figure 9showsthe basicstructure ofa taskconstruct
in our reference-net-based modelling technique. Please note that the topmost
entryplacesarechosenarbitrarilyaswellastheoutputplacesatthebottomof
Figure9.
z x
y
x y z z
x
[task,param,result]
y
y result
result y
[[x,y,z],_WF_activity]
[[x,y,z],_WF_activity]
[[x,y,z],_WF_activity]
:_WF_request([task,param],_WF_activity)
:_WF_confirm(_WF_activity,result) :_WF_cancel(_WF_activity)
Fig.9.Specicationofaworkowtask.
WF request([task,param],WFactivity) is the transition that will be
red to invoke the task. In case of an unsuccessful task termination,
transi-tion WFcancel( WFactivity)willre.Notethat WFcancel( WFactivity)
sition WFrequest([task,param],WFactivity). This restores the workow
state priorto entering thetask. In case of asuccessful task completion, ring
transition WFconfirm( WFactivity,result)willmaketheresultofthetask
available tosubsequenttasks. Itcanalsobeused forcontrolowpurposes.
Thesubnetinthegrayboxwillalwayshaveexactlythesamestructure.What
willvaryaretheinputandoutputplacestothetask.Fortheconvenienceofthe
presentationas well as the specication,weintroduce therefore anew symbol
thatrepresentsataskspecication.Asdepicted,werepresentthesubnetshown
in thelowerpartofFigure9byusingthetasksymbol, which ispresentedinits
upperpart.
4 The Runtime Environment
TheruntimeenvironmentisbasicallyprovidedbythetoolREferenceNEt
Work-shop (Renew).Renewprovidesafullsimulationenvironmentforreferencenets,
including the invocation of Javamethods that occur as reference-net
inscrip-tions and the handling of concurrent net processes. In particular, it handles
thesynchronisationofring transitionsbasedontheirchannel inscriptions.To
makeRenew incorporate acomplete workowengine, Tasks, WorkItems, and
Activities as well as their storage and handling have been implemented in
additionalpackagestotheRenew system.
4.1 The Specication Language
TheRenew systemhasbeenextended todealwith tasksymbols.Theywill be
compileddowntoreference-netstructuresaspresentedinFigure9foran
exam-pletask.ThecompilationprocesswasintegratedfairlyeasilyintoRenewbecause
of Renew's generalstructure: Betweenthe level of the graphical editor, which
has beenextended by the task symbol, and the levelof the simulator, Renew
contains anadditional layercalled the shadow level. The shadow level usesan
internalrepresentationofthenetdrawnonthenet-editorlevel.Thetranslation
process from the editor to the shadowlevel could therefore be extended by a
compilerfortasksymbolsthatreplaceseachtasksymbolbythethree-transition
sub-netitrepresents(Figure9).Ontheshadowlevelweendupwithonly
refer-encenetswithouttasksymbols,whichthencanbefedintothesimulationengine
asusual.Toaddtask-specicfunctionalitytothesimulationengine,ithasbeen
extendedbyaworkowengine.
4.2 The Workow Engine
Theworkowenginecomprisesasoneofitsmainfeaturesaninterfaceto
work-owusers: Users will be ableto access their agendas,i.e. task lists, using the
workowengine.These task listswill belteredso that a usersees onlytasks
she/heis authorisedtoworkon(seenextsection).Userscanthenselectatask
unsuccessfulcompletion(termination)ofatask.Theentirehandlingoftaskslies
withinthepackagesthathavebeenaddedtoRenew'ssimulationengine.This
in-cludesreturningunnished(unsuccessfullyterminated)taskstotasklists,
restor-ing stateinformation in caseofunsuccessfultermination oftasks, dealingwith
automatictasks(tasksthatcanbeperformedwithoutdirect userinvolvement),
and soon. It should be notedthat the additional packages provide interfaces
tofunctionalityalreadypresentinRenew,controlling,forinstance,theringof
transitions accordingto thestateof tasks.Theyalso compriseatask database
for theeÆcientstorageof tasksand theirinclusion to theaforementionedtask
lists.
Theworkowenginefulllsthereforetwotasks:thecontrolofworkow
pro-cesses via the Renew simulation engine and the management of tasks, users,
and the processing of tasks by users.As mentionedabove, tasks may only be
processedbyauserifshe/hehastheauthoritytodoso.Thehandlingofaccess
rightsisdonebyrulesaddedtotasks,whichformthemajorpartoftheworkow
securitysystem.
5 Workow Security
Inthis sectionwewill giveashortoverviewofsecurity issuesinthecontextof
workowsystems.Therst subsection coversgeneralaspects whilethe second
onecovershowaccesscontrol hasbeenintegratedin ourworkowconceptand
workowengine.
5.1 Overview
Thediscussion ofsecurityin workowsystemscanbasicallybereducedto
dis-cussingaccess control.Inallotheraspects,suchascondentialityofmessages,
authentication,etc., workowsystemsarenodierentfrom other applications.
The access-control aspect of workow systemsdeals with issues like: \Who is
responsible for performinga task and thereforeneeds access to data and
soft-ware supporting working on the task?" Also delegation of work and related
access rightsareimportantissueswithin aworkowsystem.Wewilldiscuss in
thissectionhowreference-net-basedworkowspecicationsupportsanelaborate
access-controlmechanism.
Weuse in our approach anextension to therole-based approach.
1
In
role-basedaccesscontrols,usersareassignedroles.Rolesaresimplynamedcollections
ofusers,whereasingleusercanappearinmultipleroles.Thereisalsoasub-role
relationthatholdstrue,ifallusersinonerole(thesub-role)arealsocontained
in another role (the super-role). For the easeof discussion, we will viewusers
subsequentlyassingletonroles.Theyaretheonly\roles"thancanlog-intothe
system.
1
Role-basedaccesscontrolsaresometimesalsocalledgroup-based.
foreaccessrightsto therelevantsoftware)areassignedto roles.A roleinherits
access rights from its super-roles. This is all that is possible in apurely
role-basedaccesscontrol.Toextenditslightlybysupportingdelegation,toperform
asingle task (and using the relevant software)a role may passon its own
ac-cess rights temporarily to another role. This temporary extension of a role's
access rightswillexpireassoonasthetaskiscompleted (eithersuccessfully or
unsuccessfully).
Even thoughdelegationofaccess rights makesrole-basedaccess controls in
a workow environment more exible, it is still a quite static concept. Very
frequently, access permissions to data or software will vary over time; i.e. in
dierent workowstates,access rightsbeassigned dierently.So moreexible
access-controlshaveemerged.Theideaofcontext-dependent accesscontrols,for
instance, takes into account that access to particular data will normally only
beimportanttoperformonetaskinaworkow,butnotanothertask. Sostate
information aboutthe workowis combinedwith role informationto compute
accessrights.Thiscontext-dependentconcept,wherethecontextistheworkow
state, can be applied to workows in environments in which state-dependent
protectionofdataislegallyrequired,forinstancein clinicaltrials.
Inthe approach we present in this paper we go even one stepfurther and
allowall available informationto bepartoftheaccess controldecision,i.e. we
keep the role concept but combine it with information about the workow's
state,data-baseinformation, statesof runningprograms,statesof other
work-owinstances,etc.Theaimistobeasexibleaspossible.Obviouslytheutmost
exibilitywillneverbeneeded.So,inpractice,restrictionswillapply.However,
in dierent environments,in which workow systems can support daily work,
securityrequirementsdier.Ourapproachcanthereforebeadapted tothe
dif-ferentenvironmentsby simplynot using allits possibilities. In that sense,the
approachwepresentinthispaperisagenericone.
5.2 Access Control in a Reference-NetWorkow
Asmentionedintheprevioussub-section,theaimofaccesscontrolsinworkows
istodenewhoisandwhoisnotallowedtoperformataskandaccessrelevant
data forthis task. Theaccess control systemis theimplementationof such an
accesscontrolpolicy.Inthemodellingtechniqueweareusing,wewillassignan
accessrule toeachtask.Therulewillbeevaluatedtochecktheauthorityofan
attemptto performatask.
Therstthingtonoteisthatbymovingtheaccesscontroltothetasklevel,
our access control is a context-dependent one: Aiming to perform a task will
onlybepossibleiftheroletryingtodosohastheauthorityforperformingthe
task and iftheworkowisin astatesuch that thetaskis active.However,an
access ruleforatask isin principleamethod oftypeboolean that checksthe
authorityofarequesttoperformthetask.Itmayuseanyinformationavailable
in itsenvironment,includingremote informationifit hasnetwork access.This
oersthegreatestexibilitypossible.
mentedin theworkow.There arebasicallytwooptions:inthe controlowor
in thetaskinscription.
{ (Control ow:)Wecanspecify theworkowin suchawaythat, byusing
control input places to tasks, tasks will only be enabled to be performed
by a role, if all other requirements constraining the access to a task are
satised(i.e.theruleissatised).Thesatisfactionordissatisfactionofthese
requirementswillbereectedbytheavailabilityor unavailabilityoftokens
inatask's controlinputplacenecessarytoenablethetask.
{ (Taskinscription:)Asreferencenet'sallowfortheinscriptionoftransitions
withJavacode,wecanimplementtheaccesscontrolmethodtoataskbyan
inscriptionoftheentrytransitionofthetask.Thetaskwillonlybeenabled
when its entry transition is enabled, and the entry transition can only be
enabled by being in the correct workow state plus the evaluation of the
accesscontrolmethodto true.
Obviouslywecanmixthetwoconceptsaswelikeinareference-networkow
specication,controllingonetaskusingthecontrol-owschemeandanothertask
byataskinscription.However,inpractice,combiningthetwoapproachesinone
specicationisprobablynotagoodideaasitwilldecreasethereadabilityofthe
specicationandprobablyincreasethelikelihood ofintroducingerrors.
6 An Example Workow
Thissectionpresentsanexampleofaworkowforamobile-phoneshop.It
con-tains several aspects of the workow engine. In this contribution we include
only thepure netswhich havebeen executedby ourworkowengine. The
en-vironment,thedatadescription,andsomeotherauxilary classesarenotshown
here.
Figure10representsthemainnetofamobile-phoneshop.Figure11contains
thecheckofsomecustomerdataandFigure12containsthedeliveryofthegoods
aswellasthecheckifalowerboundfortheamountofgoodshasbeenreached.
Themain netstartswith atransitionlabeledwithmanual(that isthenew
customertransition):Aneworderform iscreated.Thenthe
EnterOrderData-taskisdisplayedatallsalesmendisplays.Afteritscompletionanewinstanceof
theformexists.
Thelargerplaces in thenet are used to representthe existing orders fora
customer.Theactualordernowliesinplace unchecked orders.
ForthisorderaWorkflowTaskforthecheck of the order(anetinstance
ofFigure11)isinstanciated.:start(activity,order)allowstheaccesstothe
order within thenetinstanceof Figure11. Withinthis netaWorkItemwill be
oered to the oÆce workers in both cases (payment by credit card or bank).
Dependingontheresultofthecheckacheckoftheaddressmaybeperformed.
The main net in Figure 10 now will continue according to the result. In the