Flexibility for Distributed Workflows

Flexibility for Distributed Workflows

Manfred Reichert (University of Ulm, Germany), Thomas Bauer (Daimler AG, Germany) and Peter Dadam (University of Ulm, Germany)
DOI: 10.4018/978-1-4666-4153-2.ch072


This chapter shows how flexibility can be realized for distributed workflows. The capability to dynamically adapt workflow instances during runtime (e.g., to add, delete or move activities) constitutes a fundamental challenge for any workflow management system (WfMS). While there has been significant research on ad-hoc workflow changes and on related correctness issues, there exists only little work on how to provide respective runtime flexibility in an enterprise-wide context as well. Here, scalability at the presence of high loads constitutes an essential requirement, often necessitating distributed (i.e., piecewise) control of a workflow instance by different workflow servers, which should be as independent from each other as possible. This chapter presents advanced concepts and techniques for enabling ad-hoc workflow changes in a distributed WfMS as well. Our focus is on minimizing the communication costs among workflow servers, while ensuring a correct execution behavior as well as correctness of ad-hoc workflow changes at any time.
Chapter Preview


For a variety of reasons enterprises are developing a growing interest in aligning their information systems such that they become process-aware (Lenz, 2007; Müller, 2006; Mutschler 2006; Mutschler, 2008a). Such process-aware information systems (PAISs) offer the right tasks at the right point in time to the right actors along with the information, resources and application services needed to perform these tasks (Dadam, 2000). Business process management technology offers promising perspectives to achieve this goal (Weske, 2007). Examples include workflow management systems and case handling tools (Günther, 2008 a; Mutschler, 2008b).

A workflow management system (WfMS) enables computer-supported business processes (i.e., workflows) to be executed in a distributed system environment (Bauer, 1999; Muth, 1998; Shegalov, 2001). Usually, a WfMS provides powerful tools for implementing enterprise-wide, process-aware information systems (PAISs) (Dadam, 1999). As opposed to data- or function-centered information systems, a WfMS separates the specification of the process logic (i.e., the control and data flow between the process activities) from application coding (Dadam, 2000; Weber, 2007); i.e., process logic can be described explicitly in terms of a workflow template providing the schema for workflow enactment (workflow schema for short). The different activities, in turn, are implemented as loosely coupled application services that can expect that their input parameters are provided upon invocation by the WfMS and which only have to produce correct values for their output parameters. Usually, the core of the workflow layer is built by the WfMS which provides generic functions for modeling, configuring, executing, and monitoring workflows.

This separation of concerns increases maintainability and reduces cost of change (Mutschler, 2008a; Weber, 2008a); i.e., changes to one layer often can be performed without affecting other layers; e.g., changing the execution order of workflow (WF) activities or adding new activities to a WF schema can, to a large degree, be accomplished without touching any of the associated application services (Dadam et al., 2000). Furthermore, a WF schema can be checked for the absence of flaws already at buildtime; i.e., deadlocks, livelocks and faulty data flow specifications (van der Aalst, 2000; Reichert, 1998a) can be excluded in an early stage of the process lifecycle (Weber, 2009; Weber, 2006a). At run-time, new WF instances can be created and executed according to the underlying WF schema. When an activity becomes activated, a respective work item is assigned to the worklists of authorized users (which are determined based on the actor assignment associated with the corresponding activity). One example of such a WfMS constitutes the ADEPT system we have developed during the last years (Reichert, 2003c).

Complete Chapter List

Search this Book: