Agent-Based Integration of Web Serviceswith Workflow Management Systems

Bastin Tony Roy SavarimuthuMaryam PurvisMartin Purvis

Stephen Cranefield

The Information ScienceDiscussion Paper Series

Number 2005/05April 2005

ISSN 1172-6024

University of Otago

Department of Information Science

The Department of Information Science is one of six departments that make up theSchool of Business at the University of Otago. The department offers courses of studyleading to a major in Information Science within the BCom, BA and BSc degrees. Inaddition to undergraduate teaching, the department is also strongly involved in post-graduate research programmes leading to MCom, MA, MSc and PhD degrees. Re-search projects in spatial information processing, connectionist-based information sys-tems, software engineering and software development, information engineering anddatabase, software metrics, distributed information systems, multimedia informationsystems and information systems security are particularly well supported.

The views expressed in this paper are not necessarily those of the department as awhole. The accuracy of the information presented in this paper is the sole responsibil-ity of the authors.

Copyright

Copyright remains with the authors. Permission to copy for research or teaching pur-poses is granted on the condition that the authors and the Series are given due ac-knowledgment. Reproduction in any form for purposes other than research or teach-ing is forbidden unless prior written permission has been obtained from the authors.

Correspondence

This paper represents work to date and may not necessarily form the basis for the au-thors’ final conclusions relating to this topic. It is likely, however, that the paper will ap-pear in some form in a journal or in conference proceedings in the near future. The au-thors would be pleased to receive correspondence in connection with any of the issuesraised in this paper, or for subsequent publication details. Please write directly to theauthors at the address provided below. (Details of final journal/conference publicationvenues for these papers are also provided on the Department’s publications web pages:http://www.otago.ac.nz/informationscience/pubs/). Any other correspondence con-cerning the Series should be sent to the DPS Coordinator.

Department of Information ScienceUniversity of OtagoP O Box 56DunedinNEW ZEALAND

Fax: +64 3 479 8311email: dps@infoscience.otago.ac.nzwww: http://www.otago.ac.nz/informationscience/

Agent-based integration of Web Services with Workflow Management Systems(WfMSs)

Abstract

Rapid changes in the business environment call for moreflexible and adaptive workflow systems. Researchers haveproposed that Workflow Management Systems (WfMSs)comprising multiple agents can provide these capabili-ties. We have developed a multi-agent based workflow sys-tem, JBees, which supports distributed process modelsand the adaptability of executing processes. Modern work-flow systems should also have the flexibility to integrateavailable web services as they are updated. In this pa-per we discuss how our agent-based architecture can beused to bind and access web services in the context of exe-cuting a workflow process model. We use an example fromthe diamond processing industry to show how our agent ar-chitecture can be used to integrate web services withWfMSs.

1. Introduction

Workflow management systems (WfMSs) [20, 13] arewidely used to manage business processes due to theirknown benefits such as automation, co-ordination and col-laboration between entities. Still, the existing, commerciallyavailable workflow management systems do not offer suffi-cient flexibility for distributed organizations participating inthe global market.

Existing systems have rigid, centralised architecturesthat do not operate across multiple platforms [18]. Improve-ments can be made by employing a distributed network ofautonomous software agents that can adapt to changing cir-cumstances. In particular some of the reasons for wantingan adaptive WfMS are:

• It may not be possible to specify all the process de-tails associated with a complex process at the outset.The initial model may represent a high-level view ofthe process, which includes some of the sub-processes.Gradually some of these sub-processes may be refinedas the stakeholders obtain more experience and knowl-edge of a particular process.

• Due to changes in the market or regulatory environ-ment, new requirements may be imposed which canimpact the process definition. Changes in the marketmay also include the availability of some new tech-nologies and new services such as web services whichmay require the modification of the process.

The work of Fleurkeet al.[8, 7] deals with the frameworkof a distributed network of autonomous software agents thatcan adapt to the changing circumstances in a workflow man-agement system. The business processes undergo changesover time to accommodate a changing environment such asthe availability of web services. Business processes shouldbe able to take advantage of web services that are avail-able in an intranet as well as in the Internet, such as stockmonitoring web services. The workflow system that mod-els these business processes should have necessary mecha-nisms to integrate and use these web services. In this paperwe describe the extension to the work done by Fleurkeetal. The enhanced framework provides mechanisms to cre-ate agents that are capable of accessing various web ser-vices.

The paper is organized as follows. The next section givesan overview of the background information on colouredPetri nets, software agents,WfMSs and web services. Thearchitecture of the system is described in Section 3. In thefourth section we discuss the underlying mechanism of in-tegrating web services with our workflow system based onmultiple agents. We have used a real life example of inte-grating web services with a diamond processing workflowdriven by agents. We present the conclusions and future di-rections of our work in section five.1 2

2. Background

In this section we explain the background of our workwhich includes the coloured Petri nets that are used to de-sign the process models, the multi-agent system on which

1 * The primary author is a student.2 * A demonstration of this system will be available to be shown at the

conference.

1

our workflow system has been built, and some prior ap-proaches in using web services with agents.

2.1. Coloured Petri nets

Petri nets [14] are a formalism and associated graphi-cal notation for modelling dynamic systems. The state ofthe system is represented byplaces(denoted by hollow cir-cles) that can containtokens(denoted by symbols inside theplaces). The possible ways that the system can evolve aremodelled by definingtransitions (denoted by rectangles)that have input and output arcs (denoted by arrows) con-nected to places. The system dynamics can be enacted (non-deterministically) by determining which transitions areen-abledby the presence of tokens in the input places, select-ing one andfiring it, which results in tokens being removedfrom its input places and new tokens being generated andplaced in the output places.

Figure 1: A Coloured Petri net model of fault processingsystem

Coloured Petri nets (CPNs) [11] are an elaboration of or-dinary Petri nets. In a coloured Petri net, each place is as-sociated with a ‘colour’, which is a type (although the the-ory of CPNs is independent of the actual choice of type sys-tem). Places can contain a multiset of tokens of their de-clared type. Each input arc to a transition is annotated withan expression (possibly containing variables) that representsa multiset of tokens. For a transition to be enabled, it mustbe possible to match the expression on each input arc toa sub-multiset of the tokens in the associated input place.This may involve binding variables. In addition, a Booleanexpression associated with the transition (itsguard) mustevaluate to true, taking into account the variable bindings.When a transition is fired, the matching tokens are removedfrom the input places, and then multiset expressions anno-tating the output arcs are evaluated to generate the new to-kens to be placed in the output places. If the expression onan output arc evaluates to the empty multiset then no tokensare placed in the connected place. Our system uses CPN tomodel, simulate and execute workflow processes. Figure 1shows a coloured Petri net model of a fault processing sys-tem.

2.2. WfMSs and agents

In the context of WfMSs, agent technology has beenused in different ways [12]. In some cases the agents ful-fil particular roles that are required by different tasks in theworkflow. In these cases the existing workflow is used tostructure the coordination of these agents [10, 15]. An ex-ample of this approach is the work by M. Nissen in de-signing a set of agents to perform activities associated withthe supply chain process in the area of e-commerce [15].In other cases, the agents have been used as part of theinfrastructure associated with the WfMS itself in order tocreate an agent-enhanced WfMS [19, 22]. These agentsprovide an open system with loosely coupled components,which provides more flexibility than the traditional sys-tems. Some researchers have combined both of these ap-proaches [6], where an agent-based WfMS is used in con-junction with specialized agents that provide appropriateapplication-related services.

In our framework, JBees [8], the WfMS is partitionedamong various interacting agents following the interac-tion protocols. The model associated with a business pro-cess is represented using the coloured Petri net formalismand is executed by a specially designed agent. This agent-based environment facilitates the dynamic incorporation ofchanged models into the system and thereby assists pro-cess re-engineering. Advantages of employing agents in-clude the facilitation of inter and intra organizational co-operation and flexibility in choosing processes on-the-flyand controlling process parameters.

2.3. Web Services

Web Services are software components available on theInternet, which provide certain services that may be of gen-eral interest, such as weather monitoring services, currencyconverters, etc. A large fraction of the web services areused within companies protected within their own firewalls.These web services can be accessed for day-to-day businesstransactions. Examples of these web services include bank-ing services and air ticket booking. The workflow processmodeller can integrate web services with the existing work-flow sytem. For example, a process model associated withthe travel plan of a tourist may depend upon environmen-tal factors, such as the weather conditions. The task associ-ated with finding the weather condition can be provided us-ing a web service.

2.4. Related Work

Some researchers have integrated agent-based workflowsystems with web services [4, 5, 21]. However enhance-ments can be made to improve these approaches.

2

Figure 2: Architecture of the multi-agent based workflow management system

In the research done by Buhleret al. [4, 5], BPEL4WS[2] has been used as a process model and this model is con-verted to a Petri net. The problem with this approach as ac-knowledged by the authors, is that the demonstration systemdeveloped by the researchers so far does not support someof the simple constructs of BPEL4WS. However, in our sys-tem the process model is described using a coloured Petrinet that can be directly executed. Our system does not re-quire the conversion of a BPEL process into a Petri net pro-cess. The conversion mechanism of a BPEL4WS model toa Petri net model has to be validated to ensure the struc-tural and behavioural equivalence associated with the origi-nal model.

3. System Architecture

Our system is based on the FIPA [3] compliant agentplatform, Opal [17] and uses the CPN-execution tool JFern[16]. Our system consists of seven types of special Opalagents which provide the functionality to control the work-flow. Figure 2 shows the architecture of the agent-basedworkflow system.

The manager agent provides all functionality the work-flow manager needs, such as creation and deletion of tasks,roles and process definitions, instantiation of new processinstances, and creation of resource agents. The processagent executes a process instance. Each resource in the sys-tem has its own resource agent. Every resource in the sys-tem gets registered to one of the broker agents that allocateresources to the process. The storage agent manages the per-

sistent data that is needed. The monitor agent collects all theprocess-specific data and sends them to the storage agent.The control agent continuously looks for anomalies to thecriteria specified by the human manager and reports the vi-olations of these criteria to the manager agent. The manageragent provides information to the human manager, whichcan be used as a feedback mechanism. A detailed descrip-tion of these agents can be found in the work byX (namesuppressed for blind reviewing purposes)[24, 23].

��������

����������� ����� ������

��� ���

������� ���

���� �

���� � �

��������� �� ��� �

����������� �������������������������

� ���������������������������������

��������������� ����� ���� ������� ���������

�

�� ����������������������

����������� ����������������� �������������

��������������

�� ����� �� ���� � ���� ��� ��� �������� �

Figure 3: Task execution mechanism

4. Integrating Web Services

This section describes how we have integrated web ser-vices with our workflow management system using agents.

3

��������

��� ���������

�������

�����������������

����������� ��������

����������� ��������������

����������� �������������������������

����������� ������� ������

���

!�������������� �����������������������"�� ����

#��$�����������%����������� �������������� ������������������������ ���������������������� �� ��� ��!� "����# $���� ������� �� ��� ��!���%���&#��������'����(���'���)������ ���������������������� �� ��� ��!���%���&#�� "����# $�*+

���&������������������"�� ������ ����%� �� �������� ����" �������

,'����-"�����'��� �������)�����,'����-"�����'��.��������/

