Accommodate Dynamism
Sarita Bassil1, Daniel Rolli2, Rudolf K. Keller3, and Peter Kropf1
1 Département IRO, Université de Montréal, C.P. 6128, succursale Centre-ville, Montréal, Québec, H3C 3J7, Canada
{bassil, kropf}@iro.umontreal.ca
2 Information Management and Systems, Universität Karlsruhe (TH), Englerstr. 14, D-76131 Karlsruhe, Germany
daniel.rolli@iw.uni-karlsruhe.de
3 Zühlke Engineering AG, Wiesenstrasse 10a, CH-8952 Schlieren, Switzerland ruk@zuehlke.com
Abstract. Many challenging applications are inherently dynamic. This is mainly due to the ever changing environment applications are subjected to in areas such as supply chains, logistics or business process support. Workflow technology is often applied to find solutions in these domains. It aims to pro- vide computer support to the management of business processes in general.
However, this technology offers little support to the dynamism inherent to those applications. The Workflow Management Coalition has developed a standard general model for Workflow Management Systems (WfMSs). This model, called the Workflow Reference Model (WfRM), does not support dynamism.
This paper presents an extension of this model in order to accommodate dyna- mism. We focus our research towards dynamic workflow support for e- negotiation and transportation applications. Requirements for supporting dy- namic modifications in workflow technology are gathered from the study of these applications. The derived list of requirements serves as a valuable input for the extension of the model. An implementation of the conceptual extension enhancing the functionality of an already existing WfRM compliant WfMS, is presented.
1 Introduction
A business process is defined as a set of one or more linked activities, which collec- tively realize a business objective [14]. Workflow technology aims to provide as much computer support as possible to the management of such business processes.
Such management embraces not only design and engineering efforts but also issues occurring later in the life-cycle (e.g., business process reengineering or dynamic modification management) [12].
The completion of this research was made possible thanks to funding provided by the NSERC (CRD-224950-99), Bell Canada’s support through its Bell University Laboratories R&D program, and support by the CIRANO.
Today’s workflow-based applications progressively ask for more competence in reacting to external events. This need for dynamism stems mainly from the unavoid- ably changing environment of such applications, but also from the difficulty or even impossibility to identify all the elements of a workflow model before run-time.
Nevertheless, the problem of dynamism has not yet been addressed in a significant manner with respect to challenging applications. Hence, a workflow-based solution is often not chosen in spite of the fact that it could be suitable. On the other hand, if it is chosen, the benefits are often restricted by the missing dynamism. Since organizations and individuals are interested in optimizing their profits, they are not willing to lower their needs and expectations by committing to predefined static workflows. The latter would keep them from reacting to real-time events and information, and prevent prof- itable and sometimes mandatory adaptation.
While some research projects attempt to provide a formal foundation for the sup- port of dynamic modifications of workflows [1, 6, 7, 8], efforts towards the standardi- zation of this functionality are still lacking.
The Workflow Management Coalition1 (WfMC) [10] has developed a standard overall model for Workflow Management Systems (WfMSs). This generic model, called the Workflow Reference Model (WfRM) [15], does not support any ad hoc modifications yet. In this paper, we present an extension to this model for adequately supporting needs in dynamism and for building dynamic WfMSs.
To motivate our work, two application domains were explored by studying their dynamic requirements: the e-negotiation domain [2] and the transportation domain [3].
E-negotiation domain: In this domain, combined negotiations (CN) are a general type of negotiation, in which the user is interested in many items (goods and services) and consequently engages in many negotiations for these items. As an example of a CN, a company importing goods may negotiate a number of activities/services such as the purchase, the shipment, the insurance and the forwarding of goods. This can be modeled with workflows [4, 5] and in [2], we highlighted the need for dynamic modi- fication support in this context by identifying dynamic aspects (i.e., unexpected events) that can occur while negotiating the different items of a CN.
Transportation domain: We consider the case of multi-transfer container transpor- tation (MTCT) when a container is moved from terminal to terminal with the possibil- ity to shift it from vehicle to vehicle before delivering it to the final destination. In [3], we proposed to manage the processing of client requests in MTCT systems using workflow technology. In fact, it appears that the processing of a client request can be achieved by a specific sequence of interdependent activities: e.g., “attach empty con- tainer to vehicle”, “move vehicle to origin location”, “load container”, “move vehicle to terminal”, “transfer container to depot”, etc. Moreover, the MTCT requires the dynamic creation of the activity sequence for a request. It also requires much adapta- tion of ongoing activity sequences in order to deal with unexpected events (e.g., de- layed vehicles, crew members desistance, technical problems).
1 The WfMC, founded in 1993, is a non-profit, international organization of workflow vendors, users, analysts and university/research groups. Its goal is to develop standards for workflow systems operation, and to promote knowledge of the technology within the industry.
From these two applications, challenging dynamic aspects have been gathered.
WfMSs should support all these aspects by providing an appropriate set of modifica- tion operations.
In Section 2, we describe the dynamism process derived from studying the two in- troduced applications. We then present a wish list of dynamic modifications motivat- ing them with examples from our application domains. In Section 3, a brief review of the WfRM in its current state is given. The methodology for the extension of the model as well as the extension itself are then presented and discussed. Section 4 pre- sents the implementation related to the conceptual extension. This implementation enhances the functionality of an already existing dynamic WfMS (ADEPT) [8]. Sec- tion 5 addresses related work, followed by a conclusion and discussion of future work in Section 6.
2 Input Information for the Extension of the WfRM
As a first step, we examined the two applications presented in the previous section:
the CN application and the MTCT application. In this section, we describe the differ- ent phases involved in dynamism that we thereby discovered. Then, we introduce the resulting list of dynamic modifications that should be supported by WfMSs. This wish list will be used to extend the WfRM with respect to dynamism. Within this list, two new concepts were created: the “application” and the “activity template” concepts.
These concepts will also be explained in this section, since it appeared that they are necessary for a broad – yet focused – perspective of the insertion operation.
2.1 The Dynamism Process
We capture dynamism in workflows by a three-phase process that is part of the run- time phase: the (1) pre-modification phase is characterized by the detection of events (internal or external events) that will trigger the (2) modification phase. The latter is characterized by a set of operations/modifications that are applied (manually or auto- matically) to workflow instances and will trigger the (3) post-modification phase.
This phase is characterized by reactions triggered by the changes applied within the modification phase. As an example, it must be decided whether or not to keep a modi- fied instance as a new workflow model. This is particularly interesting in the MTCT application. Indeed, with this feature, we will be able to choose among a number of already adopted solutions resulting from previous client requests with the same origin location and final destination as a new request. This will probably reduce the modifi- cation operations during run-time.
Moreover, we think that aspects from the modeling phase (i.e., build-time phase) – namely the information available at build-time and the completeness of the workflow model – influence the level of dynamism at run-time. In the MTCT application for instance, only short-term previsions are possible. This makes it difficult or even im- possible to design complete workflow models. As a consequence, a high-level basic workflow model is initially designed. It captures a sequence of four activities as shown in Fig. 1 for the MTCT case.
Fig. 1. The high-level basic workflow model of the MTCT application.
The activities of Fig. 1 are usually required for the processing of a client request.
Indeed, the two activities “loading/unloading container” are mandatory. Moreover, these activities cannot be accomplished without a previous move of the container (using a vehicle) to the origin location (respectively, final destination). An instance of this model should, of course, be dynamically refined as soon as the required informa- tion becomes available or when unexpected events occur.
2.2 Wish List of Dynamic Modifications
In order to deal with the dynamic aspects identified in the two applications studied, a WfMS should support different dynamic modifications (structural and attribute modi- fications). The list in Table 1 gathers the latter. This list probably does not cover a complete set of dynamic modifications. It however answers our needs with respect to the studied applications. More importantly, it makes us aware of a number of modifi- cation operations to be concerned with when working on an extension of the WfRM.
Although one can consider the two applications as representative enough, it would be necessary to explore other applications in order to validate the completeness of the list presented here.
Table 1. List of dynamic modifications.
Dynamic Modifications
Structural Modifications Attribute Modifications (M1) Insert new activity (M5) Add new attribute (M2) Insert sub-process (M6) Delete existing attribute
(M3) Delete existing activity (M7) Set/update the value of an attribute (M4) Move existing activity (M8) Set/update the role/user assignment
The insertion of an activity (modification (M1) in Table 1) is an essential modifica- tion operation. In the MTCT application, workflow instances are enriched via (M1) using a repository of activity templates. We define an “activity template” as a stand- alone activity that can be designed without being part of a process definition (i.e., workflow model). Such activities are for prospective use during a workflow instance modification – mainly the insertion. In fact, they provide a broad perspective for the insertion operation, which will not be limited to the activities that are part of existing processes.
Sometimes, the insertion of a sub-process (i.e., a block of two or more activities) is required (modification (M2)). This modification is considered as the generic case of (M1). We may also think that the latter could be captured by (M2). As an example, the sequence of the two activities “detach container from vehicle” and “attach con- tainer to vehicle” should be inserted each time a container needs to be transferred from one vehicle to another.
START NODE
MOVE VEHICLE TO
ORIGIN LOCATION
LOAD CONTAINER
MOVE VEHICLE TO
FINAL DES- TINATION
UNLOAD
CONTAINER END NODE
Since a WfMS is usually used in the context of many different application do- mains, we found it necessary to define the “application” concept. An “application”
assigns certain activity templates and process definitions to a specific application domain. So, this concept is mainly used for classification purposes, and hence fosters, in practice, the more focused selection of a specific activity template or sub-process definition to be inserted. As an example, activities such as: “attach container to vehi- cle”, “move container to origin location”, “load container”, etc. belong to the trans- portation domain and specifically to the MTCT application [3]. They can rarely be useful for the design/adaptation of workflow models/instances in other domains (e.g., CN).
The deletion (modification (M3)) is useful to remove already scheduled activities from a workflow instance during run-time. As an example, a dynamic deletion of the
“move vehicle to origin location” activity (see Fig. 1) from the workflow instance of a request R should be possible in the special case where the origin location of the re- quest R corresponds to the final destination of a previous request R’, and the pick-up time of R corresponds to the delivery time of R’.
The “move” operation (modification (M4)) allows the moving of an activity from its original place to a different one. This modification is more apparent in the CN application. The user might at a certain time be interested to engage in a specific ne- gotiation for strategic purposes. Suppose that this negotiation activity is already scheduled later in the process. Thus, it would be convenient to just move this activity to an earlier time.
But moving makes sense not just for convenience reasons. It can also solve consis- tency problems. Indeed, someone may argue that it could be captured by a “delete”
operation followed by an “insert” operation. However, in the case of dependant at- tributes between activities (e.g., an activity needs the result of a predecessor activity as input), the deletion of the producing activity is not possible, since the workflow will become inconsistent from a static point of view. But if the activity is to be deleted and then inserted before the consuming activity again, the workflow will remain con- sistent. So, the issue of moving an activity can – with respect to some conditions – allow a relaxation of the consistency restrictions.
In this context of activities providing certain attributes for other activities later in the workflow, it will also be interesting to allow the deletion of specific attribute(s) (modification (M6)) from the consuming task so that the dependency between the providing activity and the consuming activity will be removed and the activity dele- tion will be allowed. This issue was already discussed in [2] in the context of the CN application.
It is possible that already defined activities within a workflow instance may not be fully predefined mainly because of some information unavailability. Allowing the insertion of a new attribute during run-time (modification (M5)) and the setting /updating of its value (modification (M7)) as soon as the needed information becomes available is an important issue. In the MTCT application for instance, the vehicle_ID attribute of a “move vehicle to location” activity takes into account the new availabil- ity of resources when a delayed vehicle event is caught.
In this scenario, a driver assigned to a delayed vehicle will probably not be avail- able for other activities. A reassignment of an activity (modification (M8)) assigned to an unavailable driver should be possible. We differentiate between the reassignment of an activity instance and the reassignment of a work-item, which is already sup- ported by the WfRM, as we will see later in this paper (Section 3.1). In the special
case where no driver is available at all, the activity should be unassigned and it should remain like this until a driver becomes available. In this case, the reassignment of the activity is of no use. However we should be able to remove the work-items from the work-list of the previously assigned and currently unavailable driver.
3 WfRM and Dynamism
It is often argued that workflow technology is still young and not yet fully shaped. To foster the maturity of this field, the WfRM [15] establishes a standard by defining the basic components of a WfMS. A set of API calls (WAPI) that form the interfaces between these components and the core of a WfMS is also provided. However, work- flow management has many faces other than the basic ones already covered by the current WfRM. Unfortunately, it is still unclear which components and/or which API calls should be added to the existing WfRM in order to provide advanced functional- ity such as the dynamic modification support of workflow instances. In this section, we begin by briefly reviewing the WfRM in its current state. We then present and discuss the extension of this model which is oriented towards the support of needs in dynamism.
3.1 Review of the WfRM
The WfRM model consists of a generic description of the structure of a WfMS, in which five main components are identified [15]: (1) Process Definition Tools, (2) Workflow Client Applications, (3) Invoked Applications, (4) Other Workflow Enact- ment Services, and (5) Administration and Monitoring Tools. These components are related to a Workflow Enactment Service, which ensures that the right activities are carried out in the right order, and by the right people/applications. This service com- prises at least one engine (the core of a WfMS, called the “workflow engine”). For the purpose of our work, we focus on the first three components:
• Workflow Definition Tools – They gather mainly the build-time functions con- cerned with modeling the workflow process and its constituent activities.
• Workflow Client Applications – They gather the run-time functions concerned with interacting with users and IT applications for completing the various activi- ties. Work-lists that identify the tasks (or work-items) to be carried out by a spe- cific user form part of this component.
• Invoked Applications – This component is responsible for the launching of ap- plications associated with the performing of specific tasks.
While these components deal with the two phases we are concerned with: (1) the run-time phase, gathering the three phases identified within the dynamism process described in Section 2.1, and (2) the build-time phase, the two other components are less relevant in this context, since they respectively address distributed workflows and workflows measurement and analysis.
Ten groups of operations (i.e., API calls) support the interfaces that exist between each of the components and the Workflow Enactment Service (Table 2; groups (G1)
to (G10)) [17]. Note that the last three groups of operations in Table 2: (G11), (G12) and (G13) concern our extension of the WfRM described in Section 3.3.
Table 2. Groups of operations distributed within Interfaces 1, 2 and 3 of the WfRM.
Components Workflow Definition Tools (Interface 1)
Workflow Client Applications (Interface 2)
Invoked Applications (Interface 3)
(G1) Connection Functions ! ! !
(G2) Process Modeling Functions !
(G3) Entity Handling Functions !
(G4) Entity Attribute Manipulation Functions !
(G5) Process Control Functions !
(G6) Process Status Functions !
(G7) Activity Control Functions !
(G8) Activity Status Functions !
(G9) Work-list/Work-item Handling Functions !
(G10) Administration Functions !
(G11) Application Definition Functions !
(G12) Activity Template Modeling Functions ! (G13) Activity Template Attribute Manipulation Functions !
Group (G1) provides two functions that allow a specific component to connect to and to disconnect from the workflow engine for a series of interactions. It is obvious that this group of operations appears in each of the three component interfaces.
Groups (G2), (G3) and (G4) are exclusively assigned to Interface 1 and gather a set of functions that deals with the definition of workflow models. Group (G2) supports the creation and the modification of a workflow process model, whereas group (G3) includes creating and deleting entities, and group (G4) allows for getting and setting the attributes of these entities. An entity is defined as a building block for a workflow definition [13]. An activity, a transition and a participant specification are examples of entities. Note that an entity is always scoped by another entity.
Groups (G5) to (G10) are assigned to Interfaces 2 and 3. Group (G5) allows the creation, the starting and the termination of a specific process instance, as well as the changing of its operational state. Group (G6) is intended to provide a view of current process instances allowing the verification of the work done, the work to be done, etc.
Similarly, groups (G7) and (G8) allow respectively for changing the operational state of activity instances, and for providing a view at the activity instance level. We spec- ify that groups (G5) and (G7) deal not only with process instances and activity in- stances, but with their attributes as well allowing the assignment of a specific value.
Group (G9) addresses work-items and allows for changing their states, reassigning them to different work-lists and assigning a specific value to their attributes.
Finally, group (G10) provides the functionality needed to perform the administra- tion and maintenance of a workflow system. This includes functions that allow for terminating and aborting process instances.
Groups of Operations
3.2 From the Current WfRM to an Extended Model
The review of the WfRM and specifically of its WAPI allowed us to retain some conventions that should be considered for the extension of the model. Firstly, we realized that operations related to a specific concept (e.g., workflow model, entity, process instance, activity instance, work-list/work-item) are gathered within a specific group. Secondly, we realized that operations that deal with the attributes of a specific concept from Interfaces 2 and 3 (process instance, activity instance and work-item) are part of the group that handles the concept itself. In contrast, the operations dealing with the attributes of a concept from Interface 1 (mainly the entity concept) are gath- ered within a group different from the one that handles the concept itself. Finally, lists of elements are manipulated by a set of four functions (open/close list, fetch/get ele- ment). For our extension, we will respect these existing conventions.
3.3 Extension of the WfRM
In this section we present the extension made to the WfRM. Our methodology is best presented by a set of five questions: (1) Is there a need for a new component? (2) Is there a need for a new interface? (3) Is there a need for a new group of operations? (4) Is there a need for new operations that will extend already existing groups of opera- tions? (5) Which group of operations should be assigned to which interface to support a specific aspect?
At this level of our research, we are more concerned by the last three questions. In- deed, a new group of operations is added when a new concept is defined. New opera- tions are added to an existing group of operations if we would like to extend the func- tionality with respect to a specific existing concept. Each time we decide to add a new group of operations, we have to decide to which interface it should be assigned.
All the functions that we define in the extension follow the naming conventions of the WfMC [16] and the traditional structure of the initial WAPI (components, inter- faces, groups of operations, etc.). Like the original WAPI specification, we do not explicitly include any requirements or provisions for process consistency. This is left up to specific implementations.
3.3.1 Extension to Interface 1
The extension brought to Interface 1 introduces mainly the two concepts presented in Section 2.2 (i.e., “application” and “activity template”). New data types are defined to support these concepts at the build-time level. A total of three new groups of opera- tions are added to Interface 1: (G11), (G12) and (G13) in Table 2. Groups (G11) and (G12) gather respectively operations for the creation/deletion of an application, and operations for the creation/deletion of an activity template and for its assignment to/detraction from an application. Since we associate attributes with the “activity template” concept, group (G13) is also added to Interface 1. Operations that allow for assigning/deleting an attribute to/from an activity template already created as well as for setting an attribute of an activity template and for assigning a workflow participant to an activity template are gathered within this group.
Finally, two operations allowing the assignment/detraction of a process definition to/from an application are added to the already existing group (G2) of Interface 1 (cf.
Table 2).
3.3.2 Extension to Interfaces 2 and 3
The extension brought to Interfaces 2 and 3 is obviously more closely related to dy- namic modifications than the one brought to Interface 1. A number of operations are added to the three groups: (G5), (G7) and (G9). The operations added to group (G7) basically allow dynamic modifications that concern the “activity instance” concept (i.e., all the modifications of Table 1 except (M2)).
The “insert” operation (M1) takes as input, among other things, an activity instance that corresponds to the activity to be inserted. On the one hand, the activity instance may already exist within the run-time environment. A “WMGetActivityInstance”
operation, already defined within group (G6), is used so that the specific activity instance to be inserted can be obtained. On the other hand, we may want to create an activity instance from an activity template. For this reason, an operation that allows this creation (i.e., WMCreateActivityInstance) as well as operations that deal with the list of activity templates (open/close the list and fetch/get activity template from the list) are also added to group (G7).
The operations added to group (G5) deal with process instances. They allow the (M2) modification of Table 1, as well as the storage of the process definition that corresponds to a modified process instance. Finally, one operation is added to group (G9). It allows the deletion of a work-item from a given work-list.
4 Functionality Extension of a WfMS
ADEPT is a WfMS developed at University of Ulm [8] that already offers support for some dynamic modifications (insertion and deletion of an activity). We used ADEPT in order to implement the conceptual extension of the WfRM (Section 3.3). Three main criteria were applied to retain this system among other WfMSs. The first and most important criterion is its compliance with the basic WfRM, as well as its support for two structural modifications. The second one concerns the interest granted to this system within the literature [6, 11]. Finally, the third criterion refers to the availability of its API. Not considering the minimal difference in the structure and interplay of functions, the ADEPT API provides most of the functionality requested by the origi- nal specification of the WfRM (the WAPI). Even more, it offers additional features that correspond to some of the functionality proposed previously in this paper: (1) the
“activity template” concept and (2) functions for structural modifications (insertion and deletion).
All new functions we implemented are collected in a Mediator component that ex- tends the existing ADEPT API and contributes to the current pool of available func- tions by running in parallel to ADEPT (Fig. 2). The ADEPT Client uses the new In- terface 2 by accessing the Mediator functions as well as the original ones in the ADEPT Server. It has to be stated here that this solution cannot be permanent and was adopted for simplicity, only. For further implementations in the context of dynamic
modifications to workflows, the ADEPT API has to be extended by modifying the source code of the system.
Fig. 2. The plugging of the Mediator component within the ADEPT structure.
The current state of the implementation extending ADEPT, covers mainly the at- tribute modifications (M5, M6, M7 and M8 in Table 1). A check for the compliance of the already supported structural modifications (M1 and M3) to the WfMC stan- dards was successful.
The WMInsertActivityInstance and the WMDeleteActivityInstance functions were therefore realized with a reasonable effort by calling respectively the dynamicInsert function and the dynamicDelete function from the ADEPT API. In our concept, an activity template has to be instantiated first in order to obtain an activity instance that then can be inserted. In the ADEPT API, however, dynamicInsert takes an activity template as a parameter and then directly inserts an activity instance. So the instantia- tion is implemented within the dynamicInsert function. Therefore, we do not use the WMCreateActivityInstance function in this context. We consciously accept this dif- ference between our conceptual specification and the actual implementation.
The functions that are related to the attribute modifications and that have been implemented so far are:
• WMAssignActivityInstanceAttribute – This function is responsible for dynami- cally adding an attribute or setting/updating its value in an activity instance. In case the attribute provided in the parameters of the function already exists, its definition is changed according to the provided parameters. If there is a value submitted in the corresponding parameter of the function, it is set or updated within the attribute. In case the specified attribute does not exist yet, it is added to the named activity instance. For consistency reasons some internal checks with the database are done to ensure that the inserted or updated values comply with the specified types (input/output and string/long).
• WMDeleteActivityInstanceAttribute – This function dynamically deletes an ac- tivity instance attribute. If we are dealing with an input attribute (i.e., it con- sumes a value provided by an activity instance earlier in the workflow), this at- tribute is simply removed from the corresponding activity instance. If however the attribute is providing output, all attributes with the same name are deleted in every activity instance in the given process instance. This is done in order to en- sure consistency on a basic level.
ADEPT Editor
ADEPT Client
ADEPT Server (Workflow API and Interchange formats)
Interface 1
Interface 2 Interface 3
Mediator Invoked Applications
• WMAssignActivityInstanceParticipants – This function dynamically sets or up- dates the participant(s) of an activity instance. According to the WfMC standard, up to ten participants can be assigned to one activity instance [17].
We are currently working on the implementation of the two remaining dynamic modifications (M2 and M4), as well as of the functions that respectively allow for storing a process definition that corresponds to a modified process instance, and for deleting a work-item from a work-list. Taking into account the already implemented functions, we began the implementation of a new client for the studied applications.
As a final note in this section, we would like to highlight the fact that the ADEPT API has not been designed to add new dynamic functionality as the one just pre- sented. Consequently, it was impossible to implement our desired functions relying exclusively on the ADEPT API. In fact, we were obliged to sometimes access the database where ADEPT stores the workflows directly. This results in the problem that in the case of direct database access, we evade all consistency checks within ADEPT.
In spite of the fact that some basic measures have been taken to ensure consistency, there are still many leaks to talk of a complete concept that ensures correctness and consistency. Therefore, with the current implementation, the responsibility is shifted to the user of the functions to invoke the latter wisely.
5 Related Work
The WfMC briefly discusses future support of so-called ad hoc activities [17]. How- ever, this only addresses the addition of activities to a process instance and has not been realized yet.
A set of structural changes of workflow instances was proposed in [8]. The ADEPT project is the most complete work in the recent literature regarding structural modifications at the instance level. Its strength roots in the verification formalism of the consistency and the correctness properties. It doesn’t touch the modifications at the attribute level and unfortunately not all the (formal) concepts/the modification operations were implemented in the prototype; only the insertion and the deletion.
Other workflow modification projects comprise Milano [1], ML-DEWS [6], the work of Sadiq and Orlowska [9] and the work of Kradolfer [7]. Most of these projects address the evolution of a workflow model, and how to apply these modifications on running instances. An interesting issue within these projects is the set of modifications allowed. The latter is sometimes too restrictive in regards to the needs in challenging applications. Moreover, most of the projects study a theoretical basis without really developing a prototype. Indeed, basic mechanisms of the framework are usually im- plemented or simulated, but a complete WfMS prototype is never developed.
Finally, a significant idea to the relaxation of consistency restrictions (cf. Section 2.2) is evoked in [7]. Kradolfer talks about effective operations that have a net effect on the modified instance. He specifies that the effects of these operations should nei- ther be overwritten nor undone by other operations. In this paper, we add to this idea the fact that while a specific modification would not be allowed, the application of a set of modifications would be possible in principal.
6 Conclusion and Future Work
In this paper, we presented an extension of the WfRM. We based our work on the analysis of two applications and presented the derived wish list of dynamic modifica- tions. Two concepts were then introduced: “activity template” and “application”. The wish list provided valuable input for extending the WfMS model with support for dynamism. An implementation related to the conceptual extension was finally dis- cussed.
Our future work includes three directions. First, some new concepts are required to effectively deal with specific applications. In particular, the “work-list updating time”
concept, which differs from the “beginning time” and the “finishing time” of an activ- ity, should be introduced. As a second direction, we plan to address more closely the automatic modification of workflow instances. In the MTCT application, operations research algorithms and heuristics are proposed for the dynamic management of re- sources (e.g., vehicles, containers, drivers) [3]. The results provided by these algo- rithms and heuristics should automatically trigger specific operations on workflow instances. This will probably require dealing with rule processor technology. The interaction between the core of a WfMS and such technologies is a challenging issue that we plan to study in detail. As a third direction of future research, we want to explore strategies for suspending the running of workflow instances, and specifically the running of an activity. This issue should be studied with respect to workflow modifications. As an example, we would like to answer the following question: how can we delete an activity in a running state while keeping its context?
References
1. Agostini, A., and De Michelis, G., Improving Flexibility of Workflow Management Sys- tems. In [12], pages 218-234.
2. Bassil, S., Benyoucef, M., Keller, R.K., and Kropf, P., Addressing Dynamism in E- negotiations by Workflow Management Systems. In Proceedings of the Thirteenth Interna- tional Workshop on Database and Expert Systems Applications (DEXA'2002), pages 655- 659, Aix-en-Provence, France, September 2002. IEEE.
3. Bassil, S., Bourbeau, B., Keller, R.K., and Kropf, P., A Dynamic Approach to Multi- transfer Container Management. In Proceedings of the Second International Workshop on Freight Transportation and Logistics (ODYSSEUS’2003), Mondello (Palermo), Sicily, It- aly, May 2003. To appear. On-line at <http://www.iro.umontreal.ca/~bassil/Odys- seus03_Dynamism_Bassil.pdf>.
4. Benyoucef, M., Alj, H., Vézeau, M., and Keller R.K., Combined Negotiations in E- Commerce: Concepts and Architecture. Electronic Commerce Research Journal, 1(3):277- 299, July 2001. Special issue on Theory and Application of Electronic Market Design.
Baltzer Science Publishers.
5. Benyoucef, M., Bassil, S., and Keller R.K., Workflow Modeling of Combined Negotiations in E-Commerce. In Proceedings of the Fourth International Conference on Electronic Commerce Research (ICECR-4), pages 348-359, Dallas, TX, USA, November 2001.
6. Ellis, C.A. and Keddara, K., A Workflow Change Is a Workflow. In [12], pages 201-217.
7. Kradolfer, M., A Workflow Metamodel Supporting Dynamic, Reuse-Based Model Evolu- tion. Doctoral thesis, University of Zurich, Swiss, 2000. On-line at <http://
www.ifi.unizh.ch/ifiadmin/staff/rofrei/Dissertationen/Jahr_2000/thesis_kradolfer.pdf>.
8. Reichert, M., and Dadam, P., ADEPTflex: Supporting Dynamic Changes of Workflow without Losing Control. Journal of Intelligent Information Systems, 10(2): 93-129, 1998.
9. Sadiq, S.W. and Orlowska, M.E., Architectural Considerations in Systems Supporting Dynamic Workflow Modifications. In Proceedings of the Workshop on Software Architec- tures for Business Process Management at the 11th Conference on Advanced Information Systems Engineering (CaiSE’99), Heidelberg, Germany, June 1999. On-line at
<http://www.dstc.edu.au/praxis/publications/ssadiq_sabpm_ 1999.pdf>.
10. The Workflow Management Coalition. On-line at <http://www.wfmc.org>.
11. van der Aalst, W., and van Hee, K., Workflow Management: Models, Methods, and Sys- tems. The MIT Press, 384 pp., 2002. ISBN 0-262-01189-1.
12. van der Aalst, W., Desel, J., and Oberweis, A. (Ed.), Business Process Management: Mod- els, Techniques, and Empirical Studies. LNCS 1806 Springer-Verlag, 389 pp., 2000. ISBN 3-540-67454-3.
13. Workflow Management Coalition, Interface 1: Process Definition Interchange Process Model. WfMC-TC-1016-P, Version 1.1, October 1999. On-line at <http://www.wfmc.org/
standards/docs/TC-1016P_v11_IF1_Process_definition_Interchange.pdf>.
14. Workflow Management Coalition, Terminology and Glossary. WFMC-TC-1011, Version 3.0, February 1999. On-line at <http://www.aiim.org/wfmc/standards/docs/glossy3.pdf>.
15. Workflow Management Coalition, The Workflow Reference Model. WFMC-TC-1003, Version 1.1, January 1995. On-line at <http://www.wfmc.org/standards/docs/
tc003v11.pdf>.
16. Workflow Management Coalition, Workflow Client Application (Interface 2) Application Programming Interface (WAPI) Naming Conventions. WFMC-TC-1013, Version 1.4, No- vember 1997. ON-line at <http://www.wfmc.org/standards/docs/tc013v14a.pdf>.
17. Workflow Management Coalition, Workflow Management Application Programming Interface (Interface 2&3) Specification. WFMC-TC-1009, Version 2.0, July 1998. On-line at <http://www.wfmc.org/standards/docs/if2v20.pdf>.
