Multiagent Architecture for Decentralized Workflow ...

4 downloads 405 Views 411KB Size Report
Mar 9, 2005 - applications) and send it to the Site Agent for its later distribution. .... different role performers: the Instance Creator and a Task Executor.
Multiagent Architecture for Decentralized Workflow Process Execution Technical Report CSI-RI-002 Ram´ on F. Brena

C´ esar A. Mar´ın Center for Intelligent Systems Tecnol´ogico de Monterrey Monterrey, Mexico March 9th, 2005 Abstract

The decentralized and distributed nature of workflow in organizations demands for support from decentralized and distributed computational systems. However, most conventional workflow applications use centralized architectures. Agent technology has proved to be an adecuate approach for supporting distributed systems. Research done in the area has tried to improve workflow applications, but paying no attention neither to the structure of the organization nor to the decentralized business process execution. In this technical report, we propose a high-level agent-based workflow architecture which maps the distributed organizational structure and the decentralized business process execution at an agent level.

1

Contents 1 Introduction

3

2 Background 2.1 Agent-enhanced Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Agent-based Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 The JITIK System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 5 6 7

3 Proposed Solution 3.1 Tasks Distribution . . . . 3.2 Process Instance Creation 3.3 Enabling Tasks . . . . . . 3.4 Disabling Tasks . . . . . . 3.5 Cancelling Task Execution 3.6 External Task Execution . 3.7 Informing Task Status . .

. . . . . . .

8 9 10 10 11 12 12 13

4 Prototype Design 4.1 Multiagent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Agent Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Software Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 15 16

5 Related Work

17

6 Conclusions

17

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

1

Introduction

Back in time, a revolution ocurred in factories as assembly lines gave way to tightly coordinated parallel processes of manufacturing, inventory management and mass customization. In his book, “The Workflow Imperative”, Thomas Koulopoulos says that workflow will similarly revolutionize the document factory1 as it creates an environment for the streamlining and integration of information based activities at never-before-possible levels of integrity and reliability. In order to solve specific business problems, many of the specific solutions were converted into some form of software; then commercial workflow products were born [21]. But there is still a lack of consensus of what constitutes a workflow specification [20], which means that all of those products manage workflow processes as they think is the best way. As these commercial software appeared, several investigations have been done trying to give a solution of how workflow processes should be defined and how workflow technology should be built. These investigations aim two particular characteristics involved in the whole business process: Communication and distribution schema: One characteristic of Workflow Management Systems (WfMS for short) is that they make sure that within a business process “the right activity is performed at the right time, at the right place, by the right people, with the right data, using the right tools” [11]. But this is not an easy goal to achieve. Modern organizations have to deal with a massive flood of unstructured information and knowledge. And in some cases, there are also organizational and cultural problems which are reasons for many anomalies and misunderstanding between several parts of the organizations [1]. Process definition schema: Most business processes are centered around sets of documents that are routed from one person to the next. This means that WfMS must have the capability to define how documents are routed from person to person within the organization, and the type of action to be performed by each individual [11]. In addition, in complex and large-scale applications, the execution of workflow in a decentralized way is imperative because of the high workload on the a single workflow engine [14]. It has been said that a WfMS can be improved with an information system that permits to detect the relevant knowledge, to identify who or with whom communicate this knowledge, and when to trigger the communication [1]. The Just-in-Time Information and Knowledge system (JITIK for short), a project from the Distributed Knowledge Technologies and Intelligent Agents Research Grant at ITESM, is an agent-based information system that distributes the right piece of knowledge to the right person within different parts of an organization, according to an organizational structure and the personal interests of each individual. The JITIK system fulfills with the communication and distribution schema: it distributes the information as soon as it is generated. In other words, it can improve business environments, but it cannot automate them. Thus, the objective on the development of this research 1

The author uses this term as an analogy between an industrial factory and an office environment.

3

