Technology - A Brief Summary

Transcription

1 CORBA-BasedRun-TimeArchitecturesforWorkow J.A.Miller,A.P.Sheth,K.J.KochutandX.Wang LargeScaleDistributedInformationSystemsLab DepartmentofComputerScience ManagementSystems ABSTRACT URL: TheUniversityofGeorgia Thispaperpresentsverun-timearchitecturesforimplementingaWorkowManagementSystem(WFMS).Thearchitecturesrangefromhighlycentralizedtofullydistributed.Twoofthe LabatTheUniversityofGeorgia.AlltheWFMSarchitecturesaredesignedontopofaCommon architectureshavebeenimplementedatthelargescaledistributedinformationsystems(lsdis) ObjectRequestBrokerArchitecture(CORBA)implementation.ThepaperalsodiscussestheadvantagesanddisadvantagesofthearchitecturesandthesuitabilityofCORBAasacommunication infrastructure.aminorextensiontocorba'sinterfacedenitionlanguage(idl)isproposed toprovideanalternativemeansofspecifyingworkows.simpliedexamplesfromthehealthcare Competitionandeconomicpressuresforcemodernbusinesscorporationstolookfornewinformation technologiestosupporttheirbusinessprocessmanagement.sinceworkowtechnologyprovides 1INTRODUCTION domainaregiventoillustrateourtechnology.1 Athens,GA amodelforbusinessprocesses,and\afoundationonwhichtobuildsolutionssupportingthe exibilitytosupportsignicantorganizationalchangesandtechnologyevolutionsassociatedwith waytotomakegooduseofpastinvestmentsbyallowingintegrationoflegacysystems,andthe today'sdynamicenterprises. thatcooperatetoimplementabusinessprocess.agoodworkowtechnologycanalsoprovidea thepastfewyears.aworkowcanbesimplydenedasasetoftasks(alsocalledactivitiesorsteps) executionandmanagementofbusinessprocesses"[hk95],ithasbeenreceivingmuchattentionin OpenSystemsandTrials,Inc.consortium.SeeURL: TechnologyAdvancedTechnologyProgram(undertheHIITcontract,number70NANB5H1011)andtheHealthcare businessprocesseswithinanenterpriseandacrossmultipleenterprises.workowmodelstendto 1ThisresearchwaspartiallydoneunderacooperativeagreementbetweentheNationalInstituteofStandardsand Aworkowmodelcanbeusedtodesignautomatedorsemi-automatedsolutionsforcertain 1

2 bemorecomputer-orientedthantraditionalbusinessprocessmodels.consequently,theybetterfacilitateautomaticgenerationofsubstantialportionsofactualsolutions(i.e.,executableworkows). managementappearsin[ghs95]andtutorialmaterialsavailableinclude[rei94,she95].after developmentofarealisticworkowmanagementsystempossible.atechnicaloverviewonworkow emergingrelatedtechnologiessuchasmiddlewareandobject-orientedtechnology,whichmakethe technologyhasgainedinpopularityduetothetrendofbusinessprocessreengineeringandmany thelate1970's,withtherstuseoftheterminearly1980's[smi93].inrecentyears,workow Thehistoryofworkowtechnologydatesbacktooceautomationandbatchprocessingin severalyearsofdevelopment,manyworkowproductsandprototypesarenowavailable[wf94, poundtasks).anentireworkowcanberegardedasalargecompoundtask.asimpletaskmay representsomeactivitieswhichcanbedividedintosub-activities(simpletasksorevenothercom- oftasks{simpletaskswhichrepresentindividualindivisibleactivities,andcompoundtaskswhich alsobeingreported[jad+94,j+95]. GHS95],andearlyempiricalstudiesinapplyingtheworkowtechnologyorusingtheproductsare beaprogramwhichcanrunonprocessingentities,whichincludeapplicationsystems,servers supportedbyclient-serversystemsortransactionprocessingmonitors(tp-monitors),database Aworkowiscomposedofmultipletasks(alsocalledstepsoractivities).Therearetwotypes ManagementSystems(DBMSs),etc.Tasksareoperationsorasequenceofoperationsthatare submittedforexecutionattheprocessingentitiesusingtheirinterfaces. forwardrecovery. tonomous,anddistributed)systems"[ks95].forworkowexecution,aworkowscheduleris necessarytoenforceinter-taskdependencies,andtherefore,tocoordinatetheexecutionoftasksin theworkow.also,taskmanagersaredesignedtostarttasksandtoperformasupervisoryrolein on,anddynamicallycontrolworkowsinvolvingmultiplehumansandhad(heterogeneous,au- AWorkFlowManagementSystem(WFMS)provides\theabilitytospecify,execute,report specicationanddesign,inter-taskdependencyandschedulingstudies,andworkowmanagement systemdesign. Mostworkowrelatedeortsdoneinthepastfewyearscanbecategorizedintoworkow methodsinthreedierentorganizations[dui94].usingthetermtransactionalworkows,useof design[hk95,sr93,ks95].krishnakumarandsheth[ks95]describedthemodelingandspecicationofworkows.forstetal.[fkb95]proposedalanguagecalledc&cowhichisanextensionof Ctospecifyworkows.Duitshofperformedanempiricalstudywithemphasisonworkowdesign transactionconceptsinworkowmanagementwasintroducedin[sr93]andsubsequentlydiscussed Manypapershavebeenpublishedonworkowmodeling,workowspecication,andworkow inseveralpapers,including[bdss93,gh94,rs95b,ghs95,m+95,tv95].however,morework needstobedoneinthisarea. 2

