A flexible workflow model for process-oriented applications

Download PDF
3 downloads 54032 Views 117KB Size Report
Comment
workflows for deploying process oriented applications that run across wide ..... Monitor and Monitoring Tools. Specification. Worklist Handler worklists. Agents.
A flexible workflow model for process-oriented applications Khalid Belhajjame LSR-IMAG, University of Grenoble BP 72 38402 Saint-Martin d’Hères, France [email protected] Genoveva Vargas-Solar Database Technology Group Department of Information Technology, University of Zurich Wintertuhrer Strasse 190, 8057 Zurich, Switzerland [email protected] Christine Collet LSR-IMAG, University of Grenoble BP 72 38402 Saint-Martin d’Hères, France [email protected]

Abstract This paper introduces definition and enactment models to characterize workflows. The proposed knowledge model provides concepts for modeling activities, data used by such activities, agents, and ordering operators and synchronization modes used for specifying activities dependencies. The behavior model provides dimensions that characterize workflow enactment. Both models are currently implemented in our workflow management system called AFLOWS. The originality of our approach is related to its flexibility as different enactment models can be associated to a workflow simply by giving values to dimensions according to application needs. Such an approach and system provide a suitable support for specifying and enacting workflow processes that may be useful today to describe and monitor process-oriented applications (i.e., large web-based applications that run across wide area networks and multiple enterprises).

1

Introduction

Workflow technology has been around for a long time. A workflow is the computerized representation of a business process (e.g., software construction, registration process at the university). It specifies the various activities of a busi-

ness process that have to be executed in some order, the flow of data between activities and the multiple collaborating agents that execute activities to fulfill a common objective. A Workflow Management System (WFMS) is a software tool for defining, instantiating and executing workflows. Workflow technology enables the separation of process logic from task logic embedded in user applications [17]. It integrates and coordinates heterogeneous applications within the same workflow. Thus it has appeared to be an interesting technology for modeling and implementing a large range of applications such as electronic commerce, virtual enterprises, medical applications, systems execution control. Yet, the Internet has opened up the possibility to use workflows for deploying process oriented applications that run across wide area networks and multiple enterprises [28]. Models and systems [11, 4, 15, 10, 18, 8, 1] are sometimes limited either to design or describe new types of workflows dealing with very large, evolving, heterogeneous, distributed components and to understand and follow their executions. In consequence, current trends in workflow domain are (i) specifying general models that represent different aspects of workflows specification and management (enactment); (ii) mechanisms and policies for supporting evolution and reuse [22, 16, 21, 19, 5]. In this context, our goal is to characterize such aspects to provide adaptability in workflow execution. We analyzed workflow models and determined the aspects that characterize them to propose a knowledge and a behavior models. Our models lead to the specification of adaptive WFMS. Indeed, be-

havior properties can be tuned independently according to applications needs (i.e., real time constraints, long transaction needs, etc.), execution contexts (i.e., intra/acrossorganizational processes, communication and activities execution costs) and evolution. The remainder of the paper is organized as follows. Sections 2 and 3 introduce concepts of our knowledge model and behavior model, respectively. Section 4 describes the AFLOWS system supporting these models. Section 5 gives an overview of existing work highlighting their advantages and limitations. Finally, Section 6 concludes the paper and gives some on-going research directions.

2

Knowledge model

A workflow is a collection of activities (tasks) organized to accomplish a process. An activity can have arbitrary granularity, it can represent a trivial task such as a simple read access to a database or it can be complex such as the computation of the credit worthiness of a client or a company. Moreover, a workflow defines the order of activities invocation, the conditions under which such activities must be invoked, and activities synchronization and information flow (dataflow). Electronic client Electronic Vendor

order and

Process Order

Access Catalogue

Stock Manager

order and client data

Cashier

bill

Execute Payment

Update the stock Ask for an Authorisation

Emit a Bill

bill

Prepare the package

bill

package

Bank Deliver the order Activity Compound activity Split into parallel activities Join of activities

Delivery Department