is to propose a multiagent architecture (suitable with JITIK) capable of workflow process managing in a decentralized way, and assuring that the right information and knowledge will arrive to the right person at the right time, meanwhile the organizational structure is kept. The particular problem to solve in this research is to implement workflow process managing features into the JITIK system, so that it can handle business processes in a decentralized way. In order to achieve this goal, there were several subproblems that were resolved during the whole investigation: • Identify the necessary role performers for decentralized process execution. • Identify and design the communication protocols to be performed. • Design an agent-based workflow architecture based on the current JITIK architecture. The relevant hypothesis for this investigation: It is possible to add workflow process handling capabilities into the JITIK system so that it can manage business processes in a decentralized way. And the questions to be answered along the course of this research are: Is there a way to represent workflow processes so that the agents in the JITIK system can understand them? Is it possible for the agents to reason about the business processes that its user is involved in?

2

Background

Within a business enterprise, where the transactional costs are high, it is very important to achieve operational efficiencies in order to reduce the costs. This means that the work needs to be governed by processes that define the flow of work throughout the organization [2]. Information Technology (IT) promises the reduction of transactional costs via management of business processes and information. But nowadays there are no enough techniques and methods to control business processes, which leads to the misunderstanding of organizational responsabilities, blocks in coordination and slow reaction to the changing market [23]. Workflow management technologies hold the promise of overcoming these problems. Some of the benefits of using workflow management technology include “explicit process definition, quick reaction to changing environments and easy racking of operations” [23]. But workflow management focuses on just managing the process logic. This means that in order to control a business process in a complete way, it is necessary to integrate other technologies. In [23] Yuhong Yan says that some of the benefits of applying agent technology to business process management include: Distributed architecture: Agent technology provides loose coupled distributed system architecture for integrating distributed business process management systems. Automation: Agents can start activities by previous user’s instructions or by triggering events. Interaction: Agents enable organizations to interact with each other through semantic message exchanging. 4

Resource management: Agents can make task assigments and allocate resources through negotiation among other agents. Reactivity: Agents have the ability to generate alternative execution paths according to agent reactions to environment circumstances. Interoperation: Agent interactions rely on semantic messages, which makes interoperation more feasible than API calls. Intelligent decision-making: High-level features of agents, such as learning, are very helpful in workflow management. Though they are still not very well matured techniques in these days. There are two approaches for creating workflow with agents: agent-enhanced workflow and agent-based workflow. The first one is “achieved by combining a layer of agents with a commercial workflow system. The agent layer is given responsibility for the provisioning phase of business process management, whilst the underlying workflow system handles process execution” [10]. On the other hand, in agent-based workflow “agents take full responsibility for process provisioning, execution and compensation, with each agent managing and controlling a given activity or set of activities” [10].

2.1

Agent-enhanced Workflow

Figure 1: Agent-enhanced workflow architecture as shown in [16]. This type of architecture is achieved by combining an agent layer with an existing commercial workflow system. But there are two types of architecture under this approach. In the first one (which is depicted in figure 1), the responsibility of the agent layer is the provisioning of business process management, meanwhile the already existing workflow system handles process execution [16], i.e., the agent layer controls the underlying workflow system. The second type of architecture is shown in figure 2, and as it can be seen, there is one central workflow engine (the existing commercial one) which controls all the activities, and the agents are invocated during the execution of one work item to implement a particular task [23], i.e., the existing workflow system controls the creation and elimination of agents.

5

Figure 2: Agent-enhanced workflow architecture as shown in [23]. No matter the type of architecture, some of the benefits under this approach are that 1) agents provide a human interface by assisting its user(s). Some tipical usages are sorting and replying emails, reminding events and acquiring work items. They also provide interfaces to other applications. And 2) agents can perform some activities autonomously without human interruptions [23].

2.2

Agent-based Workflow

Figure 3: Agent-based workflow architecture [23]. Agent-based workflow approach is getting more and more interest from the agent research community. In this approach, agents are fully responsible for workflow process management, i.e., agents have all means to analyze, integrate, automate and inspect workflow processes. 6

In addition, agents high-level abilities such as negotiation and learning, can add values to workflow systems [23]. The main agent-based workflow architecture is depicted in figure 3.

2.3

The JITIK System

