VIRTUAL ENTERPRISES AND WORKFLOW MANAGEMENT AS ...

August 28, 2002 19:36 WSPC/111-IJCIS

00063

International Journal of Cooperative Information Systems Vol. 11, Nos. 3 & 4 (2002) 355–379 c World Scientific Publishing Company

VIRTUAL ENTERPRISES AND WORKFLOW MANAGEMENT AS AGENT COORDINATION ISSUES

ALESSANDRO RICCI∗,‡ , ANDREA OMICINI∗,§ and ENRICO DENTI†,¶ DEIS, Universit` a di Bologna Rasi e Spinelli 176, 47023 Cesena, FC, Italy † viale Risorgimento 2, 40136 Bologna, Italy ‡ [email protected] § [email protected] ¶ [email protected]

∗ via

Agents and multiagent systems (MAS) have already proved suitable for dealing with the complexity of today B2B application scenarios. Application environments such as virtual enterprises (VE) and inter-organizational workflow management systems (WfMS) specially call for the integration of heterogeneous resources, services, and processes. In this article, we first recognize VE and workflow management as agent coordination problems, then discuss how objective coordination — that is, coordination from outside agents — can help to model VE and WfMS. Finally, we show the impact of an agent coordination infrastructure like TuCSoN on the engineering of highly dynamic VE and WfMS, by discussing a simple case study.

1. Agent Coordination in VE and WfMS Agents41 and multiagent systems (MAS henceforth) are widely recognized as suitable abstractions to deal with complex application environments, especially when the openness and unpredictable dynamics of the environment make traditional approaches less effective. From a strict software engineering viewpoint, since they work as independent loci of control, agents allow applications to be designed by abstracting away from control — a fairly desirable feature when dealing with highly dynamic environments. From a higher-level perspective, agent proactiveness and deliberative capabilities cope well with the unpredictable scenarios typical of today B2B applications. Also, reasoning capabilities of intelligent agents often provides a viable means to deal with the heterogeneity of information, resources and services. Even more, the metaphor of agent society26,27 has been shown to be powerful enough to harness the complexity of applications such as open digital markets, business process management12,17 and virtual enterprise management.12 Application architecture and dynamic behaviour can then be modeled in terms of inter-agent dependencies and agent organization; global application goals can be represented as social tasks and appointed to agent ensembles.23 A virtual enterprise (VE henceforth) provides an application environment where all the sources of complexity typical of today B2B systems have to be faced.30 In 355


356

00063

A. Ricci, A. Omicini & E. Denti

short, a VE is a temporary aggregation of autonomous and possibly heterogeneous enterprises, meant to provide the flexibility and adaptability to frequent changes that characterize the openness of business scenarios. Correspondingly, models and technologies for VE development have to face the strong requirements resulting from the need to integrate and coordinate distributed activities, which should communicate and cooperate despite their heterogeneity and the unpredictability of the environment. When designing a VE, two key issues arise. The first is the integration of the existing services and infrastructures of the VE component enterprises — from passive information sources to services and business processes. A key problem, here, is heterogeneity, emerging at different levels — mainly the information, technology, and process levels. The second issue concerns the development of the VE distributed workflow management systems (WfMS henceforth), which should both integrate the different business processes featured by the VE component enterprises, and enable the specification, execution, and monitoring of the VE specific business processes.16 One of the main sources of complexity in the context of VE is the large number of dependencies among autonomous and heterogeneous activities that have to be properly governed in order to achieve the global system goals. Dependencies among VE activities typically concern the share and exchange of heterogeneous information and resources, task assignments for VE business processes, as well as temporal and prerequisite constraints among heterogeneous activities. So, on the one hand, VE activities can be easily conceived as agents, featuring tasks to be pursued autonomously and pro-actively, typically involving the interaction with other agents and services. On the other hand, since coordination can be defined as the activity of modeling and managing dependencies among interacting entities,19 it is quite natural to interpret and model most VE application issues as agent coordination problems. In the context of VE, workflow management is the most obvious coordination problem.10 Modeling workflow management according to the standard WfMC approach,39 that is, in terms of workflow engines (workflow servers or coordinators, where coordination takes place) and workflow participants, induces a clear separation between coordinating and coordinated activities. Accordingly, the interpretation of workflow processes as coordination processes suggests the adoption of an approach based on objective coordination.32 In the context of MAS, objective coordination deals with inter-agent dependencies that can be expressed independently of the individual agent inner architecture and perception. By definition, objective coordination is coordination from outside agents, and promotes a clean separation between coordinated and coordinating activities — analogously to the cited WfMS standard approach. Models and technologies based on objective coordination typically provide explicit abstractions where to embed the coordination laws, both to enable the interaction among agents and enforce the required coordination policies. As a result, at least in principle, coordination abstractions can be exploited as workflow engines, embodying the workflow rules in terms of coordination laws: in


00063

Virtual Enterprises and Workflow Management

357

this way, the workflow rules can encapsulate outside agents and be superimposed on them (prescriptive coordination), so that agents need not be aware of the global workflow, thus preserving their autonomy. It is worth noticing that such an uncoupling property is peculiar to objective coordination models, and does not apply to subjective models of coordination, coordination from inside agents, where the workflow rules have to embedded inside agents and modeled according to the individual agent viewpoint and perception, therefore mixing coordinated and coordinating activities. Following the above observation, that VE management and WfMS can be fruitfully modeled as agent coordination problems, and that objective coordination provide the most effective approach to VE and WfMS modeling. The rest of this article is organized as follows. In Sec. 2, we discuss the role of agent infrastructures in VE and WfMS management, and point out the corresponding requirements. Then, in Sec. 3, we overview the TuCSoN infrastructure for agent coordination, and discuss its potential benefits in the context of VE and WfMS applications. To better illustrate and support our claims, Sec. 4 presents a case study where TuCSoN is exploited as an infrastructure for a VE a virtual bookshop. Finally, Sec. 5 discusses related works, and Sec. 6 provides concluding remarks.

2. Infrastructures for VE and WfMS A VE is a temporary aggregation of autonomous and independent enterprises connected through a network, brought together to deliver a product or service in response to customer needs.30 So, VEs mean to combine the core competences of several autonomous and heterogeneous enterprises in a new agile and flexible enterprise, addressing specific and original industrial business targets. The engineering process of a VE requires both a suitably expressive model and a coherent runtime environment embodying and supporting the model. To be addressed in an application-independent way, these requirements typically call for an adequate infrastructure providing general-purpose services (such as coordination) to be configured and tailored according to the specific application needs. An infrastructure supporting VE management has to address two main issues: (i) the integration of selected heterogeneous resources provided by single participants, and (ii) the execution of VE specific business processes featuring their own dynamics, while exploiting at the same time as many existing resources, services, and processes from component enterprises as possible. As pointed in the previous section, heterogeneity comes out at the information, the technology, and the process levels. At the information level, information to be shared can easily differ in terms of the syntax, semantics, and ontology. At the technology level, different sorts of hardware and software environments might be in use, from the operating system to the middleware used as infrastructure for the distributed computing environment.20 At the process level, heterogeneous activities and business processes should be able to interact despite the diversity in the nature


358

00063


of the involved entities (humans, services, software agents of different computational paradigms) and in protocols and languages used for agent interaction. So, the first requirement for a VE infrastructure is to promote the conceptual homogenization of VE resources, information, and activities. Acting as an organizational glue, a VE infrastructure should support consistent interactions with shared services and among processes, while minimizing VE impact on participant infrastructure.1 In this context, a VE infrastructure should also provide abstractions and mechanisms for security, safety and privacy, so as to protect the VE from the outside world, while taking into account the mutual requirements of the VE individual components. Therefore, an infrastructure for VE management should help to govern the dependencies characterizing the execution of VE business processes, such as task assignments, prerequisite and temporal constraints, which require the development of a WfMS.16 WfMS are among the most important models currently used by organizations to automate business processes while supporting their specification, execution, and monitoring. A business process is precisely a workflow, that is, a set of activities to be executed in some order, involving multiple entities in a distributed environment collaborating to accomplish a given task.16 A WfMS is meant to improve the process throughput, promote a better use of resources, and enable an efficient process tracking.31 Moreover, since workflow applications are subject to frequent changes due to the business environments,11 flexibility and adaptability are key features to face the inescapable dynamic evolution of coordination policies, and to suitably react to unpredicted situations.18 In the VE case, WfMS also have to face the issue of distribution, having to coordinate (heterogeneous) activities spread over the network. Furthermore, the requirement definition for a WfMS standard31 explicitly states that a distributed workflow infrastructure should be based upon the principle of loose-coupling between workflow engines and workflow participants. So, an infrastructure for WfMS should provide support for:31 • communication among participants and engines, with no need to agree on pointto-point protocols; • flexible and scalable workflow participation, so that participants be able to participate using both traditional devices (such as desktop PC) and non-traditional devices (such as thin clients, or PDA), requiring no a priori information on engines, nor any dedicated connections to the engines themselves; • disconnected operation, since workflow participants may be mobile and nonfrequently connected to the network, as well as location-independent; • traceability of the business process state.20 To face such requirements, the VE infrastructure should enable a clean separation between the conceptual places where the workflow rules are specified (and enforced) and the workflow participants, uncoupling the coordination activity from the activities to be coordinated. Workflow rules should also be explicitly represented, as well as (possibly) dynamically inspectable and modifiable.


00063


359

3. VE, WfMS and Coordination in TuCSoN TuCSoN is both a model and an infrastructure for the (objective) coordination of Internet agents, which has proven to be particularly suitable for mobile information agents.28 In the following, we first overview the TuCSoN model, then take it as an example of an infrastructure for agent coordination promoting the uncoupling between coordinating and coordinated entities, and finally discuss how such a coordination-based approach could be fruitfully exploited in the context of VE and WfMS. 3.1. TuCSoN overview The TuCSoN coordination model is based on the notion of (logic) tuple centre,25 a Linda-like tuple space13 empowered with the ability to define its behaviour in response to communication events according to the specific coordination needs. It has been argued4,29 that the openness and the wideness of the Internet naturally lead to conceive it as a multiplicity of independent environments (e.g. Internet nodes or administrative domain of nodes), and to design applications in terms of agents that explicitly locate and access resources in this environment. TuCSoN supports such an approach to application design by providing multiple, independent interaction spaces, called tuple centres, that abstract the role of the environment. Agents (possibly mobile ones) access tuple centres by name, either locally in a transparent way, or globally on the Internet in a network-aware fashion.28 For instance, suppose that the TuCSoN node try.deis.unibo.it (often called try node in short in the following) provides tuple centre twopa for agent coordination, and also hosts agent local. Suppose now that agent local performs the invocation twopa?out(p(b)) using the local invocation form of the TuCSoN coordination primitives. Given that no TuCSoN node identifier is specified in the invocation, the coordination space local to the try node is implicitly adopted, so the local twopa tuple centre is taken as the recipient of the invocation out(p(b)). Now, suppose that agent anywhere performs the invocation [email protected]?out(p(b)) from anywhere on the Internet, using the network invocation form of the TuCSoN coordination primitives. Since the name of node try is specified in the invocation, the coordination space of try is explicitly adopted, and the twopa tuple centre hosted by try is taken as the recipient of the invocation out(p(b)), independently of the location of agent anywhere. So, wherever anywhere is, the above invocation has in general the same effect as the invocation twopa?out(p(b)) by agent local: that is, triggering the evaluation of out(p(b)) by the tuple centre twopa of the TuCSoN node try.


360

00063


A local interaction space can be used by agents to access the local resources of an environment and as an agora where to meet other agents and coordinate activities with them. For these reasons, as fully distributed interaction media, tuple centres can be understood as social abstractions15 : indeed, they can be exploited to explicitly constrain agent interactions, and to enforce and encapsulate the coordination and cooperation activities that define agent aggregation as a society. Interaction protocols can then be designed and distributed among agents and media, adopting the most adequate balance for the specific application goals. This implies: • the enhancement of agent autonomy — i.e. agents can be designed focusing only to their own goals and tasks, disregarding dependencies with respect to other agents, and without having to track (open) environment evolution; • the enactment of prescriptive coordination, constraining agent interactions so as to reflect sound behaviours according to the defined social goals; • the promotion of the decentralized nature of the multiagent system, since tuple centres are spread over the network, and live in infrastructure nodes visited by rambling agents migrating from node to node. The topological nature of the TuCSoN global interaction space28 makes it possible to deal with the typical issues of distributed systems, enforcing flexible security policies, workload allocation policies, and fault tolerance policies. 3.2. TuCSoN as an infrastructure for VE and WfMS The problem of heterogeneity is addressed in TuCSoN both at the model and at the infrastructure levels. From the technology viewpoint, TuCSoN is developed in Java, guaranteeing portability among platforms.38 Its architecture is based on a lightweight core, designed to support different sorts of middleware — from sockets, Java RMI, and CORBA, to proprietary solutions, minimizing the impact on the hosting environments and enabling a wide range of hardware devices (desktops, PDA, etc.) to exploit the infrastructure. Also, TuCSoN directly supports the integration between heterogeneous information sources: its tuple-based coordination model straightforwardly supports uncoupled interactions, thanks to generative communication (communication data that survive communication acts),13 which provides agent uncoupling, from the name, space and time viewpoints. In this way, agents can interact needing neither to know each other (name uncoupling) nor where they are (space uncoupling), and independently of their simultaneous existence (time uncoupling). These are key features for a peer-to-peer interaction model between WfMS engines and participants, since they make it possible to go beyond point-to-point communication protocols, supporting location-independent, disconnected workflow participation. Since tuple centres can be programmed so as to suitably react to incoming/outgoing communication events, by defining the coordination laws ruling agent interactions, TuCSoN tuple centres are more powerful coordination abstractions than tuple spaces. For instance, as discussed in Ref. 22, logic tuple centres


00063


361

can act as intelligent information mediators, mapping knowledge to knowledge: so, VE participants are no longer required to change/adapt their model of knowledge representation in order to interact fruitfully. Moreover, new participants can be easily integrated dynamically, since new ad hoc rules can be added to a mediator tuple centre at run-time. The ability of defining the dynamic behaviour of tuple centres is also the key feature that allows TuCSoN to fully support heterogeneity at the process level and, more generally, to face the coordination of dynamic aspects inside the VE. In fact, this is how TuCSoN supports a form of uncoupled,37 objective32 coordination, storing coordination rules outside the interacting entities and effectively governing their interaction in a predictable way. This is a key aspect both to provide the clean separation between workflow participants and workflow engines, and to enforce prescriptive coordination, two issues not easy to be achieved when adopting approaches based on subjective coordination only. Coordination rules in TuCSoN are expressed as programs in the ReSpecT specification language,24 which are embodied within tuple centres: as a Turing equivalent language,9 ReSpecT ensures that any computable coordination rule can be expressed (and enforced). As a consequence, workflow rules can be defined as TuCSoN coordination laws, decoupled from the interacting agents and embedded into the coordination abstractions, keeping workflow coordinators and workflow participants distinct at the design, development, and run-times. For instance, suppose that tuple centre twopa in the TuCSoN node try contains the following ReSpecT specification: reaction(out(p(X)), (in_r(p(X)))). reaction(out(p(X)), (in_r(p(a)), out_r(pp(a,X)))) and that agent local (also hosted by node try) performs an invocation twopa?out(p(b)). As a first result, the p(b) tuple is added to the tuple space of twopa. Then, the execution of both the above reactions is triggered, since the primitive invocation matches their first argument out(p(X)). The first reaction always succeeds, immediately removing the p(b) tuple just inserted. Moreover, in case the tuple space of twopa already contains a p(a) tuple, also the second reaction succeeds, removing p(a) and inserting pp(a,b) instead. In case no p(a) tuple occurs in twopa, instead, the second reaction fails, producing no further effect on the twopa tuple space. The very point here is that from the viewpoint of the local agent, all the above operations are executed as a transaction. So, the global observable effect of the invocation of out(p(b)) on twopa is simply the substitution of p(a) with pp(a,b) in the case that p(a) occurs in twopa — the insertion of p(b) is never perceived by local in any case. Finally, coordination laws in tuple centres are dynamically inspectable. Since a ReSpecT behaviour specification is structured as a multi-set of logic tuples, an intelligent agent can in principle retrieve it and reason about the rules currently governing interaction — in our case, about the workflow rules. Moreover, since


362

00063


a tuple centre behaviour specification can be changed dynamically, an intelligent agent could monitor the evolution of a VE, and pro-actively adapt the workflow rules so as to improve the VE behaviour and performance. Along this direction, a TuCSoN-based WfMS could in principle exploit the full power of intelligent agents so as to provide the flexibility and adaptability that is required to face rapid changes in business environments, as well as to react to unpredicted situations.

4. A Case Study To clarify some of the ideas discussed in the previous sections, this section presents a simple case study, where the TuCSoN coordination infrastructure is exploited to build a virtual bookshop, here taken as an example of a virtual organization. In particular, we discuss two specific workflow processes likely to occur in the bookshop scenario, and show how they can be managed exploiting the TuCSoN infrastructure. 4.1. General description The virtual bookshop is a Virtual Enterprise (VE) that aggregates several companies of different sorts to sell books through the Internet. In this scenario, we identify four basic roles: the bookseller (who provides the books), the carrier (who delivers books from sellers to customers), the interbank service (which executes payment transactions), and the Internet service provider (the Web portal for customers). The two workflows that we consider in the following concern: • the purchase of a single book from a specific bookseller; and • the purchase of a set of books from different booksellers. These two examples imply the specification and execution of classic workflow rules, such as managing a sequence of activities, an AND-Splitting process (coordinating more activities executed in parallel, started at the same time) and an AND-Joining process (requiring synchronization of parallel activities). The first workflow (Fig. 1) describes the sequence of activities involved in the purchase of a specific book. First, order information is gathered by the Web site used by the customer — any of the sites provided by any Internet service provider participating to the VE. Then, the activity to get the book ready at the chosen bookseller’s starts. When the book is ready, the dispatching activity is executed, to have the book delivered from the bookshop to the customer by a carrier. Finally, after the book has been delivered to the customer, the payment transaction activity is executed, involving the intervention of an interbank service to transfer money from the customer to the VE. The second workflow (Fig. 2) involves the purchase of a set of books from (possibly) different booksellers. After order information is gathered, a number of acquiring book activities are executed in parallel, each aiming at getting a book from a specific bookseller. When all the books are ready at the involved booksellers’,


00063


Collect order

Choose a

information

specific

from the

bookshop

customer

and carrier

Deliver the Get the book ready at the bookshop

Fig. 1.

book from the bookshop to the customer

363

Execute payment transaction

Single book purchase workflow.

Get the book #1 ready at the bookshop A

Get the book #2 ready at the bookshop B Collect order

Deliver the

information

books from the

from the

bookshops to

customer

the customer

…

Execute payment transaction

Get the book #n ready at the bookshop N

Fig. 2.

Book set purchase workflow.

the dispatching activity can start as in the first case (for the sake of simplicity, we assume here that the same carrier is used to deliver all the books). So, the virtual enterprise is characterized by multiple, heterogeneous workflow engines provided by VE participants, each with its own workflow rules and tasks that depend upon the context in which the workflow engine is situated. In the case study, the TuCSoN infrastructure of each VE participant provides its local vbs tuple centre, working as its specific workflow engine. 4.2. The agent viewpoint Tasks are executed autonomously by (artificial or human) agents, coordinated by the workflow engines. In particular, the agent/engine interaction occurs either when an agent declares to be ready to execute a specific task (according to its role), or when an agent returns the result of the task execution (or communicates the related problems). In our case, interaction takes the form of insertion and retrieval of tuples in vbs tuple centres, exploiting Linda-like coordination primitives: agents check for new tasks to execute by trying to retrieve (by means of an inp operation) ready_to_do tuples, and provide task results by inserting (by means of an out) task_success or task_failure tuples. Details about agent interaction protocols


364

00063

A. Ricci, A. Omicini & E. Denti interface

interface agent

out(case_to_start(single_book_purchase, info(Customer,Book,Seller,Carrier)))

inp(ready_to_do(buy_the_book, info(Book,Seller), TaskID))

agents

inp(ready_to_do(buy_the_book, info(Book,Seller), TaskID))

delivering

delivering inp(ready_to_do(dispatch_the_book, info(BookReceipt,Carrier,From,To),

agent

TaskID))

inp(ready_to_do(dispatch_the_books, info(BookReceiptList,Carrier,SellerList,To), TaskID))

out(task_success(TaskId, CustomerReceiptList))

out(task_success(TaskId, CustomerReceipt))

payment

payment agent

info(Customer,OrderList,Carrier)))

out(task_success(TaskId,BookReceipt))

out(task_success(TaskId,BookReceipt))

agent

out(case_to_start(book_set_purchase,

buyer

buyer agent

agent

inp(ready_to_do(make_payment, info(Customer,Book), TaskID))

out(task_success(TaskId, BankReceipt))

agent

inp(ready_to_do(make_payments, info(Customer,BookList), TaskID))

out(task_success(TaskId, BankReceipt))

Fig. 3. Agent interaction protocol in the single book purchase workflow (left) and in the book set purchase workflow (right).

in the two workflow examples are illustrated in Fig. 3, and described in the following subsections. The main agents involved in the workflows are: • interface agents, responsible for collecting information about customers and orders. These agents also interact with customers during order execution, informing them about order status and possible problems; • buyer agents, responsible for ordering books from the booksellers and getting them ready for delivery; • delivering agents, responsible for delivering the books to the customers, provided that the books are ready at the bookseller’s. To do so, they inform the carrier of each new dispatching to do, and monitor the delivery until the book is in the customer’s hands; • payment agents, responsible for getting the payments done. These agents interact with an interbank service for transferring money from customers to the virtual bookshop. The execution of a task by an artificial (mobile) agent may involve agent migration through the nodes of the virtual enterprise. For instance, buyer agents start from the node where the workflow is initiated and managed, then move to the booksellers’ nodes, negotiate the service, place the order, check the correct execution of


00063


365

the service, and finally come back to the initial node, where the results are inserted in the local vbs tuple centre. 4.3. The coordination viewpoint: The workflow engine Here we consider the design and development of a simple generic workflow engine, and show its ability to support the two workflow examples discussed above. Mapping a workflow engine onto a tuple centre essentially means to define the event model and the process model. The event model defines what kind of internal and external workflow events must be considered. The process model describes the behavioural aspects of a workflow specification, from its initial state to one of its final states.6 The main element is the task, as the elementary unit of work inside a workflow. A workflow schema is the collection of tasks that collectively achieve the goal(s) of a process. Tasks are interrelated into a flow structure via connectors, such as split and join elements, which define the execution dependencies among tasks (the order in which tasks are executed). A case is an execution of a workflow schema, i.e. an instance of the corresponding (business) process. In our mapping, each workflow has a name used to identify its type; for instance, single_book_purchase and book_set_purchase are the names used for the two examples discussed above. Each case (instance of a workflow) is identified univocally by a numeric identifier, which is managed by the tuple centre. Also each task inside a workflow has a name used to identify its type (such as buy_the_book, dispatch_the_book, etc.). Each instance of a task is identified by a numeric identifier, managed by the tuple centre. 4.3.1. The event model In our model. the occurrence of an event is captured by the insertion of a descriptive tuple, which is said to reify the interaction event in the tuple centre. In this context, we consider some of the main event types found in relevant research WfMS such as WIDE, managing both internal and external events.6 Internal events are the ones defining the normal flow of activities within the workflow, such as temporal events related to the starting and the termination of a task. Here, in particular, we consider as internal events: • the start of a new case, which is represented by the tuple case_started(CaseID, WorkflowName, Info) where CaseID is the numeric identifier assigned by the tuple centre, WorkflowName is the type of the workflow (in our case study, either single_book_purchase or book_set_purchase), and Info is the information required to start the case; • case termination, which is represented by the tuple case_done(CaseID)


366

00063


• the start of a new task, which is represented by the tuple task_started(TaskID, CaseID, TaskType, Info, ExecutorID) where TaskID is the numeric identifier of the task, CaseID is the identifier of the owner case, TaskType is the type of the task, Info the starting information and ExecutorID the identifier of the agent responsible of the task; • the termination of a task, which is represented by the tuple task_success(TaskID, Info) where TaskID is the numeric identifier of the task, and Info is the information about task execution provided by the agent. External events are events that can impact on the regular evolution of a running case, but are outside the control of the WfMS. Relevant examples are asynchronous external events (such as task cancellation), changes in the process organization (such as the sudden unavailability of agents), violation of constraints over workflow data or violation of time constraints.7 Typically, exception management in state-of-theart workflow systems requires the definition of a set of triggers (rules) which specify the asynchronous actions (typically notifications) to be taken when the conditions defining exceptions occur. Analogously, workflow exceptions can be managed in tuple centres by means of reactions triggered by the interaction events related to the exception conditions: once again, exception events are reified as tuple inserted in the tuple centre. For instance: • the timeout of a task, represented by a tuple task_timeout(TaskID) where TaskID is the numeric identifier of the task; • a generic failure of a task, represented by the tuple task_failure(TaskID,Info) where TaskID is the numeric identifier of the task, and Info are details about the failure; • a generic failure of the whole case, represented by the tuple case_abort(CaseID,Info) where CaseID is the numeric identifier of the case, and Info contains details about the failure. 4.3.2. The process model Now we show how the control flow that characterizes the coordination activities of a workflow engine can be mapped upon a tuple centre. Typically, WfMSs describe control flow structures by means of flow diagrams, nets (such as Petri-like Nets) and the alike. In our case, we can describe the same diagrams in terms of coordination rules defining the behaviour of the tuple centre used as a workflow engine. Part


00063


367

of the rules (here implemented as ReSpecT reactions) constitute a basic core of meta-workflow rules, acting as the instructions of a workflow virtual machine: they are independent of the specific workflow, and are used to define standard workflow behaviour triggered by internal workflow events, making it possible to define the basic skeleton of the flow structure. These (meta-)rules interpret/execute other rules (trigger other ReSpecT reactions in our case), which are peculiar to the specific workflow type and constitute the remaining part of the rules defining the process model. The basic meta-rule cores is defined by the ReSpecT specification shown in Table 1. A workflow case starts by placing a tuple case_to_start(WorkflowName, Info) in the tuple centre acting as the workflow engine by means of an out operation — here, in the specific vbs tuple centre: WorkflowName indicates the name (type) of the workflow (such as single_book_purchase or book_set_purchase), and Info is the information needed to start the case. At the insertion of this tuple, the tuple centre vbs reacts with the first workflow meta-rule (reaction 1 in Table 1), which initializes the basic information of the new case (such as the numeric identifier), reifies the starting case event in the tuple centre by inserting the tuple case_started(CaseID, CaseName, Info)) then starts the coordination flow, by identifying the next task(s) to execute. The initialization of the basic information of the case involves also the insertion of the case_state(CaseID, executing, _) tuple representing the dynamic state of the case. The template of this tuple is case_state(CaseID, State, Detail) where State can be either executing, when the workflow is executing normally, or exception, in case of exceptions — then, Detail provides some information about it. In the meta-rules, identification of the next task(s) to execute is given by the tuple next_task(CaseID, CaseName, CurrentTask, Info) where CaseName is the type of the current case, and CurrentTask is the name of the current task (the constant case_start — as appears in the first reaction in Table 1 — is used as a task name when the first task to execute is considered). Then, the next task(s) to execute are defined by the reactions triggered by the insertion of this tuple, which are part of the rules that characterize the specific workflow type, according to its control flow structure. So, the two basic workflow example considered here (single book and book set purchase) share the same basic core rules, and define their specific coordination flow by providing specific reactions


368

00063


triggered by the insertion of the next_task tuple. The specific reactions can ask for the execution of a new task by inserting a tuple task_to_do(CaseID, TaskType, Info) in the tuple set as the reification of the related event – as already discussed above. The second workflow meta-rule (reaction 2 in Table 1) makes it possible to assign/delegate tasks to agents assuming the responsibility of their autonomous execution. In particular, an agent (either human or artificial) of the virtual enterprise declares its availability to execute a task by trying to retrieve (by means of an inp operation) a tuple of template ready_to_do(+TaskType, -Info, -TaskID)a where TaskType identifies the type (name) of the task that the agent is able to execute, and TaskID and Info are information retrieved about the specific task to be done. When the inp request is performed by an agent, the second workflow meta-rules is triggered, and the task assignment coordination step is realized. In particular, this step involves: (i) the setup of information describing the new task to be executed, such as the task numeric identifier; (ii) the retrieval of the tuple task_to_do, representing task assignment to the requiring agent; (iii) the insertion of the tuple ready_to_do required by the agent, with the details about the task to execute; (iv) the reification of the event representing the start of a new task, by means of the tuple task_started. The third workflow meta-rule of the workflow interpreter (reaction 3 of Table 1) collects the information produced by the execution of a task (and provided by the agent in charge of the task), and triggers the execution of the next tasks. This rule is triggered when the agent responsible of a task execution communicates the task termination and result by placing the tuple task_success(TaskID, Info) in the tuple centre. The rule reifies the task termination event, collects information about the case owning the task, and finally triggers the identification of the next task(s) to do (or states the termination of the case) by placing a proper next_task tuple in the tuple space. Finally, the last workflow meta-rule (reaction 4 of Table 1), triggered by the insertion of the tuple reifying the case termination event, is used to clean up the information about the dynamics of the terminated case.

a As used in the logic programming field, the symbol + means that the argument must be specified by the agent, as a sort of input argument in a procedure call. Instead, the symbol — means that the argument is retrieved through unification, as a sort of output argument in a procedure call.


00063

Virtual Enterprises and Workflow Management Table 1.

369

ReSpecT code for the workflow meta-rules.

1

reaction(out(case to start(CaseName, Info)),( in r(case to start(CaseName, Info)), in r(case id counter(ID)), NextID is ID + 1, out r(case id counter(NextID)), out r(case started(ID,CaseName, Info)), out r(case state(ID, executing, )), out r(next task(ID, CaseName, case start, )))).

2

reaction(inp(ready to do(TaskType, , )),( pre, in r(task to do(CaseID, TaskType, Info)), in r(task id counter(TaskID)), NextID is TaskID + 1, out r(task id counter(NextID)), current agent(ExecutorID), out r(ready to do(TaskType, Info, TaskID)), out r(task started(TaskID, CaseID, TaskType, Info, ExecutorID)))).

3

reaction(out(task success(TaskID, Info)),( in r(task success(TaskID, Info)), out r(task done(TaskID, Info)))). reaction(out r(task done(TaskID, Info)),( rd r(task started(TaskID, CaseID, TaskType, Info, )), rd r(case started(CaseID, CaseName, )), rd r(case state(CaseID, executing, )), out r(next task(CaseID, CaseName, TaskType, Info)))). reaction(out r(next task(CaseID, CaseName, TaskType, Info)),( in r(next task(CaseID, CaseName, TaskType, Info)))).

4

reaction(out r(case done(CaseID)),( in r(case state(CaseID, executing, )))).

4.4. Specifying the workflow examples As already mentioned, specific workflows are defined by adding the ad hoc rules describing the coordination flow for the specific workflow types to the basic reaction block constituting the workflow meta-rules. 4.4.1. The single book purchase workflow In the first workflow example (single book purchase), coordination involves the synchronization and exchange of information between tasks to be executed sequentially. So the ad hoc rules of this case define a sequential flow structure, as represented by the ReSpecT specification in Table 2. The agent interaction protocol of the workflow is sketched in Fig. 3, left. Figure 4 sketches the interactions and reactions at the beginning of the workflow. In particular, reaction 1 identifies the first task to execute, that is, the purchase of the book at the specific bookseller’s, identified by the task name buy_the_book. Reaction 2 identifies the next task to do when the purchase of book is completed, that is, the dispatching of the book from the book-


370

00063

A. Ricci, A. Omicini & E. Denti Table 2.

Reactions for the single book purchase workflow example.

1

reaction(out r(next task(CaseID, single book purchase, case start, )),( rd r(case started(CaseID,single book purchase,info( ,Book,Seller, ))), out r(task to do(CaseID, buy the book, info(Book,Seller))))).

2

reaction(out r(next task(CaseID, single book purchase, buy the book, BookReceipt)),( rd r(case started(CaseID,single book purchase,info(Customer, ,Seller,Carrier))), out r(task to do(CaseID, dispatch the book, info(BookReceipt,Carrier,Seller,Customer))))).

3

reaction(out r(next task(CaseID, single book purchase, dispatch the book, CustomerReceipt)),( rd r(case started(CaseID,single book purchase,info(Customer,Book, , ))), out r(task to do(CaseID, make payment, info(Customer,Book))))).

4

reaction(out r(next task(CaseID, single book purchase, make payment, BankReceipt)),( out r(case done(CaseID)))).

seller to the customer (task name dispatch_the_book). Reaction 3 identifies the next task to execute after the book delivery, that is, the execution of the payment transaction (task name make_payment). Finally, reaction 4 closes the case, after the payment transaction has been completed. 4.4.2. The book set purchase workflow With respect to the first example, this workflow involves also the parallel execution of a set of independent tasks: the order of distinct books from different booksellers. Task results must be all collected and joined before executing the sequential part of the workflow, that is, the dispatching of the books using the same carrier and the payment transaction. So, the specific rules for this case realize first a splitting/branching of the control flow in several independent tasks, then the AND-joining of the tasks, and finally the sequential flow, as in the previous workflow example. The rules are represented by the ReSpecT specification in Table 3; the agent interaction protocol is sketched in Fig. 3, right. In particular, reaction block 1 triggers the set of purchase tasks to be executed in parallel (with task name buy_the_book as in the first example), by generating a task_to_do tuple for each parallel task (BRANCH rule). Moreover, this rule produces some auxiliary tuples that are used later for collecting results from task execution; in particular, the tuple book_set_orders(CaseID,ReceiptList,SellerList) is used to collect book receipts from the booksellers. Reaction block 2 identifies the next task to be executed after the completion of all the purchase tasks (AND-JOIN rule), that is, the dispatching of books from the booksellers to the client (task dispatch_the_books). Reaction 3 identifies the task to be executed after the delivery of the books, that is, the execution of the payment transaction for the books (task make_payments). Finally, as in the previous example, reaction 4 closes the case after the payment transaction has been completed.


00063


371

out(case_to_start ( single_book_purchase, info(customer(id(303),surname(Johnson),name(Linda)), book(isbn(1575860082),title(“Vicious Circle”),author(“Barwise”)), seller(id(16),name(“Book World”),node(“book-word.com”)), carrier(id(8),name(“ACME”),node(“acme.com”)) ) ))

tuple centre vbs case_id_counter(845) task_id_counter(950) . ..

interface agent

case_to_start(single_book_purchase,...)

reaction(out(case_to_start(CaseName,Info)),( in_r(case_to_start(CaseName,Info)), in_r(case_id_counter(ID)), NextID is ID + 1,out_r(case_id_counter(NextID)), out_r(case_started(ID,CaseName,Info)), out_r(case_state(ID,executing,_)), out_r(next_task(ID,CaseName,case_start,_)))). ...

reaction(out_r(next_task(CaseID, single_book_purchase, case_start,_)),(

tuple centre rd_r(case_started(CaseID,single_book_purchase,info(_,Book,Seller,_))), out_r(task_to_do(CaseID, buy_the_book, info(Book,Seller))))). case_id_counter(846) task_id_counter(950) ... case_started(845,single_book_purchase, info(customer(id(303),surname(Johnson),name(Linda)), inp(ready_to_do(buy_the_book,Info,TaskID)) book(isbn(1575860082),title(...),author(...)), seller(id(16),name(...),node(...), carrier(id(323),name(...),node(...)) )) buyer agent

vbs

case_state(845, executing,_) task_to_do(845, buy_the_book, info(book(...),seller(...)))

reaction(inp(ready_to_do(TaskType,_,_)),(

pre, in_r(task_to_do(CaseID,TaskType,Info)), in_r(task_id_counter(TaskID)), NextID is TaskID + 1, out_r(task_id_counter(NextID)), current_agent(ExecutorID), out_r(ready_to_do(TaskType,Info,TaskID)), out_r(task_started(TaskID,CaseID,TaskType,Info, ExecutorID)))).

buyer agent

tuple centre vbs case_id_counter(846) task_id_counter(951) ... case_started(845, single_book_purchase, info(customer(id(303),surname(Johnson),name(Linda)), book(isbn(1575860082),title(...),author(...)), seller(id(16),name(...),node(...), carrier(id(323),name(...),node(...)) ))

ready_to_do (buy_the_book, info(book(...),seller(...)), 950) task_started(950, 845, buy_the_book, info(book(...),seller(...)), buyerAgentId) case_state(845, executing, _)

go(“book-world.com”) buyer agent goes to the seller’s node

Fig. 4.

Some interactions and reactions in the single book purchase workflow.

4.5. Handling workflow dynamics The support for dynamic changes in coordination activities and exception handling are among the most important features required from a flexible Web-based workflow


372

00063

A. Ricci, A. Omicini & E. Denti Table 3.

Reactions for the book set purchase workflow example.

1

reaction(out r(next task(CaseID, book set purchase, case start, )),( rd r(case started(CaseID, book set purchase,info( , OrderList, ))), out r(book set orders(CaseID, [], [])), out r(tasks to do(CaseID, buy the book, OrderList)) )). reaction(out r(tasks to do(CaseID, buy the book, [(Book,Seller) — L])),( out r(task to do(CaseID, buy the book, info(Book, Seller))), out r(tasks to do(CaseID, buy the book, L)), out r(single book order(CaseID, info(Book, Seller))))). reaction(out r(tasks to do(CaseID, buy the book, L)),( in r(tasks to do(CaseID, buy the book, L)))).

2

reaction(out r(next task(CaseID, book set purchase, buy the book, BookReceipt)),( in r(single book order(CaseID, info(Book, Seller))), in r(book set orders(CaseID, ReceiptList, SellerList)), out r(book set orders(CaseID, [BookReceipt — ReceiptList], [Seller — SellerList])), out r(check subtasks(CaseID, book set purchase, buy the book)))). reaction(out r(check subtasks(CaseID, book set purchase, buy the book)),( no r(single book order(CaseID, )), in r(book set orders(CaseID,Receipts, Sellers)), rd r(case started(CaseID, book set purchase,info(Customer, , Carrier))), out r(task to do(CaseID, dispatch the books, info(Receipts, Carrier, Sellers, Customer))))). reaction(out r(check subtasks(CaseID, book set purchase, buy the book)),( in r(check subtasks(CaseID, book set purchase, buy the book)))).

3

reaction(out r(next task(CaseID, book set purchase, dispatch the books, CustomerReceipts)),( rd r(case started(CaseID, book set purchase, info(Customer, OrderList, ))), out r(task to do(CaseID, make payments, info(Customer, OrderList))))).

4

reaction(out r(next task(CaseID, book set purchase, make payments, BankReceipts)),( out r(case done(CaseID)))).

system. Here, we will consider structural changes in the workflow activities, that is, changes that affect not only application data, but also the structure of the coordinating procedures.11

4.5.1. Handling exceptions As already mentioned, external events related to exceptions are captured and reified as tuples inserted in the tuple centre. Let us consider the types of exception discussed previously, that is, task_timeout, task_failure, and case_abort. As an example, here we consider simple workflow meta-rules for managing exceptions, which block the current coordination flow of the workflow, freezing task assignment, and notify the exception to the agent responsible for the specific workflow type. The reactions realizing these meta-rules are shown in Table 4. A first reaction block (Table 4, up) maps the different exception types onto the tuple format chosen


00063


373

Table 4. Managing exceptions: reifying the exception event (up) and triggering actions (freeze tasks and send notification to the exception manager). 1

reaction(out(task failure(TaskID, Info)),( in r(task failure(TaskID, Info)), out r(exception occurred(CaseID, task failure, info(TaskID, Info))))).

2

reaction(out(task timeout(TaskID)),( in r(task timeout(TaskID, Info)), out r(exception occurred(CaseID, task timeout, info(TaskID))))).

3

reaction(out(case abort(CaseID, Info)),( in r(case abort(CaseID, Info)), out r(exception occurred(CaseID, case abort, info(Info))))).

1

reaction(out r(exception occurred(CaseID, ExceptionName, Info)),( in r(case state(CaseID, executing, )), out r(case state(CaseID, exception, Info)))).

2

reaction(out r(case state(CaseID, exception, Info)),( out r(freeze tasks(CaseID, [])))). reaction(out r(freeze tasks(CaseID, TaskList)),( no r(task to do(CaseID, , )), out r(freezed tasks(CaseID ,TaskList)))). reaction(out r(freeze tasks(CaseID, TaskList)),( in r(task to do(CaseID, What, Info)), out r(freezed tasks(CaseID, [task to do(CaseID, What, Info) — TaskList])) )). reaction(out r(freeze tasks(CaseID, List)),( in r(freeze tasks(CaseID, List)))).

3

reaction(out r(exception occurred(CaseID, ExceptionName, Info)),( rd r(case started(CaseID, CaseName, )), rd r(exception manager(CaseName, NotificationBox)), out tc(NotificationBox, exception notification(CaseID, ExceptionName, Info)))).

to represent the occurrence of an exception exception_occurred(CaseID, ExceptionType, Info) Therefore, task timeout is mapped (reaction 1) onto the tuple exception_occurred(CaseID, task_timeout, info(TaskID)) A generic task failure is mapped (reaction 2) onto the tuple exception_occurred(CaseID, task_failure, info(TaskID, InfoFailure)) And finally, the abort of a case is mapped (reaction 3) onto the tuple exception_occurred(CaseID, case_abort, info(InfoAbort))


374

00063


Then, the insertion of the tuple exception_occurred triggers the simple behaviour that we established for managing exceptions (Table 4, bottom), that accounts for: (i) freezing the coordination flow, by removing the tuples task_to_do currently in the tuple centre and saving them in the auxiliary tuple freezed_tasks(CaseID,TaskList) (reaction block 2); (ii) notifying the exception to an agent manager/responsible for the specific workflow type, by inserting a notification tuple about the exception in the tuple centre (which acts as a notification box) provided by the manager (reaction 3), described by a tuple exception_manager(CaseName,NotificationBox) where NotificationBox is the name of the tuple centre where the exceptions about the single book purchase workflow should be notified. Table 5.

ReSpecT code for handling the new credit card check task in the first workflow.

1a

reaction(out r(next task(CaseID, single book purchase, case start, )),( rd r(case started(CaseID,single book purchase,info(Customer,Book, , ))), out r(task to do(CaseID, check credit card, info(Customer))))).

1b

reaction(out r(next task(CaseID, single book purchase, check credit card, check ok)),( rd r(case started(CaseID,single book purchase,info( ,Book,Seller, ))), out r(task to do(CaseID, buy the book, info(Book,Seller))))).

1c

reaction(out r(next task(CaseID, single book purchase, check credit card, check fail)),( rd r(case started(CaseID,single book purchase,info(Customer, , , ))), out r(exception occurred(CaseID,case abort, info(credit card check failed)) )).

4.5.2. Handling changes to the workflow schema This feature is easily provided by the tuple centre model, thanks to the encapsulation of the coordination specification and the uncoupling properties featured by the coordination media. Here, the key property is that structural changes have to be applied on-the-fly, during execution of the workflow activities.11 This fundamental deployment feature is suitably supported by the tuple centre run-time in TuCSoN which enables the dynamic inspection and the run-time programmability of the coordination media upon which workflow engines are built. As a simple example of a structural change, suppose that a new activity has to be inserted in the purchasing workflow. For the sake of simplicity, we refer here to the single book purchase: so, now, before ordering the book, the credit card has to be checked. In order to be implemented on-the-fly, this change to the workflow policy


00063


375

requires that the behaviour of vbs tuple centre is dynamically modified, replacing the first reaction in Table 2 with the reaction block shown in Table 5. The new rules alter the previous coordination flow, triggering the credit card check task (called credit_card_check) as the first activity to be executed after the starting of the case (reaction 1a). If the credit card check succeeds, the purchase task is specified as the next task (reaction 1b); otherwise, the proper case abort exception is triggered (reaction 1c). 4.6. Discussion The above examples show how objective coordination abstractions can be effectively used to model and engineer the workflow engines, pointing out some of the benefits of the TuCSoN approach. First, workflow engines can be naturally mapped onto coordination abstractions able to encapsulate the workflow rules as coordination laws, like tuple centres. Also, a coordination infrastructure like TuCSoN can provide the required flexibility in managing on-the-fly changes and exceptions in workflows, supporting run-time inspection and evolution of the coordination laws. Even more, expressing workflow activities in terms of a coordination specification language that feature a simple and formally-defined semantics, like ReSpecT,24 promotes the development of tools for the formal verification of liveness and safety properties, actually supporting the detection of dynamic bugs that can affect workflow activities after on-the-fly structural changes.11 The case study also outlines the benefits of uncoupling the agents from the workflows where they are called to operate: agents retrieve and provide only the information related to their own tasks (here expressed in term of logic tuples) with no need to deal with any other information concerning the workflow execution. This implies that changes to the logic of the workflow policies can be done without affecting agents. Moreover, the tuple centre coordination model allows prescriptive coordination to be enforced locally, without compromising agent pro-activeness: indeed, the model does promote agents autonomy, since agents need not be aware of workflow details (which are outside the scope of their specific goals) in order to accomplish their tasks. Finally, the case study emphasizes the role of coordination infrastructures in supporting agent cooperation without negotiation, since agents are not required to be aware of other agents’ activity. This is a valuable property especially in cooperative contexts where the workflow of the activities can be clearly defined (such as in the virtual bookshop case) and automated coordination can take place.3

5. Related Works Currently available (research and industrial) WfMS are mainly extensions of DBMS. Notable examples are WIDE,14 Regatta,35 APM,5 MILANO,2 TriGS,18 and the commercial systems ATI Action Workflow, XSoft InConcert, and TeamWARE


376

00063


Flow. The above systems face the requirements for classic WfMS, but are not especially suited to support Inter-Organizational and Web-based WfMS.10 Indeed, this scenario requires the ability to cope with the openness and distribution of the Web environment, the capability to face heterogeneity at different levels (information models, resources, processes), to support the dynamic modification of workflow rules, and to adapt the evolution of business processes so as to easily face changes and exceptions, which frequently occur in an open environment. However, approaches based on agents and coordination infrastructures are now emerging. The METEOR2 system,21 for instance, goes beyond the classic workflow systems, addressing issues such as Web-based workflow, workflow adaptation and integral support for collaboration. In Ref. 34, the researchers involved in the METEOR project asserted that “Coordination (as supported by current generation of workflow technology), collaboration (as supported by CSCW and work group systems) and information management will increasingly together merge into a higher level form of middleware”. OrbWork and WebWork, which are two implementations of the METEOR2 model, make a meaningful step toward coordination and collaboration, even though they might not be expressive enough to provide the required general-purpose coordination middleware. On the other hand, TuCSoN provides a general-purpose coordination infrastructure, which seems to be expressive enough to support distributed workflow management, as well as coordination and collaboration among heterogeneous agents. In Refs. 1, 12 and 33, mobile and intelligent agent technologies are used for VE management, yet without providing an explicit model for WfMS. In Refs. 8 and 20, VEs are represented using multiagent systems, with an explicit model of WfMS. Basically, all these approaches support business processes execution with subjective coordination, encapsulating the social rules directly within agents. As discussed in this article, we found that objective coordination, provided by TuCSoN and many other coordination models,37 is better suited to the context of VE than subjective coordination, since it provides a more effective support for dynamics, heterogeneity, and process traceability. The Workspaces coordination technology,36 specifically developed for distributed workflow management, provides one further way of developing a Webbased WfMS making explicit use of a coordination infrastructure for agent-based systems. Basically, its architecture is based on coordinated transformation of XML documents by means of distributed XSL (workflow) engines: the workflow rules are expressed via an XML-based Workspaces Coordination Language, and then compiled into a set of XSL rules to specify the engine behaviour. TuCSoN uses logic tuples for both communication and coordination, instead of XML: however, as far as any XML fragment can be expressed in terms of first-order logic, an analogous approach could in principle be adopted by TuCSoN too.


00063


377

6. Conclusions VE and WfMS call for suitable and easily deployable infrastructures, enabling the integration of heterogeneous resources and services, and supporting the development of business processes in terms of workflow rules automating coordination among participants. In this article, we claim that a suitable agent coordination infrastructure, providing the abstractions and the run-time support to address heterogeneity of different sorts and to represent workflow rules as coordination laws, may well fit the needs of VE management in a highly dynamic and unpredictable environment. To support our claim, we exploit the TuCSoN agent coordination infrastructure to develop a simple case study, concerning the management of a virtual bookshop. As a final remark, it is worth pointing out that in this article we do not mean to address the issues of the effectiveness of information representation (as tuples), the optimization of resource management, and the effectiveness of coordination algorithms and interaction protocols used — neither do we mean to propose ReSpecT as a full-featured workflow language. In fact, despite its Turing-equivalence, ReSpecT can be considered a sort of assembly language for ruling interactions — complete, general-purpose, but low-level. So, a perspective worth investigation is how to express coordination laws in a higher-level language — possibly tailored to the specific application domain, such as WPDL40 or WebWork21 in the specific case of workflow — built on top of ReSpecT. Also, given that the notion of tuple centre is not bound to any specific behaviour specification language,25 the behaviour of tuple centres could in principle be programmed in a specific, high-level workflow language, directly using workflow rules as coordination laws.

References 1. A. Aerts, N. Szirbik, D. Hammer, J. Goossenaerts and H. Wortmann, On the design of a mobile agent web for supporting virtual enterprises. IEEE 9th Int. Workshops Enabling Technol.: Infrastruct. Collaborative Enterprises — Web-based Infrastructures and Coordination Architectures for Collaborative Enterprises (WET ICE 2000), Gaithersburg (MD), 14–16 June 2000, 236–241. 2. A. Agostini, G. De Michelis and M. A. Grasso, Rethinking CSCW systems: The architecture of MILANO, 5th European Conference on Computer Supported Cooperative Work (ECSCW’97), eds. J. A. Hughes, W. Prinz, T. Rodden and K. Schmidt (Kluwer Academic Publishers, August 1997) 33–48. 3. J. Bardram, Designing for the dynamics of cooperative work activities, 1998 ACA4 Conf. Comput. Supported Cooper. Work, ACM, Seattle, Washington, USA, 1998. 4. G. Cabri, L. Leonardi and F. Zambonelli, Mobile-agent coordination models for internet applications, IEEE Comput. 33, 2 (February 2000) 82–89. 5. S. Carlsen, Action port model: A mixed paradigm conceptual workflow modeling language, ed. M. Halper, 3rd IFCIS Int. Conf. Coop. Inf. Syst., IEEE Computer Society (August 1998) 300–309. 6. F. Casati, S. Castano, M. Fugini, I. Mirabel and B. Pernici, Using patterns to design rules in workflows, IEEE Trans. Softw. Eng. 26, 8 (August 2000) 760–785.


378

00063


7. F. Casati, S. Ceri and G. Paraboschi, S. ANF Pozzi, Specification and implementation of exceptions in workflow management systems, ACM Trans. Database Syst. 24, 3 (September 1999) 405–451. 8. P. K. Chrysanthis, T. Znati, S. Banerjee and S.-K. Chang, Establishing virtual enterprises by means of mobile agents, Workshop Res. Issues Data Eng. (RIDE’99), IEEE CS, March 1999, 116–125. 9. E. Denti, A. Natali and A. Omicini, On the expressive power of a language for programming coordination media, 1998 ACM Symp. Appl. Comput. (SAC’98), Atlanta (GA), ACM 27 February–1 March 1998, 169–177. 10. M. Divitini, C. Hanachi and C. Sibertin-Blanc, Inter-organizational workflows for enterprise coordination, Coordination Internet Agts.: Models, Techol., Appl., eds. A. Omicini, F. Zambonelli, M. Klusch and R. Tolksdorf, Chap. 15 (Springer-Verlag, March 2001) 369–398. 11. C. Ellis, K. Keddara and G. Rozenberg, Dynamic change within workflow systems, ACM Conf. Org. Comput. Syst., 1995, 10–21. 12. K. Fischer, J. Muller, I. Heimig and A.-W. Scheer, Intelligent agents in virtual enterprises, Practical Appl. Intell. Multi-Agt. Technol. (PAAM’96), April 1996. 13. D. Gelernter, Generative communication in Linda, ACM Trans. Program. Lang. Syst. 7, 1 (1985) 80–112. 14. P. Grefen, B. Pernici and G. Sanchez (eds.), Database Support for Workflow Management — The WIDE Project (Kluwer Academic Publishers, 1999). 15. M. Huhns and M. Singh, Social abstractions for information agents, ed. M. Klusch, Intelligent Information Agents: Agent-Based Information Discovery and Management on the Internet (Springer-Verlag, 1999). 16. S. Jablonski and C. Bussler, Workflow-Management: Modelling Concepts, Architecture and Implementation (International Thomson Computer Press, 1996). 17. N. R. Jennings, P. Farantin, P. Johnson, M. J. O’Brien and M. Wiegand, Using intelligent agents to manage business processes, Practical Appl. Intell. Agts. MultiAgt. Technol. (PAAM’96), April 1996. 18. G. Kappel, S. Rausch-Scott and W. Retschitzegger, A framework for workflow management systems based on objects, rules and roles, ACM Comput. Surv. 32, 1es (2000) Article No. 27. 19. T. Malone and K. Crowstone, The interdisciplinary study of coordination, ACM Comput. Surv. 26, 1 (1994) 87–119. 20. M. Merz, B. Liberman and W. Lamersdorf, Using mobile agents to support interorganizational workflow-management, Appl. Artif. Intell. 11, 6 (September 1997) 551–572. 21. J. A. Miller, D. Palaniswami, K. J. Sheth, Amit P. Kochut and H. Singh, Webwork: METEOR2 ’s web-based workflow management system, J. Intell. Inf. Syst. 10, 2 (1998) 185–215. 22. A. Omicini, Hybrid coordination models for handling information exchange among Internet agents, AI*IA 2000 Workshop — Agenti intelligenti e Internet: teorie, strumenti e applicazioni, eds. A. Bonarini, M. Colombetti and P. L. Lanzi, Milano (Italy), 13 September 2000, 1–4. 23. A. Omicini, SODA: Societies and infrastructures in the analysis and design of agentbased systems, Agent-Oriented Software Engineering, eds. P. Ciancarini and M. J. Wooldridge, Lecture Notes in Computer Science 1957 (Springer-Verlag, 2001) 185–193. 1st International Workshop (AOSE 2000), Limerick, Ireland, 10 June 2000, revised papers. 24. A. Omicini and E. Denti, Formal ReSpecT, Declarative Programming — Selected Papers from AGP’00, eds. A. Dovier, M. C. Meo and A. Omicini, Electronic Notes in Theoretical Computer Science 48 (Elsevier Science B. V., 2001) 179–196.


00063


379

25. A. Omicini and E. Denti, From tuple spaces to tuple centres, Sci. Comput. Program. 41, 3 (November 2001) 277–294. 26. A. Omicini, P. Petta and R. Tolksdorf (eds.), Engineering Societies in the Agents World II, Lecture Notes in Artificial Intelligence 2203 (Springer-Verlag, December 2001) 2nd International Workshop (ESAW’01), Prague, Czech Republic, 7 July 2001, revised papers. 27. A. Omicini, R. Tolksdorf and F. Zambonelli, eds., Engineering Societies in the Agents World, Lecture Notes in Artificial Intelligence 1972 (Springer-Verlag, December 2000), 1st International Workshop (ESAW’00), Berlin, Germany, 21 August 2000, revised papers. 28. A. Omicini and F. Zambonelli, Coordination for Internet application development, Autonomous Multi-Agt. Syst. 2, 3 (September 1999) 251–269. Special Issue: Coordination Mechanisms for Web Agents. 29. G. P. Picco, A. Fuggetta and G. Vigna, Understanding code mobility, IEEE Trans. Softw. Eng. 24, 5, May 1998. 30. A. P. Rocha and E. Oliveira, An electronic market architecture for the formation of virtual enterprises, PRO-VE’99 IFIP/PRODNET Conf. Infrastruct. Indust. Virtual Enterprises, October 1999. 31. P. Santanu, P. Edwin and C. Jarir, Essential requirements for a workflow standard, Proc. OOPSLA 1997 – Business Object Workshop III, ACM, October 1997. 32. M. Schumacher, Objective Coordination in Multi-Agent System Engineering — Design and Implementation, Lecture Notes is Artificial Intelligence 2039 (Springer-Verlag, April 2001). 33. W. Shen and D. H. Norrie, Implementing internet enabled virtual enterprises using collaborative agents, Infrastructures for Virtual Enterprises (Kluwer Academic Publisher, 1999) 343–352. 34. A. P. Sheth and K. J. Kochut, Workflow applications to research agenda: Scalable and dynamic work coordination and collaborative systems, Advances in Workflow ¨ Manag. Syst. Interoperability, eds., A. Doga¸c, L. Kalinichenko, M. Tamer Ozsu and A. P. Sheth, Istanbul, Turkey, August 1997. 35. K. D. Swenson, R. J. Maxwell, T. Matsumoto, B. Saghari and K. Irwin, A business process environment supporting collaborative planning, Collaborative Comput. 1, 1 (1994) 15–34. 36. R. Tolksdorf, Coordinating work on the Web with workspaces, IEEE 9th Int. Workshops Enabling Technol.: Infrastruct. Collaborative Enterprises — Web-based Infrastructures and Coordination Architectures for Collaborative Enterprises (WET ICE 2000), Gaithersburg (MD), IEEE CS, 14–16 June 2000, 248–253. 37. R. Tolksdorf, Models of coordination, Eng. Soc. Agts. World, eds. A. Omicini, R. Tolksdorf and F. Zambonelli, Lecture Notes is Artificial Intelligence 1972, (Springer-Verlag, December 2000) 78–92. 38. TuCSoN at SourceForge, http://tucson.sourceforge.net. 39. Workflow Management Coalition home page, http://www.wfmc.org/. 40. WfMC, Interface 1: Process definition interchange, Technical Report WFMC-TC1016-P, Workflow Management Coalition, October 1999. 41. M. J. Wooldridge and N. R. Jennings, Intelligent agents: Theory and practice, Knowledge Eng. Rev. 10, 2 (1995) 115–152.