YAWL yet another workflow language

YAWL:YetAnotherWorkflowLanguageW.M.P.vanderAalst1,2andA.H.M.terHofstede21DepartmentofTechnologyManagement,EindhovenUniversityofTechnologyP.O.Box513,NL-5600MB,Eindhoven,[e-mail]2CentreforInformationTechnologyInnovation,QueenslandUniversityofTechnologyP.O.Box2434,BrisbaneQld4001,[e-mail]ofexistingworkflowmanagementsys-temsandworkflowlanguages,anewworkflowlanguageisproposed:YAWL(YetAnotherWorkflowLanguage).Toidentifythedifferencesbetweenthevariouslanguages,wehavecollectedafairlycompletesetofworkflowpatterns.Basedonthesepatternswehaveevaluatedseveralworkflowproductsanddetectedcon-siderabledifferencesintheirabilitytocapturecontrolflowsfornon-trivialwork-flowprocesses.LanguagesbasedonPetrinetsperformbetterwhenitcomestostate-basedworkflowpatterns.However,somepatterns(e.g.involvingmultipleinstances,complexsynchronisationsornon-localwithdrawals)arenoteasytomaponto(high-level)Petrinets.ThisinspiredustodevelopanewlanguagebytakingPetrinetsasastartingpointandaddingmechanismstoallowforamoredirectandintuitivesupportoftheworkflowpatternsidentified.Thispapermoti-vatestheneedforsuchalanguage,specifiesthesemanticsofthelanguage,andshowsthatsoundnesscanbeverifiedinacompositionalway.AlthoughYAWLisintendedasacompleteworkflowlanguage,thefocusofthispaperislimitedtothecontrol-flowperspective.1IntroductionDespitetheeffortsoftheWorkflowManagementCoalition(WfMC,[40,17]),workflowmanagementsystemsusealargevarietyoflanguagesandconceptsbasedondifferentparadigms.Mostoftheproductsavailableuseaproprietarylanguageratherthanatool-independentlanguage.SomeworkflowmanagementsystemsarebasedonPetrinetsbuttypicallyaddbothproductspecificextensionsandrestrictions[1,5,15].Othersystemsuseacompletelydifferentmechanism.Forexample,IBM’sMQSeriesWorkflowusesbothactiveandpassivethreadsratherthantokenpassing[41].Thedifferencesbetweenthevarioustoolsarestriking.Oneofthereasonsattributedtothelackofconsensusofwhatconstitutesaworkflowspecificationisthevarietyofwaysinwhichbusinessprocessesareotherwisedescribed.Theabsenceofauniversalorganisational“theory”,andstandardbusinessprocessmodellingconcepts,itiscontended,explainsandulti-matelyjustifiesthemajordifferencesinworkflowlanguages-fosteringupa“horsesforcourses”diversityinworkflowlanguages.Whatismore,thecomparisonofdiffer-entworkflowproductswindsupbeingmoreofadisseminationofproductsandlessofacritiqueofworkflowlanguagecapabilities[6].YAWL:YetAnotherWorkflowLanguage2Workflowspecificationscanbeunderstood,inabroadsense,fromanumberofdifferentperspectives(see[5,32]).Thecontrol-flowperspective(orprocess)perspec-tivedescribestasksandtheirexecutionorderingthroughdifferentconstructors,whichpermitflowofexecutioncontrol,e.g.,sequence,choice,parallelismandjoinsynchro-nisation.Tasksinelementaryformareatomicunitsofwork,andincompoundformmodulariseanexecutionorderofasetoftasks.Thedataperspectivedealswithbusi-nessandprocessingdata.Thisperspectiveislayeredontopofthecontrolperspective.Businessdocumentsandotherobjectswhichflowbetweenactivities,andlocalvari-ablesoftheworkflow,qualifyineffectpre-andpost-conditionsoftaskexecution.Theresourceperspectiveprovidesanorganisationalstructureanchortotheworkflowintheformofhumananddevicerolesresponsibleforexecutingtasks.Theoperationalperspectivedescribestheelementaryactionsexecutedbytasks,wheretheactionsmapintounderlyingapplications.Typically,(referencesto)businessandworkflowdataarepassedintoandoutofapplicationsthroughactivity-to-applicationinterfaces,allowingmanipulationofthedatawithinapplications.Thefocusofthispaperisonthecontrol-flowperspective.Clearly,thisprovidesanessentialinsightintoaworkflowspecification’seffectiveness.Thedataflowperspectiverestsonit,whiletheorganisationalandoperationalperspectivesareancillary.Ifwork-flowspecificationsaretobeextendedtomeetnewerprocessingrequirements,controlflowconstructorsrequireafundamentalinsightandanalysis.Currently,mostworkflowlanguagessupportthebasicconstructsofsequence,iteration,splits(ANDandXOR)andjoins(ANDandXOR)-see[5,40].However,theinterpretationofeventhesebasicconstructsisnotuniformanditisoftenunclearhowmorecomplexrequirementscouldbesupported.Indeed,vendorsareaffordedtheopportunitytorecommendimplemen-tationlevel“hacks”.Theresultisthatneitherthecurrentcapabilitiesofworkflowlan-guagesnorinsightintomorecomplexrequirementsofbusinessprocessesisadvanced[6].Weindicaterequirementsforworkflowlanguagesthroughworkflowpatterns[6,70].Asdescribedin[50],apattern“istheabstractionfromaconcreteformwhichkeepsrecurringinspecificnonarbitrarycontexts”.Gammaetal.[22]firstcataloguedsystematicallysome23designpatternswhichdescribethesmallestrecurringinterac-tionsinobject-orientedsystems.Thedesignpatterns,assuch,providedindependencefromtheimplementationtechnologyandatthesametimeindependencefromtheessen-tialrequirementsofthedomainthattheywereattemptingtoaddress(seealsoe.g.[19]).Wehavecollectedacomprehensivesetofworkflowpatternstocomparethefunc-tionalityof15workflowmanagementsystems(COSA,VisualWorkflow,Fort´eConduc-tor,LotusDominoWorkflow,Mete