There is an emphasis on the right distribution of information and knowledge because a workflow business process can be enriched with an information system that permits to detect the piece of knowledge to communicate, who or with whom communicate it, as well as when to trigger the communication. The JITIK system delivers the right information to the right people at the right time by first characterizing persons through the use of several conceptual hierarchies [1]. The JITIK system is under continuos improvement. The architecture consists of several inter-connected sites where each of them is based on five types of agents: Site Agent, Monitor Agent, Bridge Agent, and Personal Agent [9]:

Figure 4: Current JITIK architecture [9]. Site Agent: This agent, also known as cluster agent [1], works like a network router; it receives messages from any agent and distributes the information to the proper users under its site or domain. The distribution is made by first finding the corresponding users located in conceptual hierarchies. These hierarchies may represent organizational departments, interest areas, work groups, etc. Each Site Agent keeps in touch with others Site Agents so that they all together make a network of agents for information distribution. Monitor Agent: As its name says, it monitors information sources expecting for some event occurs and it also looks for certain kind of information from different source. So 7

when the agent finds or detects what it was looking for, it activates particular alarms telling the user that something requires immediate attention. Bridge Agent: The Bridge Agent receives information from external applications (legacy applications) and send it to the Site Agent for its later distribution. It allows the interaction between legacy applications and JITIK. Personal Agent: Each user may have one personal agent that filters the information addressed to the user and shows it through a web brower, sends him/her an e-mail or a message by a SMS service. It represents a worker/user within the system. There are other type of agents in JITIK (such as agents for mining the Web or databases), but they are still under research. The main JITIK architecture is depicted in fig. 4.

3

Proposed Solution

It is well known that within an organization workers (should) know2 what to do and how and when to perform their assigned tasks. In other words, the business process execution is performed in a distributed and decentralized way, i.e., with no central entity orchestrating the whole business execution since everyone works as a task executor of their own activities. Thus, our proposal it to break down the workflow execution and the process flow control into small execution units handled by intelligent agents, so that the agents reflex the organizational structure and the way the processes are controled and executed. Using the JITIK architecture depicted in fig. 4, which eases the information and knowledge flow within large organizations [1], a workflow process can be managed in a decentralized way meanwhile the organizational structure is kept. Since the decentralization of a business process execution is not easy to perform, some requirements must be first accomplished by the agents and a sophisticated coordination mechanism is necessary. Those requirements are the following: • The resulting architecture must reflect the business execution decentralization by agents that represent the workers’ part in the process flow control. • In a workflow process, the process flow obeys to certain rules, e.g., a task cannot be initiated until other three tasks finish first. This rules are the join and split operations (AND, OR, XOR). • Tasks enable, disable and cancel other tasks during a process execution. An enabled task is a ready-for-execution task. A task in execution cannot be disabled. And a task cancellation implies a task execution interruption and the disabling of enabled tasks. • There must be a mechanism to distribute the assigned tasks to the corresponding workers’ representers (i.e. agents). Thus, a workflow process must be able to be separated into its subparts, i.e., into atomic tasks. 2

We are not arguing how an organization must operate. We are just assuming an almost ideal situation were every worker knows his/her assigned activities in advance.

8

• Once every agent knows what to do when a job arrives, a mechanism to create and start a process instance is mandatory. This requires a unique identifier to be generated and handled by every agent participating in a workflow process. • Information from different external sources must be taken into account for taking decisions about a process flow direction. • And finally, it should be possible to monitor the running processes at every moment. The requirements mentioned above can be accomplished by four roles performers defined as: Instance Creator, it holds process descriptions (in a language that it understands) and creates process instances on demand. It is assumed that it holds the process descriptions since the beginning; Task Executor it performs only the tasks this executor is assigned to. This means that several Task Executors would be running in the system; Dispatcher, it searches for the apropiate Task Executors to deliver the messages addressed to them. The performer of this role is the only one that knows where to find all the Task Executors since they are mapped to a hierarchical structure of the organization; and Register, it keeps track of all the running processes at every moment. In the following subsections, the role performers are used to explain how a decentralized workflow process execution can be made.

3.1

Tasks Distribution

Figure 5: Task distribution.

9

