UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A goal oriented and decentrally controlled workflow model for facilitating exception handling Guo, Huijin 2002

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2002-0412.pdf [ 4.62MB ]
JSON: 831-1.0090472.json
JSON-LD: 831-1.0090472-ld.json
RDF/XML (Pretty): 831-1.0090472-rdf.xml
RDF/JSON: 831-1.0090472-rdf.json
Turtle: 831-1.0090472-turtle.txt
N-Triples: 831-1.0090472-rdf-ntriples.txt
Original Record: 831-1.0090472-source.json
Full Text

Full Text

A Goal Oriented and Decentrally Controlled Workflow Model for Facilitating Exception Handling by Huijin Guo B. Econ., Zhejiang University, 1992 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN BUSINESS ADMINISTRATION IN THE F A C U L T Y OF G R A D U A T E STUDIES (Faculty of Commerce and Business Administration) . We accept this thesis as conforming to the required standard  THE: UNIVERSITY OF BRITISH COLUMBIA September 2002 . ©Huijin Guo,: 2002  ;  .....  In  presenting  degree  at  this  the  thesis  in  partial  fulfilment  of  University  of  British  Columbia,  I agree  freely available for copying  of  department publication  this or of  reference  thesis by  this  for  his thesis  and study. scholarly  or for  her  Department  of  The University of British Vancouver, Canada  Date  DE-6 (2/88)  is-  y  Columbia  'y]  purposes  gain  shall  requirements that  agree  may  representatives.  financial  permission.  I further  the  It not  be is  that  the  Library  permission  granted  by  understood be  for  allowed  an  advanced  shall for  the that  without  make  it  extensive  head  of  my  copying  or  my  written  Abstract More and more organizations are starting to use workflow management systems (WfMS) to monitor, control and manage business processes. However, currently available commercial workflow systems are rather rigid and cannot meet the requirements  of a dynamic and fast-changing  business.  Exception handling  capabilities of the systems are very limited. Some research work has been done to address the issue by extending database technologies in workflow domain. In this thesis, we begin with a brief review of some main workflow concepts and do a survey of current research work on exception handling. We propose a leveled workflow model based on Micro-Organization Activity Processor (MOAP) and Object-Oriented Workflow Model (OOWM), which is an extension of Object-Oriented Enterprise Modeling (OOEM). The M O A P construct is extended with a goal concept and the O O E M service concept. We then propose a mechanism for exception handling which utilizes artificial intelligence technologies such as means-end analysis. We further demonstrate the functionalities and exception handling processes with a web-based simulator by applying some workflow exception cases.  ii  Table of Contents Abstract  ii  Table of Contents  iii  List of Tables  vi  List of Figures  vii  Acknowledgments  i  1  1  Introduction  x  1.1  Motivation  1  1.2  Thesis Objectives  2  1.3  Thesis Outline  3  2  Workflow Management System  5  2.1  Workflow and Related Concepts  5  2.2  Workflow Management Systems  8  2.3  Challenges and Limitations  3  10  Workflow Exceptions and Related Research Work 3.1  Exceptions in Workflow  12 12  3.1.1  Exception Scope: Schema and Instance  12  3.1.2  Exception Level: Expected and Unexpected  13  3.1.3  Level of Abstraction: Domain, Process, Resource and Infrastructure. 14  3.2  Scope of Exception in this Thesis  15  3.3  Survey of Related Research Work  16  3.3.1  The Workflow Activity Model  16  3.3.2  OPERA Process Support System  19  3.3.3  ADOME-WFMS  21  3.3.4  CapBasED-AMS  24  3.3.5  Adaptive Workflow  26  3.4  Summary of Survey  27  3.5  Different Views of Workflow  30  3.6  Micro-Organization Activity Processor (MOAP)  32  iii  3.6.1  The Structure of M O A P  32  3.6.2  Applicability of MOAP in workflow systems  33  3.6.3  Comparison of M O A P and A D E P T agents  34  3.7  Objected-Oriented Workflow Model (OOWM)  37  3.8  Summary  40  4  MOAP-Based Workflow Model 4.1  41  Modified M O A P Architecture  41  4.1.1  Overview  41  4.1.2  Goal  43  Representation of Goal  44  4.1.3  Service  47  4.1.4  Procedural Knowledge  49  Tasks  49  Pre-Set of Sub-Goals  50  Pre-Conditions of Goals  51  M O A P selection  52  4.1.5  Problem-Solving Knowledge  52  Goal Decomposition  53  Problem-Solving Tasks  53  Business Rules  54  4.1.6 4.2  From O O W M Object to M O A P MOAP-based Workflow Model  55 56  4.2.1  Overview  56  4.2.2  MOAP-based Workflow Model  57  Controller M O A P  59  Leveled Hierarchy  61  4.3 5  Summary  62  Handling Exceptions in a MOAP-based Workflow System 5.1 5.1.1  The Execution Mechanism  63 64  The Controller and Execution Schema  iv  64  5.1.2 5.2  MOAP-Based Workflow Example  67  The Mechanism of Exception Handling  72  5.2.1  Overview  72  Goal-Oriented Reasoning  74  OASIS Blackboard  75  5.2.2  The Logical Steps  76  5.2.3  Comparison of ADOME-WfMS and M O A P - W f  83  Comparison of Normal Processes  83  Comparison of Exception Handling  87  Summary of Differences  90  5.3 6  Summary  91  Simulation of MOAP-Wf.  92  6.1  Development Platform  92  6.2  System Design  93  6.2.1  Database Design  94  6.2.2  Functional Modules  95  6.3  Simulation of MOAP-Wf.  6.4  Summary  7  96 106  Conclusion and Future Research  107  7.1  Conclusion  107  7.2  Contributions  109  7.3  Limitations and Future Research  110  REFERENCE  112  Appendix A - FlexFlow  117  Appendix B - Control Flow of M O A P - W f Simulator Functional Modules  120  Appendix C - Page Transition Diagram of M O A P - W f Simulator  121  v  List of Tables Table 3-1 Category of Exception Handling Approach  29  Table 3-2 Object Activity Template (adapted from (Hui 1997))  39  Table 5-1 Controller M O A P - Purchasing Process  69  Table 5-2 M O A P - Purchasing Dept  70  Table 5-3 Exception Handling Example in A D O M E - W F M S  87  Table 5-4 Comparison of A D O M E - W F M S and MOAP-Wf.  90  Table 6-1 Simulator Functional Modules  95  vi  List of Figures Figure 2-1 Workflow Terminology (adapted from WfMC (1999))  6  Figure 2-2 WfMC's Workflow Reference Model (adapted from (WfMC 1995))  9  Figure 3-1: Event-State for Activities (adapted from (Eder and Liebhart 1995))  18  Figure 3-2: Control Flow of Exception Handling in OPERA (adapted from (Hagen and Alonso 1998))  20  Figure 3-3: Architecture of CapBasED-AMS (adapted from (Karlapalem et al 1995))  24  Figure 3-4 Synthesized Adaptive Workflow Approach (adapted from (Han et al 1998))  26  Figure 3-5 Micro-Organization Activity Processor (adopted from (Woo and Lochovsky 1991))  32  Figure 3-6 A D E P T Agent Architecture (adapted from (Jennings et al 1998))  35  Figure 3-7 Object-Oriented Workflow Model (adapted from (Hui 1997))  38  Figure 4-1: Modified Micro-Organization Activity Processor (adapted from (Woo and Lochovsky 1991) with modifications)  42  Figure 4-2 Goal Tree Diagram  46  Figure 4-3 Goal for Purchase Process  47  Figure 4-4: 0 0 W M Object vs. Modified M O A P  56  Figure 4-5: A MOAP-Based Workflow Model  58  Figure 4-6: An Example of Business Views  59  Figure 5-1: Execution Mechanism of M O A P - W f  66  Figure 5-2 M O A P - W f Structure for Purchasing Process  68  Figure 5-3: Overview of Exception Handling Mechanism  73  vii  Figure 5-4 Goal-Oriented Process  75  Figure 5-5 M O A P - W f Execution/Exception Handling Diagram  78  Figure 5-6 A D O M E - W F M S activity model example  84  Figure 5-7 A Purchase Process in MOAP-Wf.  85  Figure 5-8 Handling 'BudgetExceeded' Exception in MOAP-Wf.  88  Figure 5-9 Handling 'Payment Terms Change' Exception in M O A P - W f  89  Figure 6-1 Entity-Relationship Diagram  94  Figure 6-2 Example Code of Evalution Module  96  Figure 6-3 Simulation - Creating New Process  97  Figure 6-4 Simulation - ControllerMOAP Goal Decomposition  98  Figure 6-5 Simulation - Task Execution  99  Figure 6-6 Simulation - Tasks by DeptManager  100  Figure 6-7 Simulation - Request Sent to Another Capable M O A P  101  Figure 6-8 Simulation - Next Goal of Controller M O A P  102  Figure 6-9 Simulation - Service Failure  103  Figure 6-10 Simulation - New Subgoal of PurchasingDept  104  Figure 6-11 Simulation - Completion of Purchasing Process  105  Figure 6-12 Simulation - Evaluated Failure (Controller MOAP)  106  Figure 7-1 FlexFlow State Diagram  117  viii  Acknowledgments First of all, I am very grateful to my thesis supervisor Dr. Carson Woo. Without his research guidance, encouragement and support, this thesis would not have been possible. I also wish to express my gratitude to Dr. Yair Wand and Dr. Jacob Steif for being my thesis committee members and for their insightful input and advice. I also thank Gary Schmidt for his excellent editing and Leon Qiu for fruitful discussion on programming. Last but not least, I would like to thank all my fellow Master's students for their support.  ix  1  Introduction  1.1 Motivation In recent years, workflow management systems have been one of the mostspotlighted subjects for both the software industry and the research community. For the industry, there are more than 200 workflow products commercially available (WfMC, 1997). Vendors vary from small and mid-sized companies to big names such as IBM (IBM, 2002), Oracle (Oracle, 2002), SAP (SAP, 2002), and HP (HP, 2002). For the research community, there are also a number of projects and research work on workflow specification and verification, transactional workflows and extensions of ideas from active database management to workflow management (Mohan, 1997). The focus on business process reengineering as a cost saving and service improvement measure has been instrumental in this recent interest in workflow management systems (Mohan, 1997). As an information technology tool to automate, control and coordinate business processes, workflow management systems help companies to streamline processes, reduce process time, and improve business planning. Despite their popularity in the industry, current workflow systems might be hindered from playing a more effective role in business process re-engineering due to the systems' rigid designs, which were optimized for fixed and repetitive processes. The rigidity remains a problem in the context where people and organizations have to evolve constantly in a changing environment (Kappel et al., 2000). Because of the  1  dynamic and ever-changing nature of business, a process description can rarely capture all possibilities of what will occur. Exceptions always happen. However, these dynamic changes and exceptions are not adequately addressed - e.g. how to uncover exceptions and how the exceptions should be resolved, by current commercial products or even research prototypes (Chiu, 2000; Hagen and Alonso, 1998; Han et al, 1998; Klein and Dellarocas, 2000).  1.2 Thesis Objectives Motivated by the above observations, we try to find out how workflow systems can be made flexible, adaptive, and dynamic, and how this in turn can handle exceptions and changes. There have been a number of research works done on workflow exception handling, (e.g., (Casati et al, 1999; Chiu, 2000; Eder and Liebhart, 1995; Hagen and Alonso, 1998; Klein and Dellarocas, 2000)). However, most of them only focus on extending database technology  and examine the problem from a transaction  processing point of view. Particularly they lack a mechanism to handle unexpected exceptions and the support of process learning. As Abbott and Sarin noted that, "It should be possible to build the process definition 'library' or hierarchy based on experience in executing processes. On completion of a process (or before that, if necessary) it should be possible to review how it was performed and to abstract information from it in order to 'save' a process definition, or components thereof, in the library" (1994).  2  To address these limitations, we propose a flexible workflow model by extending the  Micro-Organization  Activity  Processor (MOAP)  architecture  (Woo and  Lochovsky, 1991) and incorporating Object-Oriented Workflow Model (OOWM) (Hui, 1997). The advantage of O O W M is that it captures an organizational process from a company-wide perspective and focuses on how independent objects work together in order to achieve company objectives (Hui, 1997). The M O A P architecture is an intelligent agent that supports acquisition and communication of knowledge through learning and reasoning. The objectives of this thesis are: •  To construct a flexible and dynamic workflow model that supports exception handling;  •  To explore and present the exception handling capability and mechanisms of the proposed workflow system and find out what kinds of exceptions can be handled.  •  To develop a workflow system simulator to demonstrate and study the feasibility and limitations of the proposed approach.  1.3 Thesis Outline The thesis is outlined as follows: In Chapter 2, we give an overview of workflow management systems and definitions of some common terms and concepts that are used throughout the thesis.  3  Chapter 3 has three parts: first, we examine the nature of workflow exceptions and discuss some different classifications. Then we discuss features and limitations of some surveyed research work. The last part introduces O O W M and M O A P concepts, which serve as the theoretical foundation of this thesis. In Chapter 4, the proposed MOAP-Based Workflow Model (MOAP-Wf) is presented. In Chapter 5, we first discuss the normal execution mechanism of MOAP-Wf. Then by giving a business process example, we elaborate how exceptions are handled in MOAP-Wf. We present the design and demonstrate the implementation of a workflow i  execution simulator based the M O A P - W f in Chapter 6. Chapter 7 concludes the thesis by reviewing the contributions, acknowledging the limitations, and suggesting future research.  4  2 Workflow Management System In this chapter, we briefly review main concepts of workflow systems so as to build a common ground of terminology for analysis, because researchers and commercial software vendors might have different definitions and interpretations on the same term.  2.1 Workflow and Related Concepts Generally speaking, workflow is the automation of a business process, or a set of coordinated activities representing a business process within a company or an organization (Borghoff and Schlichter, 2000). There are also some other similar definitions, for example Jablonski and Bussler say that workflow "typically consists of various activities, which have to be executed in some order involving multiple collaborating persons call agents in a distributed environment to fulfill a certain task in an organization" (1996). Among  popular terminologies  is  the  one  developed  by  the Workflow  Management Coalition (WfMC) (WfMC, 1999). WfMC is a non-profit international organization of workflow vendors, users, analysts and university/research groups. Its mission is to "promote and develop the use of workflow through the establishment of standards for software  terminology, interoperability and connectivity between  workflow products". In this thesis, we follow WfMC's terminology unless otherwise stated.  5  According to WfMC, a workflow is defined as the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules, while a business process is a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.  Business Process  . . ,. ^ is defined as cei rT_ °f!!f_ _ \ Definition  •  sub-process  r  c o m  S  P°^  e d  o  is managed a  Workflow Management System used to create i  &  f  manage  via Process Instance  : Activities  which may be orM Manual Activities  by \ .  include represented  Automated Activities  one  or more ^  Y  b  *  Work Item  Activity | t nce n s  a  and/or  Invoked Application  Figure 2-1 Workflow Terminology (adapted from WfMC (1999)) Because the terms workflow and process are so closely related, researchers sometimes use them interchangeably. In any case, a workflow is basically a business process. From a modeling point of view, a process model describes the structure of business process in the real world, while a workflow model talks about the aspects of a business that are run on a computer (Leymann and Roller, 1999).  6  WfMC's terminology can be described in Figure 2-1. Other main terms defined by WfMC are: •  Activity - a description of a piece of work that forms one logical step within a process. A n activity may be a manual activity, which does not support computer automation, or a workflow (automated) activity. A workflow activity requires a human and/or machine resource(s) to support process execution; where a human resource is required, an activity is allocated to a workflow participant. An activity is also called a task, step, workflow element, or a process element.  •  W o r k Item - The representation of the work to be processed by a workflow participant in the context of an activity within a process instance.  •  Worklist - a list of work items associated with a given workflow participant (or in some cases, with a group of workflow participants who may share a common worklist).  It should be noted that WfMC further categorizes an activity as 'automated' or 'manual' and normally refers the term 'activity' to 'automated activity', while it regards 'manual activity' as lying 'outside the scope of a workflow management system' (WfMC, 1999). We believe that 'manual activity' should be 'inside' rather than 'outside' the workflow management systems scope, as the aim of a workflow management system is not to automate necessarily all the tasks of a workflow process. Some tasks might continue to involve humans; and even for automated tasks, the determination of when to initiate them and/or determining whether such  7  automated tasks have been successfully completed might be left to humans. The emphasis is much more on automating the tracking of workflow task states, and allowing specification of preconditions to decide when tasks are ready to be executed (inter-task dependencies) and of information flow between tasks (Mohan, 1997).  2.2 Workflow Management Systems A workflow management system (WfMS) is a system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications (WfMC, 1999). Despite the differences of modeling and design among different researchers and software vendors, generally speaking, all the workflow management systems should support three main functions (Divitini et al., 2001): •  The definition of workflows;  •  The execution of workflows;  •  The administration of workflows and the monitoring of their executions.  To standardize a common architecture for their functions, Workflow Management Coalition has developed a Workflow Reference Model from the generic workflow application structure by identifying the interfaces within this structure which enable products to interoperate at a variety of levels (WfMC, 1995) as shown in Figure 2-2.  8  Process Definition Tools \) Interface  Workflow API and Interchange Formats  Interface  Administration & Monitoring Tools  1  5 — •  Workflow Enactment Service ,  Interface 4  Other Workflow Enactment Service(s) Workflow Engine(s)  Workflow Engine(s) __U Interface  Interface  2  Workflow Client Applications  _U  3  Invoked Applications  Figure 2-2 WfMC's Workflow Reference Model (adapted from (WfMC 1995)) The Workflow Reference Model consists of six components: •  Workflow Enactment Service - is a workflow system's core component, which supports the execution of workflow processes by providing a run-time execution environment. Workflow Enactment Service is defined as a software service that may consist of one or more workflow engines that create, manage and execute workflow instances. Applications may interface to this service via the workflow application programming interface (WAPI).  •  Process Definition Tools (Interface 1) - are used to analyze, model, describe and document a business process; such tools can be either informal or highly formalized and may be supplied as part of a workflow product or as a separate toolset.  •  Workflow Client Applications (Interface 2) and Invoked Applications (Interface 3) - work together to enable end-users to interact with the  9  workflow systems or call third-party applications, e.g. ERP systems, to perform a task. •  Administration and Monitoring Tools (Interface 5) - enable administrators to manage, monitor and analyze actual processes.  •  Other Workflow Enactment Services (Interface 4) -  are from other  workflow systems and are connected via interface 4 for inter-operations. In this thesis, we focus on process definition and workflow enactment service. We propose a goal- and agent-oriented workflow modeling, execution and exception handling mechanism.  2.3 Challenges and Limitations Despite their popularity in the industry, current workflow systems might be hindered from playing a more effective role in business process re-engineering due to the systems' rigid designs, which were optimized for fixed, repetitive processes. The rigidity is widely cited as a critical problem in a context where people and organizations have to evolve in a constantly changing and dynamic business environment (Abbott and Sarin, 1994; Chiu, 2000; Grigori et al, 1996; Han et al, 1998; Heinl et al, 1999; Keddara, 1999). Business processes involving people usually cannot be described completely a priori by a strict activity schedule, and exceptional situations may arise. Alternative paths for achieving the global goal must be provided or automatically generated as needed (Borghoff and Schlichter, 2000). In business reality there are some special  10  cases in which the defined process rules are by-passed. For example, a C E O may approve sales orders to a key customer without the task of credit checking. However, current workflow management systems are illsuited to handling such exceptions and do not provide support for uncovering what kinds of exceptions can occur in a given process model and how they can be resolved (Klein and Dellarocas, 2000). When such exceptions occur, the solution of current workflow management systems is to redefine and re-execute the process. One example of current workflow management systems is IBM MQSeries Workflow which uses the following steps to handle an exception (IBM, 2001): 1). Create new process model. 2). Export the new process model from Buildtime and import F D L (MQ Workflow Description Language) file into Runtime environment. New process instances will follow the new model while existing old process instances do not. Existing processes always use the template (model) that exists in the Runtime on the moment that the instances are created. This type of solution has the following shortcomings: 1). It is inefficient in that it requires redefinition and re-execution of workflow process. 2). Redefining workflow model affects existing running instances. 3). Each time an exception occurs, a new model is required to incorporate exception handling procedures, which can greatly complicate process models and 'obscure' the 'preferred' process, making it difficult to define, understand and modify (Klein and Dellarocas, 2000). In this thesis, we try to address these challenges and limitations with the proposed goal- and agent-oriented approach.  11  3 Workflow Exceptions and Related Research Work In the previous chapter, we reviewed the main concepts of workflow management systems. Challenges and limitations of current WfMS are also discussed. We will now cover the details of workflow exceptions. In this chapter, we first review some of the definitions and classifications of workflow exceptions, and then proceed with a survey of previous research work on exception handling.  3.1 Exceptions in Workflow Currently there is not established framework for exception handling in WfMSs (Chiu, 2000). Different definitions can be found in the literature. For example, Chiu defines exception as an event which deviates from normal behavior and may prevent forward progress of a workflow (2001). In (Casati, 1998), exceptions are described as "may be caused by system (hardware or software) failures, or may be related to the semantics of the business process". Exceptions can occur when the business environment changes, when organizational structure changes, or when there are system errors. In this section, we review the classification of workflow exceptions and the characteristics that might influence exception handling approaches.  3.1.1 Exception Scope: Schema and Instance An exception can be classified as schema exception or instance exception depending on its scope. Schema exceptions occur when a workflow process definition  12  is changed. However, when an exception occurs only for one process execution, it is an instance exception. Some research work, e.g. Ellis and Keddara 2000, differentiates schema change and instance change, and defines instance change as an exception. We classify the former as 'schema exception' in a wider sense in that a 'schema change' is still a deviation, thus an 'exception' from the original one.  3.1.2 Exception Level: Expected and Unexpected An exception can also be classified as expected or unexpected (Chiu, 2000; Eder and Liebhart, 1995) according the workflow level at which it occurs. Expected exceptions are those deviations and special cases that can be anticipated. Special mechanisms or 'exception handlers' can be embedded in normal workflow to handle such exceptions (Basu and Kumar, 2002). Unexpected exceptions, on the other hand, are those deviations or special cases that cannot be anticipated. Another similar definition given by Casati is that unexpected exceptions correspond to inconsistencies between the business process in the real world and its corresponding workflow description (1998). No special mechanisms or handlers are available to handle unexpected exceptions. Human intervention is usually required. Expected exceptions are to be solved at workflow system level, while unexpected exceptions need to be handled at the process definition (process modeling) level (Eder and Liebhart, 1995). Some other similar classifications  in this category  are: known/unknown  exceptions and detectable/undetectable exceptions (Luo et al., 2000). Unknown exceptions are beyond the workflow system's current knowledge, while known 13  exceptions are anticipated within it. Detectable and undetectable exceptions are defined according to whether a workflow system is capable or incapable of detecting such exceptions.  3.1.3  Level  of  Abstraction:  Domain,  Process,  Resource  and  Infrastructure Another classification is to uses a 'separating concerns' strategy to provide a taxonomy of workflow adaptation according to abstraction levels - domain, process, resource, and infrastructure (Han et al., 1998). At the domain level, workflow systems should be adapted to changes in the business context such as laws and regulations. For example, the changes of US immigration policies have significant impact on the process of issuing visas. Domain level adaptation may in turn result in a series of adaptation requirements at different levels as discussed below. Process level adaptation includes workflow model evolution and workflow instance ad-hoc modifications. This level adaptation is equivalent to a schema exception and an instance exception which we defined in section 3.1.1. At resource level, workflow systems need to be adapted to changes and rearrangement of supporting workflow resources, including organization-related resources such as personnel changes and data-related resources such as data structures. The fourth level of adaptation is infrastructure, which deals with technical advances and changes of software system configuration.  14  3.2 Scope of Exception in this Thesis Because there are many different definitions and classifications as discussed above, we limit the scope of exceptions in this thesis as follows: First, we focus on business process level exceptions, i.e. from the viewpoint of business process rather than that of software. The other levels of adaptation, for example domain and infrastructure, can be treated as 'external' to the workflow system (Chiu, 2000). We do not consider those  basic failures  and  application  failures  such as program failures and system crashes (Eder and Liebhart, 1995). These exceptions are at a lower system/software level. Secondly, it is very difficult to define exceptions. Instead of giving precise definitions, we state the types of exceptions that we consider in this thesis. We also try and  to find out other kinds of exceptions through the research. Similar to (Chiu, 2000) (Casati, 1998), we classify exceptions into expected and We  unexpected ones.  further classify expected exceptions into two types. One is that the result of  the workflow is not as expected. This type of exception usually can be resolved if there exist other equivalent and acceptable outcomes. The other type of expected exception is that one or more steps of the workflow fail or do not response. For this type of exceptions, the system can try other steps that have the same results. We  also classify unexpected exceptions in this thesis into two types. The first type  is those unexpected exceptions that can be resolved by the workflow system through reasoning and searching. The second type is those that the system does not know what to do and can only be solved by user intervention.  15  An example for resolving through reasoning is that, if the execution sequence of a workflow instance is unexpected (i.e., not specified in the normal execution pattern nor in the exception handler), but the eventual outcome/result is the same as the normal one, then if the workflow system can deduce this same effect, it should allow the execution and thus provides a mechanism to handle unexpected exceptions. A n example for resolving through searching is as follows. If the execution of a workflow instance cannot proceed because of an exception, and if the know-how to resolve it resides somewhere and the workflow system can find it, then the system can resume the execution using this newly found solution.  3.3 Survey of Related Research Work In this section, we review some of the exception handling mechanisms in related research work.  3.3.1 The Workflow Activity Model The  Workflow Activity Model (WAMO) (Eder and Liebhart, 1995) is a  transaction-oriented model that "enables the workflow designer in modeling not only correct business processes but also potential (expectable) exceptions which may arise during process execution". W A M O classifies exception into four categories: basic failures, application failures, expected exceptions, and unexpected exceptions. W A M O targets at solving 'expected exceptions' by breaking down a complex business process into smaller  16  work units (activities) which themselves consist of pre-existing tasks and guarantee reliable flow control with automatic exception handling. A conceptual W A M O architecture consists of activities, forms and agents. Activities represent any abstract description of work units in a business process; Forms are data containers to store relevant process data; Agents are responsible for execution of activities. In addition, the W A M O model defines some transaction specific parameters for each task. The parameters specify how a task behaves when compensation is needed, which in turn decides how an exception should be handled. There are four possibilities: •  None: the committed task does not need to be compensated;  •  Undoable: the committed task can be undone by the corresponding compensation task without any side-effects;  •  Compensable: the committed task can be semantically undone by the corresponding compensation task but there are side-effects;  •  Critical: the task cannot be undone or compensated afterwards because there is no compensation task to undo the already committed effects.  Compensation conception is one of the important features of W A M O . When a vital activity fails, a compensation is initiated. The compensation and exception handling mechanism is shown in Figure 3-1 as event-state change of activities. The general solution is to compensate all previous current control structure in reverse order.  17  successfully  committed  activities in the  Figure 3-1: Event-State for Activities (adapted from (Eder and Liebhart 1995)) Once all relevant activities in the current control structure are compensated, the parent activity of the current control structure changes its state to  unsuccessfully.  committed  Then the system can make forward progress or start a new  compensation process on the next higher level.  Discussion The W A M O model is transaction oriented and targeted at handling 'potential (expected) exceptions'. Unexpected exceptions are not covered in the model. Because of its transactional-oriented nature, the W A M O has the following limitations: •  Not only the 'normal' process sequence, but also all of the alternative and compensation processes have to be pre-defined. This requirement of rigid and inflexible predefinition limits the exception handling capability of W A M O .  •  It does not capture the reasons for "why?" and "how?" an exception happens. In general, there is an assumption of static relationship between the original  18  execution and its compensation (Du and Elmagarmid, 1997). Because there is no information about the cause of problem, a compensation task may just repeat what the original one has done. •  It only solves failures by providing alternative/compensation tasks. It does not support deviations from workflow schema like, for example, adding or bypassing some steps in the process. These deviations are not 'failures' and thus need not be 'compensated' for.  3.3.2 OPERA Process Support System The OPERA process support system (Hagen and Alonso, 1998) is a failure handling mechanism made flexible by using a combination of programming language concepts and transaction processing techniques. In OPERA, a workflow process has a modular structure in which different tasks are nested in a tree. The exception handling mechanism is divided into two parts: exception detection and exception handling. The mechanism is such that, when a task fails, its execution is stopped and the control of the process is handed over to exception handler. If the handler cannot solve the problem, it propagates the exception up to higher level in the task tree. The control flow of exception handling is shown in Figure 3-2.  19  =_FAILED>—^{TActivity  )-»<Re^me>  P2 ...T...  ( Activity 2 ) ( Activity 3 ) Figure 3-2: Control Flow of Exception Handling in OPERA (adapted from (Hagen and Alonso 1998)) The exception handler is controlled by the parent process (or the Caller) while the exception is returned by the sub-process (or the Signaler). The exception handler is also a type of process, which can contain arbitrary activities, blocks or sub-processes. As shown in Figure 3-2, the entry point to a handler process is a so-called proxy  activity (E_FAILED), which can be seen as a placeholder for the exception that occurred. Predicates such as PI and P2 are defined on the data that has been passed by the signaler together with the exception. Depending on the information provided by the signaler, either PI or P2 is called. Thus different execution paths are allowed depending on the information provided. Terminator proxies (RESUME and ABORT) define the endpoints of a handler and determine how the control flow has to proceed after termination of the handler.  Discussion Like W A M O discussed in the previous section, the OPERA process support system is also based on transactional concepts. As such, OPERA has the same limitations as W A M O , in that all exceptions need to be pre-defined, therefore it cannot handle unexpected exceptions, etc. If one undefined exception occurs, the whole process fails. For each task without exceptions being defined, the system  20  default handler will take control. However, this 'catch-all' default handler only aborts the signaler and propagates all exceptions to the caller, without doing 'real handling' to find a solution. Finally, recursive handler calls are not allowed (Hagen and Alonso, 1998), which means that the handler is the 'last stop' for solving an exception. There is no way to solve any exception the handler itself may encounter. Thus the problem-solving capability of the handler is limited.  3.3.3 ADOME-WFMS The A D O M E - W F M S (Chiu, 2000) is an exception-centric workflow management system framework proposed by Chiu in his PhD dissertation. It uses an event-driven approach designed to coordinate workflow execution and to handle exceptions. An A D O M E - W F M S model consists of the following sub-models: •  Organization and Resource Model, which specifies:  1). organizational  composition such as subsidiaries, divisions, departments, employees and customers etc. 2). Problem Solving Agent (PSA) objects, attributes and their methods. 3). token/role multiple-inheritance, which includes capability tokens, roles and positions that a PSA object can possess. •  Match Making Model, which enables the workflow system to find a PSA that is capable of performing a specific task.  21  •  Activity Model, which recursively decomposes an activity (workflow) into sub-activities and eventually tasks. Dependencies between activities are also defined in this model.  •  Event-Driven Execution Model, which provides a unified approach for normal activity execution and exception handling.  The A D O M E - W F M S uses a centralized control and coordination execution model on the Activity Executor, which initiates the problem solving agents (PSA) to carry out assigned tasks. PSA is selected by Match Maker. If a task raises an exception event, the Exception Manager will take control. A n event can be any of the following: data operation, workflow, clock time, external notification, or abstract event. In A D O M E - W F M S , the exception handling steps carried out by the Exception Manager upon a defined exception event are as follows: 1.) Perform notification of relevant PSAs if necessary. 2.) Identify and execute appropriate exception handlers, which are modeled as sub-activities. There are several types of handlers such as Mandatory Event-Condition-Action (ECA) handlers, Procedural handlers, and E C A handlers. For example, a mandatory E C A rule specifies that all exceptions should notify the purchasing manager in a procurement activity; a procedural handler specifies extra activity branches. 3.) If no exception handler is found, the Human Intervention Manager will be invoked and it is up to user to decide how the exception should be solved. 4.) Implement rollback if necessary. 5.) If necessary, exceptions are propagated to parent activity for further handling.  22  The exception handler resolution of A D O M E - W F M S is similar to that of OPERA does. Instead of defining each process, A D O M E - W F M S models exception handlers in the form of E C A (Event-Condition-Action) rules that can be bound to selected objects dynamically at run-time.  Discussion The A D O M E - W F M S employs a meta-modeling approach to support exception handling. It also gives an interesting exception-centric view of the workflow model. In comparison with other workflow models, it has the following limitations: •  Although A D O M E - W F M S provides a dynamic binding mechanism to reuse exception handlers, it could be difficult to make an exception handler 'reusable' (e.g. one-to-many binding to workflow instances). Since each exception could have different causes and characteristics, the handler for one exception may not work for others.  •  A D O M E - W F M S focuses on solving 'expected exceptions'. If unexpected exceptions occur, human intervention is usually required although the system may provide some assistance, e.g. finding handlers. In this regard, A D O M E WFMS  still requires that exceptions be pre-defined  and only those  'repeatable' or 'replaceable' tasks can be handled. If a 'critical' task fails, the parent activity (thus the whole workflow process) fails. •  A D O M E - W F M S uses an activity executor and an exception manager to control normal process execution and exception handling, respectively. This approach incurs the extra expense of transformation of task data between the  23  activity executor and the exception manager. It can be argued that there is no reason for putting a boundary between regular process execution and exception handling. This would remove the possibility of considering exceptions that happen all the time during regular execution. Nevertheless, A D O M E - W F M S is one of the most comprehensive frameworks for exception handling noted by the author. In a later part of this thesis, we provide a relatively more detailed comparison of the A D O M E - W F M S and our proposed M O A P - W f by using a business process example.  3.3.4 CapBasED-AMS The  Capability-Based and  Event-Driven Activity  Management  System  (CapBasED-AMS) (Karlapalem et al., 1995) proposes a framework with capability based activity specification, decomposition and identification of the problem solving agent to execute the tasks, and event-driven execution of the activities.  Activity Generator <::  System Catalog Activity graph  PSA Activity Coordinator PSA  GUI  <  he-  JL  Recovery Manager PSA  Shared Workspace  If  -3H Task Log Manager  Active Database  Capability kxiatabase--^  Figure 3-3: Architecture of CapBasED-AMS (adapted from (Karlapalem et al 1995)) 24  The architecture of a CapBasED-AMS is shown in Figure 3-4. A problem solving agent (PSA) is either a piece of hardware, a software system or a human, with a set of abilities to execute tasks. An activity consists of one or more tasks which can be executed by one or more PSAs. With capability-based activity specification and decomposition, each task is matched to a PSA by selecting a PSA that has the abilities to meet the needs of the task. Within an activity are multiple inter-dependent tasks that need to be coordinated, scheduled and executed. A l l of these inter-dependencies are expressed by means of a uniform framework of events. The execution of a task is orchestrated by the occurrence of the events. Upon predefined events, the activity coordinator initiates and controls the execution of tasks by using mapping between events and tasks. Two types of exceptions are supported in CapBasED-AMS: 1). Task execution failure. Upon such failures, the activity coordinator will initiate a predefined recovery and contingency plan to complete the execution of an activity. 2). Undefined event. Those events that are not predefined in the E C A rules will be added during runtime after validating the triggered actions by users.  Discussion PSA in CapBasED-AMS is modeled as an individual unit in a flat structure. This type of flat structure is not flexible in the sense that some processes may need to be executed by a group or department instead of individuals. Generally speaking, exception handling in CapBasED-AMS is weakly supported. It only supports predefined recovery and contingency plans upon failures of task  25  execution. As the authors of this system note, "[it] has no inherent ability to reason about the nature of the problem and solve it. It solves a certain class of problems which the system has the knowledge to solve. Also, the problem decomposition knowledge and coordination strategy are a priori defined".  3.3.5 Adaptive Workflow Han, Sheth, and Bussler propose a two-layer adaptive workflow system as shown in Figure 3-4. In the upper layer, a workflow model, there are abstract business tasks. The  lower layer, a resource level, includes a workflow model with versions,  applications and persons. Tasks are executed by binding different workflow resources. This allows a dynamic binding between a business task and various potential implementations  (Task Functionality  vs.  Workflow  Model with Versions  in  Figure 3-4). The ownership of task is resolved at runtime by concrete users who become runtime task owners  (Task/Process  Owner  vs.  Persons  in Figure 3-4).  Outgoing messanges Workflow model level Resource  level  Figure 3-4 Synthesized Adaptive Workflow Approach (adapted from (Han et al 1998)) As the authors of this system note, the proposed approach has the following features to manage workflow changes:  26  •  Business processes are hierarchically organized but not totally fixed. A business  task  is  abstracted  by  separating  its  declaration  from  its  implementation. The binding between a business task and various potential implementations are dynamic instead of fixed. •  Exception handling is enabled by embedding the generic resource binding and adaptation handling mechanism into each task. A user can try different variants (of a task) to retry, postpone, or abort the task.  Discussion Although this approach provides a way to bind tasks to workflow model versions dynamically, how the tasks are actually bound is not discussed. Because the tasks are abstract ones, they need to be 'concretized' in order to be adapted to workflow model. Secondly, because the task variants and workflow model versions still need to be defined a priori, the number of possible choices is fixed and the capability of the system to handle exceptions is also limited. There is no mechanism for deciding under what circumstances which task and which workflow model should be executed. The only way to accomplish this is by having users try those variants one by one.  3.4 Summary of Survey In this section, we reviewed existing research work on workflow exception handling. We do not include commercial products because very few of them provide support for managing exception situations (Casati et al., 1999).  27  In summary, most of the research work and system prototypes try to solve workflow exceptions at a system level by concentrating on extending database transaction process techniques. One example is use of the recovery capability of (database) environment on the top of which the WfMS is executed (Casati, 1998). One common limitation is that most of them target expected exceptions, for example by predefining such exceptions and providing 'compensation' processes, while ignoring or at least paying less attention to 'unexpected', 'unknown' or 'undetectable' exceptions. Furthermore, most of the surveyed works are traditional activity-based models, of which the process/activity/task must be predefined in rigid sequence during build time. From an exception handling point of view, a typical workflow model consists of 'core processes' and 'exception processes'. The latter is used to solve any problems the workflow system encounters. Examples of the surveyed research work that apply this approach include: W A M O , OPERA, CapBasED-AMS and A D O M E - W F M S . Both the 'core' and 'exception' processes have to be defined a priori. Changes during runtime are usually not allowed. This rigid, inflexible and sequential feature limits the capability of the exception handling of the systems. A cooperative process cannot be executed as a flowing sequence of activities, but contain many unpredictable exchanges that cannot be modeled in advance (Grigori et al., 1996). Another important consideration is that the workflow system should be able to 'learn' from its experience of handling exceptions and then use such knowledge to avoid exceptions.  28  Because one of the common assumptions most workflow research makes is the availability of pre-specified workflow definition (Du and Elmagarmid, 1997), few of the surveyed research works focus on dynamic workflow modeling. We believe that building a flexible, dynamic workflow model in the first place is much easier than solving problems afterwards. Dynamic workflow systems have no pre-specified process specifications (Du and Elmagarmid, 1997). The workflow starts with some initial activities. When an activity is completed, new activities will be selected according to the execution status and results of the current activity. The dynamic workflow is different from 'dynamic modification' of existing process  definitions  (Du and Elmagarmid,  1997). With dynamic modification  approach, the system tries to 'modify' pre-defined processes when encountering exceptions.  Then the running process is either restarted or migrated to new  definitions. Examples of this dynamic modification approach include: Han et al (1998) and van der Aalst et al (1999). In this thesis, our approach does not handle dynamic modification.  Table 3-1 Category of Exception Handling Approach Category of Approach  Examples of research w o r k  Remarks  Core Process + Exception Process  WAMO, OPERA, CapBasEDAMS, ADOME-WFMS  - Activity-based model (pre-defined sequence)  Dynamic Modification  (Han etal., 1998), (van der Aalst etal., 1999), (Heinl etal., 1999)  - Migration of running instances - Activity-based model (pre-defined sequence)  29  Lastly, to our best knowledge, few of the research works take into consideration the organizational and social aspects of workflow including, for example, how a user's goals affect workflow process execution. A summary of categorization of the surveyed research works is shown in Table 3-1.  3.5 Different Views of Workflow Generally speaking, there are two views of a business: an enterprise view and a process view (Wand and Woo, 2001). The enterprise view focuses on 'actors' or 'roles', while the process view focuses on 'activities' - how a process is comprised of a series of actions. Most of the research works that we surveyed are from only a process view, i.e. linking a number of sequenced activities to form a workflow process. As we found in our survey, this approach is not capable of efficient and effective exception handling. We take an enterprise view of workflow on actors and communications because of the following factors and requirements: •  Organization and its environment can be viewed as composed of interacting agents and all actions in the organization are done either by agents or by interactions between agents who exchange information and materials (Wand and Woo, 1999). Different groups (and agents) with the organization are relatively autonomous (Jennings et al, 1996).  30  •  Given that workflow systems operate in an organizational context, it is extremely important that they must be 'organizational aware' for the successful application of workflow technology (Basu and Kumar, 2002).  •  Within organizations, there is a decentralized ownership of the tasks, information and resources involved in business (Jennings et al, 1996). Each entity may be motivated to control its own resources and activities, and may not accede control to its partners (Basu and Kumar, 2002).  •  Business processes are highly dynamic and unpredictable and any detailed time plans are often by unavoidable delays or unanticipated events (Jennings et al, 1996).  Arguably, a single 'process view' of workflow is not sufficient. We found that Micro-Organization Activity Processor (MOAP) (Woo and Lochovsky, 1991) and Object-Oriented Workflow Model (OOWM) (Hui, 1997) can be extended to address the above requirements. M O A P is decentralized with problem-solving ability while O O W M is a workflow in an autonomous business environment. The proposed approach is agent-based and it not only supports autonomy of agents (enterprise view) but also allows processes emerge out of the interactions of agents (process view). It should be noted that there can be also other approaches that satisfies the requirements. However, choosing the best approach is beyond the scope of this thesis. In the next section, we briefly introduce O O W M and M O A P and examine how their features can satisfy the requirements of enterprise view and facilitate workflow exception handling.  31  3.6 Micro-Organization Activity Processor (MOAP) 3.6.1 The Structure of MOAP M O A P is a mobile agent architecture for modeling intelligent information systems. One of the most important features of the M O A P structure is its support of communication o f knowledge between the agents. From the M O A P point of view, an organization is composed of many small units (as 'micro-organization') that can be departments or employees (users). For each o f the units, an 'activity-processor' is assigned to perform certain functions. One M O A P is attached to only one user and each user has at least one MOAP. A M O A P structure consists of six different types of entities, including: Data Repository,  Procedural  Knowledge,  Problem-Solving  Knowledge,  Activity  Coordinator, Activity Agent, and Workspace as shown in Figure 3-5.  Organizational Worker  i Legend:  Activity Coordinator Procedural Knowledge  Data Repository  Active Entity | ProblemSolving Knowledge  Supervise execution  w  Access Workspace  • Pass control  p.  t (Other MOAPs)  Figure 3-5 Micro-Organization Activity Processor (adopted from (Woo and Lochovsky 1991))  32  Each of the components plays different roles in knowledge representation and communication. The Data Repository stores persistent information. Procedural Knowledge is well-organized, well-tested organizational knowledge,  which is  described in terms of tasks (and subtasks). Problem-Solving Knowledge consists of the knowledge related to facts, the missing parts of procedural knowledge, or that which is playing the role of procedural knowledge. Workspace is the communication medium for all of the active entities. The Activity Agent represents the M O A P and specializes in communication and coordination with other MOAPs. The Activity Coordinator controls the execution of tasks, the activity agent and use of problemsolving knowledge, and responds to inquiries by other MOAPs.  3.6.2 Applicability of MOAP in workflow systems Because of its intelligent and autonomous agent characteristics, M O A P is an ideal building unit for a decentralized computing environment. One of the examples is OASIS (Martens and Woo, 1997), which is an implementation of a M O A P architecture. In the implementation, each M O A P has the ability to communicate and cooperate with other MOAPs to complete a task by utilizing their procedural or problem-solving knowledge. Intelligent agents have been recognized as a new solution to manage workflow, or automated business processes. For example, agents are used to improve the management of business processes under control of a workflow management system (termed as 'agent-enhanced workflow') (Judge et al., 1998). Another research effort is A D E P T (Advanced Decision Environment for Process Tasks) (Jennings et al.,  33  1996; Norman et al., 1996), in which a business organization structure is modeled as a multi-agent system (termed as 'agent-based business process management system'). In summary, agents including M O A P can manage business processes better than the traditional activity-based workflow systems (Jennings et al., 1996). M O A P can satisfy the enterprise view requirements as we discussed in previous section in that: •  MOAP  is decentralized and distributed and it supports  decentralized  ownership of the tasks, information and resources involved in the business; •  M O A P is modeled as role and organization unit. Such model meets the requirement of 'organization-aware' and helps alleviate the issue that most of today's workflow management systems focus on the process dimension (i.e. routing, control flow) and oversimplify the organizational dimension (Basu and Kumar, 2002).  •  M O A P has problem-solving ability that helps handle exceptions in a workflow.  3.6.3 Comparison of MOAP and ADEPT agents In addition to general properties of agents such as autonomy, social ability, responsiveness and being proactive, a M O A P has differential features of explicitly defined procedural knowledge and problem-solving knowledge, and support of knowledge acquisition and communication. Before we examine, in later chapters, how these features could be incorporated and utilized in our workflow model to  34  support exception handling, we briefly review one of the agent types - A D E P T and compare it with MOAP.  AGENCY RESPONSIBLE AGENT  Service Execution Module (SEM)  PeerAgency  I  Self and Acquaintance modules (SM, AM)  Situation Assessment module (SAM)  Communication module (CM) PeerAgency  Interaction Management Module (IMM)  1 Sub-Agency  Figure 3-6 ADEPT Agent Architecture (adapted from (Jennings et al 1998)) The A D E P T agent architecture is shown in Figure 3-6. A n A D E P T system may consist of a mixture of hierarchies of agencies and peers reflecting organizational structures. A n agency is recursively defined with a single responsible agent, a set of tasks that the responsible agent can perform, and a set of sub-agencies. The responsible agent represents the agency and is in charge of communication with peer agencies.  The responsible agent is comprised of several modules.  Self and  Acquaintance Modules store available resources, current schedule of activity, and capabilities of other agents. The Situation Assessment Module (SAM) maintains the agent's schedule of activity. The Service Execution Module (SEM) is responsible for the initialization and management of the execution of services. The Interaction Management Module negotiates for services that are required from other agents.  35  In comparison with M O A P , the A D E P T agent architecture has the following limitations: First, the A D E P T agent architecture focuses on inter-agent communication and negotiation.  It puts more emphasis  on communication mechanisms, message  descriptions, and 'joint-decision making' processes. It lacks the representation of knowledge required for business process management. How tasks are organized to support process execution is not addressed. In contrast, the M O A P architecture focuses on agent knowledge representation. It explicitly differentiates procedural knowledge and problem solving knowledge. Thus each M O A P has the flexibility to use different knowledge to solve different problems. With an emphasis on process knowledge, the M O A P architecture captures 'what', 'when' and 'how' tasks are performed rather than, as in the case of as ADEPT, tracking 'how' communicating occurs between agents. Secondly, A D E P T takes a 'sub-agency'  approach to reflect organizational  structure. This approach puts certain restrictions on the agent's autonomy in that subagents can not communicate with other agents outside the scope of the current agent. All communications must be done through the responsible agent. For example, suppose there is a situation where a purchaser in the purchasing department needs to communicate with an accountant in the finance department. The communication must be done as 'purchaser -> purchasing manager -> finance manager  accountant'  because both purchaser and accountant are modeled as 'sub-agents' within the purchasing department and the finance department respectively. This is not, usually  36  the case in business. There is no real business reason to explain why the purchaser and accountant cannot interact directly.  3.7 Objected-Oriented Workflow Model (OOWM) Originally developed in the software engineering area, the object-oriented approach is considered to be a more natural technology for the requirements of autonomy, distribution and cooperation, because objects are a natural model of interactive components in a distributed environment (Kappel et al., 2000). Among those studies on the object-oriented approach, Hui's O O W M extends O O E M (Object-Oriented Enterprise Modeling) (Wand and Woo, 1999) to capture the informational, functional and organizational aspects of a process and the architecture can be very flexible and adaptable to fit into a constantly changing business environment (Hui, 1997). In this section, we give a brief introduction of O O W M structure.  37  Figure 3-7 Object-Oriented Workflow Model (adapted from (Hui 1997)) As shown in Figure 3-7, O O W M consists of six constructs: Object, Attribute, Service, Request, Activity and Business Rule. A n object is defined as a model of a substantial thing in the problem domain that interacts with other objects. A n object can represent an organizational unit, a division, a department, or a role. A n attribute is the state of and must belong to an object. Service models a state transformation of an object. It comprises a series of actions performed by an object with the purpose of satisfying a request, which is an interaction between two objects. A n activity is the basic unit of operation for an object. Activities form services. A Business Rule can be interpreted as pre-conditions and termination conditions for an activity. An Object Activity Template (OAT) is used to capture workflow information that includes activities and business rules that govern the activities. The O A T is shown in the following table:  38  T a b l e 3-2 O b j e c t A c t i v i t y T e m p l a t e ( a d a p t e d f r o m ( H u i 1997)) Object Name - Object  Internal Attributes  Interface Attributes Incoming Interface Attributes Returning Interface Attributes  ProCondition  Internal Attribute To Support  Returning Interface Attributes  Services Activity  Service 1 Termination Conditions  Request Generated  Receiver  PreActivity 1 Condition 1 condition 1  Request generated from activity 1  Object receiving a request generated from activity 1  PreActivity 2 Condition 2 condition 2  Request generated from activity 2  Object receiving a request generated from activity 2  Access Code  Service 1  Each row of the table represents an activity that is attached to pre- and termination conditions. If a pre-condition of one activity holds, an object will perform that activity. Similarly, if a termination condition is true while an activity is being performed, the activity will stop. One important object of O O W M is the Controller, which controls and monitors what objects should react to requests and when. The functions of the Controller are to ensure that business rules be followed in an automated workflow environment by not only keeping track of, but also the evaluating of rules based on the information carried by a request and the state of a process. We adopt some concepts of O O W M based on the following considerations: First, by extending O O E M methodology, O O W M reflects a 'natural view' of organizational processes in an object-oriented context (Hui, 1997).  39  Secondly, with the introduction of the Controller object, O O W M has the ability to separate what needs to be controlled and what does not. Such 'separation of concern' strategy ensures the autonomy and flexibility of each object. Another advantage of the Controller object is that it represents the owner of a business process and helps keep track of the overall status of each process. Thirdly, O O W M meets the demand for autonomy by decentralized units and allows locally operational autonomy while enforcing policies at the corporate level (Hui, 1997). Lastly, O O W M separates business rules from activity definitions. This approach can improve the flexibility and capability of exception handling in that a change of business rules does not require the change of tasks and activities.  3.8 Summary In this chapter, we examined the characteristics and classification of workflow exceptions.  We then reviewed some of the research on exception handling.  Advantages and limitations of the surveyed approaches were also discussed. Finally we introduced two research approaches, M O A P and O O W M , which constitute the theoretical foundations of this thesis.  40  4  MOAP-Based Workflow Model In this chapter we introduce our proposal of MOAP-Based Workflow Model  (MOAP-Wf). To demonstrate the M O A P - W f concept, we use a simple example in a business context. This example describes a computer purchase process:  The purchase process is initiated by a user who submits a purchase requisition (PR) to his/her Business Departmental manager. After the department manger approves it, the PR is passed to the purchasing department, which then issues a purchase order (PO) to the selected vendor. After the computer to the user for quantity purchasing department for payment. The whole is made.  is received, and quality then passes purchase  the purchasing department sends it verification. Upon verification, the invoices to the finance department process is completed when payment  4.1 Modified MOAP Architecture 4.1.1 Overview M O A P is the main construct in our workflow system architecture. To fit the fully distributed M O A P into a workflow context and integrate it with the O O E M Object concept, we made some modifications to its architecture. The modified M O A P architecture is shown in Figure 4-1.  41  Organizational Worker  Service Activity Coordinator  ProblemSolving Knowledge  Legend:  Procedural Knowledge Data Repository  Supervise / Control  Activity Agent  Access Request  Workspace  p.  [ O t h e r MOAPs  Figure 4-1: Modified Micro-Organization Activity Processor (adapted from (Woo and Lochovsky 1991) with modifications) Like its original architecture, this modified M O A P has the following types of entities:  data repository,  procedural knowledge,  problem-solving  knowledge,  workspace, activity agent, and activity coordinator. In addition to these entities, two new ones are proposed: Goal and Service. (These two constructs are explained in more detail in the next section.) One M O A P is always attached to a role/responsibility, which is held/implemented by a user or organizational unit (OU) (Woo and Lochovsky, 1991). The separation between activities and agents (i.e. user or actor) performing them makes it easy to cope with personnel changes (Kappel et al, 2000). Consider the purchasing process example. The Business Department and Finance Department are O U MOAPs. The Employee, Departmental Manager, and Corporate Accountant are represented as User MOAPs.  42  4.1.2 Goal A goal is what a M O A P targets to achieve, and can be treated as the MOAP's intention and the 'reasons' underlying work activity which answer the 'Why' and 'What-If questions (Yu and Mylopoulos, 1994) (i.e., why we need the process in the first place, what if one of the steps in a process is eliminated.) We propose that the goal construct be included in M O A P because of the following observations (Kueng and Kawalek, 1996) in business process redesign: •  Human action is driven by goals.  •  We need to be able to state what we want to achieve so that we are then able to define the necessary activities that a business process should encompass.  •  A clear understanding of goal is essential in the management of the process of selecting the best design alternative.  •  A clear understanding of goals is essential for it to be possible to evaluate the operating quality of a business process.  •  A clear expression of goals makes it easier to comprehend the organizational changes that must accompany a business process redesign.  Another interesting point is that people's inability to achieve goals helps explain why people generate exceptions and thus how processes emerge (Katzenstein and Javier Lerch, 2000). Thus including 'goal' in the M O A P model would also help identify exceptions and facilitate workflow evolutions. Exceptions can occur not only  43  because people do not do thing right, but also because people are not able to accomplish goals. The goal in a M O A P structure serves a number of purposes: •  As the intention and motivation of the M O A P or the user/OU it represents;  •  As the guide and target to design services and workflow activities;  •  As the criteria for the handling of other M O A P requests;  •  As the criteria to define exceptions and workflow evolution;  In an organization context, there are different levels of goals, e.g. organizationwide goals, OU-level goals, and individual goals. It also needs to be noted that there could be conflicts between the goals of different OUs and individual MOAPs. How to model and how to solve conflicts are beyond the scope of this thesis. We assume that goal conflicts, if any, are already solved. In the above purchasing process example, the organization-wide goal of the company could be increasing net value for shareholders, the Business Department's goals could be building good relationship with customers or promoting sales revenue, and the Finance Department's goals could be balancing the company's cash flow and making payment in two business days. Representation of Goal From a teleological point of view, a goal is a collection of future states of affairs, where state is a set of variables and values that those variables have at a given instant  44  (Weir, 1984). Similar, and albeit more specific, definitions can be found in business process modeling and artificial intelligence literature. For example, a goal is 'an end that needs to be achieved, for the sake of meeting some customer requirements (Narendra, 2000)'. A goal can also be specified as 'the desired state of the process domain' (Craven and Mahling, 1995). Since this thesis tries to show how the proposed approach (which may not be the best one) can handle exceptions, the details of modeling goals and the detail representation of goals are, therefore, not needed to demonstrate the approach. For the purpose of this thesis, we give an informal definition of goal as a set of future states of business objects that a M O A P is going to achieve by executing a set of tasks or requesting services from other peer MOAPs. We use a simple EBNF-style notation to represent goals: <goal>::=  "GOAL" <state> <bizObject> "END_GOAL"  For example, a goal of customer service could be 'purchase orders handled', which can be represented as: GOAL STATE Handled; BIZOBJECT P u r c h a s e O r d e r s ; END_GOAL The implementation of <state> is simplified as a word and full matching of the word satisfies the goal. A goal must be refined and decomposed until it is clear what specific actions must be performed to achieve the specified goal (Craven and Mahling, 1995). In our MOAP-Wf, goal is decomposed and organized in a goal-tree:  45  the higher level goals can be achieved by achieving lower level sub-goals. If a subgoal can not be further decomposed, we call it 'leaf-goal', which can be achieved either by a specific task or by service by other MOAPs or users. The following figure shows a general goal-tree diagram:  Figure 4-2 Goal Tree Diagram There are two basic types of relationships between sub-goals: AND-relationship and OR-relationship. We assume that these two relationships are sufficient for demonstrating the proposed approach in this thesis and do not consider more complicated ones such as E x c l u s i v e OR (XOR) and N - o u t - o f - M , which can be composed by the two basic relation types in some 'workaround' ways such as selection of transition conditions (van der Aalst, 2002). An AND-relationship means that all the sub-goals should be achieved in order to achieve the parent goal. For an OR-relationship, achieving one of the sub-goals suffices the achievement of parent goal. As shown in Figure 4-3, for the purchase process example, all the sub-goals of Approved (PR), Purchased (Item) and P a i d ( i n v o i c e ) should be achieved to successfully complete the whole process (achieving the top-level goal S u p p l i e d (Item)).  46  Figure 4-3 Goal for Purchase Process We assume that a goal tree can always be normalized. A normalized goal decomposition tree has the following characteristics (Li et al., 2001): •  Logic relationship exists and only exists among direct sub-goals of the same (parent) goal.  •  Homogeneity of logic relationship in the goal sets of the same level, i.e. there is only one type of relationship at the same level.  •  Heterogeneity of logic relationship in goal sets of adjacent levels goal tree.  For example, if GO  =  ( G l AND G 2 ) OR (G3A N D G4),  then the  decomposition will be normalized as GO = G a O R G b , where G a = G l A N D G2,Gb  =  G3 A N D  G4.  4.1.3 Service Service is the state transformation of an object from an ontological point of view. A Service comprises a series of actions performed by an object with the purpose of satisfying a request (Hui, 1997; Wand and Woo, 1999). For example, a purchasing staff handles 'purchase requisition', a corporate accountant handles 'request for payment'.  47  The relationship among goal, service, procedural knowledge (activities) and problem-solving knowledge are depicted as: first, services are guided by goals. How one service is defined and provided should comply with the related goal. We assume that it is a one-to-one relationship, i.e. one goal guides one service and one service 'serves' exactly one goal. The second assumption is that one service is implemented by at least one task (activity, function) in the procedural knowledge, or by services from other MOAPs. Lastly, services use problem-solving knowledge if necessary. One of the main components of problem-solving knowledge is business rules (cf. section 1.5). Service is also the interface or channel for inter-MOAP communications, e.g. receiving requests and delivering results. To publish and advertise its service, a MOAP: •  Sets the conditions of requests that other requesting MOAPs must follow. Some examples of the conditions include data required, who can send such requests and validation rules or constraints such as data/time etc.  •  Advertises with other MOAPs its capability, which specifies what the M O A P can deliver. The capability can be loosely defined as a replication of goal. One difference is that goal is internal to M O A P itself.  From an O O E M point of view, such communication is done via the changing of interface attributes (Wand and Woo, 1999). A MOAP's capability and the set of conditions can be viewed as 'interface attributes', which are accessible by other MOAPs.  48  4.1.4 Procedural Knowledge Procedural knowledge is well-thought-out, well-organized, well-tested and welladapted (Woo and Lochovsky, 1991), and can be regarded as 'default' execution of a workflow process. Procedural knowledge can described in terms of task/subtask hierarchy tree and the tasks should be able to be executed successfully in a specified sequence without encountering unexpected circumstances (Woo and Lochovsky, 1991). In our M O A P - W f model, we extend the procedural knowledge by including some other components and giving a concrete description of the original ones. The components of procedural knowledge include: task, pre-set of sub-goals, and M O A P selection. Tasks Task (or Activity) is a piece of work that forms one logical step within a process. Typically task is the smallest unit work scheduled during a workflow process enactment (WfMC, 1999). A similar definition is given by that tasks are the elementary or atomic work units that collectively achieve the workflow goal (Casati, 1998). We follow the concept of task atomicity that a task is the smallest unit and is to be executed to achieve one leaf-goal in the above goal hierarchy tree. Core components of a task include pre-conditions, post-conditions and functions (Woo and Lochovsky, 1991).  49  Pre- and post-conditions govern when a task should be started, completed or terminated. More specifically, Pre-conditions determine under which circumstances the task should be executed (Woo and Lochovsky, 1991). Post-conditions describe those things that must be true after the activity is executed (Woo and Lochovsky, 1991). Termination conditions determine the circumstances under which an activity should be stopped during execution. Pre-conditions can be loosely matched to the 'input' of IPO (input-processoutput) model, and post-conditions to 'output'. In this thesis, we use the same format as that of goal to describe post-conditions, i.e. business object with certain state. A task is capable of achieving a certain goal when one of the post-conditions matches the goal, i.e. the task leads to a 'state' that is the same as the state described by the goal. For the purchase process example, one pre-condition of task 'make payment' could  be  ' I s _ S u f f i c i e n t (Funds)',  and  one  post-condition  could be  ' p a i d ( i n v o i c e ) ' . Obviously, this task can achieve the goal ' p a i d ( i n v o i c e ) ' . A minimum representation of task can be shown as: <task>::=  'TASK" <Pre-conditions> <Post-conditions> <Functions> "END_TASK" Pre-Set of Sub-Goals Pre-set of sub-goals can be regarded as 'default' ones that the M O A P is going to achieve under normal circumstances, i.e. when there is no possible failure or exception. This is also the 'first try' of the MOAP. Only when encountering failure or  50  exceptions, will M O A P try other alternatives, e.g. other sub-goals with ORrelationship, by using problem-solving knowledge (cf. next section). For example, the pre-set of goals of the purchase process controller M O A P could be: PRE_SET_SUBGOALS SUBGOAL Approved(PR) SUBGOAL Purchased(Item) SUBGOAL Paid(invoice) END_PRE_SET_SUBGOALS Because the decomposition is an AND-relationship, all the sub-goals are required to achieve overall goal of S u p p l i e d (Item). Pre-Conditions of Goals By decomposing goals into sub-goals, we can have a clear picture of what needs to be done before the overall goal can be achieved. Super-goals depend on sub-goals. This dependency may also exist between sub-goals. One sub-goal may be achievable only if some other sub-goals have already been achieved. For a goal dependency, if G o a l l depends on  Goal2, Goal2  becomes G o a l l ' s  pre-condition, which must be a 'true state' before G o a l l can be achieved. In the purchase process example, the dependencies can be shown as: Purchased(Item): Paid(invoice):  has_preconditon(Approved(PR)) has_precondition(Purchased(Item))  These dependencies/pre-conditions can also lead to goal ordering - the sequence of goals that a M O A P must follow when pursuing the goals. In the above example,  51  the ordering of goals can be inferred as: -> P a i d  A p p r o v e d (PR)  -> P u r c h a s e d  (Item)  ( i n v o i c e ) . M O A P selection Similar to the Agent Selection rule in Kappel et al (2000), M O A P Selection rules determine which sub-goal should be executed by which M O A P and how the candidate M O A P should be decided. The selection is capability-based, i.e. a M O A P is selected according to its 'abilities' to execute tasks or to achieve certain sub-goals. As we discussed in the previous section, we assume that a MOAP's capabilities are published and made available to other peer MOAPs through its service advertising. For the purchase process example, the sub-goal achieved by the Business Department Manager; sub-goal be achieved by the Purchasing Department; and  A p p r o v e d (PR)  can be  Purchased (Item)  Paid (invoice)  can  is to be achieved  by the Finance Department.  4.1.5 Problem-Solving Knowledge Problem-solving knowledge provides assistance when the procedural knowledge is insufficient to perform an organizational activity (Woo and Lochovsky, 1991). It describes a way (or ways) for solving a particular class of problems (Wielinga et al., 1993). In our MOAP-Wf, we group problem-solving knowledge into the following categories:  52 Goal Decomposition As we discussed in previous sections, each M O A P has its own goal that can be decomposed into sub-goals. The top level goal is a separate component of the M O A P , while in procedural knowledge there is a pre-set of default sub-goals that the M O A P will initially try to achieve. In addition to the top level goal and pre-set of sub-goal, the complete goal decomposition hierarchical tree is stored in problem-solving knowledge. The notion is that the sub-goals other than the default pre-set ones are only needed when there is failure or exception, which makes the top level goal unachievable. New sub-goals can be added to the hierarchical tree if necessary when the M O A P tries to solve any failure or exception. Problem-Solving Tasks Problem-solving tasks are those tasks that are not included in procedural knowledge. These tasks are executed to achieve those sub-goals other than the pre-set ones. Another type of task in this category is that has not yet been approved to be stable (Woo and Lochovsky, 1991) to achieve default sub-goals in procedural knowledge. A problem-solving task is defined in the same way as one in procedural knowledge using the traditional IPO model.  53 Business Rules Business rules articulate the policies that guide a business process in its effort to achieve its goals (Keddara, 1999). Business rules usually determine who should do what tasks, how, and when the tasks should be done. We distinguish business rules from other components because business rules change frequently over time and modeling business rules separately makes it easier and more flexible to cope with such changes. Based on their functional scope, business rules can be classified into three categories according to their 'ruling' scope: organizational-wide rules, process-level rules, and individual MOAP-level rules.  •  Organization-wide rules are those that should be observed by all organizational units, processes, and individuals.  •  Process-level rules are local to process and govern the process' execution.  •  MOAP-level rules are local to individual MOAPs and govern how a M O A P handles tasks.  In general, the above 3-level business rules support inheritance: process-level rules inherit from organization-level rules and individual MOAP-level rules inherit from process-level rules. In this way, changes of lower level rules do not affect upper level rules while changes of upper level rules take effect in all lower level components.  54  The business rules in problem-solving knowledge deal with those conditions and M O A P section criteria that deviate from that of procedural knowledge. We identify two types of business rules according to their 'ruling' target:  •  Prioritization of Sub-Goals: If the default sub-goal in procedural knowledge cannot be achieved, the business rules decide which sub-goal in problemsolving knowledge should be tried, and if there are more than two sub-goals in an OR-relationship, which sequence of sub-goals should be selected.  •  Pre-Conditions of Sub-Goals: this type is identical to that of procedural knowledge. Pre-conditions define what states should be true before a sub-goal can be achieved.  4.1.6 From OOWM Object to MOAP As stated before, Object-Oriented Enterprise Modeling (OOEM) (Wand and Woo, 1999) is the theoretical foundation of both Object-Oriented Workflow Model (OOWM) (Hui, 1997) and the proposed MOAP-based workflow system architecture in this thesis. The modified M O A P structure can be regarded as an extension and enhancement  of O O W M  Object by incorporating procedure knowledge  communication capability.  55  and  OOWM Object  Modified MOAP  f  Goal Activity Coordinator Activity Agent Data Storage  1  Procedural Knowledge Problem-solving Knowledge  •*  »  • ] internal Attributes  ]  i ^Activities  j |  i •^i Business Rules  i i  i  ^  Workspace Service  \  J  i i  Interface Attributes  •(Service  !  C  1  1  J  Figure 4-4: OOWM Object vs. Modified MOAP The M O A P structure can be matched to O O W M Object as shown in Figure 4-4. A M O A P is differentiated from an O O W M Object with: •  A Goal component;  •  Separation of normal tasks from exception execution tasks.  •  A n activity agent component.  4.2 MOAP-based Workflow Model 4.2.1 Overview The  M O A P discussed in Woo and Lochovsky (1991) and this thesis is  independent and autonomous, and performs activities according to its own business rules. On the other hand, a workflow process usually involves different participants or agents of an organization. One M O A P may only perform one task and all the MOAPs involved need to communicate and cooperate with each other to complete the process. To bridge the gap between MOAP's fully-distributed nature and workflow process'  56  requirements of communication and cooperation, we introduce a special type of agent: Controller M O A P , which controls and is the owner of a workflow process. There is a requirement to monitor and manage the overall business process, because although the control and resources of the constituent sub-part are decentralized, there is often a need to place constraints on the entire process (Jennings et al., 1996). However, there is another issue to be addressed: to what extent the Controller M O A P should be 'controlling'. On one hand, the Controller M O A P is responsible for enforcing the business rules that govern one process and overseeing the execution of the process by other MOAPs. On the other hand, each M O A P decides the course of action independently and autonomously. This independency and autonomy could also facilitate exception handling by isolating and solving exceptions locally within a MOAP. To address the above issues, we propose a leveled and hierarchical workflow model with decentralized task execution by MOAPs.  4.2.2 MOAP-based Workflow Model In this section, we introduce the MOAP-based workflow system architecture, which serves as a basis for the exception handling mechanism presented in the next section. Figure 4-5 illustrates the MOAP-based Workflow Model (MOAP-Wf).  57  Result  Triggering MOAP or User  Controller MOAP Request  / / fact ,/+ Request Result / /  I—U  Request  Request  _*  MOAP n  MOAP 2  Request  Level 2  Result  I  i  MOAP 1  Level 1  Result  R  /  e  s  u  j  t  L  (Controller MOAP 2  Request  ^  Result  L MOAP n+1  Figure 4-5: A MOAP-Based Workflow Model In the MOAP-Wf, a typical workflow will work in the following way: 1. One M O A P or a User triggers the process by sending a request to the Controller MOAP; 2. The Controller M O A P then evaluates business rules, checks its own Procedural Knowledge, and decides the actions required to satisfy the request; 3. The Controller M O A P sends the requests to other MOAPs (e.g. M O A P 1 to M O A P n); 4. After all requests have been replied to and the results have been received, the Controller then sends the final result to the original requesting M O A P . When executing one step of the process, each individual M O A P can also send requests to other MOAPs, for example M O A P n can request service from M O A P n+1.  The M O A P being requested may become the second level Controller  58  (Controller MOAP  2 in Figure 4-5), which will be in charge of the second level of the  process (or sub-process). Another possibility is that there is no Controller in Level 2 workflow and whatever the M O A P does is not under control (e.g. MOAP  n+1 in  Figure 4-5). In this way, the whole workflow can be recursively defined. Controller M O A P We use the Controller M O A P to clearly identify what does and does not need to control for a workflow process. This concept is similar to the 'controller object' in O O W M (Hui, 1997). The Controller M O A P can also be a solution to OOEM's limitation of 'not captur[ing] the execution order of work' (Hui, 1997).  Enterprise View OOEM Object, MOAP (Vertical iew)  Purchaser  User Process View -OOWM Controller - Controller MOAP (Horizontal View)  Purchase  Request  Supplier  Purchase  Order  Shippment  Figure 4-6: An Example of Business Views As shown in Figure 4-6, the Controller object in O O W M can be regarded as from the process point of view: monitoring all the controller requests to and from objects, orchestrating all objects to complete the process. In our proposed workflow architecture, we follow the same concept although the construct and mechanism of orchestration might be different.  59  More specifically, a Controller M O A P in M O A P - W f is in charge of: •  Overseeing and controlling the whole process. Its goal reflects the whole process' goal. As we discussed in previous sections, M O A P is a distributed system and we need a mechanism to bridge the gap between MOAP's distributedness and the overall business process objective. By adding the Controller M O A P with a goal representing the goal of the business process, we try to make sure that actions and interactions of MOAPs can achieve the objective of a workflow process and resolve exceptions.  •  Evaluating business rules and requesting services from other individual MOAPs. Each individual M O A P handles one step of the process.  •  Serving as a 'central communication point' that coordinates among MOAPs.  By requesting services from other MOAPs, the Controller M O A P only specifies when and what the receiving MOAPs need to react to the request. How the services are provided is under the receiving MOAPs' own control. The receiving MOAPs, or service providers, have full autonomy to decide the detailed procedures according to their own business rules. With decentralized services structure, a workflow system should be more capable of handling exceptions in that: •  Each service-providing M O A P share the responsibility with the Controller M O A P for exception handling. While the Controller has to make sure the  60  process is completed, each service-providing M O A P is to solve problems if any occur in the process of handling service requests. •  The scope that is affected by exceptions is isolated and limited to local M O A P itself. Thus any problems encountered by one M O A P will have no impact on other MOAPs. Leveled Hierarchy Another major characteristic of the M O A P - W f is the leveled hierarchical structure. As we introduced in the previous section, a service-providing M O A P can further request service from other MOAPs. The requesting M O A P itself becomes the second level controller. Conceptually, the top-level Controller M O A P is an organization-wide M O A P , which deals with only one process - e.g. creating value for shareholders. In this leveled hierarchy, a Controller M O A P only communicates with those MOAPs of the same level and does not send requests to, monitor or control those of other levels. Thus the independency and autonomy are maintained. The hierarchy also enables multiple levels of abstraction, with higher level MOAPs not caring about the execution details of lower level MOAPs from which they request services. The leveled hierarchy also enables multiple levels of exception handling. A n exception is first handled at the level at which it occurs. If the exception is not solved, the correspondent M O A P generates an error and replies to the M O A P one level up. The latter then tries to solve the problem based on its own rules. This multiple-level  61  exception handling continues until a solution is found or the topmost level ControllerM O A P is reached.  4.3 Summary In this chapter, we introduced the M O A P architecture that was modified based on the one proposed in Woo and Lochovsky (1991) in order to meet the requirements of workflow management. We then proposed a MOAP-based Workflow Model (MOAPWf) that incorporates the controller concept of O O W M and is organized as a leveled hierarchy to facilitate exception handling.  62  5  Handling Exceptions in a MOAP-based Workflow System In the previous chapter, we introduced the MOAP-Based Workflow Model and  gave an overview of how a workflow is executed. In this chapter, we further elaborate the detailed Execution Mechanism. Based on the Execution Mechanism, we then explore how exceptions can be handled in the MOAP-based Workflow Model. In order to illustrate how exceptions are handled in the proposed M O A P - W f system, we will restate and revise the workflow example in Chapter 4. The example illustrates a computer purchasing process at a company.  The purchase process is initiated by a user who submits a purchase requisition (PR) to his/her Departmental Manager. The Departmental Manager checks to see if the user does have the need for a new computer, if it is within the department's capital expenditure budget, and other constraints, e.g. company policies. After approving the PR, the departmental manager passes it to the Purchasing Dept. Upon the approved PR, Purchasing Dept first decides if more detailed specification/requirements for the computer are needed. If yes, the Purchasing Dept will send a request to the IT Dept to get such specifications. The Purchasing Dept then prepares and sends a Purchase Order (PO) to a qualified vendor. Depending on the  63  availability of vendors and products, the Purchasing Dept might need to initiate a 'vendor selection and approval'process. When the computer arrives, the Purchasing Dept requests that IT Dept verify quality and/or quantity. After the verification process, the computer is handed over to the user and the Purchasing Dept sends a payment request to the Finance Dept. After an Accountant checking the required authorization, payment terms and conditions set in the PO, and verifies the completeness of required documents, the Cashier of the Finance Dept. makes final payment to the vendor and the purchase process is completed.  5.1 The Execution Mechanism 5.1.1 The Controller and Execution Schema A Controller M O A P starts to execute a process when it receives a request from a M O A P or a User. Figure 5-1 shows the execution mechanism. Usually the Activity Agent of the requesting M O A P puts its request in to the Controller MOAP's Workspace and the Activity Coordinator of Controller M O A P will pick up and handle the request (Woo and Lochovsky, 1991). (The workspace component is not shown in Figure 5-1.) After picking up the request from workspace, the Activity Coordinator then uses the following steps to complete the process:  64  Step 1: Compares the request and its service and determines if the request can be processed. If the request is beyond its capability, the Activity Coordinator simply replies to the requesting M O A P and rejects the request. Under normal conditions, the request should be valid and can be handled by the Controller M O A P because the requesting M O A P has a list of other MOAPs and their capabilities.  Step 2: Based on the pre-set of sub-goals, the activity coordinator then generates an activity path from procedure knowledge. In this step, several decisions should be made for that workflow process: •  A set of sub-goals (usually the same as the pre-set at this time) required to achieve the overall goal;  •  For each sub-goal, what task or service is needed;  •  For each service, the M O A P who will be providing that service.  As we discussed in the previous section, tasks are not specified in a rigid sequence, but rather are set up to support a goal (Craven and Mahling, 1995), and so are the services. This mechanism provides more flexibility in that the M O A P is 'free' to define or select tasks as needed on-the-fly instead of them having to be 'predefined'. The relationships among different components are as follows: first, subgoals suffice parent goal according to the sub-goal relationship. However, only top goal of a M O A P directly guides the service, which in turn satisfies requests.  65  Secondly, one sub-goal (leaf-goal in a goal tree) may be achieved by one or many tasks or services. After this step, the goal and necessary activity path are defined and written to the workspace ready for execution. The process' goal and activity path can be described by a value pair: G o a l : { G l , G 2 , ... Gn} T a s k / S e r v i c e : {Tl, T2,  Requesting MOAP or User  ..Tn |  SI,  S2,  MOAP or User  Request  _J  Controller MOAP  Results  i _  Task/ Service  Activity Agent  request  ...Sn}  result | Activity Coordinator  ••  )  Process Path  <^base o n ^  .consist ol  Goal  quide  Service  Procedural Knowledge  < ^ n s i s t o J > < c o n s i s t ^ T > Cconsist o f ; MOAP Selection  Pre-Set of Sub-goals  Figure 5-1: Execution Mechanism of MOAP-Wf Step 3: Task execution according to the activity path.  66  Task Definitions  Some tasks are executed automatically by software programs. Others may need to be done either by other MOAPs or users. The communication with other MOAPs is handled by the Activity Agent. Under normal conditions, the Activity Agent has the knowledge to direct requests to the right MOAPs. Otherwise the exception handling mechanism will be triggered (c.f. next section). Upon receiving results, the Activity Agent then hands over the results to the Activity Coordinator.  Step 4: Completion of the process and a return of the results to the requesting M O A P or User. The activity coordinator controls and monitors the execution of tasks to make sure that the specific goal is achieved. After handing over results to the requesting M O A P or User, the process is completed.  5.1.2 M O A P - B a s e d W o r k f l o w E x a m p l e The leveled workflow model for the purchasing process is shown in Figure 5-2. In the first level, the Controller M O A P only coordinates with and requests services from the Dept. Manager, Purchasing, and the Finance Department. The Controller M O A P does not have control of nor does it have information of how each service-provider M O A P implements. At the second level, Purchasing coordinates with the IT Dept and Vendor to provide 'purchasing' service, i.e. to get the required items. The Finance Dept provides payment service by further requesting services from the Accountant and the Cashier.  67  All the details of the second level workflow are encapsulated from the first level Controller M O A P .  PR  User  J  •(  Purchasing Process Controller MOAP  Request f o r ' approval  1 Request for purchase  V Request for payment  t  Dept Manager)  (  ,  Purchasing  )  IT Dept.  Request for checking  Request for verification ]  f Finance Dept.  ^  7 Request for / specification  [ Vendor j  * _  ^— Request for payment J4  [ A c c o u n t a n t ] [ Cashier  Figure 5-2 MOAP-Wf Structure for Purchasing Process The Controller M O A P for the purchasing process can be depicted as in Table 5 - 1 . A formal representation of knowledge is out of the scope of this thesis; rather we focus on utilization of different types of knowledge by M O A P . As such, we use plain English to describe the internal structure of a M O A P and omit the detailed descriptions and definitions of each knowledge item. For example, tasks and functions are listed without detailed pre- and post- condition descriptions. It should be noted that the sub-goals in Procedure Knowledge are a subset replica of that in Problem Solving Knowledge. As we discussed in the previous chapter, those subgoals in Procedure Knowledge are well-organized and have proven to be stable, and are to be achieved by the M O A P under normal conditions. Sub-goals in Problem Solving Knowledge include those that exist only for 'problem-solving' purposes.  68  For illustration purposes, we only show the internal architecture of the Purchasing Dept. while omitting that of other functional MOAPs. The internal architecture of Purchasing Dept. is shown in Table 5-2.  Table 5-1 Controller MOAP - Purchasing Process Goal  Supplied required items  Service  Handle purchase requests  Procedure Knowledge  Pre-Set of SubGoals  Problem Solving Knowledge  Condition  Sub-Goals  None  Approved(PR)  Approved(PR)  Purchased(item)  Purchase(item)  Paid(invoice)  Tasks or Functions  None /* This means that there is no atomic or executable task for this controller MOAP, which requests services from other MOAPs to achieve the overall goal.*/  MOAP Selection  Sub-Goal  MOAP  Approved(PR)  Dept Manager  Purchased(item)  Purchase Dept  Paid(invoice)  Finance Dept  Condition  Sub-Goal  Approved(PR)  Purchase(item)  Purchased(item)  Paid(invoice)  Business Rules  Goal Decomposition and Reasoning  —-  Sub-Goal  Supplied required item  OR  Supplied New Item  Supplied New Item  AND  Goal  Supplied temporarily Approved(PR) Purchased(item) Paid(invoice)  Supplied temporarily  AND  Got identical used items Purchased(item)  Problem-Solving Tasks  None  69  Activity Agent  Dept Manager  MOAP List  Purchasing Dept Finance Dept User Workspace  Temporary Data  Data Storage  List of users  Purchase requests  Table 5-2 M O A P - Purchasing Dept Goal  Purchased required item  Service  Purchase items for business as required  Procedure Knowledge  Pre-Set of SubGoals  Tasks or Functions  Condition  Sub-Goals  None  Got specification from dept. in charge  Got specification from dept. in charge  Found qualified vendor  Found qualified vendor  Issued(PO)  Issued(PO)  Shipped(item)  Shipped(item)  Verified(item)  Select vendors from database Place purchase order Deliver items to users  MOAP Selection  Sub-Goal  MOAP  Got specification from dept. in charge  IT Dept  Verified(item)  IT Dept  /*quantity and quality */  Problem Solving Knowledge  Business Rules  Shipped(item)  Vendor  Conditions  Sub-Goal  Received item from vendor  Verified(item)  Found qualified vendor  Issued(PO)  Issued(PO)  Shipped(item)  Goal  Sub-goals  Purchased(item)  70  AND  Got specification  Goal Decomposition and Reasoning  Received item from vendors Verified(item) OR Got specification  Got specification from dept. in charge Got specification from historical data  Received item from vendors  AND  Found qualified vendors Issued(PO) Shipped(item)  Activity Agent  Problem-Solving Tasks  None  MOAP List  IT Dept User Vendor  Workspace  Temporary Data  Purchase requests Specification  Data Storage  List of vendors List of purchase orders  Suppose an employee submits a purchase requisition (PR) for a new computer. Upon receiving a request, the Controller M O A P decides the process execution path by evaluating business rules to see if the request is within the scope of its goal and service. The process execution path is dynamically generated from goal/task/service evaluation and mapping. In this case, the path can be sub-goal 1: sub-goal 2:  Purchased (Item);  and sub-goal 3:  A p p r o v e d (PR);  Paid ( i n v o i c e ) .  These sub-  goals are to be achieved with services from other MOAPs. After the execution path is generated, the Controller M O A P then sends requests to related MOAPs according to the MOAP/Capability list (in the Activity Agent component) and M O A P selection criteria in Procedure Knowledge. In other words, it  71  first sends requests to Business Department Manger, and then based on the result received from Purchasing Department, sends a request to Finance Department for invoice payment. After the Finance Department makes the payment, the Controller M O A P sends notification back to the employee and closes the purchase process. It should be noted that how the Purchasing Department and  the Finance  Department handle the requests is unknown to the Controller M O A P . The Controller M O A P has no knowledge about what divisional rules apply and what steps are followed by each MOAP. For example, the Business Department Manager may check the employee's budget and year-to-date spending before approving the purchase requisition. These detailed steps are out of the 'control' of the Controller MOAP. Thus the autonomy and encapsulation of each M O A P are observed. Accordingly, each M O A P is responsible for handling exceptions, if any, at its level.  5.2 The Mechanism of Exception Handling 5.2.1 Overview Generally speaking, one of the most important objectives in the handling of an exception is to isolate it and limit its impact it has as much as possible. This strategy is supported by our proposed M O A P - W f with a leveled control structure. In MOAP-Wf, each M O A P is responsible for the execution of its own level of tasks and handling exceptions if any. All the task executions of one M O A P are encapsulated and hidden from other MOAPs and its higher level Controller M O A P .  72  Exceptions in one M O A P do not affect other MOAPs' operations, unless, for example, the M O A P returns errors to requesting MOAPs. As stated in Woo and Lochovsky (1991), the bias of the M O A P architecture is towards trying to use procedural knowledge whenever possible, and, failing that,problem knowledge, activity agent (for external communication), or a user. We use also this concept of precedence in our proposed exception handling mechanism. The general steps of exception handling are: 1. using the knowledge (procedural and problem-solving); 2. Soliciting help from other MOAPs (by activity agent); and 3. Consulting users. If, after the third step, the exception remains unsolved, then the whole process fails. We focus on the first two steps because they are to be handled by the system. Figure 5-3 gives an overview of the exception handling mechanism:  Exception GoalOriented Procedural and Problem Solving Knowledge  Other \-3+\ MOAPs  User  Exception Handled  OASIS blackboard  Figure 5-3: Overview of Exception Handling Mechanism At different steps, different mechanisms are used. At the first step, we use GoalBased Reasoning, while at the second step, OASIS Blackboard is also used.  73 Goal-Oriented Reasoning Goal-oriented reasoning starts from a goal. Upon processing failures or exceptions, the M O A P first finds out if there are other options to carry out tasks and achieve its desired goal. The identified options are usually based on procedural knowledge. After identifying possible solutions, the M O A P then examines the effects of each solution until a desired one is found. For each M O A P , goals are represented by a hierarchical tree in which super-goals are decomposed into sub-goals. Sub-goals are further decomposed into leaf-goals that can be achieved by certain atomic tasks or by the services from other MOAPs. During workflow execution, each M O A P find out which goal can be achieved by which task or service from other MOAPs by means-ends reasoning. Tasks are not specified in a rigid sequence, but rather are set up to support a goal, including handling new activities and exceptional situations (Craven and Mahling, 1995). The role of a goal in exception handling can be summarized as follows.  /. Multiple Level Exception Handling Within the goal hierarchical tree, the top level goal is achieved in a bottom-up fashion from the leaf-goals. Upon discovering any exceptions, the M O A P will first try to solve them at the current level where they occurred. If not successful, the immediate upper level goal is not achieved. The M O A P then moves up and tries to solve the problems at this next level (Figure 5-4).  74  Goal r  Process Variants  achieve Sub-Goals achieve i  Sub-Goals (Leaf)  f "achieve-"""  Figure 5-4 Goal-Oriented Process  2. Decoupling of Goal and Task/MOAP Facilitates Exception Handling Decoupling allows a M O A P have multiple alternatives to achieve one goal. If one task or M O A P fails to deliver the required results, the M O A P can try other similar tasks or request services from other MOAPs. With the goals as criteria, a M O A P is 'free' to choose different courses of action, as long as the actions can achieve the desired goals and satisfy business rules and constraints. Unlike traditional process modeling which is more rigid and difficult to change, the M O A P - W f is more flexible and different process variants can be generated dynamically (Figure 5-6). OASIS Blackboard It is possible that none of existing problem-solving knowledge and procedural knowledge will solve the problem and meet the desired goals. In this case, the Controller M O A P will try to ask for assistance from other MOAPs. We apply the OASIS Blackboard and Form concepts that were proposed by Martens and Woo (1997). OASIS (Organization Activity Support and Information System) is fully decentralized and distributed in that each task has a separate  75  blackboard from which the task starts to execute. In MOAP-Wf, the Workspace is used as a blackboard and the Activity Agent is in charge of soliciting help from other MOAPs in the case of an exception. If, based on predefined parameters such as time, no M O A P can handle the request, the Activity Agent then assumes that the task has failed. In this case, the M O A P will return errors or contact and pass the unsolved exception to the user.  5.2.2 The Logical Steps Based on the discussion in previous sections, we now formalize the workflow execution and exception handling in the following logical steps, which serve as the implementation design for the exception handling mechanism described in the next section. The logical execution and exception handling steps are shown in Figure 5-7.  Stage 1: Planning In this stage, the M O A P initializes some required parameters for a new workflow process instance and prepares for execution. The parameters include input data and specification of preferences of the workflow instance. The general steps are as follows:  1. Goal Selection and Initialization Under normal circumstances, the pre-set sub-goals in procedural knowledge will be selected and initialized. We classify a goal into three states: W A I T I N G , and  FAILED.  A goal in  WAITING  SUCCESS,  state is currently initialized and the M O A P is  waiting for the execution results of related tasks or for a response from other MOAPs.  76  S U C C E S S means the goal has been achieved and F A I L E D indicates that the selected task or M O A P failed to deliver the desired results.  2. Means-End Analysis In this means-end analysis step, the M O A P evaluates and identifies what tasks or services from other MOAPs can achieve those sub-goals initialized in the previous step. The M O A P thus maintains a mapping between tasks/services (the 'means') and sub-goals (the 'ends'). The sub-goals are usually the smallest units that are not able to be further decomposed and can be immediately achieved by tasks or services. We use a simple value pair to represent the mapping: means_ends(task  |  service,  goal)  3. Scheduling By scheduling, the M O A P decides the sequence in which goals are to be realized. This sequence is usually generated from pre-conditions of sub-goals stored in procedural knowledge or problem-solving knowledge.  77  1  JL  Exception Handling Using Goals  Planning goal selection means-ends analysis • scheduling 1/  \i/  r  Execution task execution • service requesting  SUCCESS(sub-goal) /  Exception Handling Using Tasks/MOAPs Reported Failure, Non-response  Exception Handling  Evaluation  • result evaluation goal state update  -Evaluated Failure SUCCESS(top-goal)  4 Figure 5-5 MOAP-Wf Execution/Exception Handling Diagram We use a queue structure to represent the schedule. The goal in the front of the queue is tried first and removed (dequeued) if it is successfully achieved. s c h e d u l e ( G l , G2 ... Gn) dequeue(schedule, Gl)  / * i f Gl is  achieved * /  Stage 2: Execution After certain initialization and preparation steps in the planning stage, actual process execution starts. Two steps involved in this stage are task execution and service requesting. If pre-conditions are met, e.g. no goal dependency or resource sharing conflicts, these two steps can happen in parallel.  78  The two steps are represented as: execute(task) r e q u e s t ( s e r v i c e , moap) /* r e q u e s t s e r v i c e from MOAP moap. */ Stage  3:  Evaluation  The final stage is evaluation, in which the results returned by a task or M O A P are evaluated according to the related sub-goals. If the desired results are achieved, the state of the sub-goal is updated and set as ' S U C C E S S ' . At this time, the overall top level goal is also evaluated. If the top goal state is also ' S U C C E S S ' , then the whole workflow process closes, otherwise another execution-evaluation loop starts and tries to achieve the next sub-goal. The evaluation steps are represented as: IF p o s t - c o n d i t i o n ( t a s k ) = s u b - g o a l U p d a t e _ s t a t e ( s u b - g o a l , 'SUCCESS'); IF s t a t e ( t o p - g o a l ) = 'SUCCESS' Close(worklfowProcess);  Stage  4: Handling  Exceptions  This stage is an optional one that is to be triggered by failures and exceptions in both the execution and evaluation stages. At different stages, there are different types of failures and exceptions, which are classified as follows:  Type 1 - Change of Workflow Sequence This type of change or exception is usually caused by changes  in the  preconditions and constraints of a workflow process, which in turn change the sequence of goal accomplishments.  79  One  example is where the vendor changes the terms from on credit to  prepayment, which results in the change of workflow sequence, i.e. the (pro-forma) invoice needs to be paid before the Purchase Dept can receive the item from the vendor.  Type 2 - Evaluated Goal Failure An evaluated failure is one in which a goal is not achieved because one or more sub-goals fail depending on the sub-goal relationship. If the sub-goal relationship is ' A N D ' , failure of any one sub-goal can scuttle the parent goal. However, if the subgoal relationship is 'OR', the parent goal can only be evaluated to be 'failed' if all sub-goals are not achieved. For example, an exception is raised by the Purchasing Dept when no supply (or capable vendor) is found in the marketplace. In this case, the goal Purchasedltem of Controller M O A P is failed. The failure of goal Purchasedltem consequently causes the parent goal SuppliedNewItem to fail. Upon finding such an exception, the Controller M O A P will try other alternatives. For example, it might find an equivalent used item to satisfy the user's request (pursuing the goal SuppliedTemporarily).  Type 3 - Non-Response/Unavailable MOAP Node This type of exception happens when a M O A P does not respond to a request in a timely fashion or a M O A P is not available. In both cases the requesting (calling) M O A P will try to find other capable MOAPs to provide services. The former case is similar to the time control concept of O O W M , in which the Controller object will  80  assume the whole workflow failed if it does not receive a reply from request recipient object by a preset deadline. One example is that the Dept. Manager is not available to approve the PR. So the Controller M O A P sends a request to the General Manager instead.  Type 4 - Reported Task/Service Failure This type of failure occurs at the execution stage and can be further categorized into two subtypes: service failure and task failure. A service failure occurs when a M O A P does respond to service requests, but fails to meet the requirements of service, i.e. fails to achieve the desired goal. Service failure is external to the requesting MOAP. To solve such an exception, the requesting M O A P will try to find other capable MOAPs or execute capable tasks if any, to handle the request. An example would be if the IT department (MOAP) fails to provide specifications for the required items, the Purchase Dept. will try to get relevant historical data (task) from corporate business systems. On the contrary, a task failure happens within, i.e. internal to, a M O A P node when a task execution fails to achieve the desired goal. In this case, the M O A P will try other capable tasks (means). The example assumes that the required items are not in the user's or the department's budget. Another step is added to the workflow process, Modifying Budget, to solve the exception. This step is done before the Dept. Manager approves the PR. All other steps will remain unchanged. It should be noted that a Type 4 exception may also imply a Type 2 one. A task/service failure may ultimately fail a goal. However, the key difference between 81  the two types is that Type 4 is immediately after the execution, while Type 2 exception is failing the top level goal in the evaluation stage. In summary, depending on the underlying causes, several problem-solving methods can be used, i.e. executing another task, requesting service from another M O A P , achieving another sub-goal as a replacement, soliciting help from other MOAPs, and finally consulting users. The exception handling function can be illustrated as follows: //Exception Handling Function BEGIN_EXCEPTION_HANDLING SELECT CASE method: 1:  means = means_end(?<>currentMeans, c u r r e n t G o a l ) ; / / t r y o t h e r means ( t a s k o r s e r v i c e t o a c h i e v e // c u r r e n t g o a l  2:  c u r r e n t G o a l = nextGoal(subGoals) ; //set c u r r e n t G o a l as another sub-goal i n an // OR d e c o m p o s i t i o n which i s s t o r e d i n // p r o b l e m - s o l v i n g knowledge;  3:  blackboard(subGoals); // The MOAP w i l l b r o a d c a s t // i t s d e s i r e d sub-goals i n form o f b l a c k b o a r d // t o s o l i c i t h e l p from o t h e r MOAPs ( t h a t may // n o t be i n t h e MOAP's l i s t .  4:  consult(user); //as t h e l a s t s t e p , i f e x c e p t i o n remains, t h e // MOAP w i l l c o n s u l t u s e r s .  END SELECT END EXCEPTION HANDLING  Depending on the method chosen, exception handling may follow different paths as shown in Figure 5-5. If the solution is to try other means (above-mentioned Method 1), the process will continue with the execution stage. However, if the  82  solution is to try other goals (Method 2), new planning and scheduling might be necessary, i.e. the process will continue with the planning stage.  5.2.3 Comparison of ADOME-WfMS and MOAP-Wf In this section, we demonstrate the exception handling mechanism by using the above example. As we discussed in Chapter 3, A D O M E - W f M S is one of the most comprehensive research works that we have surveyed. We do a comparison study by applying the A D O M E - W F M S model on the same exceptions. Some modifications are made to match the above example and the one provided in Chiu 2000. Comparison of Normal Processes Figure 5-6 (modified based on Chiu 2000) shows an example of an activity diagram for a purchasing process based on A D O M E - W F M S model. In A D O M E - W F M S , an activity is recursively decomposed into sub-activities and tasks, which are the smallest units. (The notation is similar to the one of processsubprocess-task in this thesis and other research work. We use 'activity' and 'process' interchangeably for this comparison study.) The requisition workflow (i.e. purchasing process) is composed of the following sub-activities: purchase request, procurement, payment, and receive/check goods. There are two possible execution paths depending on the terms of the purchase order: credit or cash on delivery (COD). During execution, one of the paths is followed and enforced by the Activity Executor.  83  (a): requisition (repeatable) Supplier not found  (replaceable)  (b): procurement begin  (c): purchase request  (repeatable)  (critical)  (critical)  (d): payment (critical, manual) begin  Figure 5-6 ADOME-WFMS activity model example As a conventional activity-based model, the A D O M E - W f M S treats an activity as a composition of multiple inter-dependent tasks that need to be coordinated, scheduled and executed. The coordination, scheduling and execution are centered on the Activity Executor of the system. In MOAP-Wf, we adopt a different approach as described in previous chapters. Our approach is goal- and agent- oriented. We model a workflow as a decomposition hierarchy of goals, and the workflow is enacted by cooperation between MOAPs, which are intelligent  and autonomous  agents from an artificial  intelligence  perspective. The following figure shows the modeling and enactment in MOAP-Wf.  84  A: goal decompositon  (Approved PR  Paid invoice  B: workflow enactment User  Controller MOAP  -PR-  ~| Request rTto approve Dept Manager  Request to purchase | Purchasing Dept  Request to pay  Finance Dept  Figure 5-7 A Purchase Process in MOAP-Wf. In Figure 5-7 we show only one level of goal decomposition, the top level goal of Supplied Item can be achieved if all of sub-goals - Approved PR, Purchased Item, and Paid Invoice - are accomplished. Part B of the figure shows that each of the sub-goals can be achieved by three MOAPs: Dept. Manager, Purchasing Dept., and Finance Dept., respectively. Compared to A D O M E - W F M S , our M O A P - W f model is more dynamic and flexible: •  Instead of following a fixed activity path, MOAPs decides a course of action dynamically at runtime depending on the status of goal achievement and resources available for accomplish the goals. From this perspective, M O A P W f is 'descriptive' while A D O M E - W F M S is 'prescriptive' (Jablonski, 1994).  85  Because of the prescriptiveness of A D O M E - W F M S , all of the workflow process and subsequent activities and tasks must be well known and fixed in advance. The only way to handle an exception is to pre-define certain compensation tasks (exception handlers). The number of handlers is limited and it is very difficult, if not impossible, to identify all the possibilities of workflow execution. Since all the activities/tasks are rigidly bound together, it is not easy to make changes to the process definition. If an exception cannot be solved, a new process definition becomes necessary. Defining a new process triggers other issues like how to migrate running instances to new definitions. Being descriptive, M O A P - W f does not 'prescribe' detailed processes/tasks in advance. Each step to execute relevant tasks and to accomplish its goals is decided at runtime by each MOAP.  Exceptions can be solved by a M O A P  trying different tasks, sub-goals or requesting services from other MOAPs. In A D O M E - W F M S , the Activity Executor controls everything, including all activities and tasks. In M O A P - W f the Controller M O A P only controls the immediate level of sub-goals. Each M O A P is free to decide how its goal should be achieved. For example, the Purchasing Dept. has full control of its own goal 'Purchased Item', which defines how an item should be purchased, how to find vendors and how to pick one from the choices. Because of the separation of responsibility, M O A P - W f has improved exception handling capability. Possible exceptions are decomposed and  86  distributed among multiple MOAPs for handling. And the 'success rate' of solving exceptions can therefore be improved. Comparison of Exception Handling In A D O M E - W F M S , handlers must be pre-defined to solve any failures or exceptions. This approach thus requires that exceptions be identified and modeled into the workflow. A typical exception handler itself is modeled as a sub-activity and is in the form of an event-condition-action rule (or E C A rule).  Table 5-3 Exception Handling Example in ADOME-WFMS Activity/Task  Exception Condition  Exception Handling Resolution  1. Budget Check  The software that checks budget raises 'Budget_Exceeded'.  The task's re-execution mode is 'critical' and there is no specific handler. The whole 'purchase request' activity fails, thus the whole workflow fails.  2. Procurement  Vendor changes payment term of 'credit'.  Since there is another replaceable branch, the activity executor would attempt the 'COD' branch instead.  As shown in Table 5-3 (adopted from Chiu 2000), a resolution is defined for each possible exception. Any exceptions other than those pre-defined ones will fail the whole workflow. In the following two sections, we illustrate how the above two exceptions are handled in MOAP-Wf.  Exception  1: Budget  Exceeded  (Reported  Failure)  In A D O M E - W F M S the Activity Executor is in control. The approach in M O A P W f is more flexible in that each M O A P is responsible for execution and exception  87  handling. The exception 'Budget_Exceeded' is handled by Dept. Manger instead of the Controller MOAP. The exception handling process is shown in Figure 5-8.  Figure 5-8 Handling 'Budget_Exceeded' Exception in MOAP-Wf. After the execution of task 'Check Budget', the goal of 'Approved PR' is not achieved (the state of the goal is WAITING). By doing a means-end analysis (as illustrated in previous sections), the Dept. Manager then tries another task - 'Modify Budget'. After this step, the result is evaluated that the budget is met and goal is achieved. It should be noted that 'Modify Budget' is only one example. There could be multiple solutions that the Dept. Manger can decide among dynamically at workflow runtime. These new tasks can be added to the execution without affecting others.  Exception  2: Procurement  (Change  of  88  Sequence)  Because each M O A P decides the course of action (i.e.  workflow steps)  dynamically at runtime, handling the second sample exception (vendor changes payment terms) is straightforward. In this case Purchase Dept. is responsible for solving the problem since without payment it cannot achieve the goal of 'Purchased Item'. Originally the Purchase Dept. does not need to care about payment because all purchases are to be made on credit. The actual workflow is depicted in Figure 5-9.  A: goal decompositon  (Approved PR  I Prepaid  B: workflow enactment User  PR-  Controller MOAP  Request  Request to purchase  to approve  i_ Purchasing Dept  Dept Manager  Request to pay  Finance Dept  Figure 5-9 Handling 'Payment Terms Change' Exception in MOAP-Wf To solve the problem, the Purchasing Dept. will send a payment request to the Finance Dept. so as to achieve the sub-goal 'Prepaid'. This, in turn, helps achieve the overall goal of 'Purchased Item'. It should be noted that the accomplishment of subgoal 'Prepaid' will automatically achieve the Controller MOAP's goal, 'Paid Invoice'  89  (the dotted arrow in Figure 5-9). So the Controller M O A P will no longer need to coordinate with the Finance Dept. because the goal 'Paid invoice' is already achieved. Summary of Differences In the following table, we summarize some of the differences between A D O M E W F M S and M O A P - W f that we have proposed in this thesis.  Table 5-4 Comparison of ADOME-WFMS and MOAP-Wf.  Workflow model  ADOME-WFMS  MOAP-Wf  Features  Activity-based  Goal-based, Agent-based Goal-oriented,  Event-driven.  Multiple levels of control (Controller MOAP and other MOAPs.)  Single centralized control (Activity Executor)  Process/task path  Dynamically decided at runtime  Pre-defined at build-time  Type(Jablonski, 1994)  Descriptive  Prescriptive  Exception Handling  Solution decided dynamically based on goal (means-ends analysis)  Exceptions and handlers must be define a priori  Recursive exception handling (exceptions encountered by handler)  Yes  No  Knowledge management (Al perspective)  Yes  No  Capability of handling some unexpected exceptions  Yes  No  Workflow type  Dynamic workflow (Du and Elmagarmid, 1997)  Core process + Exception process  Execution  90  5.3 Summary In this chapter, we introduced the exception handling mechanism of MOAP-Wf. First, we elaborated the workflow execution schema under normal conditions. We focused on the utilization and application of different types of knowledge that MOAPs hold. We then explored the exception handling mechanism based on goalbased reasoning and the OASIS blackboard. The exception handling mechanism is modeled as four integrated stages - planning, execution, evaluation, and handling exceptions. Different types of exceptions were also identified. Lastly, we did a comparison of our M O A P - W f model and the A D O M E - W f M S by applying some exception cases.  91  6  Simulation of MOAP-Wf In this chapter, we design a simulator to show how the M O A P - W f architecture  can be implemented to execute normal workflow processes and handle exceptions. We demonstrate this simulator by using some workflow cases. There are several advantages of using simulation (Mohan et al., 2002): 1). This type of simulation is often sufficient to give the users a feeling of the system and let them judge whether any functionality is missing, wrong, or unnecessary. 2). Simulation prototypes represent the concepts to the developers of how the business process might be implemented. 3). Users' evaluation of the prototype can point out alternative courses for a business process, new missing process steps, previously undetected exception conditions, or new ways to visualize information.  6.1 Development Platform The workflow simulator is developed as a web-based application using: •  Visual Basic Scripting Version 5.0  •  Active Server Page 3.0  •  Microsoft Window 2000 Server with Internet Information Server  •  Microsoft Access 2000 Database  We adopt this web-based approach because:  92  •  Web client programs (browsers) are available for all popular computing platforms and operating systems, providing access to information in a platform independent manner (Bentley et al., 1997).  •  Browsers offer a simple user interface and consistent information presentation across these platforms (Bentley et al., 1997).  •  Object-oriented features are supported by Visual Basic Script.  •  Database connections are supported by VBScript and Active Server Page.  6.2 System Design The M O A P - W f Simulator is composed of two parts: functional modules and a database. Functional modules do actual computations and the database maintains all workflow definitions, including MOAP, goal decomposition and task definitions. The results of the workflow processes are also stored in the database. With database support and functional modules, this simulator has several advantages as compared with the FlexFlow simulation tool (Mohan et al., 2002): FlexFlow tool does not use real data and contains little or no real functionality (Mohan et al., 2002). On the contrary, our simulator does have real functionality, one example being the logic algorithm. Real data, albeit very simple, is stored in the database. In the FlexFlow simulation tool, the information that appears in response to a client's request is faked or static, and report contents are hard-coded (Mohan et al.,  93  2002). Our simulator responds to requests and generates reports dynamically from the database. A brief introduction to FlexFlow is presented in Appendix A .  6.2.1 Database Design The workflow database is the central repository of the simulator and holds all the M O A P definitions, procedural knowledge and problem-solving knowledge. A formal detailed representation of MOAP's knowledge is out of the scope of this thesis. For the purpose of the simulator, we limit the scope to goal decomposition and simple task definition, an example being which task can achieve what goal. We do not consider further details and other constructs introduced in previous chapters. The entity-relationship diagram of the database is shown in Figure 6-1.  Figure 6-1 Entity-Relationship Diagram When it starts up, the simulator will connect to the database and perform initialization if necessary. After a workflow process is completed, the status of that process is written back to the database. The status could be 'waiting', 'success' or  94  'failed'. As such, the database does not maintain additional information about detailed workflow steps, like what has been done and when during workflow execution. These detailed workflow steps are handled as 'session' data, which is maintained in system memory and is disposed of when the process is finished or the simulator is shut down.  6.2.2 Functional Modules The simulator has the following functional modules: M O A P module, exception module, and initialization module. The M O A P Module is the main function of the simulator. The Exception Module simulates different types of exceptions. The Initialization Module reads and writes M O A P and process data to and from the database. The mapping of modules to simulated functions is shown in Table 6-1.  Table 6-1 Simulator Functional Modules Module (sub-module)  Simulated Workflow Function  Web Pages  MOAP Module  Main function of MOAP-Wf  Flow.asp  Evaluation sub-module  To evaluate goal state based on those of sub-goals  Evaluate.asp  Goal selection submodule  To decide next goal to work on based on current workflow state and pre-conditions of each goal.  findNextGoal.asp  Task/MOAP Selection sub-module  To find task or MOAP that is capable of achieving certain goals.  findCapableTaskMoap.asp  Execution sub-module  To execute selected task or send request to capable MOAP.  executeTask.asp  Exception Module  To simulate workflow exception.  Exception.asp  Initialization Module  To read MOAP and process information from database and initialize web session.  Initialize.asp  95  sendRequest.asp  All the modules are written in Visual Basic Scripting language. The algorithm and control flow of these modules is presented in Appendix B. Appendix C illustrates the page transition of the web-based simulator application. Figure 6-2 shows an example of the Evaluation Module. i f s e s s i o n ( s t r ) . i t e m ( g o a l ) = "AND" then ' i f c u r r e n t g o a l ' s s u b g o a l r e l a t i o n = AND isSuccess = true i s F a i l = false For i = 0 t o ubound(arrGoal) vgoal = a r r G o a l ( i ) state = session(moap).item(vgoal) i s S u c c e s s = i s S u c c e s s AND ( s t a t e = " Success") i s F a i l = i s F a i l OR ( s t a t e = " F a i l e d " ) Next End i f i f s e s s i o n ( s t r ) . i t e m ( g o a l ) = "OR" then ' i f c u r r e n t g o a l ' s s u b g o a l r e l a t i o n = OR isSuccess = f a l s e i s F a i l = true For i = 0 t o ubound(arrGoal) vgoal = a r r G o a l ( i ) state = session(moap).item(vgoal) i s S u c c e s s = i s S u c c e s s OR ( s t a t e = "Success") i s F a i l = i s F a i l AND ( s t a t e = " F a i l e d ") Next End i f i f i s S u c c e s s = t r u e then s e s s i o n ( m o a p ) . i t e m ( g o a l ) = "Success" end i f i f i s F a i l = t r u e then session(moap).item(goal) = " F a i l e d " end i f  Figure 6-2 Example Code of Evalution Module  6.3 Simulation of MOAP-Wf In this section, we demonstrate the handling of different types of exceptions (cf. Chapter 5) with the M O A P - W f simulator. A workflow process is started when a user  96  submits a new request (as shown in Figure 6-3), which is written to the database and its state is set as 'Waiting'.  IE'  MoapWorkflow Demo  |  Overview  |  Process  |  MOAP  Submit Purchase  |  Exception  |  About  Request  To submit a new purchase request, fill in the following form and click 'submit'. I t e m r e q u i r e d : Computer Quantity: 1 S p e c i f i c a t i o n : IBM T h i n k p a d P e n t i u m 4 / 256MB Memory / 20GB H a r d d r i v e / DVD-ROM  Submit  Reset  te I i  © 2 0 0 2 Hurjin Q u o  Figure 6-3 Simulation - Creating New Process Upon receiving a user's request, the Controller M O A P starts to process it based on its procedural knowledge, including goal decomposition and pre-conditions. In this example, two sub-goals are found and accomplishment of one of them can achieve the top goal - Suppliedltem. This is because the sub-goal relation is 'OR'. If the subgoal relation is ' A N D ' , all sub-goals must be achieved. The Controller M O A P will try to achieve goal SuppliedNewItem because it is the default goal according to procedural knowledge (as shown in Figure 6-4).  97  MoapWorkflow Demo  Overview  |  Process  |  MOAP  |  Exception  |  About  [Current* Moap I Control lerMoap .CurrentGoal  [Suppliedltem  ONE of the following subgoal(s) should be accomplished: 9  SuppliedTemp  9  SuppliedNewItem  m NEXT»  ('•*-' = next subgoal to be accomplished.) © 2 0 0 2 Huijin Guo  Figure 6-4 Simulation - ControllerMOAP Goal Decomposition The goal SuppliedNewItem is further decomposed into sub-goals: ApprovedPR, Purchasedltem, and Paidlnvoice. A l l these sub-goals should be achieved because the relation is 'AND'. Because ApprovedPR is a ' L E A F ' goal, it can be achieved by an atomic task or service from other MOAPs. By searching its task and M O A P list, the Controller M O A P then sends the request to DeptManager, which is one capable MOAP. Upon receipt of the request, DeptManager follows the same steps as Controller M O A P does, i.e. decomposing goals, executing tasks, or requesting services from other MOAPs if necessary. In this case, an atomic task CheckBudget is found in its procedural knowledge. The DeptManager will then try to do this task. We assume that there is a 'blackbox' application that can actually complete the function of  98  CheckBudget. For this simulator, we allow the user to choose possible results so as to 'simulate' it. The execution of a task can be either 'Completed Successfully' or 'Failed' (Figure 6-5).  MoapWorkflow Demo  Overview  |  Process  |  MOAP  |  Exception  |  About  [Current Moap DeptManager  Current Goal  ApprovedPR  Executing [Task:  CheckBudget oCompleted Successfully G'Task Failed  i  NEXT»  © 2 0 0 2 Huijin G u o  Pfll '  Figure 6-5 Simulation - Task Execution If task CheckBudget fails because the cost exceeds the available budget balance, DeptManager will look into its problem-solving knowledge and find other capable tasks by means-end analysis. In this example, task ModifyBudget is found and then executed (Figure 6-6). This demonstrates the handling of exception case Type 4 Reported Failure (task failure).  99  IF  MoapWorkflow Demo  Overview  1  Process  |  MOAP  |  Exception  |  About  Current Moap, [ DeptManager [Current Goal  |ApprovedPR  ONE of the task(s) can be executed to achive the goal: 9  Modify Budget  9  CheckBudget  X Failed  NEXT»  ('"*-' = Task to be executed.) FT|r  Figure 6-6 Simulation - Tasks by DeptManager If DeptManager is not available, the request will be sent to the next capable M O A P , which is GeneralManager in this example. Figure 6-7 depicts the handling of this Type 3 exception case - Non-Response/Unavailable M O A P Node.  100  El  MoapWorkflow Demo Overview  |  Process  |  MOAP  |  Exception  |  About  Current Moap 1 ControllerMoap Current Goal  IApprovedPR  The following capable MOAP(s) has(have) been found: Mm  9  GeneralManager  9  DeptManager  0  N/A  NEXT »  ('-«-' = MOAP to be sent request.) © 2 0 0 2 Huijin Guo  Figure 6-7 Simulation - Request Sent to Another Capable MOAP GeneralManager will also follow the general steps of goal decomposing, task executing, and service requesting. Upon successful completion of GeneralManager, the state of ApprovedPR is set to 'Success' and the Controller M O A P will continue with next goal, i.e. Purchasedltem (as shown in Figure 6-8).  101  MoapWorkflow Demo  Overview  |  Process  Exception  MOAP  |  About  [Current-Moap |ControllerMoap Current Goal  |SuppliedNewItem  A L L of the following subgoal(s) should be accomplished: 9  Paidlnvoice  9  Purchasedltem  0  ApprovedPR  \J Done  I  NEXT»  |  ('**-' = next subgoal to be accomplished.)  m  _  g  Figure 6-8 Simulation - Next Goal of Controller MOAP The request is sent to PurchasingDept because it is the M O A P capable of achieving the goal of Purchasedltem. PurchasingDept also follows the steps of selecting sub-goals, deciding work sequence, and evaluating results based on a subgoal relation. The goal Purchasedltem is decomposed  into GotSpecification,  Receivedltem, and Verifiedltem. The first sub-goal to be achieved by PurchaseDept is GotSpecifiction, which can be accomplished by requesting service from ITDepartment. If ITDepartment fails to provide specifications, PurchaseDept will try to get specifications from historical business data. The handling of such Type 4 exceptions - Reported Failure (service failure) is shown in Figure 6-9.  102  MoapWorkflow Demo  Overview  |  Process  Exception  MOAP  |  About  Current Moap iPurchasincjDept Current Goal ,' iGotSpecification  ONE of the following subgoal(s) should be accomplished: 9  GotSpecHistoricalData  0  GotSpecFromDept  X Failed  |;  NEXT»  I  ('•*-' = next subgoal to be accomplished.)  |  © 2 0 0 2 Huijin Guo  Figure 6-9 Simulation - Service Failure Under normal circumstances, goal Receivedltem can be achieved by sub-goals: FoundVendor, IssuedPO, Shippedltem. However, exceptions could occur when the vendor changes payment terms; for example, from on credit to pre-payment. In this case, another sub-goal Paidlnvoice is necessary  for the accomplishment  of  Receivedltem. So a request will be sent to FinanceDept by PurchasingDept (as shown in Figure 6-10).  103  MoapWorkflow Demo  Overview  |  Process  |  MOAP  |  Exception  |  About  .Current Moap | PurchasingDept Current Goal  Receivedltem  ALL o f the following subgoal(s) should be accomplished: 9  Shippedltem  9  IssuedPO  \J Done  9  FoundVendor  \f  A  Paidlnvoice  Done  NEXT»  HI  Figure 6-10 Simulation - New Subgoal of PurchasingDept When the process of Purchasedltem by PurchasingDept is completed, the result is sent back to Controller MOAP. Under normal conditions, the next step of the Controller M O A P will be to request that FinanceDept achieves the goal Paidlnvoice. However, in the above example, the goal is already accomplished by FinanceDept upon request from PurchasingDept. In this case, no additional request is necessary (as shown in Figure 6-11). This solves exception case Type 1 - Change of Sequence.  104  I  MoapWorkflow Demo  Overview  |  Process  MOAP  |  Exception  About  Current Moap |ControllerMoap Current Goal  | Pa i din voice  The goal: Paidlnvoice is already achieved by MOAP: FinanceDept  |  NEXT,».|  © 2 0 0 2 Huijin Quo  Figure 6-11 Simulation - Completion of Purchasing Process After this step, the whole purchase process is completed. The state of the process is set to 'success' and the database is also updated. Another possible exception for the Controller M O A P is that one or more of the sub-goals of SuppliedNewItem fail (the sub-goals as shown in Figure 6-8). In this case, the goal SuppliedNewItem will be evaluated as 'Failed'. To solve this exception (Type 2 - Evaluated Failure), the Controller M O A P will try other goals. A possible alternative is SuppliedTemp. The handling of the exception is shown in Figure 6-12.  105  MoapWorkflow Demo  Overview  |  Process  Exception  MOAP  |  About  Current Moap | ControllerMoap Current Goal  |SuppliedItem  ONE of the following subgoal(s) should be accomplished: 9  SuppliedTemp  9  SuppliedNewItem  x Failed  ['  NEXT»  |  ('•*-' = next subgoal to be accomplished.) © 2 0 0 2 Huijin Guo  Figure 6-12 Simulation - Evaluated Failure (Controller MOAP)  6.4 Summary In this chapter, we briefly discussed different options of simulator development. We  chose a web-based solution because of its platform independency, wide  availability, and support of object-oriented features. The functional modules and database design were then presented. Finally, we demonstrated the simulation of the M O A P - W f with different types of exception cases that were identified in Chapter 5.  106  7  Conclusion and Future Research  7.1 Conclusion The main objective of this thesis is to find out how workflow systems can be made flexible, adaptive and dynamic, and how these in turn handle exceptions and changes. We first reviewed some definitions and classifications of workflow exceptions in the literature. Exceptions can derive from workflow schema or instances, expected or unexpected, and at the domain, process, resource or infrastructure level. A survey of related research work was done in order that we could have an understanding of current workflow systems and exception handling mechanisms. We found that most of the surveyed research work was based on a traditional rigid sequenced model and focused on handling exceptions at the system level by extending database transaction processing technologies. One common limitation of these is that they can only handle expected exceptions and generally do not cover unexpected exceptions. Based on the findings of the survey, we then proposed to build a dynamic and adaptive workflow model by using the Micro-Organization Activity Processor (MOAP). M O A P is an agent architecture that supports organizational knowledge acquisition and communication. We extended it by introducing two more constructs: service and goal. Thus, in the proposed workflow model of MOAP-Wf, a workflow can be viewed as that MOAPs coordinate and cooperate with each other to achieve  107  certain business goals. A goal can be further decomposed into sub-goals until they can be achieved by executing certain tasks or by services from other MOAPs. M O A P concept provides an 'organizational view' of a workflow. MOAPs are also fully distributed. For these reasons, we adopted the 'controller' concept of ObjectOriented Workflow Model (OOWM) by introducing a Controller M O A P in the proposed MOAP-Wf. The Controller M O A P casts an overall horizontal process view to and is the 'owner' of a workflow. The responsibility of Controller M O A P is to monitor and control the overall progress of a workflow by interacting with other 'functional' MOAPs. In order to maintain the autonomy of MOAPs and facilitate exception handling, the M O A P - W f is constructed in hierarchical levels. Based on the discussion of normal execution procedures, we proposed the exception handling mechanism of M O A P - W f by using a purchasing process example. Exception handling in M O A P - W f is a goal-oriented reasoning process, which includes steps of goal selection and analysis, means-end analysis, scheduling, executing, and evaluating. We also presented the algorithm of exception handling logic steps in high level language. We further identified four types of exceptions and failures that can be solved by the proposed approach. To demonstrate the advantages of MOAP-Wf, we did a comparison study of handling two exception examples by our proposed model and ADOME-WfMS. Finally, we built a web-based workflow simulator with Visual Basic Scripting Version 5.0, Active Server Pages and a Microsoft Access database. The simulator is  108  based on our proposed M O A P - W f and demonstrates the detailed steps of workflow execution and exception handling.  7.2 Contributions One of the major contributions of this thesis is that it introduces and extends previous research work - Micro-Organization Activity Processor (MOAP) into workflow systems, a new domain that M O A P is applicable as architectural base. The MOAP-Base Workflow Model proposed an alternative to the traditional 'process view'. The model not only considers the autonomy of agents from an enterprise view but also supports processes emerging out of agent interactions. The introduction of the goal construct also presents some new thinking in business process and workflow modeling. Instead of modeling a workflow as rigid and interdependent activities, our goal-oriented approach focuses on realization of business goals. These goals are achieved by coordination and cooperation of independent and autonomous agents - MOAPs. The proposed M O A P - W f is more flexible and adaptive than other approaches. Changes of activities or tasks might not change the overall workflow. We identified four types of exceptions and failures that can be solved with the proposed MOAP-Wf: change of workflow sequence, evaluated goal failure, non-response/unavailable M O A P node, and reported task/service failure. Another major contribution of this thesis is the proposed exception handling mechanism. First, the hierarchical levels of the workflow model support isolation of exceptions and provide more alternatives to solve exceptions. Second, we applied  109  agent and artificial intelligence technologies, for example means-end analysis and scheduling, to exception handling.  7.3 Limitations and Future Research There are some limitations to the proposed approach that need to be addressed and that require further research. First, our proposed M O A P - W f is based on the assumption that business goals can be readily captured and modeled. The goal concept in this thesis is simplified while that of a real business context could be more complex. More research work needs to be done for comprehensive business goal modeling. For example, consideration should be carefully made in the goal-oriented reasoning process: how does one solution impact the goals of a MOAP? One solution might have a positive effect on one goal, but negative impact on another goal. Another point that requires future research is the use of goals and goal inheritance in hierarchical MOAPs. In this thesis, one goal is attached to a MOAP. However, there are some other places where goals can be used. For example, each service could have a goal, and each activity agent could have a goal. By expanding the use of goals, we can have a more complete M O A P architecture and, in turn, a more complete picture of business processes. Secondly, the simulator we used to demonstrate the functions of M O A P - W f is not a true workflow system per se. To implement a real M O A P - W f system, we need to do more research on the technical aspect of building a M O A P agent in workflow context. For example, how is a MOAP's goal matched to a business goal, how is means-end analysis done within the intelligent agent, and how are the goal and knowledge  110  represented. Another issue needs to be addressed is how to improve system performance which might be affected by the flexibility and distributedness of MOAP. Thirdly, in this thesis, we allow a M O A P participates in different workflow processes. However, there is one issue needs to be addressed: how business rules are inherited by each M O A P , e.g. how to solve the business rules conflicts among different processes. We also need to do more research on the communications among MOAPs, and between user and MOAPs. For example, how users interact with the system and MOAPs if necessary, and how lower level MOAPs provide sufficient information for upper level MOAPs to handle unsolved exceptions. Another point requires further research is that how a Contoller M O A P could know what to control and what not. Finally, the proposed M O A P - W f focuses on intra-organizational workflow. Although M O A P is capable of inter-organizational knowledge communication, further research is required to address some remaining issues, such as information exchange of business goals and communication protocol. A n interesting topic could be how to build a web-based M O A P - W f system by combining agent technologies and Web Service technology.  Ill  REFERENCE Abbott, K., and Sarin, S.K. "Experiences with Workflow Management: Issues for the Next Generation," The Conference on Computer Supported Cooperative Work, A C M Press, North Carolina, USA, 1994, pp. 113-120. Basu, A., and Kumar, A . "Research Commentary: Workflow Management Issues in e-Business," Information Systems Research (13:1), 2002, pp 1-14. Bentley, R., Horstmann, T., and Trevor, I. "The World Wide Web as Enabling Technology for CSCW: the Case of BSCW," Computer-Supported Cooperative Work: Special Issue on CSCW and the Web (6), 1997. Borghoff, U . M . , and Schlichter, J. Computer-Supported Cooperative Work: Introduction to Distributed Applications, Springer, 2000. Casati, F. Models, Semantics, and Formal Methods for the Design of Workflows and their Exceptions, PhD Dissertation, Pipartimento di Electtronica e Informazione, Politecnico di Milano, Milano, Italy, 1998. Casati, F., Ceri, S., Paraboschi, S., and Pozzi, G. "Specification and Implementation of Exceptions in Workflow Management Systems," ACM Transactions on Database Systems (24:3), 1999, pp 405-451. Chiu, K.W. Exception Handling in an Object-Oriented Workflow Management System, PhD Dissertation, Department of Computer Science, The Hong Kong University of Science and Technology, Hong Kong, 2000. Craven, N., and Mahling, D. "Goals and Processes: a Task Basis for Projects and Workflows," Conference on Organizational Computing Systems, A C M Press, California, USA, 1995, pp. 237-248. Divitini, M . , Hanachi, C , and Sibertin-Blanc, C. "Inter-Organizational Workflows for Enterprise Coordination," in: Coordination of Internet Agents: Models, Technologies and Applications, A . Omicini, F. Zambonelli and M . Klusch (eds.), Springer, 2001. Du, W., and Elmagarmid, A . "Workflow Management: State of the Art vs. State of the Products," Technical Report HPL-97-90, Software Technology Laboratory, Hewlett-Packard Company, 1997. Eder, J., and Liebhart, W. "The Workflow Activity Model W A M O , " Conference on Cooperative Information Systems, Vienna, Austria, 1995, pp. 87-98.  112  Grigori, D., Skaf-Molli, H., and Charoy, F. "Adding Flexibility in a Cooperative Workflow Execution Engine," The 8th International Conference and Exhibition on High-Performance Computing and Networking, Springer, Amsterdam, Netherlands, 1996, pp. 227-236. Hagen, C , and Alonso, G. "Flexible Exception Handling in the OPERA Process Support System," International Conference on Distributed Computing Systems, Amsterdam, the Netherlands, 1998, pp. 526-533. Han, Y . , Sheth, A . , and Bussler, C. "A Taxonomy of Adaptive Workflow Management," Workshop in the Conference on Computer Supported Cooperative Work, Seattle, USA, 1998. Heinl, P., Horn, S., Jablonski, S., Neeb, J., Stein, K., and Teschke, M . "A Compresensive Approach to Flexibility in Workflow Management Systems," International Joint Conference on Work Activities Coordination and Collaboration, A C M Press, California, USA, 1999, pp. 79-88. HP "HP Process Manager," Website: http://www.hp.com/go/e-process/. January 2002. Hui, S. An Object-Oriented Workflow Management System, MSc Thesis, Faculty of Commerce and Business Administration, University of British Columbia, Vancouver, 1997. IBM "Intra-Enterprise Business Process Management," IBM Redbooks SG24-617300, 2001. IBM "MQSeries Workflow," Website: http://www3. ibm.com/software/ts/mq series/workflow, January 2002. Jablonski, S. "MOBILE: A Modular Workflow Model and Architecture," Int'l Working Conference on Dynamic Modelling and Information Systems, Nordwijkerhout, 1994. Jablonski, S., and Bussler, C. Workflow Management: Modeling Concepts, Architecture and Implementation, International Thomson Publishing, 1996. Jennings, N.R., Faratin, P., Norman, T.J., O'Brien, P., Wiegand, M . E . , Voudouris, C , Alty, J.L., Miah, T., and Mamdani, E.H. "ADEPT: Managing Business Processes using Intelligent Agents," BCS Expert Systems Conference (ISIP Track), Cambridge, U K , 1996, pp. 5-23. Judge, D., Odgers, B., Shepherdson, J., and Cui, Z. "Agent Enhanced Workflow," BT  Technical Journal (16), 1998.  113  Kappel, G., Rausch-Schott, S., and Retschitzegger, W. "A Framework for Workflow Management Systems Based on Objects, Rules and Roles," ACM Computing Surveys (32:1), 2000. Karlapalem, K., Yeung, H.P., and Hung, P.C.K. "CapBasED-AMS - a Framework for Capability-Based and Event-Driven Activity Management System," The 3rd International Conference on Cooperative Information Systems (CoopIS-95), Vienna, Austria, 1995, pp. 205-219. Katzenstein, G., and Javier Lerch, F. "Beneath the Surface of Organizational Processes: a Social Representation Framework for Business Process Redesign," ACM Transactions on Information Systems (18:4), 2000, pp 383422. Keddara, K. Dynamic Evolution within Workflow System, PhD Dissertation, Department of Computer Science, University of Colorado, 1999. Klein, M . , and Dellarocas, C. "A Knowledge-Based Approach to Handling Exceptions in Workflow Systems," Journal of Computer Supported Collaborative Work, Special Issue on Adaptive Workflow Systems (9:3/4), 2000, pp 399-412. Kueng, P., and Kawalek, P. "Goal-Based Business Process Models: Creation and Evaluation," Working Paper, Department of Computer Science, University of Manchester, 1996. Leymann, F., and Roller, D. Production Workflow: Concepts and Techniques, Prentice Hall PTR, New Jersey, 1999. L i , Y., Huang, B., Liu, W., Gou, H . , and Wu, C. "Ontology for Goal Management of Virtual Enterprise," IEEE International Conference on Systems, Man, and Cybernetics, Tucson, USA, 2001, pp. 2034-2040. Luo, Z., Sheth, A., Kochut, K., and Miller, J. "Exception Handling in Workflow Systems," Applied Intelligence: the International Journal of Al, Neural Networks, and Complex Problem-Solving Technologies (13:2), 2000, pp 125147. Martens, C , and Woo, C. "OASIS: an Interactive Toolkit for Developing Autonomous Applications in Decentralized Environments," Journal of Organizational Computing and Electronic Commerce (7:2&3), 1997, pp 227251. Mohan, C. "Recent Trends in Workflow Management Products, Standards and Research," N A T O Advanced Study Institute Workshop on Workflow  114  Management Systems and Interoperability, Springer-Verlag, Istanbul, Turkey, 1997. Mohan, R., Cohen, M . , and Schiefer, J. "A State Machine Based Approach for a Process Driven Development of Web-Applications," The 14th International Conference on Advanced Information Systems Engineering (CAiSE 2002), Springer, Toronto, Canada, 2002, pp. 52-66. Narendra, N.C. "Goal-Based and Risk-Based Creation of Adaptive Workflow," Bringing Knowledge to Business Processes: Papers from the A A A I Spring Symposium, California, USA, 2000. Norman, T.J., Jennings, N.R., Faratin, P., and Mamdani, E . H . "Designing and Implementing a Multi-Agent Architecture for Business Process Management," European Conference on Artificial Intelligence, Springer, Budadest, Hungary, 1996, pp. 261-275. Oracle "Oracle Workflow," Website: January 2002.  http://otn.oracle.com/products/integration/,  SAP "WebFlow," Website: http://www.sap.com/solutions/technologv/workflow.htm, January 2002. van der Aalst, W.M.P. "Workflow Patterns," Website: http://tmitwww.tm.tue.tl/research/patterns, January 2002. van der Aalst, W.M.P., Basten, T., Verbeek, H.M.W., Verkoulen, P.A.C., and Voorhoeve, M . "Adaptive Workflow - on the Interplay Between Flexibility and Support," the IJCAI'99 Workshop on Intelligent Workflow and Process Management, Stockholm, Sweden, 1999, pp. 36-45. Wand, Y . , and Woo, C. "Ontology-Based Rules for Object-Oriented Enterprise Modeling," Working Paper 99-MIS-001, Faculty of Commerce and Business Administration, University of British Columbia, Vancouver, 1999. Wand, Y . , and Woo, C. "Business Modeling for Information Systems," Lecture Notes, Faculty of Commerce and Business Administration, University of British Columbia, Vancouver, 2001. Weir, M . Goal-Directed Behavior, Gordon and Breach Science Publishers, New York, 1984. WfMC "Workflow Reference Model," The Workflow Management Coalition Specification TC00-1003, Workflow Management Coalition, 1995. WfMC Workflow Handbook, John Wiley & Sons, 1997.  115  WfMC "WfMC Terminology and Glossary," WFMC-TC-1011, Workflow Management Coalition, 1999. Wielinga, B., van de Velde, W., Schreiber, G., and Akkermans, H . "Towards a Unification of Knowledge Modelling Approaches," in: Second Generation Expert Systems, J.M. David, J.P. Krivine and R. Simmons (eds.), SpringerVerlag, 1993, pp. 299-335. Woo, C , and Lochovsky, F.h. "Knowledge Communication in Intelligent Information Systems," International Journal of Intelligent and Cooperative Information System (1:1), 1991, pp 203-228. Yu, E., and Mylopoulos, J. "Using Goals, Rules, and Methods to Support Reasoning in Business Process Reengineering," The 27th Annual Hawaii International Conference on Systems Sciences, Hawaii, 1994, pp. 234-243.  116  Appendix A - FlexFlow This appendix, excerpted from Mohan et al (2002), gives a brief introduction to FlexFlow, a state machine based workflow system that was proposed by Mohan, Cohen, and Schiefer.  1. FlexFlow Process Model FlexFlow models business processes as U M L state diagrams. However, unlike U M L , where state diagrams describe the behavior of objects, FlexFlow state diagrams describe processes. The following figure shows a FlexFlow state diagram:  Event  \  Guard  \  *  ^  £  Action  1 1  Event [Guard] / Action  Stop [OrgAdminGuard] / StopAction State  Start  7  ™  C  a  n  c  e  l  l  e  d  f Active /  Transition  Cancel [MarketAdminGuard] / CancelCommand  \ / Event [Guard] / Action  Figure 7-1 FlexFlow State Diagram A FlexFlow model includes the following constructs: Actions - correspond to task logic being executed at the application server. They are atomic units of business work. Actions could appear in states and transition. A n action can be used to interface to an external system. States - correspond to stages in a business process. A state identifies a precise point within the process. In a given business process at a given state, the actions that  117  can be taken by various parties are completely defined by the set of outgoing transitions. A state may have an entry action, an action that is executed upon entering the state, and an exit action, an action that is executed upon leaving the state. Transitions - represent the changes of the process states. A transition connects two states, a source state it exits and a target state it enters. A transition corresponds to an action that is taken in response to an event. Events - are the named messages needing to get processed. A n event can be an HTTP request or an incoming SOAP request. It can also be an event generated by another process. Guards - are the conditions that need to be true before the action can be taken. In general, the guards can be rules. Contexts - are data associated with a business process. A context consists of: 1.) session information that includes information about the user including roles and permissions. 2.) the data submitted by the user such as form entries and the data stored in the form such as identification of the process and the business object.  2. Visual Modeling & Simulation The FlexFlow modeling tool includes a simulation component that allows development of a horizontal prototype. The prototype displays the facades of user interface screens from web application, possibly allowing some navigation between them. The modeling tool does not show real data and contains little or no real functionality. Information is faked or static. The purpose is to provide a process-  118  oriented navigation. The tool allows users to change the status of the current process by selecting one of the available actions on a simulation panel. The authors argue that this type of simulation is often sufficient to give the users a feeling for the web application and lets them judge whether any functionality is missing, wrong, or unnecessary. The users' evaluation of the prototype can point out alternative courses for a business process and new ways to visualize information.  119  Appendix B - Control Flow of M O A P - W f Simulator Functional Modules  MOAP = requester MOAP Goal = requester MOAP's subgoal (corresponding to the top goal of previous MOAP)  MOAP = the capable MOAP (requestee) Goal = the MOAP's top goal  -MOAP -Goal  Send request to the MOAP.  c CD  3 II  o  Means not I found  Task Jl  C CP i_ CD Q.  Set requester MOAP's goal as 'success' or| 'fail'  0- QJ  MOAP  type of /leans  CD O D)  < 1 og . Find next capable Task or MOAP  Yes  Find the requester MOAP (which requesting service from current MOAP)|  ?  Evaluate (based on subgoals  a. < O Waiting 2 § Success  ' O  D) JD  II  co  a. <  II  O o 2 O  Find next subgoal to work on  -Goal: Fail-  120  Find parent goal Set the process as 'success' or 'failed' (top goal's state)  Appendix C - Page Transition Diagram of M O A P - W f Simulator  executeTaskEval.asp SendRequest.asp Index.asp  executeTask.asp findCapable TaskMoap.asp  *  Process.asp  Start.asp  Flow.asp  i  i  Process_ new.asp  Initialize.asp  -Page transition-  findNextGoal.asp  —call —  — I — call  call r call  I  Evaluate.asp  Exception.asp  Function call —i  121  Finish.asp  


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items