Distributed Workflow Enactment: an Agent-based Framework Giancarlo Fortino, Alfredo Garro, and Wilma Russo Supported Cooperative Work (CSCW) systems that offer Abstract—This paper describes the design and the groupware applications and other shared workspace tools for implementation of an Agent-based Workflow Enactment supporting human interactions [4]. Instead, Production Framework (AWEF) which can be instantiated on the basis of a workflows are process-driven due to their highly repetitive workflow schema for obtaining a specific workflow enactment engine. A workflow engine therefore is a MAS capable of nature [7]. In this case the processes are highly structured and managing instances of the workflow schema used for the the adopted WFMS are based on workflow enactment services instantiation of AWEF. Each MAS adopts a hierarchical able to offer an efficient and accurate control about the flow organizational structure composed by an EnacterAgent, which is of the processes. Moreover, in a Production workflow, most responsible of the activation and monitoring of the workflow, one of the tasks are executed automatically by software programs or more ManagerAgents, which are responsible of the execution and applications without interacting with human users. Such a and control of the workflow/subworkflows according to a parent/child model, and one or more TaskAgents, which are kind of workflows can be modeled as a set of interrelated responsible of the execution of internal tasks and/or of the services (Service Workflow) [29]. In the context of Internet- wrapping of external tasks or services. The hierarchical based workflows [19], such services are distributed and distribution of the workflow execution control between the owned by different organizations so that they could become ManagerAgents and the distribution of the computation among unavailable due to the lack of network service guarantees. To the TaskAgents allow for more flexible, efficient, and robust deal with this important issue, a dynamic service allocation of enactment services. services is often required as well as the negotiation of service Index Terms—Multi-Agent Systems, Distributed Workflow level agreements (SLA). Due to these reasons the enactment Enactment, Workflow Patterns, Agent-based Applications. of Internet-based workflows requires more flexible enactment engines based on more adequate coordination mechanisms. I. INTRODUCTION To effectively fulfill such requirements the Agents paradigm and technology are being used since Agents are W ORKFLOW Management Systems (WFMS) are systems designed to automate complex activities consisting of many dependent tasks [26]. In the last decades widely considered very suitable for the modeling and implementation of complex software systems in open distributed environments [18]. In particular, in the context of WFMS have been developed to provide support to the workflow management, the use of the Agents paradigm allows modeling, improvement and automation of business for transforming a workflow from a sequence of activities, management, industrial engineering, and data-intensive that are often modeled and consist of (Web) services scientific processes [25,10]. Since each business area can invocation, in a society of proactive, autonomous and benefit from workflow management it is possible to coordinable entities (or multi-agent system) whose distinguish different kind of workflows and related workflow coordinated interactions drive the workflow execution management techniques specifically conceived for meeting the [20,17]. requirements of a specific business area and fully supporting This paper proposes an agent-based approach for the the associated business processes. A main distinction that can distributed enactment of workflows. The workflow enactment be done is between Collaborative and Production-oriented is enabled by an Agent-based Workflow Enactment workflows. The former are information centric: human Framework (AWEF) which is instantiated on the basis of the interactions drive the execution of workflows in a loosely schemas of the workflows to be enacted so obtaining specific structured manner. In this case WFMS are Computer workflow engines. A workflow schema can be defined by using the Workflow Patterns identified and proposed by van G. Fortino is with the Department of Electronics, Informatics and Systems der Aalst [25] and can be represented using YAWL (Yet (DEIS), University of Calabria, Rende (CS), 87036 Italy. (e-mail: Another Workflow Language) [24]. A workflow engine giancarlo.fortino@unical.it). A. Garro is with the Department of Electronics, Informatics and Systems therefore consists of a MAS capable of managing instances of (DEIS), University of Calabria, Rende (CS), 87036 Italy. (e-mail: the workflow schema used for the instantiation of the alfredo.garro @unical.it). workflow engine. The framework provides the base agents for W. Russo is with the Department of Electronics, Informatics and Systems (DEIS), University of Calabria, Rende (CS), 87036 Italy. (e-mail: wilma.russo workflow enactment (EnacterAgent, which is responsible of @unical.it). the activation and monitoring of the workflow, 110 ManagerAgent, which is responsible of the execution and TABLE I THE WORKFLOW PATTERNS control of the workflow, and TaskAgent, which is responsible PATTERN PATTERN NAME of the execution of internal tasks and/or of the wrapping of DEFINITION TYPE (SYNONYMS) external tasks or services), their interaction protocols and a set Sequence An activity is enabled after the of control-flow classes which are associated to the behavior of (Sequential routing, serial completion of another activity. routing) the ManagerAgent and implement the Workflow Patterns. The A point in the workflow where a single framework is implemented by using JADE [3,16], a FIPA- Parallel Split thread of control splits into multiple (AND-split, parallel routing, threads of control which can be executed Basic Control Flow compliant [13] Java-based agent development environment fork) in parallel, thus allowing activities to be which basically offers a distributed agent platform and an API executed simultaneously or in any order. A point in the workflow where multiple for agent programming. Synchronization parallel subprocesses/activities converge The remainder of the paper is organized as follows. Section (AND-join, rendezvous, into one single thread of control, thus synchronizer) synchronizing multiple threads. 2 introduces some background concepts about workflow Exclusive Choice A point in the workflow where, based on enactment, presents our agent-based approach enabled by (XOR-split, conditional a condition, one of several branches is AWEF and reports some related works. Section 3 and Section routing, switch, decision) chosen. Simple Merge A point in the workflow where two or 4 describe the design and the JADE-based implementation of (XOR-join, asynchronous more alternative branches merge without AWEF respectively. Finally conclusions are drawn and join, merge) synchronization. directions of further work delineated. Multi-choice A point in the workflow where, based on (Conditional routing, a condition, a number of branches are selection, OR-split) chosen. Synchronizing Merge A point in the workflow where multiple Advanced Branching and (Synchronizing join, OR-join) paths converge into one single thread. II. DISTRIBUTED WORKFLOW ENACTMENT Synchronization A point in a workflow where two or more branches reconverge without The Workflow Reference Model, proposed by the synchronization. If more than one branch Workflow Management Coalition (WfMC) [28], describes a Multi-merge gets activated the activity following the merge is started for every activation of generic architecture for workflow management consisting of every incoming branch. several functional components interfaced with a Workflow A point in a workflow that waits for a Enactment Service (see Figure 1). The Process Definition number of the incoming branches to Discriminator complete before activating the Tools allow a process designer to define business processes (N/M or partial join) subsequent activity; then it waits for the often adopting a diagrammatic representation. The diagrams remaining branches to complete and “ignores” them. Then it resets itself. (or workflow schemas), represented in a Process Description Arbitrary Cycles A point in a workflow where one or Structural Language (PDL), are received by the Workflow Enactment (Loop, iteration, cycle) more activities can be done repeatedly. A given sub-workflow should be Service via Interface 1. The Workflow Client Application is Implicit Termination terminated when there is nothing else to usually the application which requests the enactment of a be done. workflow to the Workflow Enactment Service by specifying Multiple Instances without synchronization Multiple instances of an activity can be the workflow schema to be enacted and passing the (Multi-threading without created with no need to synchronize parameters (Case Activation Record) needed for the activation synchronization, spawn off them. facility) and execution of a specific workflow instance. During its Multiple Instances Multiple Instances with a An activity is enabled a number of times enactment a workflow can be administered and monitored priori design time known at design time. Once all instances are completed some other activity needs (Interface 5) and it may interact with other automated business knowledge to be started. processes (Interface 4), with human participants (Interface 2) An activity is enabled a number of times Multiple Instances with a known at run time. Once all instances are and with other applications without human intervention priori run-time knowledge completed some other activity needs to (Interface 3). be started. Multiple Instances An activity is enabled a number of times known neither at design time nor at run- without a priori run-time time. Once all instances are completed knowledge some other activity needs to be started. It is similar to the exclusive choice but Deferred Choice the choice is not made explicitly and the (External choice, implicit run-time environment decides what choice, deferred XOR-split) branch to take. State-based Interleaved Parallel A set of activities is executed in an Routing arbitrary order decided at run-time; no (Unordered sequence) two activities are active at the same time. The enabling of an activity depends on Milestone the workflow being in a given state, i.e. (Test arc, deadline, state the activity is only enabled if a certain condition, withdraw milestone has been reached which did message) not expire yet. An enabled activity is disabled, i.e. a Cancel Activity Cancellation thread waiting for the execution of an Fig. 1. The reference model for WFMS proposed by the WfMC. (Withdraw activity) activity is removed. Cancel Case A workflow instance is removed (Withdraw case) completely. 111 As described above, the Process Definition component computation and/or data during the workflow enactment provides the process designer with a workflow language able (Figure 3). to specify a workflow schema which can be successively instantiated by means of the Enactment Service based on a workflow API and on one or more workflow engines. The WF Schemas workflow definition language is to be expressive and powerful to specify complex workflows from several perspectives: control-flow, data-flow, resource and operational [25]. The control-flow perspective describes activities and their WF Activation Params • WF Type WF Enactment Service execution ordering through different constructors, which • CAR WF Enactment permit to control the flow of execution, and provides an WF essential insight into the effectiveness of a workflow Distribution Params WF Engines specification. The data flow perspective rests on control-flow perspective, while the resource and operational perspectives Fig. 3. An A Workflow Enactment Service. are ancillary. An expressive and powerful set of control-flow constructs More in details, in order to enact a workflow the WFES for the specification of workflow schemas (WF Schemas) is selects a suitable WF Engine, from the WF Engines the set of the Workflow Patterns proposed by van der Aalst repository, on the basis of the schema of the workflow to be [25]. In Table I the Workflow Patterns, identified by enacted. If the required WF Engine is not available the WFES examining the most known contemporary workflow creates it. The creation is driven by the WF Schema which is management systems, are enumerated along with their used to properly instantiate a Workflow Enactment synonyms and a brief definition. Framework so building a WF Engine able to enact that An example WF Schema based on the WF Patterns and specific WF Schema. In building the specific WF Engine the drawn by using YAWL [24] is given in Figure 2. After the distribution params specified by the user are also considered. task A is carried out (sequence pattern), the tasks B, C, and D Finally, the WF Engine will enact the workflow on the basis are executed in parallel (parallel split pattern). When B or C of the given CAR and the possible distribution params (Figure complete (synchronizing merge pattern), the task E is 4). The created WF Engine is stored in the WF Engines executed an arbitrary number of times (arbitrary cycles repository so that it can be reused for enacting future pattern). When D completes (sequence pattern), either the task workflows of the same type. F or the task G (exclusive choice pattern) is executed. When either F or G complete (simple merge pattern), depending on WF Schema WFE Distribution Framework Params the precedent choice, the task H is executed (sequence pattern). When the iterative execution of E completes and also H terminates (synchronization pattern), the task I is executed and, after its completion (sequence pattern), the workflow terminates. No B CAR WF Engine yes E Done? C WF Enactment A I F D H G Fig. 4. The construction of a WF Engine. Fig. 2. An example WF Schema based on the WF Patterns. A generic Workflow Enactment Service (WFES) receives A. The proposed agent-based approach from the user the indication about which workflow is to be In our approach for the distributed workflow enactment a enacted (WF Type param) and the Case Activation Record WF Engine is a MAS built by properly instantiating the (CAR) for the specific workflow instance; then, on the basis Agent-based Workflow Enactment Framework (AWEF) on of the WF Schema corresponding to the selected WF Type, the basis of a WF Schema defined by using the WF Patterns. the WFES enacts the workflow by means of a specific WF In particular, a WF Engine consists of tree different agent Engine. If the WF Engine is of the distributed type the user types: indicates also a set of params for specifying some - EnacterAgent, which represents the interface between the requirements related to the distribution of control, MAS constituting the WF Engine and the Workflow 112 Enactment Service and is responsible for the activation and called Workflow Executors, from the ALW specification by monitoring of the workflow. plugging the implementation of the required workflow - ManagerAgent, which is responsible of the execution and activities, that are available in a repository, into “empty” control of the workflow. A single ManagerAgent allows for agents (skeletons). A workflow engine is, therefore, a MAS flat workflow management whereas a hierarchical structure having a peer-to-peer organizational structure in which the of ManagerAgents, formed according to the parent/child workflow execution is driven by the interactions among the model, allows for a hierarchical workflow management. Workflow Executors. The behavior of a ManagerAgent is defined on the basis of A similar approach can be found in [22] which presents a the WF Schema it has to enact. methodology for translating a workflow specification into a - TaskAgent, which is responsible for the execution of MAS architecture specifying formalized rules for modeling internal tasks and/or for the wrapping of external tasks or agents’ behaviors. The MAS is not generated automatically by services. The behavior of a TaskAgent is defined on the a compiler like in [1] but by the developer adopting a tool basis of the activities composing the task it has to carry out. called Agent Developer Studio (ADS). A WF Engine is, therefore, a MAS with a hierarchical In [7,8,9] the authors present an agent-based approach for organizational structure in which the control of the workflow enacting BPEL4WS (Business Process Execution Language execution is hierarchically distributed between the for Web Services) [6] workflow specifications. BPEL4WS is ManagerAgents and the computation is distributed among the an XML-based language that allows for the specification of TaskAgents. workflows where the activities are defined by Web service A WF Schema can be specified by using YAWL [24] invocations. The proposed distributed enactment mechanisms which is based on the WF Patterns and offers also an XML combine data-centered and control-centered coordination based representation of the WF Schema mechanisms. Data are managed via a shared XML repository The design and the implementation of the AWEF, on which while the control of the workflow activities is driven by the WF Engines are based, are presented in details in sections asynchronous messages exchanged between the agents that 3 and 4. enact the workflow. The message exchange pattern for the control messages is derived from a Colored Petri Net model of B. Other related approaches the workflow. The agents’ behaviors are configured and In the literature it is possible to find different proposals of instantiated at run time on the basis of the BPEL4WS distributed workflow enactment mechanisms based on the specification of the specific workflow to be enacted. The Agent paradigm and technologies which aim to support more organizational MAS structure is based on a RequestorAgent flexible, dynamic and adaptive workflow from the process, that orchestrates a set of Distributed Workflow Agents resource and activity perspective [8]. according to the workflow specification. The system has been Such approaches differ from each other in the supported implemented in JADE. dimensions of distribution (computation, control and data), in Another agent-based approach for enacting workflows the adopted coordination model (control-driven, data-driven) specified in BPEL4WS is proposed in [14]. The novelty of the and in the exploited MAS organizational structure approach is that the enactment of the workflows is carried out (hierarchical, peer-to-peer). by peer agents that can be associated with web services. The In [10,23,21] the authors present an agent-based workflow control flow is coded in an interaction protocol that is not engine centered on a hierarchical organizational structure in defined at the development time like in [1,22] but which is which a ProcessAgent executes a workflow instance by passed at run time between the agents together with the requesting the execution of the tasks composing the workflow messages so informing each agent what to do next to keep the to a set of ResourceAgents. ResourceAgents can be seen as workflow executing. representing web services and can be dynamically discovered Another peer-to-peer agent-based enactment approach is and allocated to a ProcessAgent by a ResourceBrokerAgent. presented in [29]. In this approach the workflow to be enacted In this control-driven approach the control about the state of is decomposed into a set of interrelated task partitions. Each the workflow execution is hierarchically distributed between task partition represents a service and its position, i.e., the the ProcessAgents and the computation whereas data are interaction and dependency with the other services in the distributed among the ResourceAgents which are responsible process. Then, each task partition is distributed to an agent of the task execution. which represents a service provider offering a service required In [1] the authors propose a software environment to by the specific workflow instance. Each agent autonomously dynamically generate agent-based workflow engines. A manages the enactment of the represented service and the workflow engine is generated by a compiler that translates an interactions between this service and the others only on the XPDL workflow definition to a MAS ready to be executed in basis of the assigned task partition; agents are not conscious of the Hermes middleware. The translation process is a two step the whole process in which they are involved. Such adopted procedure. In the first step the user-level workflow definition coordination model is known as a choreography coordination is mapped to an Agent Level Workflow (ALW) specification. model. In the second step, the compiler concretely generates agents, 113 III. THE DESIGN OF AWEF Manager/Task Interaction Protocol (MTIP). The design of AWEF was carried out by exploiting an In the Agent Behaviors Model the basic behaviors of the agent-oriented development process [11] in which the EnacterAgent, ManagerAgent and TaskAgent are defined. In requirements capture phase is supported by the Tropos particular, the defined ManagerAgent behavior (or methodology [5], the analysis and design phases are supported ManagerBehavior) is composed of: by the Gaia methodology [27] and the detailed design phase is An InitialPseudoActivity, which represents the starting supported by the Agent-UML [2] and the Distilled StateCharts point of the workflow execution in the WF Schema. (DSC) [12]. One or more FinalPseudoActivity, which represent points in The requirements, captured using the Tropos goal-oriented the WF Schema at which the workflow or a part of it ends. approach, were reported in a Requirements Statements A FinalPseudoActivity uses a parent ManagerAgent for document. On the basis of the requirements the following key notification purposes. roles were identified: One or more WFPattern, which represent the control-flow Enacter, which manages the activation and monitoring of activities. A WFPattern, which can be any of the available workflows and represents the interface between the WF WF Patterns [25] (sequence, and-split, and-join, xor-split, Engine and the Workflow Enactment Service; xor-join, or-split, multi-merge, discriminator, loop, multiple Manager, which manages the execution and control of instances, deferred choice, milestone, etc) uses one or more workflows; TaskAgents and one or more child ManagerAgents for Executor, which executes the internal workflow tasks; activation purposes and a parent ManagerAgent for Wrapper, which interacts with the external tasks or notification purposes. services. In order to model a WF Schema, InitialPseudoActivity, Each of these roles was fully described by using a Role FinalPseudoActivity, and WFPattern are linked through Schema according to the Gaia methodology. The protocols source/target control-flow associations. associated with each role were identified and documented by Figure 5 shows a Statecharts-based representation [15] of an Interactions Model. Then, the identified Roles were the ManagerBehavior. aggregated into Agent Types also specifying the agent types StateChangeNotification/ handleNotification() hierarchy (Agent Model); the main services required to ControlFlow realize each role were specified (Services Model) and the / executeNextControlAction() relationships of communication between the Agent Types documented (Acquaintance Model). ControlAction The identified Agent Types are: Executed EnacterAgent, which derives from the Enacter role. ManagerAgent, which derives from the Manager role. A ExecuteNextControlAction/ executeNextControlAction() single ManagerAgent allows for flat workflow management whereas a hierarchical structure of ManagerAgents, formed TerminateControl/ sendEndNotification() according to the parent/child model, allows for a hierarchical workflow management. Fig. 5. The generic behavior of a ManagerAgent. TaskAgent, which derives from both the Executor and Wrapper role. According to the WF Schema to enact, the ManagerAgent The detailed design phase allowed for obtaining a detailed enters the ControlFlow superstate executing the specification of the behaviors of the Agent Types which have executeFirstControlAction() method. In this superstate, every been defined in the Agent Model. The work products of this times that an ExecuteNextControlEvent is received the phase were the Agent Interactions Model and the Agent ManagerAgent executes the next control-flow action by Behaviors Model. The former consists of a set of Agent-UML invoking the executeNextControlAction() method which interaction diagrams [2] which thoroughly specify the patterns fetches the next WFPattern and executes it. Upon completion of interaction between the Agent Types; the Agent Behaviors of a WFPattern execution, two events are generated: (i) Model specifies the dynamic behavior of each Agent Type by ExecuteNextControlAction which allows the means of the Distilled StateCharts (DSC) formalism [12]. ManagerBehavior to invoke the executeNextControlAction() The main interaction patterns documented by the Agent method; (ii) StateChangeNotification which allows notifying Interactions Model are: the upper-level ManagerAgent or the EnacterAgent about the EnacterAgent/ManagerAgent, which is enabled by the control-flow state change of the workflow. If there are no Enacter/Manager Interaction Protocol (EMIP); more WFPatterns to execute, the TerminateControl event is ManagerAgent/ManagerAgent, which is enabled by the generated which drives the termination of the Manager(parent)/Manager(child) Interaction Protocol ManagerBehavior and the transmission of the related (MMIP); EndNotification to the upper-level ManagerAgent or to the ManagerAgent/TaskAgent, which is enabled by the EnacterAgent. A WFPattern execution can involve: (i) the 114 detection of the completion of a task through the reception of which models a complex task whose sub-tasks correspond a FIPA ACL message which can also carry the data produced to the activities performed in the states of a finite state by the completed task; (ii) the creation and/or activation of machine. In particular, the states of ManagerBehavior TaskAgents or ManagerAgents. correspond to the control-flow states of the workflow (or The interaction diagrams composing the Agent Interactions sub-workflow) that the ManagerAgent is controlling; each Model and the behavioral specifications of the Agent state is associated to a WFPattern which is activated when Behaviors Model are to be intended as basic schemas that will the state becomes active. EMIP, MMIP, and MTIP are be coded into the basic classes of AWEF. A WF Engine will appositely defined through sequences of ACL messages be obtained by instantiating such basic classes according to instances of the ACLMessage class of JADE. the schema of the workflow to be enacted and using the In the following subsection a hierarchical WF Engine based concrete implementations of the tasks required for the on AWEF and capable of enacting the WF Schema reported in workflow execution. Figure 2 is presented. A. A hierarchical WF Engine based on AWEF The hierarchical workflow management is enabled by a set of ManagerAgents each of which embodies a sub-schema of a WF Schema according to a hierarchical model. With reference to the WF Schema of Figure 2, the WF Engine able to enact such a WF Schema is obtained through: 1. The partitioning of the WF Schema into a set of hierarchically arranged workflow schemas: WF Schema 1, WF Schema 1.1, WF Schema 1.2 (see Figure 7); 2. The instantiation of AWEF with respect to the obtained workflow schemas (see Figure 8 for the resulting class diagram). WF Schema 1 Top Manager Agent SM1 A I SM2 SubManagerAgent1 WF Schema 1.1 No Yes B E Done? C Fig. 6. Class diagram of the AWEF Framework. SubManagerAgent2 WF Schema 1.2 F In Figure 6 the classes which compose AWEF are reported. In particular, AWEF provides the base agents for workflow D H enactment (EnacterAgent, ManagerAgent and TaskAgent), Fig. 7. Partitioned WF Schema. their interaction protocols and a set of control-flow classes With reference to Figure 8a the EnacterAgent is linked to which are associated to the behavior of the ManagerAgent and the top-level ManagerAgent which is, in turn, linked to the implement the WF Patterns. TaskAgents related to the WF Schema 1, and to the SubManagerAgents1and SubManagerAgents2 which control IV. THE JADE-BASED IMPLEMENTATION OF AWEF the WF Schemas 1.1 and 1.2 respectively. Each The JADE-based classes of AWEF were straightforwardly SubManagerAgent is, in turn, linked to the TaskAgents derived from the class diagram reported in Figure 6. In associated to its schema. particular: With reference to Figures 8b-d each ManagerBehavior is EnacterAgent, ManagerAgent and TaskAgent extend the obtained by translating its associated WF Schema in a set of Agent class of JADE [16]; classes consisting of one InitialPseudoActivity, one or more EnacterBehavior, TaskBehavior and WFPattern extend FinalPseudoActivity, and one or more WFPattern which are Behaviour class of JADE which represents a generic appositely interconnected. behavior terminating when the end-of-activity condition is met; ManagerBehavior extends FSMBehaviour class of JADE 115 (a) (b) (c) (d) Fig. 8. WF Engine class diagram: (a) MAS structure; (b-d) behaviors of the ManagerAgents (b-d) the basis of WF Schemas defined in YAWL. V. CONCLUSIONS This paper has described an Agent-based Workflow Enactment Framework (AWEF) which can be instantiated on ACKNOWLEDGMENT the basis of a WF Schema for obtaining a specific WF Engine This work was partially supported by the Italian Ministry of which mainly consists of a hierarchy of ManagerAgents. Education, University and Research in the framework of the Each ManagerAgent has in charge the enactment of a sub- M.ENTE (Management of integrated ENTErprise) research schema of the WF Schema used for the instantiation of AWEF project PON (N°12970-Mis.1.3). The authors also wish to and exploits a set of TaskAgents for the execution of the thank Serena Martino and Giuseppe Agapito for their specific workflow tasks associated to its sub-schema. This contribution to the JADE-based implementation of the AWEF MAS organization allows for the hierarchical distribution of framework. the workflow execution control between the ManagerAgents and for the distribution of the computation among the REFERENCES TaskAgents. Due to these features AWEF constitutes a basic [1] E. Bartocci, F. Corradini, E. Merelli, Enacting proactive workflows component for the construction of more flexible, efficient, and engine in e-Science, In proceedings of the 6th International Conference on Computational Science (ICCS 2006), University of Reading, UK, robust Workflow Enactment Services. May 28-31, 2006, pp. 1012-1015, volume 3993/2006, Springer-Verlag, The JADE-based implementation of AWEF has been Berlin. applied to the development of a workflow system for the [2] B. Bauer, J.P. Muller, and J. Odell. Agent UML: A Formalism for monitoring of distributed agro-industrial productive processes. Specifying Multiagent Interaction. In Paolo Ciancarini and Michael Wooldridge, editors, Agent-Oriented Software Engineering, pages 91- The developed workflow system is a component of a larger 103. Springer-Verlag, Berlin, 2001. system which was built in the context of the M.ENTE [3] F. Bellifemine, A. Poggi, and G. Rimassa, Developing multi-agent (Management of integrated ENTErprise) project which aims at systems with a FIPA-compliant agent framework, Software Practice and Experience, 31, pp. 103-128, 2001. developing a pervasive system for the control and [4] U. M. Borghoff, J. H. Schlichter. Computer-Supported Cooperative management of productive, organizational, and business Work: Introduction to Distributed Applications. Springer-Verlag. 2000. processes of companies working in the agro-alimentary [5] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, and A. Perini. TROPOS: An Agent-Oriented Software Development Methodology, industry of Calabria. The current experimentation of the Journal of Autonomous Agents and Multi-Agent Systems, 8(3):203-236, system provides support to a consortium of agro-industrial 2004. greenhouses. [6] Business Process Execution Language for Web Services version 1.1. http://www-128.ibm.com/developerworks/library/specification/ws-bpel/. Efforts are currently underway to develop an enactment [7] P. Buhler, J.M. Vidal, Towards AdaptiveWorkflow Enactment Using service which is able to automatically instantiate AWEF on Multiagent Systems, Journal of Information Technology and Management, vol. 6, pp. 61–87, 2005, Springer-Verlag, Berlin. 116 [8] P. Buhler, J.M. Vidal, Enacting BPEL4WS specified workflows with multiagent systems, In Proceedings of the Workshop on Web Services and Agent-Based Engineering, 2004. [9] P. Buhler, J.M. Vidal and H. Verhagen, Adaptive Workflow = web services + agents, In Proceedings of the First International Conference on Web Services, 131-137, 2003. [10] L. Ehrler, M. Fleurke, M. A. Purvis, and B.T.R. Savarimuthu, Agent- Based Workflow Management Systems(Wfmss): JBees - A Distributed and Adaptive WFMS with Monitoring and Controlling Capabilities, Journal of Information Systems and e-Business Management, Volume 4, Issue 1, Jan 2006, Pages 5-23, Springer-Verlag, Berlin. [11] G. Fortino, A. Garro, and W. Russo, An Integrated Approach for the Development and Validation of Multi Agent Systems, Computer Systems Science & Engineering, 20(4), pp.259-271, Jul. 2005. [12] G. Fortino, W. Russo, and E. Zimeo, A Statecharts-based Software Development Process for Mobile Agents, Information and Software Technology, 46(13), pp. 907-921, Oct. 2004. [13] Foundation of Intelligent and Physical Agents, http://www.fipa.org. [14] L. Guo, Y. Chen-Burger, and D. Robertson Dave, Enacting the Distributed Business Workflows Using BPEL4WS on the Multi-Agent Platform. In Proceedings of the Third German Conference on Multi- agent System Technologies (MATES2005), LNAI 3550, pp. 35-47, Koblenz Germany, Springer-Verlag. [15] D. Harel and E. Gery. Executable Object Modelling with Statecharts. IEEE Computer, 30(7): 31-42, 1997. [16] Java-based Agent Development Environment (JADE), documentation and software at the world wide web: http://jade.tilab.com. [17] N.R. Jennings, P. Faratin, T.J. Norman, P. O’Brien, and B. Odgers, Autonomous Agents for Business Process Management, Journal of Applied Artificial Intelligence, 14(2), pp. 145–189, 2000. [18] M. Luck, P. McBurney, and C. Preist, A Manifesto for Agent technology: Towards Next Generation Computing, Autonomous Agents and Multi-Agent Systems, 9(3), pp. 203-252, 2004. [19] D.C. Marinescu, Internet-based Workflow Management, John Wiley & Sons, Inc., New York, 2002. [20] P.D. O’Brien and M.E. Wiegand, Agent-based process management: applying intelligent agents to workflow, Knowledge Engineering Review, 13(2), pp. 1-14, 1998. [21] M. A. Purvis, B.T.R Savarimuthu, and M.K Purvis, A Multi-agent Based Workflow System Embedded with Web Services, In proceedings of the second international workshop on Collaboration Agents: Autonomous Agents for Collaborative Environments (COLA 2004), Beijing, China, September 2004, pp 55-62, IEEE/WIC Press. [22] M. Repetto, M. Paolucci, A. Boccalatte, A Design Tool to Develop Agent-Based Workflow Management Systems, In Proc. of the 4th AI*IA/TABOO Joint Workshop "From Objects to Agents": Intelligent Systems and Pervasive Computing, 10-11 September 2003, Villasimius, CA, Italy, pp. 100-107, Pitagora Editrice Bologna. [23] B.T.R. Savarimuthu, M.A. Purvis, M.K. Purvis, and S. Cranefield, Agent-Based Integration of Web Services with Workflow Management Systems, Information Science Discussion Paper Series, Number 2005/05, ISSN 1172-6024, University of Otago, Dunedin, New Zealand. [24] W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language. Information Systems, 30(4):245-275, 2005. [25] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros, Workflow Patterns, Distributed and Parallel Databases, 14(3), pp. 5-51, July 2003. [26] W.M.P. van der Aalst and K. van Hee, Workflow Management: Models, Methods, and Systems, The MIT Press, Cambridge (MA), 2002. [27] M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia methodology for agent-oriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, 3(3):285–312, 2000. [28] Workflow Management Coalition, http://www.wfmc.org. [29] J. Yan, Y. Yang, R. Kowalczyk, and X. T. Nguyen, A service workflow management framework based on peer-to-peer and agent technologies, In Proc. of the International Workshop on Grid and Peer-to-Peer based Workflows co-hosted with the 5th International Conference on Quality Software, Melbourne, Australia, September 19 -21, 2005. 117