When the system starts up and all the role performers are up and running, the Instance Creator segments the process descriptions into atomic task descriptions. Each atomic task description explains how to execute the task, i.e., it contains the identifier of the process this task belongs to, the description of the information to be generated, the Task Executor Description, which describes a Task Executor in terms of a place within the organization (e.g., the “head of the accounting department”) and whether it is able to request an instance of the process this task belong to or not, a list of tasks to be disabled before this task starts execution, a list (which could be empty) of tasks to be cancelled during this task execution, a list of tasks to be enabled right after this task finishes execution, and the split and join operations (AND, OR, XOR) to apply to the lists mentioned before. After process segmentation, the Instance Creator sends messages containing task descriptions and a Task Executor Description to the Dispatcher. The Dispatcher searches for the proper Task Executor according to the hierarchical structure of the organization. And finally, it distributes each message to the corresponding Task Executor. This way, Task Executors know in advance the processes in which they participate and what to do during that process execution. The task distribution mechanism is depicted in Fig. 5.

3.2

Process Instance Creation

Figure 6: Process instance creation. When a Task Executor is going to start a process execution, it asks to the Instance Creator for a process instance. This is made by sending a message, containing the process identifier, directly to the Instance Creator. A process instance is created when a token for a unique process instance is generated. A token (as in Petri Nets [17]) is an marker of a process execution. In our context, a token is represented by a message which contains a unique process identifier, a unique instance identifier, and a list of tasks being enabled, disabled or cancelled at a particular time. The process instance creation mechanism is depicted in Fig. 6.

3.3

Enabling Tasks

When a task is being enabled, a token, containing a list of the enabled tasks, is sent to the corresponding Task Executors through the Dispatcher. That token can be sent by two different role performers: the Instance Creator and a Task Executor. When the former enables one or more tasks is because a process instance has just been created by it and the 10

Figure 7: Task enabling by the Instance Creator. first tasks in such process are being enabled. This is the only case in which the Instance Creator is involved in the process flow control. When a Task Executor enables one or more tasks is because it just finished the execution of one of its tasks. This is how the decentralization of workflow process execution is made, by allowing several independent entities to eventually execute a segment of a process without a central orchestration. The enabling tasks mechanism is depicted in Fig. 7 and 8.

Figure 8: Task enabling by a Task Executor.

3.4

Disabling Tasks

Figure 9: Task disabling. A task disables other ones only when all of them are competing for the same token, i.e., when a Task Executor starts the execution of a competing task and consumes the token 11

in dispute by disabling the other competing tasks. A task is disabled by sending a token, containing a list of the tasks being disabled, to the corresponding Task Executors through the Dispatcher. Disabling tasks in this way, permits the decentralization of workflow process execution by allowing several independent entities to disable a portion of a process without a central orchestration. The disabling tasks mechanism is depicted inFig. 9.

3.5

Cancelling Task Execution

Figure 10: Cancelling Task Execution. Some tasks may involve an execution interruption of other tasks. When this is required, a token, containing a list of the tasks being cancelled, is sent by a Task Executor (through the Dispatcher) to other Task Executors whose tasks are being cancelled. In other words, all tokens are consumed no matter whether some tasks were in execution or just were enabled. Additionaly, a message is sent to the Register notifing about the cancelled tasks. Cancelling tasks in this way, permits the decentralization of workflow process execution by allowing several independent entities to cancel a process, the whole or just a portion of it, without a central orchestration. The cancelling task execution mechanism is depicted in Fig. 10.

3.6

External Task Execution

Figure 11: External Task Execution. The execution of external tasks refers to information acquisition from out-the-system sources, e.g., a database, a web page, legacy applications, etc. When an external task is 12

required for execution the Task Executor searches for particular information, from different sources, and incorporate it into a workflow process. This information can be useful for deciding the direction of the process flow, i.e., selecting to which route send a token. This mechanism is shown in Fig. 11.

3.7

Informing Task Status