3 trytospecifytransactionstructureandbehavior[kle91,cr90,dhl91].kleinproposedtwo primitivestodescribeconditionalexistencedependency[kle91].thetaskstatetransitiondiagram relateddependencies(e.g.,commitdependencyandabortdependency)havealsobeendenedin introducedisstillapopularwaytodescribetaskstructures.avarietyofdatabaseoperation [CR92,ANRS92,GH94]. Thespecicationandenforcementofintertaskdependenciesstartedwiththeearlyeortsto tionssatisfyingthegivendependency,anddesignedacentralizedscheduler.tangandveijalainen [TV95]extendedtheworkin[ASSR93]andproposedaprotocoltoenforceinter-taskdependencies. Severalschedulingapproacheshavebeenreviewedin[RS95b]. (CTL)language[Eme90],introducedawaytosynthesizeanautomatonthatcapturesthecomputa- Sinceworkowmanagementsystemdesigndependsonworkowspecication,researchonthis Attieetal.[ASSR93]formalizedinter-taskdependenciesbyusingtheComputationTreeLogic aspectstartedalittlelaterthanthatofworkowspecication.breitbartetal.[bdss93]proposed anintegratedarchitecturetosupportthepropertiesoftransactionsandtheirworkowmodels.the centralizedarchitectureofflowmarkisdiscussedin[la94].alonsoetal.extendedthecentralized FlowMarkarchitecturetoadistributedarchitectureofaworkowmanagementsystem[AAA+95]. turewhichintegratestherulesintoanobject-orientedmodel[krr95].barbara,mehrotraand ObjectFlow'sarchitectureisdiscussedin[HK95].Kappeletal.presentedaWFMSarchitec- RusinkiewiczproposedanimplementationofanewWFMSmodelbasedontheINformationCArrier(INCA)[BMR94].INCAscarrydataaswellasscheduling/routinginformationandtravelfrom processingstationtoprocessingstation.thisapproachfacilitateshighlyexible,fullydistributed appearin[rs95b,ks95].failurehandlinginlargescaleworkowmanagementsystemshasbeen anddynamicworkows,possiblyatthesacriceofeciency.issuesoflow-levelandinfrastructure discussedin[aka+95]. AnearlyeortisreportedinthethesisbyWang[Wan95].Workowreliabilityandrecoveryis stillanewareawherefewpeoplehaveventured.discussionsonrecoveryanduseofcompensation wehavenotseenempiricalstudiesofdierentworkowsystemarchitecturesinpublishedliterature. supportforbuildingworkowmanagementsystemshavebeendiscussedin[ghs95,rs95a].sofar, managementsystemsin[ghs95],thispaperdiscussestheuseofspecicservicesprovidedbypost- ModernComputing'sORBeline,aCORBA-basedproduct(wealsogainedadditionalexperiencein usingcorbabyusingiona'sorbixandbyparticipatinginabetatestofsun'sdoe).as apartofourcomprehensiveinvestigationintoalternativeworkowmanagementsystemarchitectures,wehavedesignedverun-timearchitectures.inthispaper,weintroducethesearchitectures Followingtheadvocacyfordistributedobjectmanagementbasedinfrastructureforworkow turesplayanimportantroleinourworkowmodeltosupportheterogeneousnon-transactional andspecicallycommentontheuseoforbservicestosupportthesearchitectures.taskstruc- 3

4 andtransactionaltasks.withtheaimofeasilydevelopingrun-timeexecutablecodefromahigh levelworkowspecications,weproposetheworkowinterfacedenitionlanguage(widl)that presentthevewfmsrun-timearchitectures.taskstructuresandtaskmodelsarepresentedin ityforworkow.section3brieydescribeshowworkowsaremodeled/specied.insection4,we involvesasimpleextensiontocorba'sidl. section5.finally,section6summariestheadvantagesofcorbaandhighlightsusefulcapabilities foundincorba2.0. Insection2ofthispaper,wediscusstheCORBAcommunicationinfrastructureanditssuitabil- applicationpartnershipwiththeconnecticuthealthcareresearchandeducationfoundationinthe aspectofwhichisdescribedinthispaper),weareapplyingandevaluatingthetechnologythrough areaofhealthcaredeliveryinamanagedcarecontext(seehttp:// fordetails).ourgoalistodevelopanddemonstratetheuseofappropriateworkowtechnologythat (a)enablesadditionalfunctionalityinhealthcaredeliverysystemsthroughbettercoordinationof IntheHIITproject,asafollow-oneorttodevelopingtheworkowautomationtechnology(one taskswithinandacrossenterprises,and(b)supportshealthcaredeliverybyutilizingtheresources (e.g.,doctors,nurses,technicians,operatingrooms,hospitalrooms,labtests,etc.)moreeciently, Atpresent,mostsystemsinanenterpriseareconnectedtogetherwithnetworks.However,to thusleadingtohigherqualitypatientcareinlesstimeandatalowercosttothepatientandthe buildaworkowmanagementsystemthatsupportstheintegrationandinteroperabilitybetween healthcaresystem. 2CORBACOMMUNICATIONINFRASTRUCTURE Heterogeneous,Autonomous,andDistributedsystems,acommunicationmechanismoperatingat ahigher-levelthensocketsorremoteprocedurecalls(rpc)wouldbebenecial.distributed ObjectManagement(DOM)supportsthiskindofintegrationandinteroperability.OMG(Object ManagementGroup)'sCORBA(CommonObjectRequestBrokerArchitecture)[OMG93]isa rapidlymaturingstandardfordom.thecorbaspecicationdenesthearchitectureofan ObjectRequestBroker(ORB),whosejobistoenableandregulateinteroperabilitybetweenobjects andapplications.corbaisseenastheonlyviabletechnologytrulyheadedinacross-platform, infrastructureforourworkowproject. non-proprietarydirection.corbamatchestherigorousdemandsofworkowsystemsintoday's widelydistributed,rapidlyevolvingandunpredictablyuctuatingenterprises.sincecorbais March1992andCORBA1.2inDecember1993.CORBA2.0wasannouncedinNovember1994 maturingrapidlybothasatechnologyandasastandard,itwaschosenasthecommunication TheCORBA1.0specicationwasreleasedinOctober1991.ItwasfollowedbyCORBA1.1in 4