Synchronisation of sequential activities Association activity-agent

Figure 1. Electronic store application Let us consider the following application that implements an electronic store (e-store) depicted in Figure 1. To choose items they want to buy, clients first access a catalog

that describes products. Through the AccessCatalog activity a client may get characteristics, properties, price, etc. of products proposed by the e-store. Then he/she contacts a vendor who processes the order ( ProcessOrder). The vendor checks that chosen products are available, gets the client references (name, address, account number, bank). If the order is correct then the vendor contacts the cashier who executes a payment process (ExecutePayment). Therefore the cashier contacts the bank to ask if the transaction (purchase operation) can be charged to the client account (AskforAuthorisation). If the operation is authorized he/she emits a bill (EmitaBill). Once the order has been payed, the stock manager updates the stock (UpdateStock) and an employee prepares a package (PreparePackage). When the package is ready and the stock has been updated, the package is delivered (DeliverPackage). An activity is executed by a processing entity named agent that can range from a human to an arbitrary software system. Agents participating in a workflow has to be characterized too. For example, our application involves five types of agents: (i) the client that accesses and chooses items in the store, (ii) the seller who receives clients requests, (iii) the cashier that controls payments executed by a bank server, (iv) the stock manager that is responsible of stock updates and (v) the delivery department that manages invoices and delivery. The above example briefly introduces the main entities needed to specify a workflow (i.e., essentially activities and agents). It shows that agents have some role and that there exist an order among activities. Also data are needed and have to be exchanged between agents to execute activities. The following presents a general description of how such aspects are described using our knowledge model. More details about the model can be found in [3]. Main entities Figure 2 gives the UML diagram representing the concepts of our workflow knowledge model and the way they are related among each other. In our model a Workflow is characterized by a wfname and start and completion conditions (startCondition, completionCondition). It is composed of a collection of activities that are ordered and synchronized. The control flow of a workflow process specifies ordering between its activities and is described using ordering relationships ( OrderingOp). The synchronization between two entities specifies a temporal relationship a triggering activity and a triggered activity, respectively. A triggering activity causes the execution of a triggered activity. Such a relationship is defined using synchronization modes (SynchronizationMode) that are described in the following. An Activity is characterized by a name, a description, a pre/postcondition and an invariant. The name must be unique within the workflow. Precondition, postcondition

Scheduling

OrderingOp

SynchronizationMode

symbol : string

symbol : string

operator(A1:Activity[],A2:Activity[])

mode(A1: Activity, A2: Activity)

1..*

1

Activity

Workflow

name : string description : string boolean precondition() boolean postcondition() boolean invariant()

1..*

1

1..*

wfname : string 1

boolean startCondition()

boolean completionCondition()

0..*

1..*

1..*

0..*

RelevantData

Agent

attributName : string attributType : string

name : string type : string

sub> 1

1..*

Hierarchy

Position 1

name : string

1..*

Role name : string

Figure 2. Knowledge model (in UML)

and invariant are predicates. They must be checked respectively before, after and during the execution of an activity. Relevant data are required to execute an activity and to evaluate its precondition, invariant and postcondition. Such data are characterized by an identifier ( attributName) and attributType that denotes its type. In our model an Agent is characterized by an identifier (name) and a type that indicates whether the agent is a human or an application. Each agent has an associated position within an organization. For example, employee sub> service head specifies that the position employee is at a lower level than the position service head in the hierarchy. Each position is associated with one or several roles. As shown in Figure 3 the position director is associated with the role manager, while the position employee is associated with roles stock manager and salesman and deliveryman. sub>