Figure 12: Informing Task Status. In order to monitor a process execution, it is necessary to know what is happening all the time. Since the process execution is decentralized, it would be difficult and expensive to ask all role performers what are they doing and then build a report about the monitoring with all the answers. Instead of that, every Task Executor sends a message to the Register to inform about the status of its tasks, just when a task status changes. The three cases for informing task status are when a task execution is about to begin, when the execution just finished and when tasks are cancelled. Notice that informing the task status does not involve a flow control of a process. It is only for monitoring purposes. The informing task status mechanism is depicted in Fig. 12.

4

Prototype Design

Now that we have explained how decentralized workflow process execution can me made in general terms, let us explain how it can be integrated to the JITIK system.

4.1

Multiagent Architecture

In last section we explained how the decentralized workflow process execution can me made using different roles performers. Now let us map those roles into agents and thus construct a multiagent architecture, according to the current JITIK architecture, for decentralized workflow process execution. The roles which can be mapped directly to agents are the Dispatcher and the Task Executor. The former is mapped to the Site Agent and the later is mapped to a Personal Agent, i.e., the worker representer since, as occurs in organizations, they are the actual task performers. However, not every task is necessary to be performed by a Personal Agent. There are tasks that do not process information, i.e., they just require to verify current process conditions and decide to which direction conduct the process flow. These tasks may be executed by a special entity dedicated to tasks of this kind because they represent process segments that can be fully automated. This special entity is a Control Agent. Another difference between the Control Agent and the Personal Agent is that the 13

Figure 13: JITIK agent-based workflow architecture. later is the only kind of agent that can request for a new process instance. Since the execution of external task is a too specialized activity, it can be assigned to a specialized agent, i.e., a Monitor Agent which already exists in the current JITIK architecture. And finally, the activities performed by the Instance Creator and the Register roles are simple enough to be performed by separate agents. Therefore, these roles can be merged to form a Registry Agent. In Fig. 13 the new JITIK multiagent architecture is shown. The agents circled in thicker lines are the new agents and thicker arrows indicate the additional communication flows.

Figure 14: Multi-site JITIK architecture. For keeping the organizational structure several inter-connected (not necessarily fully 14

conected) JITIK sites are required. Each of them representing a fragment of the whole distributed organization, e.g., in a university context, each site may represent an entire campus, a faculty, a department or a laboratory. Each site holds an organizational hierarchy of its domain represented in a similar way as in [13], i.e., each organizational unit (e.g., a department) belongs to another organizational unit; each organizational position (e.g., professor or research assistant) depends on another organizational position; each organizational position is part of an organizational unit; finally, each worker is assigned to an organizational position within an organizational unit. The granularity of the distributed sites depends on the representation requiered by the organization itself. Keeping the structure of an organization actually requires no more effort since JITIK already has such capability [1]. The multisite architecture is depicted in Fig. 14.

4.2

Agent Communication

As mentioned a long section 3, several messages are sent for task enabling, disabling and cancelling, instance creation, informing task status and task distribution. Here, we define these messages as JITIK Tokens (JTokens for short) for decentralized workflow execution. A JToken is an ACL message which contains the tuple Γ = {ω, ρ, τ } where ω is a worker description defined in terms of the organization (i.e., position and department); ρ is a unique process ID; and τ is a task ID. The JToken is a generic token. There are specialized tokens for different purposes which are the ones used by the agents. Description JToken: It is used for task distribution by the Registry Agent in order to let all agents to know their assigned tasks. The Description JToken is defined as a tuple ∆ = {Γ, ν, δ, ι, σ, φ, rem} where Γ represents the elements of the generic JToken; ν is the full name of the task; δ is the job that actually must be done; ι is the join operation to perform before task execution, i.e., one of AND, OR, XOR [20]; σ is the split operation to perform over the elements of φ right after task execution, i.e., one of AND, OR, XOR [20]; φ and rem are lists of task identifiers which each of them has a worker description (ω) asociated to them. φ represents the tasks to where the process flow might continue. And finally, rem represents the tasks to be cancelled right after task execution. Instance JToken: It is used when a Personal Agent wants to create a process instance and sends this token to the Registry Agent. The Instance JToken is defined as a tuple Υ = {Γ, η} where Γ represents the elements of the generic JToken; η is the instance quantity of a process (ρ) to be generated. Control JToken: This is the token through which the workflow decentralization is made. When agents are involved in a running process, they sent to each other tokens of this type in order to inform the operations to be made over a list of task. This token is defined as a tuple Θ = {Γ, ψ, λ, o} where Γ represents the elements of the generic JToken; ψ is a unique process instance ID; λ is a list of task identifiers which each one of them contains a worker description (ω); and finally, o represents the operation to perform to the elements of λ, i.e., one of ENABLE, DISABLE or CANCEL. 15

