=Paper=
{{Paper
|id=None
|storemode=property
|title=Agentworkflows for Flexible Workflow Execution
|pdfUrl=https://ceur-ws.org/Vol-851/paper14.pdf
|volume=Vol-851
|dblpUrl=https://dblp.org/rec/conf/apn/Wagner12
}}
==Agentworkflows for Flexible Workflow Execution==
https://ceur-ws.org/Vol-851/paper14.pdf
Agentworkflows for Flexible Workflow Execution
Thomas Wagner
University of Hamburg, Faculty of Mathematics, Informatics and Natural Sciences,
Department of Informatics, Theoretical Foundations of Computer Science Group
http://www.informatik.uni-hamburg.de/TGI/
Abstract. Dynamic aspects of workflow execution require flexible solu-
tions. Especially in an interorganisational context many variable factors
can only be determined during the actual execution of a workflow. These
factors may require contextual, local changes within a process in order
to adequately support and represent the real-world scenario. This paper
describes the agentworkflow approach, which uses a combination of the
agent and workflow concepts to address a number of challenges of work-
flow execution. Both agents and workflows are provided as high-level
Petri nets.
The focus of this paper is the flexibility aspect of this approach. Agent-
workflows allow the dynamic reconfiguration of the workflow specifi-
cation. The key to this is the exchange of subworkflows depending on
the changing circumstances of the workflow execution. This allows the
workflow system to adapt to these circumstances and support users ad-
equately.
Keywords: Workflows, Agents, Combination, Flexibility
1 Introduction
Business processes (BP) are becoming ever more complex, especially in large
organisations. Their correct execution is crucial to the successful operation of a
company. Any incident occurring due to errors in a BP needs to be avoided by
all means. This is why BP are commonly facilitated with the help of workflow
software systems. Workflow management systems (WFMS) map real-life BP
to computerised representations and manage and control their execution, while
automating the processes as far as possible and supporting human users during
task execution.
Classically, WFMS are aimed at supporting static processes, that rarely
change. Dynamic changes, which might become necessary on a case-by-case ba-
sis, are difficult to handle and often require different solutions for every situation.
This is, however, a static approach to a dynamic problem and rather inefficient,
especially if the required changes are only minor and affect very small parts
of the workflow. Unforeseen changes that develop out of unique circumstances
cannot easily be handled by a static WFMS. These changes cannot be handled
on-the-fly and require a workflow modeller to implement a new version of the
200 PNSE’12 – Petri Nets and Software Engineering
overall workflow, especially dealing with the specific problem. The new workflow
then has to be re-initiated and an equivalent to the previous workflows’ state
has to be established. This requires time and effort, which, in real-life situations,
may be in short supply.
Because of this, another fundamental approach to workflow management can
be helpful or even crucial. Instead of only supporting static workflows, a degree
of flexibility should be added to the workflow management. It should be possible
to exchange certain parts of a workflow during execution, depending on the
current state of the system and workflow. If unforeseen changes occur, eligible
workflow administrators and modellers need to be able to simply (re-)design the
relevant parts and infuse them into the system in order to make further execution
of the workflow possible. Standardised exception handling or skipping patterns
can be used to automatically handle occurring issues and simplify the work of
administrators.
Another important aspect relates to interorganisational workflows, i.e. work-
flows executed cooperatively between different organisational entities. In this
context flexibility becomes especially important if partners in a workflow of-
ten change, which would require differing workflows each time in classical ap-
proaches. Interorganisational aspects will feature heavily in the discussion later
on in this paper.
We propose an approach to flexibility in workflow execution that strongly
relies on and profits from the agent-oriented paradigm. By using software agents
we can exploit the naturally distributed nature of these software entities to profit
in various ways. The approach, called agentworkflows, uses one agent for each
workflow instance. This agent is responsible for the execution, handling and
distribution of this workflow. The workflows themselves feature a hierarchical
structure, utilising subworkflows nested in an overall workflow. These subwork-
flows are essential to the support of flexibility and will receive special attention
in this paper.
This paper is structured as follows. In Section 2 we will discuss related work.
Section 3 highlights the modelling background for our research. Section 4 then
presents the agentworkflow concept and implementation, while Section 5 dis-
cusses the flexibility aspects of agentworkflows. Both agentworkflow concept and
how it can be used for flexibility are illustrated in an simple example in Section 6,
followed by the conclusion of the paper in Section 7.
2 Related Work
In this section we will discuss other approaches to flexibility in workflow man-
agement. The ADEPT (Application Development based on Encapsulated pre-
modeled Process Templates) project described, for example, in [4] deals with flex-
ible and robust workflow management. Using an advanced meta-model, which de-
fines all possible, allowed process structures, the system developed in this project
allows users to change single process instances or whole process templates. Most
aspects of a process or template can be changed during run-time, as long as the
T. Wagner: Agentworkflows for Flexible Workflow Execution 201
changes are allowed by the meta-model. Updating a process template updates
all of its currently running instances, as long as the changes do not produce
inconsistencies. The key to the flexibility in ADEPT is the so-called delta-layer.
This layer is situated between process template data and process instance data
and enables changes made to single instances. If the template is changed, the
information in the delta-layer and process instance data are checked against the
updated template and the decision whether to migrate or not is made. Com-
pared to our approach, the agentworkflows, ADEPT offers a much higher degree
of flexibility, but is very focussed on the processes. Agentworkflows add qualities
to the workflow execution, which are usually only associated with agents. These
go beyond the flexibility, which is the focus of this paper.
Another approach is presented in [6]. Similar to our approach the JBees
WFMS is implemented using agents and Petri nets. Based on the agent-platform
Opal and the Petri net tool JFern, the JBees system consists of several types of
agents. Interactions between these agents enable the execution of workflows. Of
special interest is the process agent, which similarly to our approach, encapsu-
lates a process instance and is responsible for its execution. Workflow flexibility
is also available in JBees using different algorithms to determine safe transfers
between process instances. While JBees uses agents and Petri nets to implement
workflow management it does not seem to offer the integration between agents
and workflows we strife to achieve with our overall approach. The agentwork-
flows partially fulfil our goals and can be compared in scope to a WFMS like
JBees.
[1] proposes a smart WFMS. During execution the WFMS possesses con-
text awareness for a process, so that it can adapt to the current circumstances.
The conceptual framework adds two key components to an otherwise regular
WFMS: smart workflow descriptions and a context reasoner. The smart work-
flow descriptions contain generic activities that are only linked to particular tasks
during runtime, similar to our approach. The context reasoner is responsible for
evaluating current circumstances and linking the generic activities to tasks.
[3, 2] propose recursive ECATNets (Extended Concurrent Algebraic Term
Nets) to model hierarchical and flexible workflows. Similar to our approach they
differentiate between elementary tasks, which are directly executed by resources,
and abstract tasks, which correspond to subworkflows.
Both the smart WFMS and the recursive ECATNets share similarities to
how flexibility is handled (e.g. late coupling of tasks, representing subworkflows
as tasks in overall workflows). However both approaches do not utilise agents.
As mentioned before agentworkflows can benefit in more ways then flexibility
from the employed agents.
All approaches, which have been discussed here, deal with flexibility in work-
flow execution in different and effective ways. Our approach exhibits similarities
to certain aspects of these approaches, like the use of Petri nets and agent-
orientation. In its current stage our approach may not offer the distinguished
and elaborated possibilities offered by the other approaches. However, it is just
one of the stepping stones toward a full integration of agents and workflows as
202 PNSE’12 – Petri Nets and Software Engineering
proposed in [11]. As such, the possibilities, w.r.t flexibility and other properties,
in later stages will be significantly improved yet again, though this is outside the
scope of this paper (see [17] for more information).
3 Modelling Background
The modelling background for our approach contains two major areas: agents
and workflows. Agents are provided through the Mulan and Capa agent archi-
tectures ([12, 5]). Mulan is a conceptual agent framework/architecture based
entirely on reference nets, a high level Petri net formalism introduced in [8].
Every aspect of a multi-agent system in Mulan, from agent protocols to the
overall systems, is modelled in reference nets. As the reference net formalism
follows the nets-within-nets principle [13], each layer is nested within its upper
layer creating a four-level hierarchy. Capa is an extension to Mulan introducing
full FIPA compliance to Mulan and replacing the upper levels of the Mulan
hierarchy. This provides the functionality to allow distributed execution.
Workflows on the other hand are provided through workflow (Petri) nets. In
our implementation workflow nets are specialised reference nets using a special
transition to model the tasks of the process. These workflow nets were introduced
in [7]. They follow the basic principles of (coloured) workflow Petri nets described
in [14].
Since both agents and workflows have a common technological base, the
reference net formalism, an integration of both concepts is not only possible in
our approach, it is also quite natural. Both concepts can profit from one another,
though the focus of this particular paper is on workflows benefiting from agent
technology. The overall aspects of the work on integrating agents and workflows
has been the subject of, for example, [11, 16, 10, 17].
Mulan/Capa and workflow nets have previously been used to implement
WFMS functionality. In [15] an agent-based WFMS (AgWFMS) was presented,
which provides full workflow functionality using the above mentioned technolo-
gies. The functionality required is naturally divided between several types of
agents. Users can log into the system remotely, but workflows are executed cen-
tralised. The AgWFMS managed to capture and support many interesting as-
pects, like interoperability due to the FIPA compliance of Capa. Some aspects,
however, such as distribution and flexibility of workflows, could not be ade-
quately supported in the classic AgWFMS. This was one of the motivations to
extend the system with our new approach.
The development and runtime environment for our systems is the Renew
(Reference Net Workshop) editor. The editor was developed alongside the refer-
ence net formalism and is described, for example, in [9]. It supports the execution
of all aspects described in this paper.
T. Wagner: Agentworkflows for Flexible Workflow Execution 203
4 Agentworkflows
Our approach to flexible workflow management is called agentworkflows. This
name reflects the combination of the agent and workflow concepts in this ap-
proach. The approach was originally described in [16] and general properties were
discussed in [10, 17]. It is part of a larger, ongoing effort, also described in the
previously mentioned works, but originating in [11]. This effort aims to combine
agents and workflows into a new concept that exhibits the advantages and char-
acteristics of both classical concepts. The overall goal in this is to address some
of the shortcomings each classical concept (can) exhibit. The agentworkflow ap-
proach represents one of the later steps in the overall effort, that integrates both
agents and workflows conceptually in the background, but still exhibits classical
workflow behaviour to its environment.
The approach is based on the classic, regular AgWFMS, mentioned above.
The agentworkflow approach replaces part of the workflow handling process in
the AgWFMS and can thus be seen as a natural extension. The extended Ag-
WFMS containing the enhanced functionality of and for agentworkflows is called
AgWFMS*.
The basic principle behind our agentworkflow approach is that of hierar-
chical nested subworkflows. In short a workflow basically consists of a num-
ber of subworkflows, which are orchestrated in an overall workflow, called the
structure-workflow. The relation between structure-workflow and subworkflows
is handled through the tasks of the structure-workflow. Tasks in the structure-
workflow correspond to subworkflows. Subworkflows can, conceptually, be other
structure-workflows also containing further subworkflows. However, for readabil-
ity and simplicity we will restrict ourselves to a two-level hierarchy in this paper.
This means that subworkflows consist only of tasks being executed by work-
flow resources (human or automated). In other words, the structure-workflow
defines the basic outline and connection (the structure) between the different
subworkflows. One key aspect of the development of this approach was to allow
distributed workflow execution. For the agentworkflow approach in particular
this manifests itself in the subworkflows. Each subworkflow is independent from
the others and can be executed on a different registered system in the network,
depending on the requirements of the particular subworkflow. Since the data-
and control-flow of the workflow is handled within the structure-workflow the
different subworkflows can be executed independently and only need to be coor-
dinated at their beginning and end.
One designated agent, the so-called structure-agent, is responsible for the exe-
cution of the structure-workflow and the aforementioned distribution aspect. For
each new workflow instance a new structure-agent is instantiated. This structure-
agent is only responsible for his own agentworkflow instance. The structure-
workflow is part of the structure agent. In fact, the agent is not only responsible
for the execution of the structure-workflow, it even handles most of it itself. For
this (and further autonomy reasons) it contains and replicates some parts of the
AgWFMS functionality.
204 PNSE’12 – Petri Nets and Software Engineering
The system functions as follows: When the structure-agent is started it re-
ceives the structure-workflow definition from the AgWFMS*. It instantiates and
stores the workflow net internally and registers as a listener for this net (and
this net only). This way, when tasks become activated the structure-agent can
automatically react. When that happens it reads the description of the subwork-
flow directly from the task of the structure-workflow. From this description the
structure-agent determines the circumstances for the subworkflow execution. It
determines what kind of or what particular system this subworkflow needs to be
executed on and then inquires which of these eligible systems are currently online
and registered. It then proceeds to choose one of the (possibly) multiple systems
for the actual execution of the subworkflow and contacts the interface agent of
the chosen AgWFMS*. After authentication the interface agent can decide to
accept or reject the subworkflow. If it rejects the subworkflow the structure-
agent chooses another system and tries instantiation of the subworkflow again,
unless no suitable systems are found, in which case error handling must occur1 .
If it accepts the subworkflow, (optional) input data is sent from the structure-
agent and the subworkflow is instantiated locally at that AgWFMS*. This point
is crucial to the flexibility aspect, since only the designation of the local sub-
workflow needs to be known to the structure-agent. The actual implementation
of the subworkflow is, except for input and output data, independent from the
structure-workflow. This will be discussed in the next section. The subworkflow
is executed by the local2 resources logged into that AgWFMS*. When the sub-
workflow has finished its execution the (optional) output data is transferred,
along with the confirmation of the subworkflows success, from the AgWFMS* to
the original structure-agent. The structure-agent then takes this information for
the structure-workflow, which completes its own task-transition. This process is
repeated for all subworkflows that become active during the execution of the
structure-workflow. Once the structure-workflow reaches the final transition the
workflow is finished and the structure-agent can persistently store the data and
then terminate.
Figure 1 shows a snapshot of an execution of an exemplary agentworkflow.
The structure-workflow is being executed by the structure-agent on AgWFMS*1.
It contains two active tasks/subworkflows that are currently being executed
on two AgWFMS*. AgWFMS*1 is home to the structure-agent and is execut-
ing subworkflow A, while AgWFMS*2 is executing subworkflow B. The figure
clearly shows the relations between the agents and the workflows. The structure-
workflow is only executed by the structure-agent. The structure-agent is in com-
munication with the AgWFMS* agents to oversee subworkflow execution. The
subworkflows are in no way executed by the structure-agent, but only corre-
spond to tasks in the structure-workflow. The only agents involved in the actual
execution of the subworkflows are the ones of the local AgWFMS* systems.
1
This could, for example, include the search for alternate systems or require manual
input from a user.
2
Local in this context refers to the resources logged into this particular AgWFMS*
and does not exclude resources connected to the AgWFMS* through a network.
T. Wagner: Agentworkflows for Flexible Workflow Execution 205
Fig. 1. Principle agentworkflow approach (from [17])
To conclude this description of the agentworkflow principle and AgWFMS*
system we will now shortly discuss its general attributes. This will not include
the flexibility aspect, which will be discussed in the next section especially ded-
icated to this aspect. One of the most prominent features of the agentworkflow
approach is the clear encapsulation of a workflow instance through a software
agent. It provides the workflow instances with a very clear identity during its exe-
cution. This can be advantageous for monitoring and maintenance of the system.
A disadvantageous aspect of the encapsulation is, that it increases the number
of agents active within the system which can lead to performance issues. Fur-
thermore if the structure-agent or its agent platform is terminated erroneously,
the entire agentworkflow is lost. This is a problem we aim to fix in the future.
Additionally the encapsulation opens up many of the possibilities of software
agents for workflow instances. Since, logically, the structure-agent and the work-
flow can be seen as equivalent many attributes usually associated with agents
can be related to the workflow. This is further supported by the fact, that both
the workflows and agents rely on the same technical background: reference nets.
Both the approach and the technological implementation add to the integration
of agent and workflow principles as proposed by the overall effort in [11].
The most obvious possibilities opened up by the integration are the distri-
bution of workflow execution and interoperability. Since now all parts, including
workflow instances, are implemented as agents, they can be distributed almost
arbitrarily on the network. Also, since Capa adheres to the FIPA standards,
206 PNSE’12 – Petri Nets and Software Engineering
interoperability with other agent systems is guaranteed, as long as the interfaces
match up. In the future, further agent attributes can be added to the agentwork-
flow approach. Mobility for one matter can remedy some issues arising from the
fact that the structure-agent serves as a central point of execution. In the orig-
inal agentworkflow approach a AgWFMS* platform would have to stay online
for as long as the structure-agent was active. If the structure-agent was able to
migrate to other platforms, the AgWFMS* platform could shut down while the
structure-agent continued its work on another AgWFMS* in the network. This
could also be used in error handling situations.
Furthermore, intelligence and autonomy could be added to the structure-
agent. These two attributes could be used in various ways, for example resource
access or control. But in combination with the mobility and distribution aspects
this becomes even more interesting, since it is possible to create an intelligent,
adaptive, migrating workflow instance. This is, however, outside of the scope of
this paper.
5 Flexibility in Agentworkflows
In this section we will discuss the agentworkflows with regards to their flexibility
aspects. As other attributes, such as mobility and intelligence, have already
shortly been discussed before, we will not address these here.
The most crucial aspect of the agentworkflow approach with regards to flex-
ibility is obviously the exchange of subworkflows and the loose coupling be-
tween structure-workflows and their related subworkflows. In the local view of
the structure-agent (and as such, the structure-workflow) each subworkflow pos-
sesses only a name, a place to be executed at and a (possibly empty) input and
output. The internal workings of a subworkflow are completely transparent to the
structure-agent. In fact, they are completely irrelevant to the structure-workflow,
as long as the subworkflow is completely executed and the correct output, w.r.t.
types, is produced. As a simple example imagine a subworkflow dealing with
checking the validity of a document nested within a structure-workflow for a
bank. As input, this subworkflow would possess the document, the output could
be a report on the document. How and in which order the different attributes
of the document are checked is of no concern to the structure-workflow3 , which
just needs the report to continue its execution.
This key characteristic of agentworkflows can positively influence flexibility
in workflow execution in a number of ways. First and foremost, it can enable
the dynamic reconfiguration of the workflow specification. The simplest way to
support this is to use a variable for the name of the subworkflow in the structure-
workflow, instead of a constant identifier. This variable can depend on various
factors, like results of previous subworkflows, and implicitly4 represents the cur-
rent circumstances of the workflow execution. When the task/subworkflow be-
3
Of course it is of concern for the real-world application, but for this generalisation
we can abstract from this.
4
The variable has to be an identifier for the subworkflow.
T. Wagner: Agentworkflows for Flexible Workflow Execution 207
comes activated now it is instantiated with an identifier depending on the current
circumstances of the workflow execution. In this way, the structure-workflow can
dynamically adapt to external factors of the execution. From a technical point of
view, this is relatively easy to realise, since the unification algorithm of Renew
allows for such substitutions. The idea can even be extended to the target Ag-
WFMS* of the subworkflow. Depending on certain factors it might be necessary
to not simply execute another subworkflow, but to also change the location.
This can be achieved, pretty much in the same way it was done for the sub-
workflow identifier, although the computations might be a bit more complex.
One might also consider extending this principle to input and output. This is
however, more difficult, since input and output are usually quite closely tied to
the subworkflow. Changing them in accordance to changing the subworkflow is
possible (input and output are just variables anyway), but changing them inde-
pendently would require the target platform to provide subworkflows with equal
names and differing parameters. This would make the system more difficult to
maintain, administrate and monitor.
It should be noted though, that the degree of flexibility added by this is not
as high as could be desired. The subworkflows have to be known prior to work-
flow execution, so that they are available and compiled during runtime. This
implies that unforeseen situations cannot be handled by our current approach.
However, the particular flexibility added by the agentworkflows still enhances the
system to deal with predictable, dynamic situations. This, in combinations with
standardised error-handling mechanisms (e.g. subworkflows that involve admin-
istrators), can handle many practical scenarios. Furthermore, it is already quite
easy to exchange or add subworkflows in the system. If unforeseen situations
arise, adapted subworkflows could be modelled by a workflow modeller and in-
troduced into the system. Making this functionality available more “on-the-fly”
and integrating it more directly into the approach could remedy the current
shortcomings in flexibility.
Though not implied by the “regular” agentworkflow approach it is also pos-
sible to modify the AgWFMS* in order to support the flexibility mechanic from
its side. In principle, this is mostly equivalent to the variable identifier ver-
sion described above, only that the variables depends on factors of the target
AgWFMS* and the structure-agent. In this modification, the AgWFMS* can
autonomously decide which subworkflow to instantiate. It can take the proposed
subworkflow, the input and the output, as well as its own state into consider-
ation in this decision. The effect would generally be the same, only that the
ultimate control would lie with the target AgWFMS*. The combination of both
approaches would yield an even higher degree of flexibility, since all factors local
to the structure-agent and AgWFMS* would be taken into consideration during
subworkflow instantiation.
There are some further aspects the subworkflow characteristic adds to work-
flow execution with regards to flexibility, though these do not impact as much as
the ones described above and also focus on other variations of flexibility. Since the
structure-agent is ultimately responsible for choosing which AgWFMS* should
208 PNSE’12 – Petri Nets and Software Engineering
execute a subworkflow, an adapted structure-agent with reasoning functionality
and additional information about the different AgWFMS* available could en-
hance flexibility in regards to load balancing or other similar efficiency factors.
The agent could, for example choose (among the set of suitable AgWFMS*)
the system with the lowest workload or the one with the best network connec-
tion. The counterpart to this mechanic is to include the reasoning within the
AgWFMS*, which yields similar results. If the AgWFMS* determines that its
workload is too high, or that too few resources are available, it can reject the sub-
workflow, which would force the structure-agent to choose another AgWFMS*.
The subworkflow hierarchy also contributes to flexibility. The two-level hier-
archy discussed in this paper is only the simplest and easiest to describe version
of the agentworkflow approach. When considering workflow hierarchies of more
then two levels, each additional level offers a more fine-grained degree of flexi-
bility. This can be especially useful in an interorganisational context, since the
additional levels of organisation can profit there.
Interorganisational workflow execution deals with workflows that are exe-
cuted cooperatively by different organisations. In this context each organisation
is responsible for its own part of the workflow. Even though the organisations are
working together within the process, each organisation is, of course, interested
in keeping the confidential details from the other partners. Furthermore, each
organisation will prefer to use their own WFMS, instead of relying on a central
one which is used by all partners. For these reasons the agentworkflow approach
is well suited for the interorganisational context, since the encapsulation ensures
security and the interoperability and distribution aspects support the second
requirement.
Nevertheless the flexibility aspects discussed above are also quite effective in
this context. First and foremost, the ability to exchange subworkflows without
influencing the overall structure-workflow is even more useful. In an interorgan-
isational setting, factors that influence workflow execution can be even more
varied, dynamic and demanding, since the collaboration introduces a lot of com-
plexity in the real-world scenario. Being able to handle these factors by providing
different subworkflows for different examples reduces the complexity again.
As mentioned before, adding additional levels to the hierarchy can also be
used as an improvement in this context. By allowing subworkflows to be structure-
workflows again, the flexibility aspects available on the interorganisational level
(original structure-workflow) become available to the individual organisation as
well. If the individual organisation uses this hierarchy-level to distribute work
between different departments, additional levels would again open up these pos-
sibilities to the departments and so forth.
The structure-agents ability to choose a WFMS for subworkflow execution
could take on a fully different role in the interorganisational context. By using
negotiation concepts, different WFMS of different organisations could offer to
take over subworkflows, which in the real-world scenario would translate to or-
ganisations competing for work assignments/contracts. This is, however, outside
of the scope of the current agentworkflow approach.
T. Wagner: Agentworkflows for Flexible Workflow Execution 209
Fig. 2. Example Structure-Workflow
210 PNSE’12 – Petri Nets and Software Engineering
Fig. 3. Example Subworkflows
T. Wagner: Agentworkflows for Flexible Workflow Execution 211
6 Example
In this section we will discuss a simple example of a flexible agentworkflow in
an interorganisational setting. The structure-workflow can be seen in Figure 2.
Workflow nets like these consist of regular Petri net places and transitions, as
well as a few special elements. A workflow net starts with a transition connected
to a synchronous channel labeled :startWf(input) over which it can receive pa-
rameters, and ends with a transition connected to synchronous channel labeled
:stopWf(output) over which an optional result can be send. Tasks are repre-
sented as transitions with thick vertical bars, called task-transitions. Tasks in a
structure-workflow representing subworkflows are also drawn as transitions with
thick vertical bars and the letter S marked in the centre. The “regular” Petri net
transitions within the figure represent (abstract) operations on the variables and
data within the workflow. Usually they would/could feature more complex net
structures as well as synchronous channels to receive outside information. How-
ever, to retain readability of the net for this paper we have chosen to abstract
from a detailed and technical view in favour of a simplified version. For the same
reason we omitted the exact, complex inscriptions on the example workflow nets.
It should also be noted that, in order to keep the net size and complexity man-
ageable error handling and aborting the workflow due to failures in subworkflows
have largely been omitted.
Figure 2 represents a workflow for processing and handling an incoming order
in a generic company offering many items. The company offers standard items,
which are in stock and don’t need special treatment, and special items, which
have to be ordered from a third-party provider and handled differently (e.g.
large items or large quantities of items). The workflow encompasses the different
steps from processing the incoming order, handling the standard or special item,
handling payment, shipping via another third-party and finally book keeping.
Each of these complex tasks is modelled as a subworkflow. It should be noted
that we consider the main company to be in charge of this workflow, so that only
the two subworkflows for the third-party providers feature distributed execution.
We can observe three different types of subworkflows in this example.
The first type are regular subworkflows, which do not exhibit or require flex-
ibility. In this example these are the processing of the original order (Receive
order ) and informing the consumer about problems in ordering a special item
(Inform consumer about failure). These subworkflows do not need to be flexible,
since, given the scenario, one version for each subworkflow can handle the pos-
sible circumstances. However, changing these subworkflows to be flexible would
only require adding some variable processing ahead of them, changing the in-
scriptions to support the variables and providing the different subworkflows on
the systems they would need to be executed on.
The second type of subworkflows are the flexible, interorganisational ones.
These are ordering a special item (Order special item) and handling the shipping
(Shipping). These are flexible since, depending on the item, they might have to
be taken care of by different companies and through different subworkflows.
For example ordering a bulky, large household item like a refrigerator would
212 PNSE’12 – Petri Nets and Software Engineering
require a different company and subworkflow then ordering a smartphone. These
subworkflows illustrate how agentworkflows in general and their flexibility in
particular can support interorganisational settings.
The third and final type of subworkflows are flexible, but local ones. These
are handling a special item which has been ordered and received and now needs
to be temporarily stored (Handle special item), the handling of the payment for
a consumer (Handle payment) and book keeping and accounting (Book keeping).
These are flexible since special items may have special requirements in storage
or handling and the company might offer different ways of paying for an item.
Three different versions of the Handle payment subworkflow are shown in
Figure 3. The three versions all represent the process involved in handling and
receiving payment from the user. All three have in common that the original
order information is stored for later processing with the last task before the
subworkflow is finished (the lower branch in all three versions).
The topmost version represents prepayment by the user. The company pre-
pares the invoice, sends it out and, at some later point, receives payment before
the item is shipped. The middle version supports payment by credit card. The
company receives credit card information from the consumer and executes the
transaction. At this point the transaction was either successful or failed. If it
failed user interaction (e.g. re-entering the credit card information) is required. If
the transaction succeeds the item can be processed and shipped. The lowest ver-
sion models payment by cash-on-delivery. In this case the cash-on-delivery only
needs to be prepared with the postage service before the item can be shipped.
In this case processing payment would be included in later stages of the overall
workflow (e.g. a corresponding version of the Book keeping subworkflow).
This example illustrates the kind of scenario for which agentworkflow flexibil-
ity is especially suited. The different possibilities are known beforehand (e.g. the
different payment options offered by the organisation) and each can be modelled
accordingly. During execution the correct subworkflow can be instantiated and
the requirements given by the variable factors of the workflow (in this simple
example the choice of payment) can be fulfilled. While the different versions
of the Handle payment subworkflow only differ in small parts, other scenarios
could require more substantial changes in subworkflows. This could also easily
be handled by the agentworkflow approach.
Though the workflow of Figure 2 is a simple example, it serves to illustrate
the agentworkflow approach quite well. Subworkflows can feature distribution
and flexibility, and it is also conceivable to mix subworkflows and regular tasks
to loosen the hierarchy. If further aspects of agentworkflows, like intelligence and
mobility, are considered, it becomes clear that even these already versatile ways
only scratch the surface of the overall approach and its possibilities.
7 Conclusion
In this paper we have presented an approach to workflow management, called
agentworkflows. It incorporates elements of both agent orientation and classic
T. Wagner: Agentworkflows for Flexible Workflow Execution 213
workflow execution to combine strengths of both fields. The agentworkflow ap-
proach exhibits many interesting attributes, like encapsulation, intelligence and
distribution. The focus of this paper though, was on the flexibility introduced by
it. The flexibility of the agentworkflows relies on using a hierarchy of workflows
and subworkflows and on allowing the dynamic exchange of subworkflows depen-
dent on variable factors. This enables the dynamic reconfiguration of workflow
instances at runtime. We discussed this aspect of the approach in detail and fi-
nally gave an example of how it could be used in an interorganisational context.
The example illustrated the versatile ways, in which agentworkflows and their
subworkflows could be deployed.
The flexibility introduced by the agentworkflow approach makes it more suit-
able for real-world scenarios than a classically rigid approach. However, there
are currently some shortcomings to our approach, since subworkflows need to
be known and compiled before execution of the overall structure-workflow. This
limits the possibilities of the approach, since on-the-fly changes become difficult.
These limitations, however, do not relate to the general approach and need to
be fixed on a technological level, rather then a conceptual one. Addressing them
is one of our goals for future work. Furthermore we also aim to address the
other flexibility aspects discussed in this paper, as well as generally extend the
agentworkflow approach with more concepts from both agents and workflows.
Enhanced agent mobility, intelligence and distribution can greatly improve work-
flow execution and the process view given by workflows can enhance the agent-
side. We hope to combine the two paradigms to profit from one another and
further our overall goal to provide the desired complete integration of both. Ul-
timately, the intent is to develop a novel, general unit concept, which can serve
as agent, workflow or both, depending on the dynamic requirements at runtime.
Agentworkflows are one of the later steps towards that goal.
In conclusion, the agentworkflow approach possesses many qualities beneficial
to flexible workflow execution. Tt serves as an important basis for future work
regarding the integration of the agent and workflow concepts. By itself, the
approach offers a simple, yet elegant way of supporting flexibility in workflow
management.
References
1. Abu Zafar Abbasi and Zubair A. Shaikh. A conceptual framework for smart work-
flow management. In Information Management and Engineering, ICIME ’09, 2009.
2. Kamel Barkaoui, Hanifa Boucheneb, and Awatef Hicheur. Modelling and analysis of
time-constrained flexible workflows with time recursive ecatnets. In Roberto Bruni
and Karsten Wolf, editors, WS-FM, volume 5387 of Lecture Notes in Computer
Science, pages 19–36. Springer, 2008.
3. Kamel Barkaoui and Awatef Hicheur. Towards analysis of flexible and collabora-
tive workflow using recursive ecatnets. In Arthur H. M. ter Hofstede, Boualem Be-
natallah, and Hye-Young Paik, editors, Business Process Management Workshops,
volume 4928 of Lecture Notes in Computer Science, pages 232–244. Springer, 2007.
214 PNSE’12 – Petri Nets and Software Engineering
4. Peter Dadam, Manfred Reichert, Stefanie Rinderle-Ma, Kevin Göser, Ulrich Kre-
her, and Martin Jurisch. Von ADEPT zur AristaFlow BPM Suite - Eine Vision
wird Realität: "Correctness by Construction" und flexible, robuste Ausführung von
Unternehmensprozessen. EMISA Forum, 29(1):9–28, 2009.
5. Michael Duvigneau. Bereitstellung einer Agentenplattform für petrinetzbasierte
Agenten. Diploma thesis, University of Hamburg, Department of Computer Sci-
ence, Vogt-Kölln Str. 30, D-22527 Hamburg, December 2002.
6. Lars Ehrler, Martin Fleurke, Maryam Purvis, and Bastin Tony Roy Savarimuthu.
Agent-based workflow management systems (WfMSs) - JBees: a distributed and
adaptive WfMS with monitoring and controlling capabilities. Information Systems
and E-Business Management, 4, Number 1 / January, 2006:5–23, 2005.
7. Thomas Jacob. Implementierung einer sicheren und rollenbasierten Workflow-
management-Komponente für ein Petrinetzwerkzeug. Diploma thesis, University
of Hamburg, Department of Computer Science, Vogt-Kölln Str. 30, D-22527 Ham-
burg, 2002.
8. Olaf Kummer. Referenznetze. Logos Verlag, Berlin, 2002.
9. Olaf Kummer, Frank Wienberg, Michael Duvigneau, Michael Köhler, Daniel Moldt,
and Heiko Rölke. Renew – the Reference Net Workshop. In Eric Veerbeek, editor,
Tool Demonstrations. 24th International Conference on Application and Theory of
Petri Nets (ATPN 2003). International Conference on Business Process Manage-
ment (BPM 2003)., pages 99–102. Department of Technology Management, Tech-
nische Universiteit Eindhoven, Beta Research School for Operations Management
and Logistics, June 2003.
10. Daniel Moldt, José Quenum, Christine Reese, and Thomas Wagner. Improving
a workflow management system with an agent flavour. In Michael Duvigneau
and Daniel Moldt, editors, Proceedings of the International Workshop on Petri
Nets and Software Engineering, PNSE’10, Braga, Portugal, number FBI-HH-B-
294/10 in Bericht, pages 55–70, Vogt-Kölln Str. 30, D-22527 Hamburg, June 2010.
University of Hamburg, Department of Informatics.
11. Christine Reese. Prozess-Infrastruktur für Agentenanwendungen. Dissertation,
Vogt-Kölln Str. 30, D-22527 Hamburg, 2009.
12. Heiko Rölke. Modellierung von Agenten und Multiagentensystemen – Grundlagen
und Anwendungen, volume 2 of Agent Technology – Theory and Applications. Logos
Verlag, Berlin, 2004.
13. Rüdiger Valk. Concurrency in Communicating Object Petri Nets. In Advances
in Petri Nets: Concurrent Object-Oriented Programming and Petri Nets, volume
2001 of Lecture Notes in Computer Science, pages 164–195. Springer-Verlag, Berlin
Heidelberg New York, 2001.
14. Wil M.P. van der Aalst. Verification of Workflow Nets. In ICATPN ’97: Proceed-
ings of the 18th International Conference on Application and Theory of Petri Nets,
volume 1248, pages 407–426, Berlin Heidelberg New York, 1997. Springer-Verlag.
15. Thomas Wagner. A Centralized Petri Net- and Agent-based Workflow Manage-
ment System. Number FBI-HH-B-290/09 in Bericht, pages 29–44. University of
Hamburg, September 2009.
16. Thomas Wagner. Prototypische Realisierung einer Integration von Agenten und
Workflows. Diploma thesis, University of Hamburg, Department of Informatics,
Vogt-Kölln Str. 30, D-22527 Hamburg, 2009.
17. Thomas Wagner, Jose Quenum, Daniel Moldt, and Christine Reese. Providing an
agent flavored integration for workflow management. LNCS Transactions on Petri
Nets and Other Models of Concurrency (ToPNoC), LNCS 6900, 2012.