A MODULAR EVENT-BASED ARCHITECTURE FOR WORKFLOW SYSTEMS

Mehran Najafi and Kamran SartipiDepartment of Computing and Software, McMaster University, Canada

{najafm, Sartipi}@mcmaster.ca

ABSTRACTReal life work processes are dynamic and much richer invariation to be expressed by typical static workflowmodels. Two conflicting goals to be addressed include:flexibility to handle changing situations, and simplicity todesign workflows that can be understood andimplemented efficiently. This paper addresses these twoissues by introducing a novel architecture for workflowsystems. In this architecture, a workflow is defined interms of modules and templates. Modularity providessimplicity and reusability for a workflow system. In ourapproach, problem independent modules are adopted for aspecial workflow system by placing them in problemdependent templates. Also different users in the systemcan interact with the workflow to make appropriatechanges via events. Modules and templates have theirown event handlers that allow them to be modified basedon changes in user requests or situations. We illustratethese features in our architecture using two case studies,one in healthcare domain and another in a bankingsystem.

KEY WORDSModelling; Flexible Workflow; Event-based Architecture;Modular Architecture; Intelligent Workflow.

1. IntroductionA workflow is a set of ordered steps consisting of tasks,data and resources (human or machine) in order toachieve a goal [1]. A workflow management system(WFMS) is a system that defines, creates and manages theexecution of workflows on one or more workflow engines[2]. The system is able to interpret the process definition,interact with workflow participants and, where required,invoke the use of other applications.Workflows in a WFMS can be subject to change due todifferent reasons, such as unforeseen errors, faults andfailures, new development, or administrative decisions(e.g., process optimization, incorporation of newresources, and modification of existing product lines).These reasons may cause different types of workflowchanges, such as addition of a new task, deletion of anexisting task, and modification in order of tasks.Workflow systems need mechanisms to make themflexible and deal with those deviations.In a small system, it is reasonable to show a workflow bya dataflow diagram of single tasks. However, in a morecomplex system, modeling workflow by using onlydataflow constructs can quickly lead to overly complex

workflows that are hard to understand, reuse, reconfigure,maintain, and schedule. Modularization is a softwaredesign technique that divides a large system into anumber of smaller and manageable parts, namely modules[3], [4]. Each module is designed individually wheredifferent modules can be combined to form a largermodule. One of the most advantages of modularization isits reusability.In this paper, reusability and flexibility in workflowsystems are the main objectives. We address reusabilityby introducing modules and workflow templates.Modules are problem independent and can be used indifferent types of workflows. On the other hand,workflow templates are designed for individual processesand contain customized modules. In our architecture, weuse events and event handlers to provide flexibility anddynamism for the workflows. Event handlers of modulesand workflow templates are triggered by events and canmake changes in the order or content of steps in aworkflow.Also, we introduce a consistency checking mechanismthat prevents any changes that may invalidate theworkflow. This consistency checking would become veryimportant when we allow the users to design events andevent handlers.The organization of this paper is as follows. Related workis discussed in Section 2. The proposed architecture andits details are discussed in Section 3. Two case studies inthe healthcare domain and banking system are explainedin Section 4. Finally, the conclusion and future work arediscussed in Section 5.

2. Related workCurrent research in workflow systems concentratesprimarily on making the workflows flexible with respectto the changes in processes.The dynamism in workflows has been studied usingexception handling techniques [9], [10] and [11]. In theseapproaches a workflow is designed in a regular style andany changes in a workflow system, presumed or un-presumed, is considered as an exception and is handled byusing one of the exception handling methodologies. Themain difference between our proposed architecture andthese approaches in the case of change handling, can beaddressed by differences between “events” and“exceptions”. An exception is usually raised to signalexceptional situations like errors and failures, while in anevent based system we concentrate on interaction betweenusers and systems in all situations. In other words, our