Status JToken: This token was designed for process monitoring purposes. It is used when a Personal Agent or a Control Agent informs about a task status and is defined as follows: A Status JToken is a tuple Σ = {Γ, ψ, } where Γ represents the elements of the generic JToken; ψ is a unique process instance ID; and  is a task status, i.e., one of IN-EXECUTION, FINISHED or CANCELLED. Monitor JToken: When a Control Agent requires certain information from external sources in order to incorporate it into a workflow process, the Control Agent sends this token to the Monitor Agent requesting an information retrival. The Monitor JToken is defined as tuple Π = {Γ, ψ, µ} where Γ represents the elements of the generic JToken; ψ is a unique process instance ID; and µ is the information source to retrieve external data from. Event JToken: After an information retrival, the Monitor Agent sends back to the Control Agent the monitoring results in a Event JToken which is defined as a tuple Ξ = {Γ, ψ, µ, π} where Γ represents the elements of the generic JToken; ψ is a unique process instance ID; µ is the information source to retrieve external data from; and π is the actual value obtained from µ.

4.3

Software Layers

Figure 15: Software layers. The architecture design for decentralized workflow execution is divided into several layers which the most important is the Agent layer. The rest of the layers provide services to the Agent layer. The layers are shown in Fig. 15 and are the following: DAO: Data Access Objects. This layer provides an interface to a repository like a database, which is the one that allows percistency of the information handled by the JITIK 16

system. And it allows independency from the repository location and a database manager (e.g. MySQL [15]). ACL: Agent Communication Language. Since agents do not invoke methods among them like simple objects, they requiere a communication channel [22] provided by an agent platform (e.g. JADE [7]). Agents communicate through this channel by putting a message into the channel and hoping the recipient (another agent) receives the message. JTokens are sent through this communication channel. WPDL: Workflow Process Definition Language. It provides an interface to a process description, generally represented in XML, which describes a whole workflow process. This layer validates a process description and incorporate it into the system by allowing agents to create workflow process objects (e.g. an atomic task object, an external task object). Agents: This is the main layer, where all the agents run independently over an agent platform (e.g. JADE [7]). Monitor Interface: This layer only provides a simple graphical interface for monitoring purposes. In a real application this interface may not be required, but a more sophisticated interface (through web perhaps).

5

Related Work

Some workflow agent-based architectures are focused on specific agent aspects like mobility among different platform, cooperation, and negotiation [8, 18, 5, 6]. Other architectures have been proposed for just task execution [3, 19, 12]. In general, all these architectures allow every user to perform his/her asignedtask while being supported by a personal agent. Hoever, the process flow control is made in a centralized way by using a single workflow agent to execute the whole busines processes in the system. An approach for decentralized process execution, porposed by Pinto Ferreira et. al. [4] is to break down business processes into small atomic business activities and assigning them to small execution inter-connected units. Nevertheless, they neither say how to keep the organizational structure at the level of the small execution units nor how to decentralize business process flow control.

6

Conclusions

Organizations are distributed by nature and the business process execution is decentralized. Because of these, it is necessary to build distributed and decentralized systems that adapt to the way organizations work and not allowing organizations adapt to the supporting systems. The workflow JITIK architecture maps the structure of the organization and decentralizes the process flow control, i.e., it adapts to the way an organization works.

17