Ordering operators They are used to describe the order among the activities of a workflow. Our model proposes five ordering operators used to define ordering expressions + of the form: A+ i op Aj where Ai denotes a triggering activity, Aj a triggered activity and 00 +00 means “one or several”. Considering activities (A1 , A2 , ... An ), our operators are defined as follows:  A1 seq A2 : the execution of A1 triggers A2 . For example, in the e-store application an order can be submitted and processed only after having accessed the catalog: AccessCatalog seq SpecifyOrder.  A1 and-split (A2 , : : :, An ): the execution of A1 triggers A2 , : : :, An . For example, activities Payment and PreparePackage are triggered by the activity SpecifyOrder (SpecifyOrder and-split (Payment, PreparePackage)).  A1 or-split (A2 , : : :, An ): the execution of A1 triggers a subset of the set {A2 , : : :, An }. Such a subset contains activities which preconditions are satisfied.  (A1 , : : :, An 1 ) and-join An : the execution of A1 , : : :, An 1 triggers An . For example, the package is delivered only if the payment is authorized and the package is prepared: (Payment, PreparePackage) and-join Delivery.  (A1 , : : :, An 1 ) or-join An : the execution of a subset of A1 , : : :, An 1 triggers An . The corresponding subset contains activities Ai (1  i  n 1) that satisfy their corresponding precondition. Note that ordering operators, in particular or-join (resp. or-split) can use control data to determine triggering activities (resp. triggered activities). For instance, an or-split can use control data such that “relevant data of precondition are ready for evaluation”. Synchronization modes Ordering operators do not specify temporal relationship between triggering and triggered activities. For example, assume that A1 and A2 must be executed sequentially, at which instant of the execution of A1 should A2 be triggered? Just after A1 starts/finishes or while A1 is being executed. Such an interesting information is given through temporal constraints specified using synchronization modes.

1..*

Role

1..*

1

Position 1

delay

Agent

duration

A time

Director

activate(A)

begin(A)

end(A)

sub>

Manager

equipment head

Cashier

appliances head

sub>

Service head Household

Computer

Employee Deleveryman

Salesman

Stock manager

Figure 3. Agent organization

Figure 4. Activity An activity A is represented by two intervals delay and duration (see Figure 4). Delay represents the interval during which an activity is ready to be executed but its execution has not started yet. Duration represents the interval during which an activity is being executed. Thus, three instants are

relevant to an activity life cycle: (i) trigger(A) denotes the instant at which activity A is ready to be executed but the agent has not already started its execution; (ii) begin(A), denotes the instant at which the execution of activity A starts; (iii) end(A), denotes the instant at which the execution of A is accomplished. Our model proposes three synchronization modes. Considering two activities A and B their semantics are defined as follows:  A meet B: B is triggered at the end of the execution of A (trigger(B) = end(A)). For example, an order can be processed only after the activity AccessCatalogue has been accomplished: AccessCatalogue seq meet SpecifyOrder. That is, the triggering instant of SpecifyOrder corresponds to the end of the execution of AccessCatalogue.  A overlap B: the triggering instant of B occurs between the beginning and the end of the execution of A (begin(A) < trigger(B) < end(A)). In other words, B is triggered at an instant begin(A)+t, where t > 0 corresponds to a duration expressed in minutes or seconds 1 . For example, consider an activity ProposePromotion that advertises interesting opportunities for buying new products. This activity can be triggered at begin(AccessCatalogue)+ 10 minutes.  A start B: B is triggered at the beginning of the execution of A (trigger(B) = begin(A)). For example, consider an activity ClientProfil that checks the client preferences for visualizing her/his data when accessing the catalogue. Such an activity can be triggered as soon as the client accesses the catalogue: AccessCatalogue start ClientProfil.

3

The execution of workflows can be characterized by four steps (see figure 5): activities scheduling, agent assignment, worklist management and activity execution. Our behavior model characterizes them through dimensions that take their values from predefined ones. A dimension characterizes a set of policies used to implement an aspect of workflow execution steps. Scheduling It is the process by which the execution of a workflow is planned. Table 1 describes dimensions associated to this phase. Dimensions 1-5 describe aspects to be considered for scheduling one activity. Dimensions 67 describe policies to be adopted for managing the global execution of a workflow (i.e., a set of activities). An activity can be triggered at specific instants with respect to a triggering activity A (dimension 1): (i) at the triggering instant of A (trigger(A)), at the beginning of the execution of A, (begin(A)), (ii) once it has been accomplished must not exceed activity A duration.