event based architecture receives all possible and relatedevents from the users, and the system evolves accordinglyas the process progresses. Our architecture supportsexceptions as a special type of events.A mathematical model for dynamic structural changealgorithm in workflow systems is introduced in [8]. In thismethod changes are divided into two categories: changingthe structure of the workflow procedures, and changingthe workflow in the middle of executing procedures. Thismodel seems to have scalability problem and hence wouldnot be applicable for complex workflows.Dividing a workflow into independent parts (namelycomponents) to make it easy to understand and reuse, hasgained more attention recently. In [13] the problem ofcombining dataflow and control-flow is addressed forscientific workflows. Generic behavioral specifications(i.e., controlflow) in workflows are encapsulated intemplates. Templates are separate components and thuscan be easily reused in other workflows. Also templatescan contain subcomponents. The notion of template inthis approach is different from our definition of template.We consider two types of components: problemindependent component as module and problemdependent component as workflow template. Workflowtemplates are designed for specific organizationalactivities while modules are reusable in differentworkflows.Due to the variety of changes that can be applied on aworkflow, correctness and verification of workflows arecrucial. During the changes, a workflow must not enter anincorrect state after a predicated or unpredicted change. In[9] a foundation set of constraints for flexible workflowspecifications are developed. The authors claimed that theconstraints should optimally balance the flexibility andcontrol requirements. However, this method and othermethods that attempt to find process model for workflows[10] have introduced overheads since they need to importall modified nodes in the workflow. In our architecture,by equipping each module with simple constraints, theworkflow will be guaranteed to be valid after authorizedchanges.In the proposed architecture that will be discussed in thenext section, we model each workflow based on itsrelevant events. Combination of events andmodularization provides flexibility, reusability andconsistency in workflows.

3. Proposed ArchitectureIn this section, we present an overview of our proposedarchitecture with focus on the relevant issues and thedynamism of modules and templates. Further, we discussevents and event handlers and different types ofconstraints in the architecture. Finally, we elaborate onworkflow consistency.

3.1 Architecture OverviewFigure 1 illustrates different parts of the proposedworkflow architecture.

• A workf low represents a set of modules withpredefined orders among them. A workflow ismodeled by a workflow template that is a collectionof customized modules for a specific organizationaloperation. A workflow template (or simply atemplate) also establishes data flow and control flowconnections among the template's modules.

• A module is a container for a set of tasks whose orderof executions can be changed by receiving events.Modules are designed individually and aremaintained in the module repository containing a setof reusable modules. A module can be placed eitherin a template as a part of the current workflowsolution, or in a module repository to be reused. Eachmodule has a collection of shared data that maintainthe state of the module.

• An event is any information that is provided by theenvironment (user or system) and can change thecurrent workflow solution.

• An event handler is a program that receives eventsfrom the environment and modifies the current tasks(or modules) within a module (or template) byconsulting the state of the module (or template)accordingly. In general, a module or templatecontains several event handlers. An event tablepresents the relevant events in the architecture alongwith their corresponding event handlers.

• A task is an atomic entity that represents anindivisible functionality that is performed within amodule. A task can have optional constraints in termsof pre-conditions, post-conditions, and invariants onits operation. The execution of a task may change thestate of the module through module's shared data.This state is used by the event handlers to makechanges in the execution order or the number of themodule tasks.

A template uses its event handlers to customize itsmodules or import new modules from the repository touse for the modified workflow solution, provided that theimported modules preserve the template or module'sconsistencies. Similarly, the deleted modules from thetemplate are returned back into the repository. TheWFMS uses the event handlers of the modules andtemplate to generate a flexible workflow. The operationsof the WFMS for this architecture are as follows.• Initialize the workflow template by using a number

of modules in a predefined order (according to thedefault or general case of the workflow.)

• Receive events through interaction with the users andthe environment.

• Change the current workflow by adding, removing,or reordering the modules in the template, using thetemplate event handlers.

• If some changes are needed within a module, thetemplate transfers the event to the proper module,where the module event handlers make appropriatechanges on the internal workflow of the module. Themodule event handler can add or remove a task in amodule, as well as reorder the tasks.

Figure 1: Different parts of the proposed event-based workflow architecture.