5 alreadyalmostadozencommercialorbsorcorba-likeproductsavailableinthemarket(many [OMG93,Bet95]anditsspecicationwaspublishedinJuly1995[OMG95a,OMG95b].Thereare implementingcorba1.2andafewimplementingcorba2.0).table2listssomeofthem. ProductNameCompany DOE(NEO)SunMicrosystems ORBeline Orbix ObjectBrokerDigitalEquipmentCorporation SOM(DSOM)IBM PostModernComputingTechnologies,Inc.C++ IONATechnologies MappingLanguages HyperDeskHyperDeskCorporation C++,C ORBplus XShell HewlettPackard ExpertsoftCorporation CSmallTalk gramscommunicatewithservers(objectimplementations).thisisusuallydonebyspecifyingan CORBAprovidesaclean,high-levelapproachtowritingdistributedapplications.Clientpro- Table1:CommercialORBs C++ interfacebetweentheclientandtheserver.forgreaterexibility,theinterfaceisspeciedina anobjectimplementationtobechangedwithoutaectinganyclients.bindingsbetweenidland relativelysimpledenitionlanguagecalledtheinterfacedenitionlanguage(idl).thisallows commonlyusedprogramminglanguages(e.g.,c,c++,smalltalk)allowmixingandmatching (programmer'schoice)oflanguages[omg93]. ifthekeywordonewayisusedandvaluesarenottobereturned,thecallcanbeasynchronous. bindingreturnsareferencetotheobjectimplementation.usingtheobjectreference,clientsmake requestsintheformofremoteoperations(ormethodcalls).similartoordinarymethodcallsin C++,clientsmaypassparameterstothemethodandreceivevaluesbackfromtheobjectimplementation.Typically,methodcallsaresynchronous(clientswaitformethodstoreturn);however, Clientprogramsbindtoobjectimplementationsinordertomakerequeststobeserviced.The method.aftertheremotemethodnishes,controlandoutputvaluesarereturnedtotheclient. Onlytheclientandtheactualmethodimplementationneedtobecoded,sincetherestofthecode methodcallontheidlskeletonwhichthencallstheactualuserwrittencodeimplementingthe (hostmachineandprocess)bytheorb.attheremotemachine,themessageisconvertedintoa whichmarshalsparametersintoamessagethatissenttotheappropriateobjectimplementation Remotemethodcallsareimplementedinthefollowingmanner.Aclientcallsaclientstub isgeneratedautomaticallybytheidlcompiler.5

6 8).ThesedenitionsaremuchlikeaC++classdenitioninthatseveralmethodsaredened asapackageandtheinheritancemechanismcanbeused.unlikec++classdenitions,private datarepresentingthestateofanobjectisnotdenedintheinterface,butratherintheobject Thesignaturesfortheoperations(ormethods)aregiveninaninterfacedenition(seeFigure return_value=object_reference->operation(param1,param2,...); possibletospecifyattributesininterfaces.thisdoesnotviolateindependence,sincetheattributes implementation.thisincreasestheindependencebetweenclientsandservers.itis,however, language.becauseofthemultitudeoffactorsinvolvedindesigningecientworkowsforhealthcare Workowsmaybemodeledorspeciedusingagraphicalmodelorusingaworkowspecication 3WORKFLOWMODELING areimplementedasfunctionsreturning/settingvalueswithinanobject'sstate. deliveryandmanagedcare,highlevelmodelingbecomesveryuseful.usingourgraphicalworkow notbeatechnologyexpert. Designer[Mur95],aworkowcanbereadilydesignedbyanapplicationdomainexpertwhomay formoredetailedexamples).thepatientrstregisterswiththereceptionist,whothenassigns Room(ER)ofahospitalwithaspeciccomplaint(seehttp:// thepatienttoanexaminingroomintheemergencywing.onceanerdoctorbecomesavailable, he/sheexaminesthepatientandcomesupwithaninitialdiagnosis.theinitialdiagnosismay callforlabtests(x-raysorabiopsy)whichwillthenbeanalyzed,oritmaysimplyleaddirectly LetusconsiderthefollowingsimpliedexampleinwhichapatientcomestotheEmergency toanaldiagnosis.thedoctoratthistimedeterminesifthepatientshouldbetreatedonan anoutpatientorterminatetreatment.iftheout-patient'sprogressisnotsatisfactory,thenthe in-patientoroutpatientbasis.afterin-patienttreatment,thepatientmaycontinuetreatmentas treatment.specictreatmentplans(bothin-patientandoutpatient)wouldinpracticeexpand patientmayreturntothehospitalforanotherroundofdiagnosis;otherwise,theymayterminate intotheirownsubworkows.figures1and2areworkowmodelsproducedwithourgraphical WorkowDesignerdepictingthisexample(thegureswereadaptedfrom[HK95]). Language(WFSL)[KS95]isadeclarativerule-basedlanguagetodescribetheconceptualworkow orbydesigningthemwithourgraphicalworkowdesigner[mur95].theworkflowspecication itorybyspecifyingtheminaworkowlanguage(e.g.,wfsl/tsl[ks95]orwidl(seesection5)) workowsmaybeselectedforexecution(weplantomakeourrepositorymoresophisticatedin futureimplementations).workowsorcomponentsofworkowsmaybeaddedtothemodelrepos- OurWorkowManagementSystem(WFMS)utilizesasimplemodelrepositoryfromwhich specication,whilethetaskspecicationlanguage(tsl)[ks95]isalanguagetospecifysimple 6

7 Register Diagnosis Figure1:PatientWorkowModel End_Diag Outpatient Case_Closed Inpatient Examine X_Rays Analysis Figure2:DiagnosisSubworkowModel Biopsy 7

8 tasksthatruninahadinformationsystemsenvironment.onceaworkowisselectedfromthe repository,severaltranslationstepsarecarriedoutthatinstantiateaworkowinstancethatisable 4RUN-TIMEARCHITECTURESFORAWFMS torunwithinthehadexecutionenvironment(somemanualcoding/recodingmaybenecessary). Themaincomponentsintheexecutionenvironment(orrun-timesystem)aretheWorkowScheduler,TaskManagers(TMs)andTasks.Tasksaretherun-timeinstancesofanenterprise'sapplications.Todaytheytypicallyrunindependentlyoraretiedtogetherinadhocways.WFMSsticationsprovidehooksintothetaskthatallowthetransitionsbetweenmajorstepstobeobserved toexistingapplicationcodeorenforcingstandardsfornewapplicationdevelopment.themodi- andinsomecasescontrolledbythetaskmanagerforthetask.toestablishglobalcontrolas thesetaskstogetherinalooselycoupledfashion.thisisachievedbymakingminormodications architecturesisgivenintheconclusions. 4.1HighlyCentralizedArchitecture two[wan95].wediscussthevearchitecturesinthesubsectionsbelow.abriefcomparisonofthe possiblefortheschedulertobeeithercentralizedordistributed,orevensomehybridbetweenthe wellasfacilitaterecoveryandmonitoring,thetaskmanagerscommunicatewithascheduler.itis visionswithinaboxrepresentthreads(lightweightprocesses). interface.thearchitectureisshowninfigure3,whereeachboxrepresentsaprocess,whilesubdi- Thisarchitectureincorporatestaskmanagersintothescheduler'sprocess.Thisprocessismultithreadedandhasathreadfortheschedulerproper,athreadforthescheduler'sdispatcher,and 4.2SynchronousCentralizedArchitecture Themaindierencebetweenthisarchitectureandthepreviousoneisthattaskmanagersarenot athreadforeachtaskmanager.taskmanagerscommunicatewithtasksthroughacorbaidl thisarchitecture.) thatsynchronouscallsarestillusedtocommunicatebetweentheschedulerandtaskmanagersin eachtaskmanager.thethreaddoesnothingotherthanactivatethetaskmanageronaspecied machineusinganothercorbaidlinterface.(thereasonforkeepingathreadforeverytaskis threadsanymoreandmayresideatremotesites.however,theschedulerstillhasathreadfor (1)theschedulerprocesscontainsthreadswhichcommunicatewithtaskmanagersusingCORBA IDLinterfaces;and(2)taskmanagerscommunicatewithtasksusingCORBAIDLinterfaces. Inthisarchitecture,asshowninFigure4,CORBAIDLinterfacesareusedattwodistinctlevels: 8

9 Dispatching Service Scheduler Monitoring Service TM TM 1 TM 2 n nodes,taskmanagerscantakeadvantageofmultiplenodestodoworkinparallel.communication IDL IDL IDL co-locatedinthesameprocessusingorbelineservices. Figure3:HighlyCentralizedScheduler 4.3AsynchronousCentralizedArchitecture betweentaskmanagersandtasksmaybespedupsinceataskanditstaskmanagermaybe Sincetaskmanagershavebeenseparatedfromtheschedulerprocessandmayresideatother Task 1 Task2 Taskn sendasynchronousmessagesbacktotheschedulerifnecessary.taskmanagerscommunicatewith tasksusingsynchronousidlinterfaces,althoughthisinterfacecouldbemadeasynchronousas Thisarchitecturedoesnotusethreadagentsorthreadsfortaskmanagers.AsshowninFigure5, theschedulercommunicateswithtaskmanagersusingasynchronousidlinterfaces.taskmanagers fromthemessagecollectingservice.inordertoprocessthereceivedmessagesbetter,themessage state,thetaskmanagersendsanasynchronousmessagetothemessagecollectingservicewhichis agerforataskusinganasynchronousmethodcallthroughtheorb.afterataskcompletesa designedasaserverincorporatedintotheschedulerprocess.theschedulercanobtainmessages wellṫhedispatchingservicesendsanasynchronousmessagetoinitiatethecorrespondingtaskman- beusedtoidentifythetaskmanagerfromwhichthemessagehasbeensent. collectingservicecouldrunasathreadinthisarchitecture.inthisscheme,ataskidnumbercan 9

10 Dispatching Service Scheduler TA 1 TA 2 TA n Monitoring Service IDL IDL IDL TM Figure4:SynchronousCentralizedScheduler 1 TM 2 TM n IDL stillsenttothescheduler,whiledataissentdirectlytotheappropriatetaskmanager. andthepreviousoneisthattaskmanagersareallowedtotalktoeachother.controlsignalsare 4.4Semi-DistributedArchitecture Inthisarchitecture,asshowninFigure6,theschedulercommunicateswiththetaskmanagers taskmanagersthroughasynchronousidlinterfaces.themajordierencebetweenthisarchitecture throughasynchronousidlinterfaces.taskmanagersarealsoallowedtocommunicatewithother 1 2 n todistributemoreworktotaskmanagers,whilestillkeepingthecentralizedschedulingalgorithm andtheadvantagesofthecentralizedarchitecture. Thepurposeofdesigningthisarchitectureistoreducethecentralscheduler'sworkburdenand 10

11 Scheduler Monitoring Service Dispatcher Message Collecting Service TM 1 TM 2 TM 4.5FullyDistributedArchitecture IDL IDL IDL Inthefullydistributedarchitecture,asshowninFigure7,thereisnocentralizedscheduler.Inthe gure,eachtaskmanager(markedastm)isequippedwithafragmentofcodewhichdetermines n ifandwhenagiventaskissupposedtostartexecution.sinceataskmaydependonanumberof Figure5:AsynchronousCentralizedArchitecture Task 1 Task 2 Task othertasks(eitherand-edoror-ed),anand-ortreeisused(normalizedtoadisjunctionof n conjunctions)andcompiledintoafragmentofc++code,essentiallyactingaspartofthescheduler oftheoverallworkow. Task Manager inthegraphicaldesigner(seefigure2).individualtaskmanagershave\knowledge"ofonlythe successortasks.theycommunicatewithothertaskmanagersthroughasynchronousidlinterfaces. AsseeninFigure7,thelayoutoftheworkowcloselyresemblestheworkowasitwasdesigned Themonitoringserviceisusedtowatchovertheworkowexecution.Individualtaskmanagers 11

12 Scheduler dispatcher Message Collecting Service Monitoring Service Figure6:Semi-DistributedArchitecture TM 1 TM 2 TM n IDL IDL IDL 1 2 n centralizedschedulerduringtheexecutionoftheworkow.anotheradvantageofthisarchitecture communicatetothisservicetheirinternalobservablestates,aswellasdataobjectreferences(for well.also,iteliminatesthebottleneckoftaskmanagershavingtocommunicatewitharemote possiblerecovery).taskmanagerscommunicatewiththemonitorbyasynchronousmessagessent throughtheorb. isitsresiliencytofailures.ifonenodecrashes,onlyapartoftheworkowisaected. Thedistributedarchitecturematchestheinherentdistributionalcharacterofworkowvery TM Manager ofthetask.beyondthetaskstructure,thisalsorequiresaspecicationofallowableoperations. andthepermissibletransitionsbetweenthosestates.afulltaskspecicationwillxthetype 5TASKSTRUCTURESANDTASKMODELS Followingtheobject-orientedparadigm,eachstatewillcorrespondtoanoperation(ormethod). Ataskstructureindicatesthegenericformofatask.Astructuresimplyidentiesasetofstates 12

13 Monitoring Service Sched. TM 1 Sched. TM 1 IDL IDL Task 1 Sched. Figure7:FullyDistributedArchitecture Sched. Task 1 TM 1 TM 1 IDL IDL Severaldierenttaskstructureshavebeendeveloped[ASSR93,KS95,Wan95]. Task 1 Task 1 thetoplevelisamodelfortheoverallworkow(seefigure1),belowthisaresubworkows(or Sched. compoundtasks)(seefigure2)whichthemselvesmaybemadeupofsubworkowsorsimpletasks. TM section5.1)guardingstatesmaybedisplayed.thesegraphicalworkowandtaskmodelscreated Inoursystem,diagrammaticworkowmodels[KS95,Mur95]areinherentlyhierarchical.At 1 IDL usingthegraphicalworkowdesigner,alongwithsupplementaryspecications(e.g.,conditions, Eachtaskisfurthermodeledviaastatetransitiondiagram(seeFigure9).Optionally,thegates(see Task 1 inputs,outputs,etc.),arethebasisforpartiallyautomatedcodegenerationforactualworkows. icationispreferred).wfsl/tslmaybeusedtospecifyworkows[ks95].wearecurrentlyin theprocessofdesigningalanguagethataddswfsl/tsl-basedfeaturestocorba'sinterface DenitionLanguage(IDL).Forbrevity,wediscusssomeelementsofthislanguagebelowusinga simpleexample.consideranapplicationinwhichmoneyistobewithdrawnfromanaccountin Ourworkowsystemalsoallowsworkowstobespeciedtextually(althoughgraphicalspec- 13