Agents Assignment

Activity

Worklist Management

Activities Execution

Figure 5. Behavior model Dimension 1 triggering instant

2 precondition evaluation instant 3 precondition failure 4 postcondition evaluation instant 5 postcondition failure 6 matching 7 ordering operator activation times

Behavior model

1 Note that the duration begin(A)+t

Activity

Scheduling

Values begin(A), after postcond. eval. of A, during(A), end(A), explicit before triggering, after triggering stop + exception, compensation, continue immediate after end stop + exception, compensation, continue best effort, rigid, recovery at check point once, multiple

Table 1. Scheduling

(end(A)) and (iii) after the postcondition of A has been evaluated. Activities can also be triggered (iv) explicitly (i.e. triggered by an event such as the connection of a user). For instance, in our e-store example, the first activity of the workflow is triggered explicitly by a user when he/she accesses the catalogue. Every activity A has an associated precondition that can be evaluated before or after the activity has been triggered (before/after trigger(A), dimension 2). Strategies must be adopted when an activity precondition fails (precondition failure, dimension 3). Either the workflow execution is aborted and an exception is raised (stop + exception) or it continues, for example, triggering alternative activities. In the last case, alternatives or compensations to be executed must be explicitly specified in the workflow definition. Once an activity has been executed its postcondition must be evaluated to determine which activity must be next

scheduled and whether the workflow can continue or not. This can be done immediately after the end of an activity execution (immediate after (end(A)), (dimension 4)). Strategies must be also adopted when the postcondition is not satisfied (dimension 5), either continue or abort the workflow execution and raise an exception (stop + exception). Furthermore, strategies must be adopted when the initial definition of a workflow can no longer be ensured (dimension 6). To illustrate this situation, consider the case where an activity A3 is triggered by activities A1 and A2 : (A1 , A2 ) and_join (meet, start) A3 . This means that the triggering instant of A3 corresponds to the beginning of the execution of A2 and to the end of the execution of A1 : trigger(A3) corresponds to end(A1 ) = begin(A2 ). In this example, three situations are possible: 1. The initial definition is respected: A2 execution starts at the end of the execution of A1 . Consequently A3 execution can be triggered by A2 (trigger(A3 ) = begin(A2 )). 2. The end of the execution of activity A1 happens before the instant at which A2 execution starts: A3 triggering is delayed until begin(A2 ) happens. 3. The end of the execution of activity A1 happens after the instant at which A2 execution starts: A3 triggering is delayed until end(A1 ) happens. In cases 2 and 3, the workflow definition is not completely respected as the constraint end(A1 ) = begin(A2 ) is not satisfied. In such a case, (i) the workflow execution continues trying to respect as far as possible the workflow definition (best effort); (ii) the execution is completely aborted (rigid); (iii) the workflow execution is interrupted and re-executed from a predefined check-point (recovery at check point). Finally, there are specific situations where an activity can be potentially activated more than once within the same workflow execution (dimension 7). Consider the following ordering expression (A1 , A2 ) or-join A3 . Here A3 can be triggered either by A1 or A2 or by both (we consider that or-join is not an exclusive or). In this case, A3 can be activated first by A1 and later by A2 (multiple) or it may be blocked once it has been executed and it cannot be triggered anymore during the same execution (once). In the first case, policies must be adopted to control a consistent and correct workflow global execution. For instance, it must it must be determined whether the completion of the workflow is achieved when activities are triggered more than once. Agent assignment This phase is done considering different criteria mainly that depend on the agent types and organization. Table 2 shows dimensions that describe policies to be taken into account.

Dimension 8 selection criteria 9 filtering 10 agent membership

Values free, identifier, role predefined priority, load, QoS intra-organization, external

Table 2. Agent assignment