The major difference between event handlerscorresponding to a module and to a template is the levelof abstraction, where the former deals with details of anoperation, and the latter adds or deletes major businessfunctionality.

3.2 Workflow dynamic behaviorA template acts as a coordinator for the workflowmodules by importing, re-ordering, and deleting modulesfrom the workflow. Consequently, it provides flexibilityand dynamism for the generated workflow. The workflowevolves through receiving events and adjusting itself tosatisfy the requested operation by the events. This isachieved through a set of constrains for modules and tasksthat allow the WFMS to modify the workflow ingredientsand to keep the workflow consistency. These constraintsare as follows.1. Precondition: conditions that must be met before

execution of a module or task.2. Postcondition: conditions that are guaranteed to be

met after the execution of a module or task.3. Invariant: constraints that control the correct

execution of a module or task.

Figure 2: Constraints for tasks and modules.

A sequence of modules in a template (or tasks in amodule) is called valid, if it preserves the constraints thatare defined for each module (or task) based on theirspecification. Figure 2 presents the above constraints in amodule. The case studies in Section 4 provide exampleson the use of constraints.Events are generated by the environment in the form ofspecific information. These events trigger the module (ortemplate) event handlers, where the event handlers decide

whether the required action should change the order of themodules within the template (i.e., high-levelmodification) or change the order of tasks within amodule (i.e., low-level modification). In the first case, theevent is consumed by the template event handler, whereasin the second case the event is forwarded to thecorresponding module event handler to react upon it. Thetemplate events are categorized into two types:• Specific transaction, where the transaction (as event)

refers to a valid and high-level operation in thecorresponding business process, e.g., a specificmortgage package request in a banking system.

• Module - l eve l , which will be directed to thecorresponding module as defined below.

Similarly, the module events are categorized into threetypes:• User interaction, represents the general case where a

user intends to change the workflow based on theirchoices and preferences. For example, when a patientcould choose between a daily tablets and twomonthly injections.

• Exception, in the form of unexpected input data to amodule that causes the corresponding event handlerto change the module workflow and use specifictasks to handle the situation. For example, when apatient gets sick by another type of disease in thecourse of treatment for his/her current disease.

• Reflexive task, refers to the event that is caused by theenvironment's reaction to the result of a taskexecution. For example, in the task of prescribing amedicine by a physician, each side effect of themedicine is considered as a reflexive event where theassigned event handler catches the event andmodifies the treatment workflow.

In the proposed architecture most of events are of type‘user interaction’ and hence they are suitable for domainsthat many factors can change the general workflow (e.g.,healthcare domain as it is a dynamic environment).The dynamic behavior of the proposed workflowmechanism is modeled in the form of ``event [condition]/ action'' which allows the workflow to change its stateand evolve. In Figure 3 ``event'' is a template event or a

module event, as defined above. A condition is modeledas ``pre condition”, ``post condition” or ``invariants” andis evaluated by comparing the state of the module (ortask) before and after the modification by the eventhandler.

Figure 3: Event handling in the proposed architecture.

The action is the modification of the workflow thatconforms with the module or task's constraints. In otherwords, if the condition is true, the change is accepted andworkflow evolves to the new state, otherwise the changeis ignored and the workflow remains in its current state.The possible changes to a workflow according to a``template event” are as follows:• Adding a module to the workflow from the repository

of the reusable modules.• Removing a module from the workflow (a copy of the

module still exists in the repository).• Changing the module interconnections (dataflow and

control flow) with other modules in the workflow.• Delivering the module events to the proper modules

so that they can modify themselves accordingly.Similarly, the possible changes to a module according to a``module event” are as follows: i) introducing a new taskto the module or deleting an existing task; ii) changing theexecution order of tasks; iii) changing the description oftasks, and; iv) sending events to the workflow template torequest modifications in other modules.

