In distributed software development projects the different parties involved can be coordinated by the use of flexible workflow management systems (WfMS). Often the process cannot be defined completely in the beginning of a project or has to be adapted later on when conditions change. In this paper the handling of workflow change in the agent-oriented Potato system for distributed development will be presented. This includes the interaction of the different agents and their protocols as well as the mechanisms for ensuring the soundness of workflows even if they are changed during their execution.
For distributed software development, the definition and enactment of processes with workflow management systems (WfMS) is an important means of structuring the interaction between the different participants. Often it can be important to modify these processes during the course of the project. This can be to reflect changes in the general conditions which require changes in the workflow. In other cases, it is not possible to completely specify the required process in the beginning of a project, so that some parts of the workflow can only be defined at a later stage. In ad-hoc workflows defined for one instantiation only, this is obviously more common than in production workflows, in both cases modifications can be necessary, though.
In these cases the workflow process definitions or even the running workflow instances need to be modified. Often it is difficult to decide whether a certain modification can be safely enacted on a workflow. Therefore instead of changing a running workflow changes are often only applied to a new instance, or special monitoring is required. Since workflows in the Potato system (Process-Oriented Tool Agents for Team Organization) are specified with Petri nets, net-based methods can be used to ensure soundness of these modifications. In section 2 the Potato system will be described with a focus on the process infrastructure used to enact workflows. Section 3 describes the methods for modification of workflows within the system. In section 2.4 the algorithms for checking the modified workflows for soundness are presented.
This paper describes the editing of workflow definitions in the context of the Potato system for distributed software development. Therefore this section outlines the main properties of this system.
Potato is an agent application built on the (Petri net based) Mulan/Capa
agent platform (see [
The structure of Potato is twofold: It has a tool-based organization that allows users of the system to equip their user agent (UA) with different kinds of tool agents (TA), in order to execute the tasks in the system they need to do. On the other hand a process infrastructure allows the execution of workflow processes in the system, connecting and integrating the different users. 2.1
The main goal of the Potato system is to facilitate the work of different people
working together to produce software. To achieve this, users can use different
tools to manipulate materials, which are over the course of a project
transformed into work results. This follows the notions of the tools and materials
approach [
The main idea about the tool agent concept is that each user controls a user
agent (UA), which can be enhanced by different tool agents (TA) (see [
Those tool agents can then plug into the user agents UI with their own UI parts, offering their functionality to the user. By choosing the specific set of tool agents, the user can tailor his workspace to his specific needs. A developer for example needs a completely different workplace then a tester or someone writing documentation.
Material agents (MA) are used to represent and encapsulate the materials or work objects that are currently worked on. Materials are manipulated by tools and can be created, deleted and moved between workplaces. Tools and materials populate the workspace of the user. 2.2
A generic agent-based process infrastructure has been created (see [
In [
As one of the most wanted properties during the execution of a workflow
no deadlocks should occur nor should tokens be “lost” in the process. Therefore
the notion of soundness has been defined. If a workflow net is started with a
token on the start place, no matter which firing sequence occurs, it will always
be possible to reach a marking in which only the end place is marked, and this
is the only reachable marking in which the end place is marked. To check this
property, the short-circuited net is constructed, by adding a transition to the
net from the end place to the start place. Iff this net is live and bounded, the
original workflow net is sound.[
There are different degrees of possible modifications, that can be handled 2.4
differently. If the definition of a workflow is changed with no currently running instances or if the currently running instances are not to be changed, it suffices to check the new workflow definition for soundness, without any concern for the old definition.
The same is the case, if already running instances are concerned, but changes only occurr within subworkflows, which are not yet started. This is often the case if sections of a process are not specified when the execution begins, and only placeholder subworkflows are inserted to be defined later on. As long as the unspecified segments are workflows of their own, simply checking for soundness of the new definition is sufficient here, too.
It gets problematic however, if workflows have to be changed that already
have running instances associated and those instances have to be converted to
the new version. Since these instances can be in various states of execution,
the standard method of checking for workflow soundness [
is considered sound, if for every possible firing sequence it is possible to reach a state, in which only the final place is marked with a token. As mentioned above, for a normal workflow this can be ensured by constructing the sort-circuited net and checking it for the live and bounded properties.
In the case of a modified workflow, the structure of the net changes during the execution, therefore some special constructions are necessary to ensure the soundness.
For every place in the original workflow net a corresponding place in the modified net has to be defined, so that the transition to the new workflow can be executed and checked for soundness. To do this a modification net can be constructed as follows.
For a workflow net its modification net consists of all places, transitions and arcs from the original net as well as the modified net (disjointly united), connected by transitions from all places in the original net to the modified net.
With this construction it is possible to convert any instance of the original net to the new definition since all tokens are then accounted for. With the construction as seen in figure 1 it should also be possible to check the absence of deathlock possibilities during the transformation by checking the modification net for soundness. We will not try to formalize or proof this here though. Example An abstract example for a Wf modification net can be seen in figure 1. The original workflow WA consists of two parallel branches, one of which consists of two tasks. In WB the other branch has got two parallel tasks. In ttrans the fact is accommodated, that no tokens must be left behind. Therefore even though one of the parallel tasks is deleted in the modified workflow, the corresponding tokens must be disposed of. Similarly, the task that is split up into two tasks in WB requires two tokens to be generated in the target workflow. t_iA T_trans i_mod
t_iB W_A
W_B t_oA
t_oB o_mod
Modifying Workflows in the Potato System In this section the mechanisms for modifying workflows are described. Since Potato is agent-oriented, the change process involves a couple of agents.
Users with the appropriate authorization can edit workflows. To do so, they use a workflow edit tool agent via their user agent. This tool agent communicates with the workflow definition database agent to get the old workflow definition as a workflow definition material agent. This is then edited and the new version uploaded back to the definition database. 3.2
To add a new workflow definition, the net editing features of Renew can be used. Additional properties of the workflow can be defined in a special tool, like roles and rules for execution, workflow specific context data, tasks etc.
A material agent is then created and sent to the workflow definition database agent, where it is checked for soundness. This can not find all problems with a workflow, as many problems can occurr in the accompanying definitions of roles, participants, tasks etc. and not in the net structure itself, but at least some of the problems can be avoided this way. 3.3
If a workflow is to be modified, it must be decided how to handle already running instances of this workflow. If old instances are to be finished according to the old definition, the modification can be handled like a new workflow. The new version can then be added just like a completely new workflow.
If running instances are to be updated to the new definition however, care must be taken to migrate the processes correctly. In section 2.4 a simple algorithm is described to ensure soundness of workflow modifications. It is mandatory however, to specify the migration from the old to the new definition. For every place in the old workflow a place in the new workflow must be specified, so that all tokens can be moved over to the new definition.
In the editing process therefore a special mapping phase has to be added, in which this can be defined. By default it is sensible to assume, that all places existing in both versions of the workflow net are mapped to themselves, but it needs to be checked by the modifying user. If the workflow editing consists of a series of soundness-preserving transformations, each of these transformations could be assigned a default pattern of transformation, which can be adjusted by the user.
Then the new workflow definition along with the migration mapping is sent over to the workflow definition database agent, where it is verified. If verification is successful, the new version is saved as the new default for this workflow type. All workflow engines currently executing instances of the old definition must then be notified of the change and the migration mappings be applied. 4
Potato integrates the ideas and concepts from [
In the long run it is planned to apply these concepts to our own software development process and environment. Therefore, the Renew-IDE will be enhanced considerably.