,'����-"�����'��"����!(���0'��)� ���������,'����-"�����'��"�����/

11�*������������������������� ��������������� ������ ����������� �����������

'��&������� ������� ��� ����� ���������������)���������� ��������������#$2 ���/�����������'0����-��/��������������������� �� ��� ��!���%���&#������.�3��� ��/

�4'����-�������3������������$5����0����'��#-���/

Figure 4: Code generation for a Web Service Agent

4.1. Underlying mechanism

The resource agents in our WfMS are equipped to per-form the tasks specified in the transition of the CPN. Eachresource subsumes one or more roles. Each role is capableof performing certain tasks.

4.1.1. Types of resource agents.These resource agentsmay be interfaces to the human agents as well as devicessuch as scanners and printers. Previous work by X [24] de-scribes how WfMSs support resource agents that interfaceboth humans and computatinal devices. Our objective hereis to specialize the resource agent in order to obtain an agentthat can perform the task of connecting to any web service.

4.1.2. Execution of tasks.The workflow process modelsare executed by the process agents. The process agent usesthe CPN engine to validate the process model and executeit. A transition in a CPN represents the task that has to beperformed. The process agent assigns this task to a resourceagent. The resource agent will perform the task and reportthe result to the process agent. The task to be performed isembedded within the transition of CPN - known asactioncode.

