ضوابط صحت و درستی برای تغییرات پویا در سیستم های جریان کار - یک نظرسنجی

The capability to dynamically adapt in-progress workflows (WF) is an essential requirement for any workflow management system (WfMS). This fact has been recognized by the WF community for a long time and different approaches in the area of adaptive workflows have been developed so far. This survey systematically classifies these approaches and discusses their strengths and limitations along typical problems related to dynamic WF change. Along this classification we present important criteria for the correct adaptation of running workflows and analyze how actual approaches satisfy them. Furthermore, we provide a detailed comparison of these approaches and sketch important further issues related to dynamic change.

A rapidly changing environment and a turbulent market force any company to change their business processes ever more frequently [1]. Process changes become necessary, for example, when new laws come into effect, optimized or restructured business processes are to be implemented, exceptional situations occur, or reactions to a changed market are required. Therefore, a critical challenge for the competitiveness of any enterprise is its ability to quickly react to business process changes and to adequately deal with them [16] and [31]. As pointed out in [17], [22], [28] and [34], basically, WF changes can take place at two levels––the WF type and the WF instance level. Instance-specific changes are often applied in an ad-hoc manner and become necessary in conjunction with real-world exceptions. They usually affect only single WF instances. As opposed to this, in conjunction with WF schema changes at the WF type level, a collection of related instances may have to be adapted. There are many approaches supporting such adaptive workflows [1], [5], [9], [18], [21], [26], [28] and [34]. All of them present very interesting, but partially strongly differing ideas and solutions. Therefore, it is an important job to summarize central correctness criteria for adaptive workflows and to compare actual approaches along them. In this survey, we focus on three fundamental issues regarding dynamic WF changes: (1) Completeness. Users must not be unnecessarily restricted, neither by the applied WF meta model nor the offered change operations. Therefore, expressive control/data flow constructs must be provided [7]. For practical purposes, at minimum, change operations for inserting and deleting activities as well as control/data dependencies between them are needed. (2) Correctness. The ultimate ambition of any adaptive WF approach must be correctness of dynamic changes [1], [5], [9], [18], [21], [26], [28] and [34]. More precisely, we need adequate correctness criteria to check whether a WF instance I is compliant with a changed WF schema or not; i.e., whether the respective change can be correctly propagated to I without causing inconsistencies or errors (like deadlocks or improperly invoked activity programs). These criteria must not be too restrictive, i.e., no WF instance should be needlessly excluded from being adapted to a process change. (3) Change realization. Assuming that a dynamic change can be correctly propagated to an instance I (along the stated correctness criteria), it should be possible to automatically migrateI to the new schema. In this context, one challenge is to correctly and efficiently adapt instance states. In the following, we provide a classification of actual approaches based on the operational semantics of the underlying WF meta models and on the kind of correctness criteria applied for dynamic WF changes (2 and 3). Section 3 introduces a selection of typical dynamic change problems and discusses strengths and weaknesses of the approaches when dealing with these problems. A detailed comparison of the different approaches is presented in Section 4. We sketch important change scenarios and existing approaches in Section 5 and close with a summary in Section 6.