Agents that may execute an activity can be selected (dimension 8) with no specific criteria (free, i.e., the first available) or with respect to their identifier, their role. For example an activity PurchaseExecution is assigned to an agent having salesman role. For a given activity there are potentially several agents that can execute it (salesman and manager in our example). Criteria must be then used to decide which one has to be chosen (dimension 9). For instance the one that has the less pending activities (load), the one that costs less (i.e., execution or communication costs QoS), according to predefined priorities associated to agents, etc. Workflow process can run across several enterprises. In some cases, apart from roles, agents can be grouped according to the organization of a company. For example, consider a company having several agencies in a country. Agents can be then associated to specific agencies. In such a case, the membership (dimension 10) can be an assignment criteria. In the previous example, assume that the agencies of the company use the same workflow specifications to execute their business processes. In that case, for executing a workflow one can specify that activities must be assigned to agents belonging to the same (different) agency where the workflow is executed (intra-organization, external). Worklist management A worklist is a list of pending activities assigned to an agent. Table 3 describes worklist management dimensions. An agent can adopt different policies for selecting the next activity that must be executed (dimension 11). Activities can be selected in the same order as they are inserted (FIFO), according to predefined priorities associated to activities and/or to workflows (activity/ workflow priority). In order to avoid activities starvation in a worklist, each activity Ai can have a persistence scope that describes the maximum period of time during which it can persist in the worklist before being selected (dimension 12). Such a scope can be restricted to a duration, or it can be indefinite. Furthermore, strategies must be adopted to process an activity which persistence scope reaches its limit (dimension 13). In such a case, the activity can be delegated to another agent, canceled or an exception can be raised and the workflow execution is interrupted until an explicit action from the user is undertaken. In our example, Payment must be executed within a delay of 20 minutes, if such a constraint is violated

either the purchase operation is aborted, or the activity Payment is executed on another account. Dimension 11 activity selection

Values

FIFO, activity priority, workflow priority, activity workflow priorities 12 persistence scope duration, indefinite 13 persistence scope exceed delegate, cancel

&

model. The engine has three main components: Coordinator, Agents manager and Worklist handler. The Coordinator ensures activities scheduling by interacting with an event service. The Agents manager controls activities assignment and agent availability. The Worklist handler manages agents worklists using different policies as specified in our model. Specification and Monitoring Tools

Table 3. Worklist management

Specification tools

Monitor

Agents

Workflow Engine Agents Manager

Activity execution Table 4 shows dimensions that describe execution policies for activities. As discussed in Section 2 an activity A can have an associated invariant that must be checked during the whole execution of A. Such invariant can be checked periodically or at a specific instant during the execution of A (dimension 14). When the invariant is not satisfied (dimension15) either (i) the activity execution is immediately aborted, (ii) it is re-executed, or (iii) the execution of a compensation is started.

14 15 16 17 18

Dimension

Values

invariant evaluation instant invariant failure execution mode atomicity isolation

periodic, instantaneous abort, re-execute, compensation ACID, non transactional set, instance set, instance

Table 4. Activity execution

An activity can be executed in different modes depending on agent properties (dimension 16). In our model, activities can be executed using any model or within ACID transactions. In the last case, the agent chosen to execute the activity must support such an execution model. Atomicity and isolation properties can be associated to one or several activities execution (dimensions 17 and 18). For example, in our purchase application, Payment and StockUpdate can be executed atomically to ensure that payed products are available on stock.

4

Implementation

We are currently conducting the implementation of AFLOWS a flexible workflow management system that supports our models. Figure 6 depicts its architecture. It is based on services ensuring asynchronous communication (event service [24, 26]), reactivity (event and rule services [20, 7]) and persistence support. AFLOWS provides specification tools for processing workflow definitions and a workflow execution engine that implements our behavior

Coordinator Worklist Handler

worklists

Services DBMS

Event Service

Rule Service

Figure 6. General architecture

4.1

Specification and runtime execution