Figure 3 shows an example in which the process agentassigns resource agent X to perform task A. The action codespecifies the internal logic of task A. The process agentsends a message to a specialized resource agent Y, whichis capable of connecting to a web service to perform thetask (task B) specified in the action code. The agent con-nects to the appropriate operations requested by the process

agent on a web service. The agent then sends the result tothe process agent.

4.1.3. The Web Service Agent (WSA).In our design wehave wrapped the web service as an agent. A specializedagent called Web Service Agent(WSA) is created, and itcan be used to query various operations exposed by the WebService. Thus a resource agent in the WfMS is specializedinto a Web Service Agent.

When the process agent executes a process model, ajobtokenobject is created. This job token consists of a map,that stores various attributes, which include details such asthe URI of the WSDL file, and the operation to be invokedon the web service. The workflow manager will create theseattributes in the job token.

The attributes encoded in the job token in the form ofname-value pairs are:

• Attribute 1: (URIName, URI)

• Attribute 2: (transition name, operation name)

The process agent assigns a task to a resource agent.It passes the job token to the resource agent. The re-source agent accesses the URI from the job token andreads the WSDL document and uses WSDL2java from theAxis toolkit [1] to create the necessary stubs. It also gener-ates necessary code for handling requests from other agentsto access appropriate operations exposed by the web ser-vices and also the code for sending responses to otheragents. Figure 4 shows the code that is generated dur-ing the creation of a web service agent.