14 actionsisgiveninfigure8whichdisplaystheworkowinterfacedenitionlanguage(widl).a fulltaskspecicationrequiresthattheparametersandreturntypeofeachoperationbespecied. Inessence,thisisanalogoustoaclassspecicationinC++.However,tofacilitateinteroperabilityanddistribution,thespecicationisintheformofaCORBAIDLinterfacespecication.In additiontooperations(methods),attributesandexceptionsmaybespecied. abstractclass(allmemberfunctions(methods)arepurevirtual).thus,thebaseclassservesasan applicationframework[str91]. SmallTalk).Servers(i.e.,implementations)havethissameexibility. ForourWFMSsystem,thebaseinterfaceTTask(TransactionalTask)isimplementedasan Clientsmaycallthisinterfaceusinganylanguageforwhichabindingisprovided(e.g.,C,C++, multipledatabases.thespecicationforthisworkowthatcoordinatestheexecutionoftwotrans- onebankanddepositedintoanaccountinanotherbank.thisisanexampleoftransactionson 5.1IntertaskDependenciesandEnableArcs objectsarenotsentoverthenetwork,ratherreferencestocorbaobjectsarepassed. puts)aregroupedtogetherintoasinglestructurederivedfromwfldata(similarlyfortheout parameters(outputs)).thesestructuresmaycontainembeddedobjectreferencessothatactual Forsimplicity,onlyCORBAinandoutparametersareallowed.Allinparameters(thein- byclauses.anenabledbyclausemayhaveanynumberofpredicates.eachpredicateiseithera task-statevectororabooleanexpression. Coordinationbetweentasksisaccomplishedbyspecifyingintertaskdependenciesusingenabled clauses.justasinmostprogramminglanguages,theandoperatorisgivenhigherprecedencethan or.thereforetheclausewillbeindnfifnoparenthesesareused.ifparenthesesareused,then TheentireclausewillberepresentedinDisjunctiveNormalForm(DNF),i.e.,theorofand enabledby([<task_1>,<state_1>]&&[<task_2>,<state_2>]&&<condition>) theclauseisconvertedtodnf. at<time>; mightbeofthefollowingform. maybeanybooleanexpressionontheinparametersofthecorrespondingmethodcalls.for entireexpressionincluding<condition>evaluatestotrue,theactionisenabled.the<condition> example,suppose<task2>isdeposittaskand<state2>isexecute,thenapossiblecondition (e.g.,<task1>leaves<state2>)thecorrespondingtask-statevectorissettotrue.thenifthe ThisissimilartoanEvent-Condition-Action(ECA)rule[C+89].Whenaspeciedeventoccurs payment.money>= &&payment.retries<=3

15 structmoney_transfer:wfl_data{ interfacebank_workflow:compound_ttask{ };//Money_Transfer doublemoney; longaccount_no; longretries; longexecute(); longabort() interfacewithdrawal_task:ttask{ };//Bank_Workflow longcommit() enabledby([deposit_task,commit]); enabledby([withdrawal_task,abort] [Deposit_Task,Abort]); longexecute(inmoney_transferrequest) interfacedeposit_task:ttask{ };//Deposit_Task longabort(); longcommit(outmoney_transferpayment); enabledby([bank_workflow,execute]); };//Deposit_Task longexecute(inmoney_transferpayment) longabort(); longcommit(); enabledby([withdrawal_task,commit]); Figure8:BankWorkow.widl 15

16 Onlyifthisconditionevaluatestotruewilltheremotemethodcall becometrue.ifthegate'sand-ortreenowevaluatestotrue,thegatewillopen(itisfully bescheduledforexecution. enabled)andthemethodimplementing(<task2>,<state2>)willbescheduledforexecution.if Asuccessfulenablewillcauseoneleafnodeinthegateguarding(<task2>,<state2>)to return_value=deposit_task->execute(payment); causestaskinitiation.theexecutionmaybescheduledtooccurimmediately(thisisthedefault) <state2>istherootofthedirectedgraphrepresenting<task2>'staskstructure,thenenabling executionpriorityforoperatingsystemsthatallowsuchinuence. complexissues.ourwfmsisatpresentnotintendedforuseindomainswherehardrealtime ThedynamicprioritywillaectplacementonWFMSdispatchqueues,andoptionallytheactual oratagiventimeinthefuture.forschedulingusingrealtime,onecouldpotentiallyaddressmany constraintsarepresent;wesimplyincorporatedeadlinesintothecalculationofdynamicpriorities. workowstructureisadatastructurewithintheschedulerthatrepresentseachtask'staskstructure, Theloadmoduleisanautomaticallygeneratedfunctionwhichloadstheworkowstructure.The theenablearcsbetweentasksandthegatesguardingcertainstates,aswellasthecurrentstate, aworkow.thisleispreprocessedtoprovidethefollowing:(1)ataskmanagerforeachinterface; (2)a.idlleforeachinterface;and(3)aloadmoduleforthescheduler(loadwfstructure.cc). ThespecicationsofTaskInterfaces,EnableArcsandGatesareallembeddedinthe.widllefor toprovideaxedsetoftaskstructuresorallowusers(albeitsophisticatedones)tocreatetheir priority,etc.ofeachtask. 5.2VarietiesofTaskStructures Inthissubsection,wediscussseveralusefultaskstructures.Onefundamentalquestioniswhether designconstraints.intherestofthissubsection,wepresentseveralfundamentaltaskstructures owntaskstructures.ifthelatterischosen,thensurelydesignconstraintsshouldbeenforced.a userstheabilitytodesigntaskstructures,andarestillworkingonformulatingasimplesetof proliferationoftaskstructureswouldlikelyleadtoincomprehensibility.wehavechosentogive thatwebelieveshouldbebuiltintoanywfms.thetaskstructuresareshownasdirectedgraphs (typicallyacyclic).thenodesinthegraphcorrespondtotheexternallyvisiblestates,whilethe arcscorrespondtopermissibleinternaltransitions.aninternaltransitionissaidtobecontrollable ifitcanbeaectedbyanothertaskviaanenablearc;otherwise,theinternaltransitionissaidto beuncontrollable.notethattheguresdepictingtaskstructuresalsoshowsampleenablearcs, eventhoughthesearenotpartofthetaskstructureperse. 16

17 orisolationistobeincludedinaworkow.thismodeldoesnotpermitmicromanagementofthe thatisit.theexternallyvisiblestatesofasimplenon-transactionaltaskareinitial,executing, owofcontrolwithinatask.suchataskcanbeinitiatedorforcedtofail(terminateearly),but failedanddone.thetaskstructureisshowninfigure9.optionalenablearcsmaycomeinto thefailedstatetoforcethetasktofail.thetransitioni-ewouldbeuncontrollableifnoenable Anon-transactionaltaskisusedwhenanordinaryapplicationthatdoesnotenforceatomicity anenablearcforcesthetasktofail.theyareuncontrollableifnoenablearccomesintothefailed arccomesintotheexecutingstate,andcontrollable,otherwise.transitionse-fande-dwouldbe controllableifanyenablearccomesintothefailedstatesincethetransitione-dwouldberejectedif state. i i e e optional a c f d Durability)properties[GR93].Theexternallyobservablestatesofatransactionaltaskareinitial, theatomicitypropertyandmaximallysupportsallacid(atomicity,consistency,isolation,and Figure9alsoshowsthetransactionaltaskstructure.Atransactionaltaskminimallysupports Figure9:TaskStructures Transactional Task Non-Transactional Task 17 Enable Arc from Outside Internal Uncontrollable Transition Internal Controllable Transition

18 Theyareuncontrollable,otherwise. executing,abortedandcommitted.thetransitioni-eisuncontrollable.optionalenablearcsmay e-carecontrollableifthereareanyoptionalenablearcssincethetransitione-cwouldberejected. comeintotheabortedstatefromoutsidethetasktoforcethetasktoabort.transitionse-aand typesofcompoundtasks,transactionalcompoundtasksandnon-transactionalcompoundtasks. tasks)canonlycommunicatewitheachotherandthecompoundtask(parenttask).consequently, compoundtasksprovideamechanismforhierarchicallyorganizingaworkow.therearetwo Thetaskstructuresarethesameasthoseforsimpletasks(seeFigure9).Thebasictechniquesfor supportingtransactionalcompoundtasksare(i)two-phasecommitment,(ii)nestedtransactions Acompoundtaskorganizesacollectionofrelatedtasksintoagroup.Thesesubtasks(children [Mos82],and(iii)sagas[GMS87].Morecomplexstrategiesarepossible,butweignorethemfor brevity. allyallcommitorallabort.typically,aworkowmayinvolvesometransactionssupportedby taskstructureandacoordinatorthatcanenforcetwo-phasecommitinvolvingthemembersofa describethisfeature.wehavedesignedandimplementedatwo-phasecommit(2pc)coordinator DBMSswhichneedthe2PCfeature[KS95].Therefore,itisnecessarytoprovidethe2PCtaskto compoundtask.fordetailsonbothtaskstructuressee[wan95]. Two-PhaseCommit(2PC)isawell-knownprotocolallowingasetofparticipantstoeventu- 6CONCLUSIONS tralizedserver,thesebottlenecksmaynotbesignicant.wehaveimplemented,evaluatedand thecentralizedscheduler.however,ifanorganizationusesapowerfulmultiprocessorasacen- architecturesshouldenhancereliabilityandeliminatepotentialbottlenecksatthemachinerunning implementandmakesimulation,animationandmonitoringeasier[msk+95].themoredistributed areadvantagesanddisadvantagestoeach.thecentralizedarchitecturesaresomewhateasierto Inthispaper,wepresentedverun-timearchitecturesforaworkowmanagementsystem.There CPUrequirements,whiletheSynchronousCentralizedarchitectureissuperiorwhenCPUrequirementsfortaskmanagersaresubstantiallygreaterthantheCPUrequirementsfortasks.Wearenow intheprocessofimplementingtwomoreofthearchitecturesandplantocarryoutacomprehensive comparedthehighlycentralizedandsynchronouscentralizedarchitectures[msk+95].thislimitedstudysuggeststhatthehighlycentralizedarchitectureissuperiorwhentaskshaveheavier studycomparingtheperformanceandreliabilityofthesearchitectures. taskhasnoside-eects.thewfmsatpresentprovidesnodirectsupporttoenhancetransactional transactionaltasksinthecasethattheprocessingentity(e.g.,adbms)supportsthiscapabilityora Anotherneartermgoalistosupporttransactionalworkows.Ourcurrentprototypesallowfor 18

19 capabilitiesorprovideglobaltransactionalcapabilities.(note,oneexceptionisthatwedoprovide atwo-phasecommitcoordinatortofacilitatetransactionaltaskscommittingasagroup.)inour nextprototype,weplantoutilizethetransactionalcapabilitiesofcorba2.0objectservicesto achievethisgoalmorefully. serviceiseasy;simplyndtheobject(usingbind)andthencalltheremotemethodpassing clientstocommunicatewithserverssimplybyexecutingaremotemethodcall.invokingaremote alsoconsideredthesuitabilityofbuildingawfmsontopofcorba(specicallyorbeline,a communicationinfrastructuresarethefollowing:theobject-orientednatureofcorbaenables CORBA1.2implementation).ThemainadvantagesthatCORBAprovidesoverotherpossible Inadditiontoconsideringtheadvantagesanddisadvantagesofthevearchitectures,wehave wellasrununderdierentoperatingsystems).finally,theusualadvantagesofobject-oriented clientsandserverstousedierentlanguages,dierentmachines,dierenttypesofmachinesas machinenameorobjectname.oncefound,areferencetotheobjectmaybemaintained.theuseof awell-denedinterface(inidl)facilitatesdistribution,interoperabilityandheterogeneity(allowing therelevantparameters.objectsmaybefoundbasedupontheirinterfaceandoptionally,ahost programmingbroughtaboutbyencapsulationandinheritance,suchasprotection,information hiding,modularity,andcodereuse,werefoundtobeindeedvaluable.webelievethatcobra1.2 providesasolidfoundationforbuildingaworkowmanagementsystem. (WIDL)simplyaddsanenabledbyclausetoIDL.WebelievethatWIDLwouldbeusefulto meansforspecifyingworkows.thislanguagecalledworkowinterfacedenitionlanguage likewfslcanbecapturedinjustidl. thosealreadyfamiliarwithidl.italsoshowsthatmuchofthespecicationgiveninalanguage Inthispaper,wealsoproposedaminorextensiontoCORBA'sIDLtoprovideanalternative managementsystem. owmanagementsystems,particularlyonessupportingtransactionalworkows.corba2.0 providesseveralpowerfulobjectservices[omg95b]whichwouldbeusefulinbuildingaworkow NamingService.Thisserviceallowsnamestobeassignedtoobjects.Namesmustbe ThenewestCORBAstandard,2.0,isevenmoresuitableasanunderlyingtechnologyforWork- EventService.Eventscanbethoughtofasmessagessentbetweenclientsandservers. uniquewithinanamingcontext(analogoustolenameswithinadirectory).thisprovidesa PersistentObjectService.Thisserviceallowstheprivatedatawithinanobjecttobemade exiblewayforobjectstobelookedup. Theydierfromordinarymethodcallsinthatmethodcallsrequirebothclientandserverto berunning(oriftheserverisnotrunning,itwillbeactivated),whileeventsdonot. persistent,sothattheobjectmaintainsitsstateeveniftheprocesscontainingitterminates. 19

20 ConcurrencyControlService.Agenerallockingfacilityisprovidedtoallowmultiple LifeCycleService.Thisservicefacilitatesthecreation,destruction,movementandduplicationofobjects.Tocreatemultipleobjectsforacertaininterface,theusershouldwritea ExternalizationService.Thisservicepermitsasnapshotofanobject'sstatetobesaved bothtransactionalandnon-transactionalclients. clientstoaccessasharedserverobjectwithoutcorruptingitsstate.lockingmaybeusedby factoryinterfaceforit. inadatastream(e.g.,anasciile).itfacilitatessaving,displayingandcopyingobjects TransactionService.Thisservicecombinedwiththeconcurrencycontrolservicegreatly RelationshipService.Objects(orentities)canformrelationshipswithotherentityobjects. arerich,includingmuchofwhatisfoundinerandomtmodels. Relationshipsarestoredinrelationshipobjects.Therelationshipstructuresandconstraints (eventodierentorbs). reducestheamountofworkrequiredtoimplementawfmssupportingtransactionalwork- ows.bothatandnestedtransactionalmodelsaresupported. 20

21 References [AAA+95]G.Alonso,D.Agrawal,A.Abbadi,C.Mohan,M.Kamath,andR.Guenthoer.Exot- [AKA+95]G.Alonso,M.Kamath,D.Agrawal,A.Abbadi,C.Mohan,andR.Guenthoer.Exotica/FMDC:Handlingdisconnectedclientsinaworkowmanagementsystem.In S.Laufmann,S.Spaccapietra,andT.Yokoi,editors,Proc.ofthe3rdIntl.Conference ica/fmqm:apersistentmessage-basedarchitecturefordistributedworkowmanage- ment.inproc.oftheifipworkingconferenceoninformationsystemsdevelopment fordecentralizedorganizations,pages1{18,trondheim,norway,august1995. [ASSR93]P.Attie,M.Singh,A.Sheth,andM.Rusinkiewicz.Specifyingandenforcingintertask [ANRS92]M.Ansari,L.Ness,M.Rusinkiewicz,andA.Sheth.Usingexibletransactionstosupportmulti-systemtelecommunicationapplications.InProc.ofthe18thIntl.Conference oncooperativeinformationsystems,pages99{110,vienna,austria,may1995. [BDSS93]Y.Breitbart,A.Deacon,H.Schek,andA.Sheth.Mergingapplication-centricanddatacentricapproachestosupporttransaction-orientedmulti-systemworkows.SIGMOD dependencies.inproc.ofthe19thintl.conferenceonverylargedatabases,pages 134{145,Dublin,Ireland,1993. onverylargedatabases,pages65{76,august1992. [Bet95]M.Betz.OMG'sCORBA.Dr.Dobb'sJournal,9(16):8{13,March1995. [BMR94]D.Barbara,S.Mehrotra,andM.Rusinkiewicz.INCAs:Acomputationmodelfordynamicworkowsinautonomousdistributedenvironments.Technicalreport,University Record,22(3):23{30,September1993. [CR90]P.ChrysanthisandK.Ramamritham.ACTA:Aframeworkforspecifyingandreasoning [C+89]U.Chakravarthyetal.HiPAC:Aresearchprojectinactivetime-constraineddatabase Cambridge,MA,1989. management.technicalreportxait-89-02,xeroxadvancedinformationtechnology, ofhouston,may1994. [CR92]P.ChrysanthisandK.Ramamritham.ACTA:TheSAGAContinues,chapter10.MorganKaufman,SanMateo,CA, ManagementofData,pages194{203,AtlanticCity,NJ,1990. abouttransactionstructureandbehavior.inproc.ofacmsigmodconferenceon

22 [DHL91]U.Dayal,M.Hsu,andR.Ladin.Atransactionalmodelforlong-runningactivities.In [Eme90]E.A.Emerson.Temporalandmodellogic.InJ.VanLeeuwen,editor,Handbookof [Dui94]M.Duitshof.Workowautomationinthreeadministrativeorganizations.Master's thesis,universityoftwente,netherlands,july1994. Proc.ofthe17thIntl.ConferenceonVeryLargeDataBases,pages113{122,Barcelona, TheoreticalComputerScience,volumeB.Elselvier,Amsterdam,Netherlands,1990. Spain,September1991. [FKB95]A.Forst,E.Kuhn,andO.Bukhres.Generalpurposeworkowlanguages.Distributed [GH94]D.GeorgakopoulosandM.F.Hornick.Aframeworkforenforceablespecicationof andparalleldatabases,3(2):187{218,april1995. extendedtransactionmodelsandtransactionalworkows.internationaljournalof [GMS87]H.Garcia-MolinaandK.Salem.Sagas.InProc.ofACMSIGMODConferenceon [GHS95]D.Georgakopoulos,M.Hornick,andA.Sheth.Anoverviewofworkowmanagement: Databases,3(2):119{154,April1995. Fromprocessmodelingtoworkowautomationinfrastructure.DistributedandParallel IntelligentandCooperativeInformationSystems,3(3):599{617,1994. [GR93]J.GrayandA.Reuter.TransactionProcessing:ConceptsandTechniques.Morgan [HK95]M.HsuandC.Kleissner.ObjectFlow:Towardsaprocessmanagementinfrastructure. ManagementofData,pages249{259,SanFrancisco,CA,May1987. [J+95]J.Juopperietal.Usabilityofsomeworkowproductsinaninter-organizationalsetting. InProc.oftheIFIPWorkingConferenceonInformationSystemsDevelopmentfor Technicalreport,DigitalEquipmentCorporation,1995. KaufmannPublishers,SanMateo,CA,1993. [Kle91]J.Klein.Advancedruledriventransactionmanagement.InProc.oftheIEEECOM- [JAD+94]S.Joosten,G.Aussems,M.Duitshof,R.Humeijer,andE.Mulder.WA-12:An DecentralizedOrganizations,Trondheim,Norway,August1995. PCON,pages562{567,SanFrancisco,CA,1991.IEEEComputerSociety. EmpiricalStudyaboutthePracticeofWorkowManagement.UniversityofTwente, enschede,thenetherlands,july1994.researchmonograph. 22

23 [KRR95]G.Kappel,S.RauschSchott,andW.Retschitzegger.TriGSowactiveobject-oriented workowmanagement.technicalreport,departmentofcomputerscience,university [LA94]F.LeymannandW.Altenhuber.Managingbusinessprocessesasaninformationresource.IBMSystemsJournal,33(2):326{348,1994. [KS95]N.KrishnakumarandA.Sheth.Managingheterogeneousmulti-systemtaskstosupport enterprise-wideoperations.distributedandparalleldatabases,3(2):155{186,april oflinz,austria,1995. [M+95]C.Mohanetal.Exotica:Aprojectonadvancedtransactionmanagementandworkow [Mos82]J.Moss.Nestedtransactionsandreliabledistributedcomputing.InProc.oftheSecond systems.acmsigoisbulletin,16(1):45{50,august1995. [MSK+95]J.A.Miller,A.P.Sheth,K.J.Kochut,X.Wang,andA.Murugan.Simulationmodelingwithinworkowtechnology.InProc.ofthe1995WinterSimulationConference, Arlington,VA,December1995. SymposiumonReliabilityinDistributedSoftwareandDatabaseSystems,pages33{39, [Mur95]A.Murugan.Graphicalworkowdesigner.Master'sthesis,UniversityofGeorgia,1995. Pittsburgh,PA,July1982. [OMG93]OMG.Thecommonobjectrequestbroker:Architectureandspecication.Technical [OMG95a]OMG.Thecommonobjectrequestbroker:Architectureandspecication,revision2.0. (inpreparation). [OMG95b]OMG.CORBAservices:Commonobjectservicesspecication.Technicalreport,Object ManagementGroup,March1995. Technicalreport,ObjectManagementGroup,July1995. report,objectmanagementgroup,december1993. [RS95a]A.ReuterandF.Schwenkreis.Contracts-alow-levelmechanismforbuildinggeneralpurposeworkowmanagementsystems.IEEEDataEngineeringBulletin,18(1),1995. [RS95b]M.RusinkiewiczandA.Sheth.Specicationandexecutionoftransactionalworkows. [Rei94]B.Reinwald.Tutorialnotesonworkow-management.Technicalreport,IBM,Almaden, August1994.presentedatthe13thIFIPWorldComputerCongress. Beyond,pages592{620.ACMPress,NewYork,NY,1995. InW.Kim,editor,ModernDatabaseSystems:TheObjectModel,Interoperabilityand 23

24 [SR93]A.ShethandM.Rusinkiewicz.Ontransacationalworkows.IEEEDataEngineering [She95]A.Sheth.Tutorialnotesonworkowautomation:Application,technologyandresearch. [Smi93]T.Smith.Thefutureofworkowsoftware.INFORM,pages50{51,April1993. Technicalreport,UniversityofGeorgia,May1995.presentedatACMSIGMOD,San Jose,CA, [Str91]B.Stroustrup.TheC++ProgrammingLanguage.Addison-Wesley,Reading,MA, Bulletin,16(2):1{4,June1993. [Wan95]X.Wang.ImplementationandperformanceevaluationofCORBA-basedcentralized [TV95]J.TangandJ.Veijalainen.Enforcinginter-taskdependenciesintransactionalwork- secondedition,1991. [WF94]T.WhiteandL.Fischer.TheWorkowParadigm-TheImpactofInformationTechnologyonBusinessProcessReengineering.FutureStrategies,Inc.,Alameda,CA,1994. workowschedulers.master'sthesis,universityofgeorgia,august1995. ows.technicalreportj-2/95,vttinformationtechnology,espoo,finland,january 24