Workflows are defined in XML [27] documents defined using the AFLOWS-DTD specified for this purpose [25]. For a given workflow one defines instances of our knowledge and behavior models. Such documents are then compiled to obtain an internal representation comprised of (i) objects that materialize knowledge model entities (ii) event types and active rules; and a (iii) configuration file specifying execution policies to be used by the engine. In the current version of AFLOWS workflow definitions consistency is not provided the system. We are currently developing tools that will provide graphic definition interfaces for this purpose. A workflow execution starts in response to explicit requests. First, the system instantiates the workflow (i.e., it retrieves its specification from the persistence support and configures execution engine parameters). The coordinator instantiates the first activity and sends a request to the agent manager. The activity is then assigned to an available agent taking into consideration the assignment policies specified in the definition. Scheduling operations executed by the coordinator are done in response to events (e.g., an activity A has been executed). Finally, worklists management policies are implemented using active rules [2]. Such rules are managed by the rule service that cooperates with the execution engine for executing reactions (e.g., on persistence scope exceed do delegate an activity to another agent).

4.2

Properties

Flexibility denotes the capability of a WFMS to characterize processes enactments and to manage their evolution either during its execution or not. In the following we describe briefly how AFLOWS ensures this property. Agents Connection Agents can connect and disconnect to AFLOWS dynamically. The event service notifies such operations to the agent manager that keeps track of agents availability. The manager receives events that contain information about the type and the location of new connected agents. For a given application the agent manager knows the associated agents hierarchy (i.e., position and roles of each agent type). Once subscribed, a worklist is associated to an agent. Before its un-subscription, their activities are delegated to other agents. The same procedure coupled with an underlying event based communication protocol, can be adopted in presence of agent crashes. Assuming that the execution of agents can be monitored, crashes are detected by the event service which notifies an event of type agent crash(agentid, workinglist). Activities contained in the worklist are then delegated to another agent. Structural Changes It consists in adding or deleting ordering operators and activities. For example, assume that our e-store changes its selling policies and decides that packages are prepared while the order is being specified and that the payment is started only after the order has been completely specified. This implies that the original workflow definition (SpecifyOrder and-split meet (Payment, PreparePackage)) is modified to (SpecifyOrder and-split ((meet Payment) (overlap PreparePackage))). AFLOWS implements strategies to decide in which cases such a modification is taken into consideration immediately, until the next execution or at a specific check point during the workflow execution. The structure of a given workflow can be updated thanks to a set of primitives provided by the interface of the monitor. Generally speaking, for executing such modifications, the administrator specifies the identifier of the workflow, the type of update (e.g., add/delete an activity, modify the order and synchronization), its scope (all the active instances, a specific instance) and execution instant (immediately, next execution). In order to execute the operation, the system first checks the consistency of the new version. Then, for immediate updates, the system checks the execution state of the running instances. This is done to determine, for each instance, the strategy to adopt for updating it. Execution policies management Dimensions chosen for executing processes (e.g., agent assignment policies) can

be dynamically changed. AFLOWS implements strategies to decide at which instant such modifications must be taken into consideration (immediately or at a specific check point). The scope of such modifications can be also chosen by the user. In other words, updates on execution parameters can concern a specific workflow instance or all instances running. Furthermore, such modifications can be persistent or not.

5

Related Work

In this section we discuss characteristics of approaches that provide general workflow models. We also compare WFMS with systems built using approaches similar to the one we propose.

5.1

Models

WIDE [21] proposes three models to characterize workflows organization, information and process aspects. Similar to us, they aim at modeling workflow aspects in an orthogonal way. However, we remark that the process model merges some knowledge features with behavioral ones. For example, transactional aspects are specified within activities structure. The REWORK [22] meta-model comprises a set of conceptual tools for the specification of workflow system architecture. Actors composing the system are represented by aggregate components called EOB. Properties of the actors include access interfaces and execution properties and represented by the properties of an EOB. Response to evolving environmental requirements is carried out via the modification of corresponding system architecture. [16] proposes a workflow meta-model for supporting dynamic workflows evolution and reuse. A taxonomy of operations that can be applied for modifying workflows is specified. Particular operations are defined for creating new workflows from existing ones and for migrating to certain workflow version (older or newer).

5.2

Systems

