Database programming languages : proceedings of the Fifth International Workshop on Database Programming Languages, Gubbio, Umbria, Italy, 6 - 8 September 1995 ;

324 Pages·1996·2.276 MB·

by  Paolo Atzeni, Val Tannen (eds.)

ELECTRONIC WORKSHOPS IN COMPUTING
Series edited by Professor C.J. van Rijsbergen
Paolo Atzeni and Val Tannen (Eds)
Database Programming Languages
(DBPL-5)
Proceedings of the Fifth International Workshop on Database
Programming Languages, Gubbio, Umbria, Italy, 6-8 September 1995
Paper:
From Database Programming to Business
Process Programming (Invited Talk)
Umeshwar Dayal (Hewlett-Packard Laboratories)
Published in collaboration with the
British Computer Society
BCS
©Copyright in this paper belongs to the author(s)
From Database Programming to Business Process Programming
UmeshwarDayal QimingChen
Hewlett-PackardLaboratories Hewlett-PackardLaboratories
PaloAlto,California,USA PaloAlto,California,USA
Abstract
Over the past decade, databaseprogramming has focused on languagesand methodologies for developingdata-
intensive applications, and on techniques for efficiently implementing them. Research in this area has yielded
languageswithrichtypesystems,orthogonalpersistence,supportforcollectiontypes,andotheradvancedfeatures.
Thecommercialimpactofthisresearch,however,hasbeenratherlimited. Databaseapplicationsareamulti-billion
dollarbusinessworldwide,butmostapplicationsarestilldevelopedusingrudimentarytools.
Thegoalof this paperis to urgethedatabaseprogrammingresearchcommunityto rise tothe nextchallenge:
businessprocessprogramming,afieldthatisinitsinfancy,andwherethereisthepotentialfor significantimpact.
Competitivepressuresareforcingenterprisestore-engineerandautomatetheirbusinessprocesses. Suchprocesses
areoflongduration,complex,anderror-prone. Theyconsistofmultiplestepsthatneedtobecoordinated;thatmay
beexecutedbyapplicationprograms,machines,orhumansindifferentrolesacrossdifferentorganizations;andthat
mayexecuteinheterogeneous,distributedcomputingenvironments.
Thispaperintroducestopicsinbusinessprocessprogrammingthatwebelievewillbeofinteresttothedatabase
programmingcommunity. Theserangefrom issuesinmodelingandspecifyingbusinessprocesses,includingnew
transactionalmodelsforcapturingtheirexecutionsemantics,toproblemsofefficient,scalableimplementationinthe
heterogeneousdistributingenvironmentsprevalentintypicalenterprises.
1 Introduction
Research in database programming, as reflected in the Proceedings of the five DBPL Workshops held so far, has
focusedprimarilyonnewlanguagesandmethodologiesfordevelopingdata-intensiveapplications. Thishasresulted
in the design and implementation of database programming languages with rich type systems that are extensible,
provideorthogonalpersistence, and supporta varietyof collection types tofacilitate the manipulationof persistent
bulkdatastoredinadatabase.
Whatimpacthasresearchondatabaseprogramminglanguageshadonthemulti-billiondollardatabaseapplications
industryworldwide? Relativelylittle, unfortunately. Most of these applicationsare stillbeingdeveloped in fourth
generation languages or even third generation languages (COBOL or C) plus SQL. The elusive research goal of
orthogonalpersistencehasnotbeenattainedinpracticeasthe“impedancemismatch”betweenthehostprogramming
language(inwhichtheapplicationlogiciscoded)andthedatabasemanipulationlanguagecontinues. Whileobject-
orienteddatabasesystemssupportingPersistentC++orSmalltalkwithvaryingdegreesoforthogonalpersistencehave
appeared,thetechnologyhasnottakenoffcommercially,andthesesystemsrepresentatinyfractionofthemarket.
So, what can the DBPL research community do to increase commercial impact? The next big challenge for
the information technology industry is the management and automation of business processes. Business process
management,or“workflowmanagement”,recentlyhasgeneratedalotofresearchactivityindifferentsub-disciplines
ofcomputerscience. Also,severaldozencommercial productshaveappeared, andanindustrygroup,theWorkflow
ManagementCoalition(WfMC),haspublishedareferencearchitectureforsuchproducts[28]. Thispaperarguesthat
therearemanyimportantresearch problemsinthiscomplexareatowhichtheDBPLresearch communitycanmake
importantcontributions.
Businessprocessmanagement cannotbehandledbymeansofconventionaldatabase techniquesalone. Business
processes typically are of long duration, complex, and error-prone. A business process, in general, is a set of
activitieswithacommongoal. Itisbuiltbylinkingtogetherdiverseactivities,specifyingtheflowofdataandcontrol
among them, and specifyingbusiness rules that have to be enforced duringthe execution of the process. Business
processesoftenconsistofmultilevel,long-durationandcollaborativeactivities,andinvolvemanyusers,information
DatabaseProgrammingLanguages,1995 1
FromDatabaseProgrammingtoBusinessProcess Programming
systems, applications and tools in heterogeneous and distributed environments. Examples of business processes
includepurchaseorserviceorderprocessing,insuranceclaimsprocessing,loanapplicationprocessing,makingtravel
arrangements, planningand scheduling,designandmanufacturingprocesses, andmedical and laboratoryprotocols.
Consider the process of opening a new sales office for a company’s division; this includes several sequential and
parallelactivities,suchassubmittingaproposal,determiningthelocation,negotiatingofficerentalpricewithowners,
gettingapproval, etc. These activitiesmay betransactionalornon-transactional,andmay range fromtheexecution
of computer programs to human actions such as attendingmeetings or signingforms. Also, some of the activities
themselvesmaybecomplexprocesses. Today,thelogicforlinkingtheactivitiesthatcompriseabusinessprocessare
eitherexpressedinformallyinoperatingmanualsorinpeople’sheads,orembeddedinapplicationprograms.
As enterprisesseek tobecome more competitive,theyare turningtobusinessprocess managment technologyto
help re-engineer and automate critical business processes. The Workflow Management Coalition defines business
processmanagementas“atechnologythatallowscompaniestodeploybotholdandnewbusinessprocessapplications
that are faster and more flexible to build by making the business rules and flow of work logic independent of the
business application” [28]. A business process management system (or workflow system) controls and automates
theinteractionsbetweenactivities,programs,dataandusers. Theabilitytointegratethesecomponentssetsbusiness
process programmingapartfrom database programming: programminginthe largeversus programmingindividual
applications.
InSection2,webrieflydescribetherequirementsforbusinessprocess management, andtheextenttowhichthe
existingcommercial workflow productsmeet these requirements. Then, inthe remainder of the paper, we describe
an approach tobusiness process management thatwe are takingat Hewlett-Packard Laboratories. In Section3, we
describeourprocessmodel;inSection4,wedescribethetransactionalsemanticsassociatedwithourprocessmodel;
andinSection5,wedescribefailurehandling. InSection6,weillustrateourapproachviaafairlycomplexexample.
2 Business Process Management
We first describe the requriements for modeling, specifying, and managing business processes. Then, we reveiew
the state of commercial practice, and pointout the strengths and limitationsof commercial products. This should
underscorethekeyareasforresearchcontribution.
2.1 Requirements
Wecharacterizetherequirementsforbusinessprocessmanagementintermsofavarietyofservices.
Processdefinitionservices
(cid:15)
Processenactmentservices
(cid:15)
Distributionservices
(cid:15)
Organizationservices
(cid:15)
Monitoringandadministrationservices
(cid:15)
Processdefinitionentailsthespecificationoftheactivitiescomprisingtheprocess;thecontrolanddataflowsamong
them; andthebusinessrules, policiesandconstraintsrelevanttotheprocess. Processes are oftendefinedas graphs,
withthenodesrepresentingtheactivitiesoftheprocess, andthedirectededges representingcontrolanddataflows.
Some models specify controland data flows declarativelythroughrules ordependencies. Rulesspecify thatevents
signaled by activities cause downstream activities to be triggered. Dependencies prescribe temporal relationships
among activities (e.g., activity 1 cannot start until 2 terminates). Some models use procedural specification in
a a
a scriptinglanguage (typicallya block structuredconcurrent programming language). For complex processes, itis
usefultosupportabstractionsforhierarchicalstructuring. Somemodelsallowprocesses toberecursivelydefinedin
termsofsubprocesses. Itisimportanttoallowflexiblebindingofsubprocesses: atprocessdefinitiontime,atprocess
instantiationtime, or even later at the time the subprocess executes. This flexibility is important in that it allows
subprocesslibrariestobeconstructedusingreusabletemplates. Italsosupportsautonomyinthatthesubprocesscan
beredefinedwithoutaffectingthelargerprocess;thisisespeciallyimportantifprocessexecutioncrossesorganization
boundaries.
DatabaseProgrammingLanguages,1995 2
FromDatabaseProgrammingtoBusinessProcess Programming
Process enactment includes services for instantiatingprocesses, orchestrating the controland data flows among
theactivitiesofaprocess,andenforcingbusinessrules,policies,andconstraints. Sinceprocessesmayaccess shared
persistent data, they must be subject to transactional control. However, executing an entire complex process as a
singletransactionisunnecessary andinefficient. Somemodelssupportextendedtransactionsemanticsformodeling
a processas a hierarchicalcollectionofrelatedtransactions. Finally,services forexceptionandfailurehandlingare
required. Theexecutionofabusinessprocessmayfailtocomplete. Thisrequiressystemsupportfordeterminingthe
scopeofthefailure,rollingbacktheprocesswithinthatscope(suchaswithdrawinganofficerentalapplicationinthe
aboveexample),androllingforwardtheprocessviaalternativepaths.
Variousdistributionservicesarerequired. Theseincludeinteractionwithusersandcommunicationwithapplication
systems;naminganddirectoryservicesforlocatingresourcesrequiredforexecutingactivities;andinteroperationwith
otherprocessmanagementsystems.
Organization services support role resolution, the assignment of resources to activities, and authorization and
accesscontrol.
Finally,servicesformonitoringandadministrationofprocessesarerequired. Theseincluderecordingthehistory
andstatusofprocessexecutions,queriesoverthestatusinformation,anddynamicmodificatonofprocesses.
The architecture of a typical process management system includes several components: a worklisthandler for
managinginteractionsbetweenauserandthesystemviaworklistscontainingtheactivitiesheisassignedorallowed
toperform;oneormoredatabaseserversformaintainingprocess-relateddata(thisisoftenseparatefromthe“business
dataobjects”usedbytheactivities);aworkflowserverforprovidingflowcontrol;anorganizationserverforidentifying
andlocatingtheappropriateusersorinvokedapplications;andatransportserviceforcommunicationbetweenusers,
externalapplicationsandcooperativeworkflowsystemsinaheterogeneousanddistributedenvironment[26,10,11,
5,8, 4,21, 23, 20, 16,18, 2, 7]. Areference architecturehas beendefined bytheWorkflowManagement Coalition
[28].
2.2 Commercial Practice
Overtwodozenworkflowproductsareonthemarkettoday. Theearlyproductswereaimedat“automating”clerical
tasks in administrative and other office procedures. These systems, therefore, were message-centred or document-
centred.
Message-centred systemsessentiallyare extensionsofelectronicmail. Workisroutedbetweenworkersthrough
the flow of structuredmessages. Flows are either staticallydefined or may be dynamic based on message content.
Forms-based utilities are often provided for creating, approving, and signing forms. Such systems are limited to
manualtasksandprovidenorecoverybeyondrelaiblemessagedelivery. Also,theydonotprovidestatusmonitoring
orreporting.
Document-centredsystemsareextensionsofimage(documentorfile)managementsystems,andtypicallysupport
theflowoffoldersbetweenusers. Theyweredevelopedforapplicationssuchasloanorclaimsprocessing. Documents
andaccompanyingroutinglistsmaybestoredinadatabaseorfilesystem. Suchsystems, too,arelimitedtomanual
tasksandprovidelimitedrecovery(ofthedocumentdatabaseorfiles).
More recently, we have started to see the emergence of process-centered systems aimed at high-end business-
criticalprocesses suchasorderprocessingorcustomercare. Thesesystems providetoolsformodelingprocesses as
collectionsofactivitiesortasks, specifyingcontrolanddataflow, anddefiningbusinessrulesandconstraints. They
supportmanualandautomatedactivities,providesomerecoveryandexceptionhandling,andintegrateintodistributed
computingframeworkssuchasCORBA.Forinstance,theymaysupporttheencapsulationoflegacydatabasesystems,
file systems, and application systems as buisness objects using CORBA interfaces, and use CORBA RPC as the
transportmechanismtolaunchapplications. Theyusepersistentdatabasestorecordhistoryandstatusandtosupport
thequeryingofthisinformation. They alsosupportorganizationdatabases, and toolsformonitoringandmanaging
processes.
Theprocessmodelssupportedarestillquitelimited,however. Inparticular,thereislittlesupportforhierarchical
modelingofcomplexprocesses,andthislimitsscalabilitytoenterprise-wideorinter-enterpriseprocesses. Also,failure
andexceptionhandlingareratherlimited,andtherestillarenogenerallyacceptedtransactionalmodelsforinterrelated
collectionsoflong-durationactivities.
Insummary,businessprocessmanagementreliesonseveralrelevantsub-disciplinesofcomputerscience: software
processmodeling,groupwareandcollaborativework,distributedcomputing,distributeddatabasesystems,andtrans-
actionmanagement. The challengeistointegratethese technologiesintoacoherentframework thatprovidesarich
DatabaseProgrammingLanguages,1995 3
FromDatabaseProgrammingtoBusinessProcess Programming
processmodel, flexibleyetprecisetransactionalsemantics, integrateddatasharingandfailurehandlingmechanisms
andcapabilitiesforincorporatingactivities,dataobjectsandusers.
3 Open WorkFlow Manager Process Model
In the rest of this paper, we describe work we have done on an Open WorkFlow Manager (OWFM). This section
describesourprocessmodel.
Mostworkflowsystemsareactivity-netbased,whereactivitiesforaprocessorsubprocessaremodeledbygraphs
thatreflect the forkingand joiningofcontrolflow. Also, insome ofthese models, dataflow can be separated from
controlflow. Aflatmodel, however, makes itdifficulttoprovideawellunderstoodfoundationfordata sharingand
failurerecovery, and doesnotscale uptocomplexprocesses. However, itisalso insufficienttorepresenta process
purelybyatreestructure,sincethetreestructureonlycapturesthecontainmentrelationshipbetweenaparentactivity
anditschildactivity,butnotanyrelationshipsthatassociateactivitiesatthesamelevel.
Tosupportmultilevelprocessmanagementflexibly,weintroduceaprocessmodelthatischaracterizedbymultilevel
blocksandhyper-activity/blockcoupling. Thismodelprovidesonewaytomaterializetheconceptualmodelprovided
bytheWorkflowManagementCoalition.
3.1 SpecificationModel
A business process is a top-level block that contains multilevel nested blocks representing either subprocesses or
nested process modules [1, 7]. A block contains a set of activities linked to represent control flow and data flow.
Conditionalbranching,parallelforkingandjoining,aswellaslooping(iteration)areallowed. Ablockisrepresented
bya hyper-activity at the nexthigherlevel; theblock isdenoted by , and isreferred to as the parent ofthe
T BT T
activities directly contained in . Since a component activity can be a hyper-activity representing another inner
BT
block,blocksorhyperactivitiescanbenestedtoarbitrarylevels.
A block, , has an associated logical data container called Block Data Container (BDC) that is denoted by
P . TheBDBCT ofthetop-levelblockofanactivityhierarchyisactuallytheprocessdatacontainer. BDC’smaybe
imBpTlementedinterms of multi-leveldatabases withcontrolledaccess [19], orinterms of otherrepositoryfacilities.
DataheldintheBDCofablockisvisibletotheactivitiesinthatblockandinanyinnerblocks;therefore,anactivity
cancheckoutdatafromtheBDCofanyhigherlevelblock. Anactivitycanacquiredatabyaccessingexternaldata
sources,orbycheckingoutdatafromtheBDCofablockcontainingitdirectlyortransitively. Upontermination,an
activitychecksinitsresultsintotheBDCofitsparentblockorofsomeancestor. Wewilldescribetheseoptionsfor
commitcontrollater.
Forthepurposeoffailurehandling,anactivityatanylevelmaybepairedwithacontingencyactivity ˜,whichis
T
usedwhenrollingforwardalonganalternativeexecutionpath;and mayalsobepairedwithacompensationactivity
¯thatcanlogicallyeliminateitseffects. AcompensationorcontingTencyactivitycanbeflatorhierarchicalandmaybe
T
structureddifferentlyfromtheoriginalactivity. Acontingencyactivitymayinturnhaveitsowncontingencyactivity.
Finally, themodelincludesa multilevelauthorizationresolutionfacilitytoallowuser interventionofprocesses
andsubprocessesbyauthorizedusers(supervisors),i.e.,todynamicallymodifyflowcontrol,changeuserassignments,
partiallyrollbackprocesses, and soon. To allowusers tobalance process protectionand subprocess autonomyina
waysuitabletotheirapplications,asupervisionprotocolcontrolsupwarddelegationofinterventionprivilegesalong
theprocesshierarchy.
3.2 OtherSpecificationStyles
Inadditiontotheexplicitspecificationofprocessandactivitystructuredescribedsofar, wesupportthreeadditional
mechanismsformodifyingthecontrolanddataflowwithinaprocess: events,dependencies,andself-repairprotocols.
Theevent-drivenmechanismisbasedonEvent-Condition-Action(ECA)rules[22,15]Thebasicsemanticsofrule
executionisthatwhenthespecifiedeventisdetected,theconditionisevaluated;andiftheconditionissatisfied,then
theaction(whichcanbeanactivityorevenanactivityhierarchy),istriggered. Asdescribedin[22],wedistinguish
threeevent-actioncouplingmodes: immediate,deferredanddetached,whichprovideflexiblewaystomodifyactivity
hierarchies. The use of ECA rules allows process specifications to be dynamically modified or overridden. Rules
canbeusedforintra-processactivitytriggering,inter-processsynchronizationandreactingtogeneralsystemfailures,
resourcereallocations,securityviolations,andsoon.
DatabaseProgrammingLanguages,1995 4
FromDatabaseProgrammingtoBusinessProcess Programming
Dependenciesareusedtoenforceacceptableactivityexecutionorders,andoncetranslatedintodependencygraphs,
theycanalsobeusedto“trigger”activities. Statedependenciesbetweenactivitiesmayoccurfortuitously,ortheymay
beexplicitlyspecified. Adependencybetweentwoactivities and canberepresentedby where ,
areinstatesstart,commit,abortandsoon;and isthedepenTdjencyTtyipe. Forexample, thefaTiild!ep(cid:28)eTndjencydeTnjoteTdi
(cid:28)
by meansthatincase hasfailed,if hasnotcompleted,then iscanceledandanycompletedblock
comTpio!nefnatiloTfj is compensated fToir; else is coTmj pensated for. InformallyT,jthe faildependency asserts thatif
fails,then mTujstfailtoo;andthisdependeTnjcyunderliesthesemanticsoffailurehandlingacrossactivityhierarchiTesi
orsubhieraTrjchies.
Self-repairmechanismsincludeprotocolsforexceptionhandlingandcompensation. Theseaffectprocessexecution
byerasingtheeffectsofnon-fatalfailuresthroughrollbackandrollforward. Thesemechanismswillbedescribedin
moredetailinSection5.
3.3 ExecutionModel
Itisimportanttoseparatethespecificationmodelandtheexecutionmodelofabusinessprocess. Theformerprovides
atemplateforthestructureoftheprocessandcontrolflowwithinit. Thelatterisdynamicallyconstructedatruntime,
andexpressestheactualprogressoftheprocessinstanceandrecordsthehistoryofitsexecution. Theexecutionhistory
isusedinfailurerecovery,andcanalsobeusedbyvisualizationtoolstoanimatetheprocess.
Toexecuteabusinessprocess, aninstanceofitstop-levelactivityiscreatedbasedonitsspecification. However,
theinstanceofacomponentactivityiscreatedonlywhenitshouldbeexecuted. Thus,asshowninFigure1,activities
formingconditionalbranchesorevenloopsinprocessspecificationaredescribedlinearlybasedontheactualexecution
ofthemultipleactivityinstances. Activitiestriggeredbyrulesandenforceddependenciesalsohaveanimpactonthe
constructionofaprocessinstance.
process definition process execution history
condition
I*
D E I C* D* D* D* E*
C 2 3
conc
A B branch L conc K A* B* L* K*
H J J*
F G
condition
Figure1: SpecificationModelvs. ExecutionModel
Thus, the instances of an activity’s children activities simply form either a sequential execution or a parallel
execution. Amultilevelbusinessprocess instanceis builtrecursivelywithsequentialandparallelactivityinstances
(forbrevity,anactivityinstanceishereaftersimplycalledanactivity).
Anactivityatanylevelundergoesstatetransitionsatruntime;itisinitiatedinthestartstate, remainsactivefor
some time, andthenexits byeitherreaching theend ofitsworkora failure; accordingly, itterminates eitherinthe
commitstateorintheabortstate.
Rollingback an activityhierarchy, either fully or partially, is not based on its specification, but on its instance
executionhistory. Therefore,whencontrolflowformsbranches,onlytheexecutedactivitiesareconsidered,andwhen
controlflowforms a loopeach executed instance ofactivitiesistaken intoaccount. Asactivitiesare parameterized
(throughtheassociateddatacontainers),appropriateinformationcanbepassedfromtheinstanceofanactivitytothe
instanceofitscompensationactivity. Forexample, whenactivityreserve-flight isassociated withthecompensation
activitycancel-reservation, thepassenger’s identifiercan be a parameter for both; and inthisway a loopincluding
multipleexecutions of reserve-flight can be compensated for by multipleexecutions of cancel-reservation withthe
proper parameters. Further, activities involved in a loop may be "re-entered" with different parameters, and "re-
entering" actually means re-creating an instance. Thus, each execution of the activity involved in a loop can be
consideredasanindividualactivityinstanceassociatedwithitsowncompensationactivityinstance. Thoseinstances
aredistinguishablebytheirparameters.
Thehyper-activity/blockcouplingallowsaprocesstobehandledatdifferentabstractlevels,andofferssignificant
flexibilityinlayeringcontrol. Forexample,compensatingthecollectiveeffectsofablockofactivitiesatahigherlevel
DatabaseProgrammingLanguages,1995 5
FromDatabaseProgrammingtoBusinessProcess Programming
canavoidhavingtodefinecompensationactivitiesforeachofthem,sincethelatterissometimesimpossible.
4 Transactional Semantics
Businessprocessesmayaccess shared,persistentdata,andthusmustbesubjecttotransactionalsemantics. However,
executing a complex process as a single transaction is unnecessary in most cases. Instead, organizing a process
hierarchicallyallowsitseffectsondataobjectstobecontrolledlevelbylevelwithrelaxedtransactionalsemantics.
Many extended transactionmodels supportnested structures andrelaxed atomicity. Forexample, closed nested
transactions [25, 17], allow concurrent subtransactions but strictlyenforce atomicity; by allowinga subtransaction
onlytocommittoitsparenttransactiontentatively,itspartialresultsarenotexternalizeduntilthetop-leveltransaction
commits. Sincesuchatomicityistoorigidforengineeringapplications,theopennestedtransactionapproach[29,11,3]
relaxedittoenhanceconcurrencyofsubtransactionexecution. Byallowingasubtransactiontocommittothedatabase
independently of its parent transaction, the visibility of its effects can be broadened, but top-level atomicity and
protectionaresacrificed.
Similarly,Sagas[14]relaxisolationforlong-livedtransactions,allowingtheirserialcomponenttransactionstobe
interleavedwitheachother. WhileaSagaisnotatomic,itcannotbeexecutedpartially;also,itlackstheflexibilityto
retryanabortedcomponent,totryanalternativecomponentoreventoignoreacomponentfailure. Theseissueshave
beentackledbynestedSagasandACTA[13,9]butonlyindependentlycommitted(open)componenttransactionsare
considered. ATM[11]supportsactivityhierarchieswithboth(closed)transactionsand(open)activities,butsacrifices
atomicity of the top-level activity while improving inter-sub-activity parallelism; also, commit scopes other than
closedandopenarenotconsidered. Thereforethesemechanismsonlyprovidetwoextremes inthetradeoffbetween
maintainingatomicityandenablingconcurrency.
4.1 Commit ControlinOpenWorkFlow Manager
To adequately balance atomicity and concurrency and to control visibility and protection at selected levels of a
transactionhierarchy,wehaveextendedthenotionsofclosedandopentransactionsbyallowinganactivitytocommit
toa selected ancestor independentlyofits parent, making itsresultsvisibletothat ancestor and thusimprovingthe
concurrencyinthetransactionsubtreebeneaththatancestor[7,6]. Suchanactivityiscalledascopedactivity. This
extensionprovidessynergybetweenadvancedtransactionmodelsandworkflowmodelsfornestedactivitymodeling.
TheintroductionofBDCprovidesdataaccesscontrolalongtheblockhierarchy. Upontermination,anactivitycan
committoparentbycheckinginitsresultstotheBDCofthecontainingblock,makingitseffectsvisibletothe
(cid:15)
activitiesinsidethatblock;
committotoporcommittoanancestorbycheckinginitsresultstothecorrespondingBDC,makingitseffects
(cid:15)
visibletoallactivitiesinsidethatblock;or
committodatabasebycheckinginitsresultsintoanexternaldatabase,makingitseffectspermanentandvisible
(cid:15)
topublic(i.e.,toactivitiesinsidealltop-levelblocks).
As we described in [7], such multilevelcommit scope controlextends the closed/open nested activitymodel to
accommodateapplicationsthatrequireimprovedprocess-wideconcurrencywithoutsacrificingtop-levelatomicity. In
[6]wehavepresentedafurtherextensionthatallowsasubactivitytocommittoanarbitraryancestor. Forsimplicity,
wedonotdiscussthisextensioninthispaper.
5 Failure Handling
Transactional systems handle transaction failures by undoing(rollingback) in-progresstransactions. For handling
process failures, there are two complications. First, an in-progress process may actually have committed some
transactions, so these cannotbe undone;rather, theyhave tobecompensated for. Second, requiringthatthefailure
of any step ina businessprocess cause the entire process tofail is expensive, because rollingback a process could
potentiallyundoorcompensatealotofwork. Weallowactivitiesinsideaprocessorsubprocesstobedesignatedvital
toindicatethatthefailureofanyofthemshouldcausetheentireprocesstofail.
DatabaseProgrammingLanguages,1995 6
FromDatabaseProgrammingtoBusinessProcess Programming
Our model supports a combination of backward failure recovery and forward failure recovery. This allows a
processtopartiallyrollbacktoasemanticallyacceptedrestartpoint,thencontinueto“rollforward”,makingfurther
progress.
5.1 Failure HandlingInside ABlock
Handlingfailureinside a blockor in a flat process is based on ideas found inadvanced transaction models such as
Sagas[14]forbackwardrecovery(i.e.,howtoundotheeffectsofcertainoperations),orinFlextransactions[30]for
forwardrecovery(i.e.,howtoselectdifferentpathsofexecution[12]).
Inthefollowingcases,wesaythatthereexistsanin-blockfailurerecoveryplanwrt ’sfailure,if:
Tf
(a) isnon-vitaltothecontainingblockB,soitscancellationcanbeignored,andtheblockexecutioncancontinue;
Tf
(b) can be replaced by a contingency transaction acting as its exception handler, so upon its cancellation the
bTlfockexecutioncancontinuebyretryingthecontingencytransaction[11,27,29];
(c) isretriable,thatis,iswilleventuallysucceedifretriedasufficientnumberoftimes[24,30];
Tf
(d) the failurecaused by is recoverable withinthe block B, since the blockexecution can be rolledback toa
transactionfromwhichTfanalternativepathisavailable(suchatransactioniscalledpivotintheFlexTransaction
approach[24,30],andisimplementedin[12]),andlogicallyundoinganytransactionontherollbackpathdoes
notcauseblockBtofail;
(e) thereexistsamodifiabletransaction, ,specified bythebusinessprocessdesigner(e.g. modifyingadesign,
arequest,aschedule, etc.) precedingTtmhefailedtransaction, ,suchthattheblockexecutioncan belogically
rolledback(withoutcausingBtofail)to ,thenrestartedbTyfredoing .
Tm Tm
The restrictiononcases (d)and (e)is essential: logicallyundoinganytransaction onthe rollbackpathfrom ,
mustnotcauseblockBtofail. Ifthisrestrictionisunsatisfied,thenevenifthereisaTcokmpensationtransactiondefinTefd
for ,wecannotensuretheexistenceofanin-blockfailurerecoveryplanwrt ,sinceundoing wouldcausethe
failuTrketobepassedtothehigher-levelblockanyway. Tf Tk
Whenthereexistsanin-blockfailurerecoveryplanwrt ’sfailure,thefailuremayberecoverablewithinblock
B.Otherwise,failurerecoverybypartiallyundoingtransactioTnfswithinblockBonly,isimpossible.
However,inthepresenceofmultilevelcommitscopes,differentpiecesofpartialresultsofablockmaybevisible
todifferentscopes,andshouldbecompensatedinmatchedscopestoensureconsistentfailuresemantics. Forexample,
when a seminar announcement is made accessible to a department, the seminar cancellation notificationshould be
madeaccessibletothesamedepartment,ratherthantoasmalleroralargerscope.
5.2 Failure HandlinginanActivityHierarchy
Failurehandlingfornestedactivitieshasthefollowingspecificcharacteristicscomparedwiththatforflatortwo-level
transactions.
Inanactivityhierarchy,thefailureofasub-activitymaycauseitsparentorhigherlevelancestorstoabort. The
(cid:15)
highestancestoraffectedbysuchabort-uprepresentsthescopeoflogicalrollback,andpossibly,therestartpoint
forrollingforwardthroughanalternativepath.
Differentfromcompensatingatomictransactionsdiscussedinpreviouswork,compensatinganactivityhierarchy
(cid:15)
maybemadedirectly,orindirectlythroughcompensatingitschildrenactivities(e.g. make-applicationmaybe
compensatedfordirectlybywithdraw-application,orindirectlybycompensatingeach step). Acompensation
activity may either be flat or nested, and can be constructed differently from the activity to be compensated
for. Further, an activityhierarchy shouldbepartiallycompensatableforitsalready committedsub-activities,
regardlessofitsowncommitstatus.
It is reasonable to try to logically roll back an activity subtree at the highest applicable level. Rollingback
(cid:15)
anactivitysubtreefromitsrootcan haltallitsbranchespromptly;andcompensatingahigher-levelactivityis
potentiallymoregeneralthancompensatingalower-levelactivity. Forexample,whenactivitymake-application
isdirectlycompensatedforbywithdraw-application,thecollectiveeffectsofmake-applicationcanbeeliminated
regardlessofitsinternalsteps(someofthosestepsmaynotevenbecompensatable).
DatabaseProgrammingLanguages,1995 7
FromDatabaseProgrammingtoBusinessProcess Programming
Activitynestingprovidesfailureprotectionintwogeneralsituations. First,whenafailedactivityisnon-vitaltoits
parent,thefailurecanbeignored,andtheparentactivitycancontinue. Second,whenafailedactivitycanbereplaced
byacontingencyactivityactingasitsexceptionhandler,theprocesscancontinuebyretryingthecontingencyactivity.
Therefore, when an activity fails, the "abort-up" chain terminates at the closest ancestor of that is non-vital,
T T
associated with a contingency activity, or withouta parent (e.g. the top-level activity of a process, a contingency
activity,oracompensationactivity). WecallsuchanactivitytheUndoRootof .
T
Failurerecoveryconsistsin
(a) bottom-upsearchingfortheUndoRootoftheoriginallyfailedactivity,and
(b) top-downlogicallyrollingbacktheactivitysubtreeunderthatUndoRoot,usingcompensateandabortoperations.
Intop-downundoing,scopedactivitieswitheffectsinternaltothesubtreeundertheUndoRootshouldbeaborted
and activitieswitheffects externalized overthe UndoRootshouldbe compensated for. However, a scoped activity
mayormaynotnecessarilybecompensatedfordirectlysinceitseffectsmaybelogicallyeliminatedbyacompensation
appliedatahigherlevel. Foranactivity thatneedstobecompensated for,if isassociatedwithacompensation
activity ¯, then andthewholeactivityThierarchybeneath can be directlycoTmpensated forbyexecuting ¯ with
T T T T
thesamecommitscopeas ;otherwisethechildrenof areprocessed,andtherecursionmayspreaddownalongthe
T T
activityhierarchy,witheachbranchendingupwithadirectcompensationorabortion. Wehavedescribedthisprocess
in[6].
6 An Example
Figure 2 shows an example of a complex business process implemented on our OWFM prototype. This example
illustratesatripplanningprocessforattendingaconference. Itdemonstratesanopennestedactivityhierarchy,flexible
flowcontrol,activitydependencies,activitytriggeringwithvariousmodes,exceptionhandling,activitycompensation
andrecovery.
The top-level activity,trip-planning,is broken downinto several sequential subactivities(theirexecution order
isindicatedbyarrows): trip-authorization,travel-reservation, notification,billing,expense-approval, anddocument
filing. Each subactivitymay be further broken down, thus forming an activity hierarchy. Activitiesat leaf levels
may be explicitlyassigned to particular users. These subactivities may be executed sequentially, concurrently, or
conditionallybasedonthesystemstate,theuser’soption,ortheprespecifiedpriorities. Forinstance
activity notification has four subactivities to be executed in parallel, for notifyingthe manager, co-workers,
(cid:15)
systemadministrator,andtheconferenceorganizersaboutthetrip;
activity flight-reservation, a subactivity of travel-reservation, has three optional subactivities that allow the
(cid:15)
travelertochosefromthreeairlines;
activityhotel-reservationhastwosubactivitiesorderedbyprespecifiedpriorities,whereHiltonisthefirstchoice,
(cid:15)
andRamadaisconsideredonlyifHiltonisunavailable;
activitycar-rental-reservation,hasconditionalbranches,wheretheselectionofcar-rentalcompanyisbasedon
(cid:15)
theselectionofairline,e.g.,ifNWairlineischosen,Hertzcar-rentalwillbeselected,andifUAairlineischosen,
Nationalcar-rentalwillbeselected.
Activity dependencies describe the relationships between activities and can be used as constraints on activity
firing. For example, under activitytravel-reservation, there exist three subactivitiesfor flight, hotel, and car-rental
reservations. whoseorderofexecutionisnotspecifiedexplicitly,butenforcedbythefollowingactivitydependencies:
commit dependency (CD): the commit of hotel-reservation depends on the commit of flight-reservation; the
(cid:15)
commitofcar-rental-reservationdependsonthecommitofhotel-reservation;(infact,theconditionalbranching
ofcar-rental-reservationisalsoexpressiblebycommitdependencies);
exclusion dependency (EX): if Ramada hotel is taken, car-rental is unnecessary (we may assume that the
(cid:15)
conferenceisheldattheRamadahotel).
DatabaseProgrammingLanguages,1995 8
FromDatabaseProgrammingtoBusinessProcess Programming
Activitiesmaybetriggeredunderimmediate,deferredordetachedmodes. Forexample,thefollowingactivities
aretriggereduponsuccessfulterminationofactivityexpense-approval:
activitytravel-recordistriggeredasanimmediatechildofexpense-approval;
(cid:15)
activity rearrange-appointmentsis triggered as a deferred activity to be executed at the end of the top-level
(cid:15)
activity,trip-planning;
activitydata-surveyistriggeredasadetached,independentactivity.
(cid:15)
An activity that is unable to commit, may invoke a contingency activity. For example, if activity expense-
approval cannot commit, its pre-defined contingency activity, corporate-approval is invoked, and if it succeeds,
activityexpense-approvalisconsideredtobesuccessfulaswell,andthentheprocesscontinuestorollforward.
An activitymay be associated witha predefined compensation activitythatlogicallyundoes the effect of that
activity. Forexample, flight-reservationmay be compensated forbycancel-reservation. InFigure2, compensation
activitiesareindicatedbydashed-lineboxes.
7 Conclusions
As enterprises try to re-engineer and automate critical business processes, there is the need for middleware for
developing,executing,andmanagingbusinessproceses. Numerousworkflowproductshaveappearedonthemarket,
but these do not scale to enterprise process management. In particular, these products provide limited capabilities
forprocess modeling,andlimitedexecutionandfailuresemantics. The database research communityhasproduced
several extendedtransactionmodels, butmore research isneeded todescribetheformalpropertiesofthese models,
andtodeviseefficientimplementationtechniques.
Businessprocess programminggoesbeyondtheprogrammingofindividualdatabase applications,since itdeals
withthelinkingofmanyapplicationsintoacomplexprocess. Abusinessprocessisacontainerforasetofactivities
andlinksbetweenthem. Ataminimum,thespecificationofaprocessincludesattributessuchasname,createdateand
soon;activities(ornodes);linksthatlinkactivitieshierarchicallyandhorizontally,eitherforwardorbackward;rules;
dependencies; process data; andsupervisors whocan intervene duringprocess execution. An activityspecification
mayinclude: attributessuchasname,create date,andpossiblyothers;theusertowhomtheactivityisassigned;the
actiontobeperformed;acommitscope;asubsetofprocessdata,orothervisibilitycontrolinformation;triggerswith
couplingmodes;dependencies,andsoon.
According to the Workflow Management Coalition, the specification of a business process environment should
include the following: process groups containing processes in specific application domains; processes; invoked
applications; process data; roles that are users capable of doing certain work. Our richer model adds to these
informationabout event services, workflow domains, transport mechanisms, resource managers, process execution
statusmonitors,andusergroups.
These requirements pointto the need for business process programming languages and environments withrich
formallydefinedsemantics,andaccompanyingmethodologiesandtools;butsuccessfulsolutionswillhavetointegrate
many technologies. The challenge lies in dealing with heterogeneous, distributed and legacy applications, and in
supportinganacceptabledegreeofavailability,scalability,andreliability.Thegoalofthispaperistourgethedatabase
programmingresearchcommunitytorisetothechallengeofbusinessprocessprogramming,afieldthatisinitsinfancy,
andwherethereisthepotentialforsignificantimpact.
References
[1] G. Alonso, D. Agrawal, A. El Abbadi, C. Mohan, R. Gunthor, andM. Kamath. Exotica/FMQM:A persistent
message-basedarchitecturefordistributedworkflowmanagement. InProc.IFIPWG8.1WorkingConferenceon
InformationSystemDevelopmentforDecentralisedOrganizations,1995.
[2] D. Barbara, S. Mehrota, and M. Rusinkiewicz. INCAS: A computation model for dynamic workflows in
autonomousdistributedenvironments. TechnicalReport,MatsushitaInformationTechnologyLaboratory,1994.
DatabaseProgrammingLanguages,1995 9