3.4 Consistency in the architectureIt is important to ensure a workflow remains valid after achange. Consistency for this architecture is defined as thecorrect positions of reusable modules in the template aswell as preserving the main goals of the workflowthrough modifications. In this architecture, we confinechanges in workflow to modifications that are done byevent handlers. Each event handling is defined in terms ofconditions and actions; i.e., if the condition is true for amodification it will be performed. For each type ofpossible modification, we define specific conditions.These conditions are in terms of architectural constraintsin order to preserve the workflow consistency.Consistency checking consists of data flow and controlflow checking for templates and modules. Data flowrepresents the flow of data in the workflow and if theconnections between modules and template are completedata flow consistency is satisfied (i.e., other modules orthe template provide all modules’ input data). If a part ofinput data for a module is eliminated by a modification(i.e., delete or change order) the event handler mustprovide its input via other sources in the template.We assume workflow constraints are true before applyingany changes; also adding reusable modules to an emptytemplate can generate an initial workflow.

Control flow consistency checking follows the data flowconsistency checking. Control flow conditions fortemplates that include adding a new module, deleting amodule and changing the order between modules areillustrated in Figure 4. Sending and receiving events donot change the structure of workflow and because theworkflow is valid before this action, the workflow will bevalid after it too. Hence, no consistency checking isrequired. Control flow consistency checking within themodules (i.e., adding, removing, and changing theexecution orders of tasks) are similar to those discussedfor the workflow template. As a general rule, the moduleinvariant must be satisfied after any changes.

4. Case studiesIn this section, we present the application of our proposedapproach on modeling two cases of healthcare andbanking domains. Also some advantages of ourarchitecture in comparison with previous ones arediscussed in this section.

4.1 Case study 1: healthcare domainThe healthcare domain is an active area for developingand using workflows [6], [7]. A simple workflow fortreatment of a muscle disease is shown in Figure 5 (top).This treatment consists of two parts: Step 1: diagnosisand drug prescription, in which the physician prescribesdrug X for the patient. Step 2: physiotherapy exercises, asthe follow up treatment after treatment 1. Each of thesetwo treatments can be considered as a separate module.Their module specifications are illustrated in Table 1.Also, each task may have its own constraints. An exampleof task pre-condition is shown in the second task of thephysiotherapy treatment. In Table 1, a number that isassigned to each event handler identifies theircorresponding event.The nature of each treatment imposes some obligations orconsiderations. For example, most drug prescriptions (i.e.,task execution) have side effects on the patients and hencethe physician may decide to change the treatment methodby prescribing a different drug without those side effects.

Workflow consistency checking: According to Table 1some of these consistency issues are as following:• Since the pre-condition of module ``treatment by

physiotherapy” is satisfied by post-condition ofmodule ``treatment by drug X”, this combination isconsistent.

• In module ``treatment by drug X” the event handlerEH1 for event ``fever” is consistent if the dose ofdrug X prescribed by physician is between theLOWER and UPPER limits and also the ``newprescribed duration for drug X” is according to thepair (duration-of-applying-X, dose-D) in one of thetasks, otherwise this change will not be applied onthe workflow.

Figure 4: Control flow constraints for workflow template

• For event ``strong headache” and its event handlerEH2, because the pre-conditions of module CT-scanare satisfied, this module can be added to theworkflow. Figure 5 (bottom) illustrates thismodification.

• In module ``treatment by physiotherapy” the eventhandler EH1 for event ``high heartbeat rate” isconsistent, because it decreases the time of vigorousworkout and increases the time of the moderateworkout, which is according to the moduleinvariant.

Therefore, each modification in the workflow isconsistent and the workflow remains consistent and valid.

4.2 Case study 2: banking domainIn the previous case study, we focused on “satisfyingconstraints” and the mechanism of applying changes onthe workflow in order to keep it consistent. However, inthe current case study, we present how templates andmodules can collaborate through using events and event

handlers, in the context of a complete workflow for thebanking domain.This workflow describes the process for applying,receiving and paying back of a house mortgage. Therelevant modules to this workflow are defined in Table 2.These modules are general and can be used in anyworkflows in this domain or other domains. The templatefor this workflow is shown in Figure 6.