References [1] Ram´on Brena, Jos´e Luis Aguirre, and Ana C. Trevi˜ no. Just-in-time information and knowledge: Agent technology for KM bussines process. In Proceedings of the 2001 IEEE Systems, Man, and Cybernetics Conference, Tucson, USA, October 2001. [2] Paul A. Buhler and Jos´e M. Vidal. Towards adaptive workflow enactment using multiagent systems. Information Technology and Management Journal, 2003. [3] Jin W. Chang and Colin T. Scott. Agent-based workflow: TRP support environment. In Fifth International World Wide Web Conference, Paris, France, May 1996. [4] J.J. Pinto Ferreira, Hugo Ferreira, and C´esar Toscano. Distributed workflow management enactment engine. In International Conference on Industrial Engineering and Production Management, Porto, Portugal, 2003. [5] Hongmei Gou, Biqing Huang, Wenhuang Liu, Shouju Ren, and Yu Li. An agent-based approach for workflow management. In IEEE International Conference on Systems, Man, and Cybernetics, pages 292–297, Nashville, USA, October 2000. [6] Jarle G. Hulaas, Henrik Stormer, and Martin Schonhoff. ANAISoft: An agent-based architecture for distributed market-based workflow management. In Software Agents and Workflows for Systems Interoperability workshop of the Sixth International Conference on CSCW in Design, London, Canada, July 2001. [7] TILAB: Jade - java http://jade.tilab.com/.

agent

development

framework.

Web

site,

2004.

[8] N.R. Jennings, P. Faratin, M.J. Johnson, P.O. Brien, and M.E. Wiegand. Using intelligent agents to manage business processes. In First International Conference on The Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM96), pages 345–360, London, UK, April 1996. [9] Just-in-time information and http://lizt.mty.itesm.mx/jitik/.

knowledge.

Web

site,

2004.

[10] Michal Laclav´ık, Zolt´an Balogh, and Ladislav Hluch´ y. Workflow process creation by pellucid agents. In The Sixth International Conference on Information Systems Implementation and Modelling, Ostrava, Czech Republic, April 2003. [11] Frank Leymann and Dieter Roller. Production Workflow. Concepts and Techniques. Prentice Hall, New Jersey, USA, 2000. [12] Xia Manmin and Li Huaicheng. Cooperative software agents for workflow management system. In Fifth Asia-Pacific Conference on Communications and Fourth Optoelectronics and Communications Conference (APCC/OECC’99), pages 1063–1067, Beijin, China, October 1999.

18

[13] Michael Zur Muehlen. Organizational management in workflow applications —issues and perspectives. Information Technology and Management Journal, 5(3):271–291, 2004. [14] Peter Muth, Dirk Wodtke, Jeanine Weisenfels, Angelika Kotz Dittrich, and Gerhard Weikum. From centralized workflow specification to distributed workflow execution. Journal of Intelligent Information Systems, 10(2):159–184, 1998. [15] MySQL: The World’s Most Popular Open Source Database. http://www.mysql.com/.

Web site, 2005.

[16] B.R. Odgers, J.W. Shepherdson, and S.G Thompson. Distributed workflow coordination by proactive software agents. In Intelligent Workflow and Process Management. The New Frontier for AI in Business IJCAI-99 Workshop, Stockholm, Sweden, August 1999. [17] James L. Peterson. Petri nets. ACM Computing Surveys, 9(3), September 1977. [18] Henrik Stormer. Task scheduling in agent-based workflow. In International ICSC Symposium on Multi-Agents and Mobile Agents in Virtual Organizations and E-Commerce (MAMA’2000), Wollongong, Australia, December 2000. [19] Henrik Stormer. A flexible agent-based workflow system. In The 5th International Conference on Autonomous Agents, Montreal, Canada, May 2001. [20] W.M.P. van der Aalst, A.H.M ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow patters. Technical Report FIT-TR-2002-02, Queensland University of Technology, Brisbane, Australia, March 2002. http://www.workflowpatterns.com/. [21] Thomas E. White and Layna fisher, editors. The Workflow Paradigm. Future Strategies Inc., Alameda, USA, 1994. [22] Michael Wooldridge. An Introduction to MultiAgent Systems. John Wiley and sons, LTD, Baffins Lane, England, 2001. [23] Yuhong Yan, Zakaria Maamar, and Weiming Shen. Integration of workflow and agent technology for business process management. In The Sixth International Conference on CSCW in Design, London, Canada, July 2001.

19