=Paper=
{{Paper
|id=Vol-204/paper-18
|storemode=property
|title=Distributed Workflow Enactment: an Agent-based Framework
|pdfUrl=https://ceur-ws.org/Vol-204/P08.pdf
|volume=Vol-204
|dblpUrl=https://dblp.org/rec/conf/woa/FortinoGR06
}}
==Distributed Workflow Enactment: an Agent-based Framework==
https://ceur-ws.org/Vol-204/P08.pdf
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