Trigsflow [12, 14, 15, 13] is a WFMS based on an active extension of the ODBMS Gemstone. In Trigsflow , activities are assigned to agents with respect to their role and/or load. Activities can be delegated to other agents. The workflow execution engine in Trigsflow is embedded within an active DBMS. Rather, we use separated active services [7] adapted for workflows execution characteristics. In the Brokers/Services [23] approach, agents are brokers that execute services. Agents are specified and implemented as reactive components based on the event engine

EVE [10]. Agents interact asynchronously (using events) to ensure workflow execution. CoopWARE [18, 9] focuses on interaction aspects between workflow servers and agents. Different to Brokers/Services they adopt a centralized architecture where the WFMS coordinates agents. Our work is similar to the Brokers/Service approach in that it uses separate active services for executing workflows. Different to our system, behavior aspects are specified in a fixed model based on a rule execution model.

5.3

Discussion

The literature agrees in general to consider the following elements for defining workflow models and systems:

  

general models that represent workflow structure, data, agents and execution policies according to user and applications needs; policies for ensuring correctness of workflows; strategies for enabling the modification of workflows (e.g., versions management, cascade modification of workflow definitions and instances).

As we already discussed, several works have provided solutions that are concerned with these aspects. The main difference with our approach is that besides structural aspects, it also focuses on execution ones. Hence, the model, correctness and modification strategies are revisited and adapted to provide flexible workflow executions according to application requirements and on the context in which such applications are executed.

6

Conclusions and future work

In conclusion, the main contribution of our work is to provide general workflow models that compile techniques proposed by existing workflow systems and models. The originality of the model relies in the separation of knowledge aspects from behavioral ones to enable flexible management of workflows. As far as we know a specification of dimensions to characterize workflow execution aspects has never been presented before. Thus, using our approach, workflows definition and execution can be tuned separately according to specific application needs. In addition, reusability of workflow definition can be also supported, since the same workflow definition can be associated to different execution models according to their context of use. As a result, our models offering a lot of concepts may seem complex and we plan to provide designers of workflows with some (graphical) tools and methods to help him/her in specifying his/her definitions. Also a formal semantics

of our models is needed in order to describe the correct relationships between values and dimensions and the correct configuration of relationships (i.e. the compatible relationships). Further work includes pursuing the implementation of AFLOWS. We also want to experiment on interorganizational applications (virtual enterprises or organizations). Such experience will help us to analyze and determine the needs of such applications, and to evaluate AFLOWS behavior and performance. Another domain of experimentation concerns platforms for describing, composing and follow the execution of services or components. Specifically, experiences will be carried out within infrastructures NODS (Networked Open Distributed Services) for database component systems [6]; and the ODAS (Open Distributed Active Systems) infrastructure [7] for building and controlling the execution of component-based and distributed active database applications. Acknowledgments Thanks to Prof. K. D ITTRICH, A. VADUVA and D. DAMM of the Database Technology Group, Department of Information Technology, University of Zurich for their careful reading and useful discussions about our work.

References [1] G. Alonso, G. Mohan, C. Guenthoer, R. Agrawal, A. E. Abbadi, and A. Kamath. Exotica/FMQM: A Persistent Message-Based Architecture for Distributed Workflow Management. In Working Conference on Information Systems for Decentralized Organizations, Trondheim, 1995. [2] K. Belhajjame. Services Actifs pour les Flots de Travail. Master’s thesis, Joseph Fourier University, 2000. Rapport de DEA. [3] K. Belhajjame, G. Vargas-Solar, and C. Collet. Towards adaptable workflow management system. In Journées Bases de Données Avancées (BDA), Agadir-Morocco, October 2001. [4] F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Semantic Workflow Interoperability. In Advances in Database Technology - EDBT’96, 5th International Conference on Extending Database Technology, Avignon, France, Proceedings, volume 1057 of Lecture Notes in Computer Science. Springer, 1996. [5] F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Workflow Evolution. Data & Knowledge Engineering, 24(3), 1998. [6] C. Collet. The NODS Project: Networked Open Database Services. In Proc. of the 14th European Conference on Object-Oriented Programming (ECOOP 2000)- Symposium on Objects and Databases, Cannes, France, June 2000. http://wwwlsr.imag.fr/Les.Groupes/storm/NODS/index.html. [7] C. Collet, G. Vargas-Solar, and H. Grazziotin-Ribeiro. Open Active Services for Data-Intensive Distributed Applications.