4

The resource agent sends a message to the process agentabout the creation of the Web Service Agent, which is ca-pable of handling requests for operations defined in WSDL.The process agent then assigns the task of connecting andquerying the web service, by handing over the job tokento the WSA. The web service agent matches the task namefrom the map and retrieves the operation to be performed.The web service agent connects to the web service and re-trieves the result and sends it to the process agent.

In our framework, FIPA ACL [9] is used for agent com-munication. Figure 5 shows that FIPA messages are ex-changed between interacting agents. In the current systemthe Petri net model provides an abstract view of the pro-cess, and the process agent has the built-in intelligence tomap the transitions with the agents that are capable of per-forming the tasks and thereby sending messages to appro-priate agents.

4.2. Demonstration of agent-based integration ofweb service using an example

In this section we describe how a web service has beenintegrated with the multi-agent based workflow manage-ment system. The Petri net model shown in figure 6 illus-trates how agents can be used in a diamond processing in-dustry. When the Petri net model shown in figure 6 is exe-cuted by the process agent, a token representing a job is cre-ated at theStartnode. The attributes added to the token aregiven below.

• Attribute 1 : (URIName,http://www.stardiamonds.com/diamonds.wsdl)

• Attribute 2 : (connectAndQueryWebServive, getAll-StoneDetails)

• Attribute 3 : (determinePrice, getPrice)

As described in the previous section, the process agentassigns to the resource agent the task of creating a web ser-vice agent as inscribed increateWebServiceAgenttask def-inition. The resource agent creates a web service agent ca-pable of connecting to the web service as described by theWSDL file given by the URI.

Once the process agent receives a message from the re-source agent that a web service agent has been successfullycreated, the process agent executes the next transitioncon-nectAndQueryWebService. The operation that is to be in-voked is encoded in the job token that is passed along whena transition has been fired successfully. The process agentassigns this task to the web service agent by sending themessage to the web service agent with the details about theoperation that is to be invoked. The web service agent in-vokes the webservice, obtains the result, and sends backthe result to the process agent as a message. The results arestored in the job token.

Figure 5: Interactions of a process agent with a web serviceagent

The result consists of an array comprising of details ofthe diamonds. For each diamond in the array, a job to-ken is created. A diamond job token would contain detailssuch asclarity, color, cut, carat weight, lusture, nextPro-cess, nextArtisan, hasProcessingFinished, price and name-value pairs of the web serivce operations that are to be in-voked. The name represents the transition that is executedand the value represents the operation that is called on theweb service. These job tokens are available for the assorter3

agent who decides if the diamond has been processed. Theprocess agent directs the assorter agent to decide whethereach of the diamonds requires further processing. If a dia-mond requires further processing, the assorter agent deter-mines which process the diamond should undergo and thenallocates the appropriate artisan agent to perform that task.If the assorter agent decides that the diamond has been pro-cessed completely, it updates the details of the diamond to-ken that can be sent to the evaluator. This is done be settinga value for the boolean attributehasProcessingFinishedforthat particular token to indicate whether the diamond hasbeen processed.

The web service agent, which acts as a evaluator deter-mines the price of the token depending upon the 4 c’s of di-amond quality, namelycolor, clarity, cut, carat weight,andassigns a price for that diamond.

3 The job description of an assorter is defined athttp://www.occupationalinfo.org/77/770281010.html

5

Figure 6: A snapshot of the diamond process model during execution

Each artisan agent is capable of performing one or moretasks. These tasks arelasterCut, windowing, acidBoil, man-ualCut and polishing. Each unprocessed diamond is as-signed to one of these tasks by the assorter agent. Depend-ing upon the attribute of the job token, these diamonds willbe available to a particular artisan agent. The artisan agentperforms a particular task on the diamond. After the com-pletion of a task, the artisan agent requests the process agentto add a name-value pair to the attribute list of the job to-ken to indicate the completion of the task. For example, af-ter the completion of a task named laserCut, an attributebinding such as (laserCut, true) is added to the job token.

After a stone has been processed into a diamond that canbe sold, it is evaluated and the diamond is made available

at theendplace for further operations such asdispatchTo-HeadOffice. If the processing of the diamond is not com-plete, the stone details can be obtained from the diamondprocessing web service. The diamond goes through an iter-ation of several processes before it is ready for the market.After every task is executed, the storage agent persistentlystores all the details of a diamond. Figure 6 shows the poolof resource agents and the process model that is executed.The dotted arrows start from an agent and end in a transi-tion of the CPN. This indicates that the agent is able to per-form the task indicated by the transition. Figure 7 shows thesequence diagram for the above mentioned example.

6

���

���������� �����������

���������������������

���������������

����������������������������� �

���������������

�����������������������������

�����������

����������� ��������!�����������"�����#

������������$���������

����������������������������%���������

��������������������������������������

�����������

��������������������$��������������

�����������

������&������������'����������������

������������

������������������������$������������

�������������

Figure 7: Sequence diagram of agent interactions in diamond processing scenario

4.3. Advantages of wrapping a web service as anagent

We believe that modelling a web service as an agent of-fers the following advantages:

The web service agent speaks FIPA ACL [9]. One of theadvantages of modelling the web service as an agent is theability of the agents in the workflow system to communi-cate using FIPA ACL [3], messages. This provides a uni-form agent-based infrastructural support to the workflowsystem. Other flexibilities of the web service agent includethe storage of the history of successes/failures of web ser-vices (which can be used for performance analysis), match-making to find web services available on the Internet that of-fer services specified in WSDL and negotiation with othersimilar web service agents to perform an operation. Theweb service agent can be used in the determination of dy-namic binding and choosing of protocols. The web serviceagent is also used to execute the CPN model that modelscomposition of web services since the agent can bind to anyweb service dynamically. This is achieved by the virtue ofthe fact that the input to the web service agent is the WSDL

description and the required stubs for connecting to the webservice are generated during run-time.Similar to the other agents in the Workflow managementsystem (JBees), the web service agents can be embeddedwith intelligent decision-making capability, such as choos-ing the most appropriate operation in a web service or con-necting to another web service which offers the same opera-tion, such as contacting a different weather monitoring ser-vice to find the temperature of a tourist place of interest. Theweb service agent can maintain a record of the reputation ofWeb services and choose the appropriate one dynamically.The web service agents would be able collect and analyzeinformation such as comparing prices of different productsacross different manufacturers. The agents can also be usedfor monitoring and controlling, such as constant monitoringfor a particular stock increase or decrease or monitoring thelevel of some reservoir or monitoring temperatures in boil-ers or reactors. These web service agents can also be spe-cialized into experts, in connection to web services, that be-long to particular domains of interest.

7

5. Conclusion and future work

We have described our flexible, agent based architecturefor workflow management systems. The agent based archi-tecture facilitates the easy integration of Web Services withthe workflow system. We have demonstrated using an exam-ple how a web service can be used in a diamond processingworkflow with limited effort. The Web service agent will beable to connect to any Web service dynamically.

In the future we intend to integrate workflow ontologiesand domain-specific ontologies to our system and harnessthe power of the Semantic Web when using the Web Ser-vices. We are currently extending our architecture to acco-modate a process model that executes composite web ser-vices. We are also planning to extend our work to form asociety or institution of web service agents that can workcollaboratively to achieve a common goal.

6. Acknowledgements

The authors thank Mariusz Nowostawski for his helpwith the Opal platform.

References

[1] Apache Axis Toolkit . http://ws.apache.org/axis/.[2] Business Process Execution Language for Web Services

(BPEL4WS). http://www.ebpml.org/bpel4ws.htm.[3] Foundation for Intelligent Physical Agents .

http://www.fipa.org.[4] Paul Buhler and Jose M. Vidal. Enacting BPEL4WS speci-

fied workflows with multiagent systems. InProceedings ofthe Workshop on Web Services and Agent-Based Engineer-ing, 2004.

[5] Paul Buhler and Jose M. Vidal. Integrating agent servicesinto BPEL4WS defined workflows. InProceedings of theFourth International Workshop on Web-Oriented SoftwareTechnologies, 2004.

[6] Q. Chen, M. Hsu, U. Dayal, and M.L. Griss. Multi-agent co-operation, dynamic workflow and XML for e-commerce au-tomation . Infourth international conference on Autonomousagents, Barcelona, Spain, 2000.

[7] Martin Fleurke. JBees, an adaptive workflow managementsystem - an approach based on petri nets and agents. Mas-ter’s thesis, Department of Computer Science, University ofTwente, P.O. Box 217, 7500 AE Enschede, The Netherlands,2004.

[8] Martin Fleurke, Lars Ehrler, and Maryam Purvis. JBees - anadaptive and distributed framework for workflow systems.In Workshop on Collaboration Agents: Autonomous Agentsfor Collaborative Environments (COLA), Halifax, Canada,pages 69–76, 2003.

[9] Foundation for Intelligent Physical Agents.Fipa communicative act library - specification.http://www.fipa.org/specs/fipa00037/, 2002.

[10] N.R. Jennings, P. Faratin, T.J. Norman, P. O’Brien, andB. Odgers. Autonomous Agents for Business Process Man-agement . Int. Journal of Applied Artificial Intelligence,14(2):145–189, 2000.

[11] K. Jensen. Coloured Petri Nets - Basic Concepts, Analy-sis Methods and Practical Use, Volume 1: Basic Concepts. EATCS Monographs on Theoretical Computer Science.Springer-Verlag, 1992.

[12] G. Joeris. Decentralized and Flexible Workflow EnactmentBased on Task Coordination Agents . In2nd Int’l. Bi-Conference Workshop on Agent-Oriented Information Sys-tems (AOIS 2000 @ CAiSE*00), Stockholm, Sweden, pages41–62. iCue Publishing, Berlin, Germany, 2000.

[13] S. Meilin, Y. Guangxin, X. Yong, and W Shang-guang. Workflow Management Systems: ASurvey. In Proceedings of IEEE Interna-tional Conference on Communication Technology,cscw.cs.tsinghua.edu.cn/cscwpapers/ygxin/WfMSSurvey.pdf,1998.

[14] Tadao Murata. Petri nets: Properties, analysis and applica-tions. Proceedings of the IEEE, 77(4):541–580, April 1989.

[15] M.E. Nissen. Supply Chain Process and Agent Design forE-Commerce . In33rd Hawaii International Conference onSystem Sciences, 2000.

[16] Mariusz Nowostawski. JFern - Java-based Petri Net frame-work . http://sourceforge.net/projects/jfern/, 2003.

[17] Martin K. Purvis, Stephen Cranefield, MariuszNowostawski, and Dan Carter. Opal: A Multi-LevelInfrastructure for Agent-Oriented Software Develop-ment. The information science discussion paper seriesno 2002/01, Department of Information Science, Univer-sity of Otago, Dunedin, New Zealand, 2002.

[18] J.W. Shepherdson, S.G. Thompson, and B. Odgers.Cross Organisational Workflow Coordinated by SoftwareAgents. InCEUR Workshop Proceedings No 17. Cross-Organisational Workflow Management and Coordination,San Francisco, USA, 1998.

[19] H. Stormer. AWA - A flexible Agent-Workflow System . InWorkshop on Agent-Based Approaches to B2B at the FifthInternational Conference on Autonomous Agents (AGENTS2001), Montral, Canada, 2001.

[20] W.M.P van der Aalst and K. van Hee.Workflow Manage-ment: Models, Methods, and Systems. MIT Press, 2002.

[21] Jose M. Vidal, Paul Buhler, and Christian Stahl. Multiagentsystems with workflows.IEEE Internet Computing, 8(1):76–82, January/February 2004.

[22] M. Wang and H. Wang. Intelligent Agent Supported Flexi-ble Workflow Monitoring System . InAdvanced InformationSystems Engineering: 14th International Conference, CAiSE2002, Toronto, Canada, 2002.

[23] X and Y. A collaborative multi-agent based workflow sys-tem. InKnowledge-Based Intelligent Information and Engi-neering Systems (KES), pages 1187–1193. Springer, 2004.

[24] X, Y, and Z. Monitoring and controlling of a workflow man-agement system. InIn Proc. Australasian Workshop on DataMining and Web Intelligence (DMWI2004), pages 127–132,2004.

8