Work ow Management Systems (WFMS) are used to organize work processes between di erent people within an organization or between organizations. In this paper we will describe an agent-based WFMS, built with Petri nets, to utilize the formal soundness of Petri nets and the exibility of multi-agent systems to enhance the usefulness of a WFMS. The focus of this paper lies in the way activities are handled in the WFMS. We will rst discuss the way this works in the system as of now. Then we will go on and describe a way to use Activity Agents to add a further exibility to the activity handling of the system. These Activity Agents will be responsible for providing the functionality, including materials and user interface associated with an activity.
The technological foundation for this contribution are the Mulan and Capa
agent architectures. Mulan stands for Multi-agent nets, which is also the main
idea behind it. It was described in [
Capa (Concurrent Agent Platform Architecture) is an extension of
Mulan, which was introduced in [
Within the WFMS work ows are modelled using a variation of the work ow
nets described in [
In its current version the system supports basic WFMS functionality. It provides the means to administrate the system, add and edit work ow de nitions and instantiate and execute work ow instances.
The functionality of the WFMS is provided by a number of di erent agent types. The system's core is made up of a trio of agents, which provide the internal function of the WFMS. These agents are the Work ow Engine agent (WFEngine agent), the Work ow Enactment Service agent (WFES agent) and the Workitem Dispatcher agent (WiDi agent). The WFEngine agent is responsible for ring the internal transitions of the tasks and for initiating the work ow instances. The WiDi agent distributes work items and activities to the users, if they are eligible for them. The WFES agent is located between the other two agents. It manages di erent work ow instances on the work ow engine. These three agents interact with each other to organize the functionality to provide work items and activities to the user. For each user a user agent exists, which manages the interactions between the WFMS and the user's GUI. Its main responsibility lies in invoking interactions upon actions of the user within the GUI and in initiating display updates within the GUI. The other agent types o er the functionality to manage and authenticate logged in users as well as access to the database.
Currently the WFMS supports two kinds of tasks. Simple tasks can only be accepted and then be marked as completed or canceled. They represent actions, which have to be completed outside of the functionality the WFMS o ers. The other kind of tasks is form tasks. When a form task is assigned to a user, a form window is opened, in which the user enters the necessary information. Forms can consist of an arbitrary number of labels, text boxes, check boxes and radio buttons. When the form task is completed the data entered into a form is read into the system and can be used in later form tasks.
The subject of this contribution concerns the the way activities are handled within the system. Because of this it is important to give a description of the way activities are assigned in the current version.
While work ow instances are active within the system, eligible users can request the work items, which are currently activated in the work ow nets. When a user wishes to request a work item he initiates the associated interaction. If this interaction is successful the WFEngine agent res the internal request transition of the task and creates the activity.
When any changes in a work ow net occur a decision component (DC) net, a special part of the WFEngine agent, is automatically informed. This listener DC net contains a cycle, which is responsible for handling reported changes in the set of activities and is always repeated when a new change occurs. The cycle checks which activities have changed and need to be updated. The cycle ends with the initiation of the UpdateActivityList interaction. The UpdateActivityList updates the internal lists of the WFEngine agent, the WFES agent and the WiDi agent.
After the UpdateActivityList interaction has been completed, the O erActivityList interaction is started, in which the WiDi agent informs all user agents connected to him about the previously updated status of their activities. These updated activities are then displayed for the user and can be executed. 4
In this paper we propose a new way of handling activities in the WFMS by using a special kind of Tool Agents, called Activity Agents. We will rst describe the notion of Tool Agents and how they can be used to build exible tool-based applications. Then we will describe the special incarnation of Activity Agents and the way they will be integrated into the WFMS architecture. 4.1
Tool Agents are a way to use multi-agent systems to build tools for supporting
individual users work as well as collaborative e orts. This follows the notions of
the tools and materials approach [
Overview The main idea about the tool agent concept is that each user controls
a user agent (UA), which can be enhanced by di erent tool agents (TA) as shown
in [
Material agents (MA) are used to represent and encapsulate the materials or work objects that are currently worked on, like an insurance claim or a text le. Materials are manipulated by tools and can be created, deleted and moved between workplaces. Tools and materials populate the workspace of the user.
An agent called the Tool Factory is used to manage the di erent types of tool agents known to the system. It is called by the user agent to create a ne instance of a tool agent to use. Figure 1 shows how these agents work together. The de nition of a work ow can contain any number of di erent types of tasks for a user to perform. In the current systems, all these tasks have to be de ned in advance and the user needs to know how to handle them. It seems clear that in this way the user can be a real bottleneck in the deployment of new work ows, if these contain new types of tasks.
Tool Agents already provide a way to enhance the functionality of a User Agent. Therefore, an adaptation of Tool Agents for WFMS will provide a way to handle this problem, this adaptation is called an Activity Agent.
Like any Tool Agent it can be used to manipulate materials, but in this case the material and the context for its manipulation is provided by the work ow. An Activity Agent is not requested by the User to perform some task but it is rather assigned to it by the work ow engine to handle an activity. Once it is connected to the User however, it functions like another Tool Agent. It only needs a way to determine that the work on the activity is done, so that it can return the material and feedback on activity completion back to the work ow engine, for example a \ nish" or \abort \ button in the GUI. 4.3
Activity Agents represent activities within the running WFMS. When a user successfully request a work item available to him, the system will automatically start a new Activity Agent. This Activity Agent will be responsible for this activity alone, and will only be active while the activity is being executed by the user. During the execution of the activity the user will exchange information with the Activity Agent, in order to work on the activity. When the activity has been nished, the Activity Agent will transmit the relevant data back to the work ow engine and terminate. 5
In this section we will describe our proposed way to implement the Activity Agent. The Activity Agent will be started after the listener DC net of the WFEngine has detected that a new activity has been created. Before the UpdateActivityList interaction is started the listener will check if the activity is agged as an Activity Agent activity. If the activity is to be executed by an Activity Agent, a new DC net is entered. The purpose of this new DC will be to start the new Activity Agent and add the agent's information to the activity, so that the executor's user agent knows how to interact with the Activity Agent. After this is done, the listener DC net can continue and start the UpdateActivityList interaction. Within The UpdateActivityList and O erActivityList interactions only the internal lists have to be modi ed, in order to incorporate the added information.
While the Update- and O erActivityList will not have to be changed much, the handling of activities in general and within the user GUI require changes. Concerning the handling of activities changes have to be made, because in the proposed version the actual handling of the activity will be done by the Activity Agent. In the current version the activities are manipulated within the GUI and then passed to the user agent, who, upon completion of the activity, sends them to the WFEngine agent. In the new version the user agent will not directly communicate with the WFMS's core in this matter, but will only communicate with the Activity Agent in order to manipulate materials involved in the activity (e.g. forms). When the user has nished his work on the activity he will inform the Activity Agent, who then informs the WFMS's core.
The reason for changes to the GUI is, that in the current version tasks are simply displayed in a list (simple tasks) or a generic form window is opened (form tasks). In both cases, the interface to complete the activity is embedded into the general GUI. Since the Activity Agent is designed to be able to o er arbitrary functionality with a possibly specialized GUI, this GUI has to be o ered by the agent itself, because otherwise the main user GUI has to be changed and enhanced, whenever a new type of task is added. In order to support this, the GUI has to be changed so that selecting an activity will contact the Activity Agent who will in turn invoke his own GUI. 6
We have proposed in this paper a way of enhancing an Agent-based WFMS
with exible activity-handling procedures. Specialized agents will be used to
plug into the users' system and provide them with the functionality needed to
perform their tasks within the work ow process. The underlying Petri nets allow
rst of all an appropriate modelling of the system and its processes. In addition
the agents and their behaviour become a well de ned semantics. Following our
Paose approach (see [
Activity agents will directly be used in our next version of our distributed and no longer centralized agent-based WFMS. There it will take care in a quite generic way of activities of the work ows, the core of work ows in general.