[8]

[9]

[10]

[11] [12]

[13]

[14]

[15] [16]

[17] [18]

[19]

[20]

[21] [22]

[23]

[24]

In Proceedings of the 16èmes Journées Bases de Données Avancées, 2000. S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997. A. Gal and J. Mylopoulos. Supporting Distributed Autonomous Information Services Using Coordination. International Journal of Cooperative Information Systems, 2000. A. Geppert, M. Kradolfer, and D. Tombros. EVE, Event Engine for Workflow Enactment in Distributed Environments. Technical Report 96.05, University of Zurich - Switzerland, Department of Computer Science, 1996. D. Hollingsworth. The Workflow Reference Model. http://www.aiim.org/wfmc/, 1995. G. Kappel, B. Proll, S. Rausch-Schott, and W. Resschitzegger. TriGSflow: Active Object-Oriented Workflow Management. In Hawaii International Conference on System Sciences, volume 28, 1995. G. Kappel, S. Rausch-Schott, and W. Resschitzegger. A Framework for Workflow Management Systems Based on Objects, Rules and Roles. IEEE Bulletin of the Technical Committee on Data Engineering, 18(1), 1995. G. Kappel, S. Rausch-Schott, and W. Resschitzegger. Coordination in Workflow Management Systems - A Rule-Based Approach. Coordination Technology for Collaborative Applications - Organizations, Processes, and Agents, W. Conen, G. Neumann (eds.), Springer LNCS 1364, 1998. G. Kappel, S. Rausch-Schott, and W. Resschitzegger. Workflow Management Frameworks. Wiley & Sons, 1998. M. Kradolfer. A Workflow Metamodel Supporting Dynamic, Reuse-based Model Evolution . PhD thesis, Department of Information Technology, University of Zurich, Switzerland, mai 2000. C. Mohan. Workflow Management in the Internet Age. Talk/Tutorial. O. Mylopoulos, A. Gal, K. Kontogiannis, and M. Stanley. A Generic Integration Architecture for Cooperative Information Systems. In Proceedings of the First IFCIS International Conference on Cooperative Information Systems (CoopIS’96), 1996. M. Reichert and P. Dadam. ADEPT flex -supporting dynamic changes of workflows without losing control. Journal of Intelligent Information Systems, 10(2):93–129, 1998. H. Ribeiro. Service de Règles Actives pour Féderation Base de Données. PhD thesis, Université Joseph Fourier, july 2000. G. Sánchez-Gutiérrez. The WIDE Workflow Model and Language. Technical report, WIDE, 1997. 2eme version. D. Tombros. An Event- and Repository-Based Component Framework for Workflow System Architecture. PhD thesis, Department of Information Technology, University of Zurich, Switzerland, november 1999. D. Tombros, A. Geppert, and K. Dittrich. The Broker/Services Model for the Design of Cooperative ProcessOriented Environments. Technical report, University of Zurich, 1997. G. Vargas-Solar. Service d’Événements Flexible pour l’Intégration d’Applications Bases de Données Réparties. PhD thesis, Université Joseph Fourier, december 2000.

[25] G. Vargas-Solar, K. Belhajjame, and C. Collet. Towards adaptable workflow management systems. Submitted to ER01. [26] G. Vargas-Solar and C. Collet. ADEES, an Open Eventbased Infrastructure for Distributed Information Systems. Submitted to VLDB 2001. [27] W3C. Extensible Markup Language (XML). http://www.w3.org/XML, 2000. [28] Workflow Management Coalition. Workflow and Internet: Catalysts for Radical Change. http://www.aiim.org/wfmc/, June 1998. A WFMC White Paper.