4.3 Advantageous of the proposed architectureAlthough these two case studies can be modeled withother approaches, but the proposed architecture seems tobe more appropriate. Some of its advantages are:1) Where several factors exist that can change a workflow(e.g., healthcare domain), flexibility is inevitable. Designof a static workflow and apply possible changes throughexceptions [5] can be one alternative to our architecture;but in the case of a large number of changing factors,(e.g., in a surgery operation) a lot of added exceptionscomplicate the workflow and reduce its understandability.

Table 1: Module specification for two treatment methodsModule name: Treatment by drug X Module name: Treatment by physiotherapyPre condition:

• Physician diagnoses diseases A or B or C for the patientTasks:

1. Prescribe drug X with dose D1 for N1 weeks (or)2. Prescribe drug X with dose D2 for N2 weeks (or)3. Prescribe drug X with dose D3 for N3 weeks

Post condition:• The patient must not have pain in muscles

Module invariants:• LOWER LIMIT < dose of X< UPPER LIMIT• The pair (duration-of-applying-X, dose-D) must match with one of

the pairs defined in Tasks 1 to 3.Events:

• Each side effect of drug X is considered as an event:o E1: fevero E2: strong headache

Event Handlers:• EH1: weaken the dose of X and increase the duration of using it in

the current task• EH2: ask for a CT-Scan via adding its module into the template

Pre condition:• The patient must not have pain in muscles

Tasks:1. Moderate workout for M1 minutes2. [Pre: the moderate step must be done] Vigorous workout for M2 minutes

Post condition:• Null

Module Invariant:• The duration of vigorous workout must be less than the moderate

workoutEvent:

• E1: high heartbeat rateEvent Handler:

• EH1: change the remaining time of the current vigorous workout to themoderate workout

Also some situations impose major modifications in aworkflow (e.g., addition a new module in the first casestudy) according to definitions and applications ofexception and event, the latter seems to be morereasonable.2) In domains such as banking, where there are severaldependent and independent workflows, the benefit ofmodularization is clear. These modules, as parts of aworkflow, need a mechanism for interaction. Sending andreceiving events under supervision of a workflowtemplate that customizes independent modules andconsiders a workflow as a whole body, can improvetraditional methods such as [13], which allow independentmodules to communicate without any specific manager.3) In the case of consistency checking, defining properconstraints for each task and module is simpler thandealing with complex equations, which describe thewhole process model, as defined in [9].

5. Conclusions and Future WorkIn this paper, we presented a new architecture forworkflow evolution. The architecture takes advantage ofthe modularity concept in terms of modules and templatesthat generate reusable and understandable workflows.Also, it provides dynamism and flexibility in workflowsystems by employing a mechanism based on event andevent handling. In some cases, designing a completeworkflow, which provides solutions for all possibleoperations, is almost impossible. With this architecture, apartial workflow is designed as a template, and the user isallowed to define and add new events, event handlers, andmodules to the workflow as long as the WFMS canapprove the consistency of the workflow after eachmodification. The future expansion of this architecturewould provide an intelligent WFMS that predicts nextstates and possible events for each instance of theworkflow in the execution time.

References[1] W. Aalst & K. Hee, Workflow managment: models,methods, and systems: cooperative information systems,(The MIT Press, 2004).

Figure 5: Initial and modified workflow templatefor the treatment in case study 1.

[2] A. Cichocki, A. Helal, M. Rusinkiewicz, & D. Woelk,Workflow and process automation: concepts andtechnology (Kluwer Academic Publishers, 1997).[3] M. Aquin, M. Sabou, & E. Motta, Modularization: akey for the dynamic selection of relevant knowledgecomponents, ISWC 2006, Georgia, USA, 2006, 289-314.[4] L. Cardelli, Program fragments, linking, andmodularization, Symposium on Principles ofprogramming languages, Paris, France,1997, 266–277.[5] Z. Luo, A. Sheth, K. Kochut, & J. Miller. Exceptionhandling in workflow systems, Applied Intelligence, 13(2), 2000, 125-147.[6] N. Krishnakumars & A. Sheth. Managingheterogeneous multi-system tasks to support enterprise-wide operations, Journal of Distributed and ParallelDatabase Systems, 3(2), 1995, 155-186.[7] J. Eder & W. Liebhart, Contributions to exceptionhandling in workflow systems, EDBT Workshop,Valencia, Spain, 1998, 399-412.[8] W. Aalst, Generic workflow models: how to handledynamic change and capture management information,IECIS, Washington, USA, 1999, 115–126[9] S. Sadiq, M. Orlowska, & W. Sadiq. Specification andvalidation of process constraints for flexible workflows,Information Systems, 30 (5), 2005, 349–378.[10] P. Mangan & S. Sadiq. On building workflowmodels for flexible processes, Australian ComputerScience Communications, 5,2002, 103–109.