In the previous sections emphasis has been put on fundamental correctness issues related to dynamic WF changes. So far it has been circumstantial whether a single WF instance or a collection of instances is subject to change. In this section we have a closer look at different change scenarios and related requirements. We provide a short categorization of adaptive research WF engines which includes Chautauqua [10], WASA2[34], Breeze [26], and ADEPT [21] whose basics have been already described in 2, 3 and 4. In addition, we consider the respective approaches followed by AgentWork [20], EPOS [19], and DYNAMITE [12] as well as the flexibility offered by commercial tools. 5.1. Changes of single WF instances Adaptations of single WF instances become necessary when exceptional situations occur or the structure of a WF dynamically evolves. Both scenarios can be found, for example, in hospital and engineering environments [12] and [20]. Besides state-related correctness properties instance-specific changes pose several challenging issues. In particular, change predictability influences the way how WF instances are adapted during runtime. Regarding evolving workflows, for example, necessary changes and their scope are often known at buildtime [12], [19] and [20]. Consequently, respective adaptations can be pre-planned and automated. In contrast ad-hoc changes have to be applied as response to unforeseen exceptions [21]. Usually, user interaction becomes necessary in order to define the respective runtime change. Of course, we cannot always see WF instance changes in terms of black and white, but the distinction between pre-planned and ad-hoc change contributes to classify existing approaches. 5.1.1. Approaches supporting ad-hoc instance changes In Breeze and WASA2, instance changes can be defined by the use of a graphical WF editor. Using a WF editor for change definition, however, is only conceivable for expert users. If changes shall be definable by end users as well, application-tailored user interfaces must be offered to them. Obviously, this requires comprehensive programming interfaces. Only few approaches provide such interfaces [21] and [34]. ADEPT, for example, offers a change API which enables change definition on WSM Nets at a high semantic level, e.g., to jump forward in the flow or to insert a new step between two sets of activities [21]. Very important in this context is to ensure that none of the guarantees which have been achieved by formal checks at buildtime are violated due to the ad hoc change. Note that this does not only require compliance checks and marking adaptations, but also checks with impact to correctness properties of the WF schema itself (e.g. regarding data flow). Therefore ADEPT uses well-defined correctness properties for WF models, formal pre- and postconditions for change operations, and advanced change protocols [21]. 5.1.2. Approaches supporting pre-planned instance changes Support for automatic WF changes is provided by AgentWork [20], DYNAMITE [12], and EPOS [19], but may be realizable on top of adaptive WfMS like WASA2, ADEPT, or InConcert as well. The overall aim is to reduce error-prone and costly manual WF adaptations. In order to realize automatic WF adaptations, firstly, the WfMS must be able to detect logical failures in which WF instance changes become necessary. Second, it must determine necessary adaptations, identify the instances to be adapted, correctly introduce the change to them, and notify respective users. This poses many additional issues ranging from the consistent specification of pre-planned changes at buildtime up to their concrete realization during runtime. Existing approaches supporting automatic WF instance changes can be classified according to different criteria. The most important one concerns the basic method used for automatic failure detection and for change realization. We distinguish between rule-based, process-driven, and goal-based approaches. Rule-based approaches use ECA (Event/Condition/Action) models to automatically detect logical failures and to determine necessary WF changes. However, most of them limit adaptations to currently executed activities [4] and [6]. In contrast, AgentWork [20] enables automatic adaptations of the yet unexecuted regions of running WF instances as well. Basic to this is a temporal ECA rule model which allows to specify adaptations at an abstract level and independently of concrete WF models. When an ECA rule fires, temporal estimates are used to determine which parts of the running WF instance are affected by the detected exception. Respective WF regions are either adapted immediately (predictive change) or––if this is not possible––at the time they are entered (reactive change). Goal-based approaches formalize process goals (e.g., process outputs). In ACT [3], necessary instance adaptations (e.g., substituting the failed activity by an alternative one) are automatically performed if an activity failure leads to goal violation. EPOS [19], in addition, automatically adapts WF instances when process goals themselves change. Both approaches apply planning techniques to automatically “repair” workflows in such cases. However, current planning methods do not provide complete solutions since important aspects (e.g., treatment of loops) are not considered. Process-driven approaches restrict the possible variants of WF schemes as well as WF changes in advance. DYNAMITE, for example, uses graph grammars and graph reduction rules for this [12]. Automatic adaptations are performed depending on the outcomes of previous activity executions. Interestingly, process-driven as well as goal-based approaches have been primarily applied in the field of engineering workflows. Both DYNAMITE and EPOS provide build-in functions to support dynamically evolving WF instances. Instance-specific changes pose several other challenges. For example, one must decide on the duration of an instance change. Concerning loop-related adaptations, ADEPT differentiates between loop-permanent and loop-temporary changes [21]. The latter are only valid for the current loop iteration. The handling of such temporary changes is not trivial since permanent changes must not depend on them in order to avoid potential errors. AgentWork [20] even follows a more advanced approach by allowing rule designers to specify temporal constraints indicating how long WF adaptations shall be valid. 5.1.3. Ad-hoc changes in commercial tools Production WFMS like WebSphere MQ Workflow and Staffware [14] provide powerful process support functions but tend to be very inflexible. Particularly, ad-hoc changes of running WF instances are not supported. Unlike these WFMS, engines such as TIBCO InConcert, SER Workflow, and FileNet Ensemble allow on-the-fly adaptations of in-progress instances. For example, users may dynamically insert or delete activities for a given instance in such a way that the past of this instance cannot be changed.2 Though ad-hoc WFMS provide high flexibility, they have failed to adequately support end users. Particularly, they do not support them in defining changes and in dealing with potential side-effects resulting from them (e.g., missing input data of an activity due to the deletion of a preceding step). Since one cannot expect from the end user to cope with such problems, this increases the number of errors and therefore limits the practical usability of respective WFMS. Case handling systems like FLOWer (Pallas Athena) [30] try to address flexibility issues from another viewpoint. Unlike traditional WFMS, case handling provides a higher operational flexibility and aims at avoiding dynamic changes. More precisely, users are allowed to inspect, add or modify data elements before the activities, which normally produce them, are started. Consequently, the decision about which activities can be executed next is based on the available data rather than on information about the activities executed so far. Since FLOWer allows to distinguish between optional and mandatory data elements, a broad spectrum of processes can be covered with this data-driven approach. FLOWer also enables the definition of causal dependencies between activities. The question remains, whether this mixed view on processes (process-driven, data-driven) contributes to completely avoid dynamic changes. 5.2. Workflow type changes and change propagation WF schema changes at the type level may become necessary, for example, to adapt business processes to a new law or to realize process optimizations. In any case we are confronted with the problem of how to migrate a potentially large number of WF instances I1,…,In running on the old schema S to the new schema S′. Basically, things seem to be the same as for dynamic changes of single WF instances. However, in addition, we are confronted with the problem that the WF type change may have to be propagated to WF instances whose current execution schema SI:=S+Δ does not completely correspond to S (due to a previous instance change Δ). To exclude such instances from migrating to the new schema S′, however, is out of touch with reality, particularly in case of long-running flows. Interestingly, none of the WF engines supporting WF type changes and change propagation has dealt with this problem so far. In WASA2, for example, individually modified instances cannot be further adapted to later type change. Chautauqua [10] even does not support changes of single instances at all, since instances of a particular type are always connected to the same Flow Net. Usually, commercial WfMS do not allow change propagation to in-progress instances when a WF schema is modified at the type level. Instead, simple versioning concepts are used to ensure that already running instances can be finished according to the old schema. One exception is offered by Staffware [14]. However, there are several critical aspects arising in this context. For example, running activities can be deleted without any user information. If the deleted activity is finished the returned results disappear to the nirvana. Furthermore, Staffware suffers from the CP problem which may lead to missing input data and activity program crashes at runtime. Finally, Staffware is by far too restrictive (e.g., insertions before activated tasks are forbidden).