• Figure 6: Different parts of the proposed architecture for house mortgage

Table 2: Module specification for reusable modules in the banking domainModule name : Customer qualifying Module name: Indicate Customer's Monthly Income (ICMI)Pre condition :

• TrueTasks:

• Check customer creditPost condition:

• The result of the qualification checking.

Pre condition :• True

Tasks:• Add all customer's salaries for his/her part time and full time jobs

Post condition:• The customer's monthly income is determined.

Module name : Compute the Affordable Monthly Mortgage (AMM) Module name: Payment Process

Pre condition :• The customer's monthly income is determined.

Tasks:1) Multiply customer's gross income by C=0.28.2) [Pre: Task 1] Subtract the monthly debt payments.3) [Pre: Task 1] Subtract the monthly cost for property taxes and homeowners insurance

Post condition:• AMM is determined

Module invariants:• C must be less than 0.36

Events:• E1: The customer has other debt.

Event Handlers:• EH1: Set C=C+0.02 and start from Task 1.

Pre condition :• Down payment was determined• Monthly payment was determined• Interest rate was determined

Shared data:• Remaining loan

Tasks:• Reduce the paid amount by customer from the remaining loan variable.

Post condition:• The loan is repaid

Events:• E1: Customer does not pay any amount.• E2: Customer pays less than the monthly payment.• E3: Customer pays more than the monthly payment.

Event Handlers:• EH1: According to the bank policy (E.g., increase the interest rate)• EH2: According to the bank policy• EH3: According to the bank policy

Module name: Home Evaluation Module name: Choose a Mortgage Payment PlanPre condition :

• TrueTasks:

1) Evaluate the location2) Evaluate the condition3) [Pre: task 1 and 2] Evaluate the value

Post condition:• The actual value of the house is determined.

Pre condition :• Down payment was determined.• AMM was determined.

Tasks:1) Determine loan duration.2) [Pre: Task 1] Determine the annual interest rate.3) [Pre: Task 2] Determine the monthly payment.

Post condition:• Monthly payment is determined.

Module invariants:• Monthly payment must be less than AMM.

Module name: Foreclose a house process Module name: Set a Down PaymentPre condition :

• The customer has not paid the payment for N months.Shared data:

• NTasks:

• According to the bank policy.Events:

• E1: The same customer wants to buy the house from the bank again.Event Handlers:

• EH1: According to the bank policy

Pre condition :• The customer was qualified.• The loan request amount was determined.

Tasks:• The customer suggests an amount A.

Post condition:• Down payment amount is determined.

Module invariants:• A must be larger than 5 percent.

Events:• E1: A is less than 20 percent.

Event Handlers:• EH1: Ask for private mortgage insurance.

[11] K. Hee, H. Schonenberg, A. Serebrenik, N. Sidorova,& J. Werf. Lecture notes in computer science: adaptiveworkflows for healthcare information systems, (SpringerBerlin / Heidelberg, 2008).[12] H. Fu-Shiung. Context-aware workflow drivenresource allocation for e-healthcare, International

conference on e-Health networking, application andservices, Taipei, Taiwan, 2007, 34–39.[13] S. Bowers, B. Ludascher, A. Ngu, & T. Critchlow.Enabling scientific workflow reuse through structuredcomposition of dataflow and control-flow. 22nd ICDEworkshop, Washington DC, USA, 2006, 70–83.