This paper presents a mapping between an elementary Higher Order Net (eHornet) system and the Paffin-system, a practical hybrid agent and workflow system. The eHornet system provides a formal basis for the processes. It also supports properties, like adaptivity and mobility, which can be preserved in the mapping and used in the Paffin-system. The paper describes the basics of elementary Hornets, the Paffin-system, as well as the mapping between them.
Consequently, the goal of the research presented in this paper is to find a
mapping between the formal Hornets and a practical execution environment. The
intended execution environment is a hybrid agent and workflow system called the
Paffin-system (Processes and Agents f or a f ull Integration, [
The paper is structured as follows: Section 2 discusses Hornets and describes the example used within this paper, while Section 3 presents the basics of the Paffin-system. Section 4 describes the mapping between eHornets and Paffin-system. Throughout these sections a common illustrative example will be maintained. Finally, Section 5 takes a look at related work, before the paper is concluded with an outlook in Section 6. 2
Hornets [
For Hornets Object Petri Nets have been extended with algebraic concepts
that allow modifying the structure of the net-tokens as a result of a firing
transition. This is a generalisation of the approach of algebraic nets [
This paper will give a simple example only and refer to [
- ris- e }Z
Z =
q ZslHyHj slx p * t
(xky-) N1 ii1- a iu- b - riv- c f1 i
r l f2 i
net-token produced on r by t N3 i3 h
N1 hi-1 a u h- b - rh- c
v - rhs - e f1 h hf2 f3 h binding enables the transition t. Assume that (xky) evaluates to N3. If t fires it removes the two net-tokens from p and q and generates one new net-token on place r. The net-token on r has the structure of N3 and its marking is obtained as a transfer from the token on v in N1 and the token on s in N2 into N3. This transfer is possible since all the places of N1 and N2 are also places in N3 and tokens can be transferred in the obvious way.
Workflow nets as introduced by van der Aalst (see [
In the following, a scenario featuring mobile and adaptive workflows is discussed. This scenario is used in the remainder of this paper to illustrate the different models. It is an artificial family situation:
A child wants some candy and asks its parents for permission. The parents are in different rooms of the house and the child always asks its mother. If the mother approves the candy consumption the child can eat some incoming or outgoing arcs works in similar ways. Their informal behaviour can be described as follows: The operator binds the variables to the nets (tokens) on the incoming places and the outgoing places. The usual non determinism applies if there are several tokens within one place. candy. If the mother disagrees the child becomes sad and won’t eat any candy. However, the child can also decide to ask its father, who always agrees to eat all of the available candy in our artificial setting.
This simple scenario can be easily captured as a workflow system. Following our idea that the behaviours of people are modelled as workflows, the child and its parents are modelled as individual, interacting workflows. When the child asks one of its parents the two corresponding workflows need to interact. The child moves between the rooms to interact with its parents.
The scenario features adaptive and mobile behaviour. The child adapts when it decides that it can ask the father after the mother didn’t allow eating candy. The child is also mobile as it has to move between the rooms in which its mother and father are located.
The scenario is now presented as an eHornet system. The three different (workflow) nets (Child, Mother, Father) are shown in Figure 3. They are executed in the system net depicted in Figure 2.
The partition of the system net into the three rooms serves to illustrate the
movement of the family members during the scenario. The father net instance
(the token named “Dad”) is in room 1, the mother net instance (the token named
“Mum”) is in room 2. Initially, the child net instance (the token named “Kid”) is
in its own room 3 but moves to the other rooms during the scenario4.
4 The nets are just an informal representation and do not include the inscriptions for
the formal representations of the eHornets as introduced in [
The adaption mechanism replaces the part of the child net that accepts the mother’s decision with another net structure that asks the father for candy. It removes the child net from the place in room 3 and puts the changed net back instantaneously (the change is indicated by child’ )5. 5 In this paper we use mostly an informal notation for the eHornets. The adaption needs to be covered by inscriptions that allow for the changes of the tokens / nets.
The adapted child net can then move to room 1, merge with the father net, and finally return to room 3 when the interaction is finished. Since the father will always allow candy, the child net can complete its own workflow. Child The child net represents the main workflow. It begins with the task to ask-mum (for the candy). That task enables the merger of the mother and child nets. When these nets merge, the places with the same name (mum/mum’) are combined. This initialises the mother workflow.
When the mother’s answer is put onto the mum’ place the mother and child nets can separate again. Depending on the mother’s answer either the mumsays-yes or mum-says-no transitions can fire. If the mother allowed the candy the next transition is eat-candy, after which the workflow can terminate. If the mother did not allow the candy there are two options.
The original net implements the child accepting the mother’s decision. The dont-eat-candy transition fires and the workflow can be completed. If the child decides to ask its father the Original Net Structure is replaced by the Ask-Dad Net Structure. This adaption is controlled and executed on the system net level. When the adaption transition in the system net is fired the child net is, in one firing step, removed from its original place, the net structures exchanged, and finally the adapted net put back onto the original place.
The Ask-Dad Net Structure is similar to asking the mother. The father, however, always agrees to the candy, so there is no negative option. The child asks its father, thus initialising the father workflow, which returns a yes to the child, which can now eat-all-candy. Finally, the workflow is then in its end state. Mother/Father The mother and father nets follow a similar structure. Since the mother and father in the scenario are just secondary (they are object nets) they are not initialised in the usual way and cannot work without being merged with the child net.
Consequently the structure of both nets is very simple. The start place mum/dad enables the sequence of a “think” and an “answer” transition. The answer is finally put on the end place mum’/dad’.
When the mother or father nets are merged with a child net for interaction,
the start and end places are the merging points. This way the answer can be
transferred to the child net when the nets are separated again. The separation
is not described here, since it follows similar patterns as the merging according
to the details of the firing rule described in [
This section describes the basics of the Paffin-system (Processes and Agents
f or a f ull Integration-system), which provides the hybrid agent and workflow
So to adapt in the Figure 2 means that the child, as informally described in Figure 3
will change its structure from the left net part (Original Net Structure) to the right
net part (Ask-Dad Net Structure). The formal inscriptions are not shown here.
management utilised later on. More information about the Paffin-system can
be found in [
In general, a combination of agents and workflows is not a new idea. There has been a number of research efforts that combined the two concepts on some level (see the discussion on related work in Section 5). However, most of these research efforts only utilised one concept to enhance the other one, e.g., using agents to implement and improve workflow management. Our research related to the Paffin-system goes beyond this. The goal is not just to improve one of the concepts. Rather, the goal is to improve both concepts, integrate and combine them and also provide both of them in a unified way to application modellers. This is what we call a full integration of agents and workflows, as opposed to a partial integration which enhances only one of the concepts.
The result is a modelling construct which is no longer just a workflow or an
agent, but instead an abstract entity which inherits the capabilities /
functionalities of both concepts. Entities can dynamically act and be interacted with as
an agent, a workflow, both or something in between depending on the current
situation and needs at runtime. Such an entity is, in short, called a Paffin or
Paffin-entity. Paffins serve as the main modelling construct within the
Paffin-system and are modelled and, at runtime, managed similarly to agents and
workflows. The ideas leading to the Paffin-system were presented e.g. in [
A full integration of agents and workflows as realised in the Paffin-system provides a number of advantages. The advantages of partial integrations, i.e., the enhancements for one of the concepts by incorporating strengths of the other one, are available for modelling in both directions. Paffins as agents can utilise workflow properties like atomicity of tasks and simple user interaction. Paffins as workflows can utilise agent properties like intelligence and mobility. Furthermore, since Paffins can dynamically be agents or workflows, modellers are no longer restrained to using one of the two exclusively. Rather, modellers are free to flexibly adapt the Paffin to the needs of specific situations and choose whether agent, workflow or something in between is best suited at that moment.
For example, a Paffin acting as a workflow can, during the execution of its tasks, act as an agent receiving and reviewing intermediate results of the task. If the intermediate results indicate errors or other problems, the Paffin, as an agent, can autonomously decide to cancel the execution of the task it executes acting as a workflow. The combination and full integration of the concepts agent and workflow on the same abstraction level provides application modellers with a powerful modelling mechanism. That mechanism, the Paffin, is highly versatile, flexible and sophisticated. The downside of the power and expressiveness of the Paffin mechanisms is that they are more difficult to use efficiently. Still, this disadvantage can be alleviated with supporting modelling tools, guidelines and approaches.
For the purposes of this paper the usability of Paffins as enhanced agents and workflows is most important. The eHornets are workflows on the secondary level (the object nets). These workflows interact at some points (merging mother/father and child), they make decisions (the decision to adapt), and they are mobile. Interaction, decision making, mobility and more are classical agent properties. The full integration in the hybrid system allows to model these workflows as enriched Paffin-entities, adopting agent properties while retaining workflow behaviour. The adaptivity of the workflows can also directly be mapped into agent behaviour as explained in the remainder of the paper. 3.2
The core of the integration within the Paffin-entities is the so-called Agent
Activity (AgAc) (see [
Using these three types of operations and three types of actions it is possible
to model any agent or workflow behaviour. An AgAc incorporating both actions
and operations then describes the abstract activity of a Paffin-entity acting
as both agent and workflow. Actions and operations are combined in a small
process description. Figure 5 shows such a process for an extended task. The
net is a reference net [
The small and simple example shown in Figure 5 already shows how the
combination of agent actions and workflow operations is utilised in AgAcs.
Through this combination the Paffins within the system can maintain a singular
6 Note that the resource may itself be executing an AgAc within its own Paffin
which is not shown here. The implementation of the resource is irrelevant, as along
as a compatible message is sent to the Paffin executing the net in Figure 5.
context in which they act as agent (Actions 2 and 3), workflows (Operation 1)
or both (Operations 4 and 5). The AgAc is the core mechanism through which
the overall integration of agents and workflows within the Paffin-system is
achieved. More information about the AgAc can be found in [
The prototype of the Paffin-system is implemented using reference nets [
Agent aspects of the Paffin-prototype are based on the Mulan reference
architecture (Multi agent nets [
The Paffin-system itself adopts the principle four layers of the Mulan reference architecture and extends the layers to capture workflow aspects. This is illustrated on the right-hand side of Figure 6. The system level represents the entire system and is a logical summary of the other levels. The system consists of a number of management platforms, which serve as the next level. These serve a similar role as workflow and agent management systems in classical system.
The management platforms serve as the execution environment for the Paffins, which make up the third level. Finally, the Agent Activities are defined and related to each other in the process-protocol level. A process-protocol serves a similar function to an agent protocol or a workflow 8.
The Paffin-architecture describes, as a reference, the internal composition and interrelation between the individual elements of the executed management system. It represents a detailed view of the internal structure. The application architecture shown on the left-hand side of Figure 6 on the other hand describes the structure of an application built with the Paffin-system. The foundation is given by Renew and reference nets. Capa tools and infrastructure (e.g. monitoring and administration), as well as reference workflow net mechanisms are built on top of Renew. The Paffin-system, whose internal architecture was described above, builds on top of all of these mechanisms as well as Renew and reference nets directly. On top of the Paffin-system the Paffin-application is created. The application is what is actually built by a modeller using the Paffin-system. It provides the content of Agent Activities, process-protocols, Paffin-knowledge, etc. that actually captures what the modellers want their system to do. The mapping between eHornets and Paffins creates exactly such an application as will be described in the following section.
The current prototype of the Paffin-system already fully supports the full
integration as motivated in the previous subsection. Paffin-entities of the
prototype can execute AgAcs that include workflow operations and agent actions
in any (reasonable) order. Currently ongoing work on the prototype focusses
on supporting the modelling, which addresses the disadvantageous effects of the
extended modelling capabilities. Standardised AgAc net components, adapted
monitoring and administration tools and simplifications to the modelling
process are currently being investigated. Additionally, the applicability of the Paose
modelling approach (Petri net-based Agent- and Organisation-oriented Software
Engineering [
The preceding sections explored the basics of eHornet systems and the Paffin execution environment. This current section outlines how to map an eHornet system to a Paffin-application. Mapping, in this context, is meant as a rough translation coming from a modelled eHornet system and yielding a Paffinapplication containing the same functionality. Figure 7 gives an overview of the mapping process. Mapping can be broken down into two basic steps:
First, identify the structural, behavioural, and additional aspects of the eHornet system. Second, combine these aspects into the appropriate constructs in a Paffin-application.
The behavioural aspects include the processes, the individual tasks/actions, and the access/execution rules. In the eHornet system, this corresponds to the different workflow nets. In the example introduced in Section 2, the processes are Child, Mother, and Father. The tasks can be extracted directly from the workflows, as well as the executing resources. In the example the executing resource is always the actor of the same name (e.g. the child executes the tasks of the Child workflow).
Structural aspects deal with the individual actors, their properties, and their relationship with one another. The actors themselves need to be identified from the executing resources of the eHornet workflows. For the example these are the child, the father, and the mother. The communication and infrastructure between the actors is defined in the system net of the eHornet system. A group of places in the system net will always represent a logical execution environment, while the transitions between these groups define the communication infrastructure. In the example, there are three execution environments, the different rooms. The transitions between the room 3 and both room 1 and 2 represent an infrastructure that allows the child to move from room 3 to room 1 or 2 and back. Consequently, there are three execution environments for the Paffin-system, with a communication/migration infrastructure that allows actors from room 3 to move to room 1 or 2 and back. The communication between different actors is modelled by merging and unmerging workflow nets into an eHornet system. Instances of this merging also need to be identified and analysed for the participating actors. In the example these are the times, at which the child workflow merges with the mother and father workflows to ask permission for candy. The actors involved are the child and mother in the first case and child and father in the second case.
Additional aspects include those aspects, which cannot be classified into the structural and behavioural groups. These include the ontology, which is orthogonal to the structure and behaviour, and the adaption rules, which affect both structure and behaviour. The ontology needs to be identified from the eHornet system by analysing which (data) objects are considered and communicated between the actors. For the example this is only the question and answer for candy between the child and one of its parents. To identify the adaption rules, each possible adaption in the eHornet system needs to be analysed. The circumstances and requirements for each adaption have to be noted, as well as the possible outcomes. 4.2
After having identified the different aspects, they need to be combined to create a Paffin-application. The elements which must be modelled for a Paffinapplication are: entity-knowledge, process-protocols with the included AgAcs, decision making of the entities, and the deployment management platforms. The remaining technical administration and management of Paffins do not need to be changed for each application.
As a basis, each actor from the structural aspects is mapped onto one Paffinentity each, though there can be multiple instances of an entity (e.g. a second child). These entities are assigned to management platforms according to the identified execution environments from the eHornet system. The communication/migration infrastructure is coded into the management platforms to allow or disallow communication with certain other management platforms. Communication between Paffins is enabled by providing the identifiers and communication information for each communication partner in each Paffin’s knowledge. In the example, this results in three Paffins (child, mother, father) and three management platforms (rooms 1-3). Rooms 1 and 2 manage the father and mother entities respectively and allow only communication/migration to/from room 3. Room 3 manages the child entity and consequently allows communications/migrations to/from both rooms 1 and 2. The father and mother entities know only the identifier of the child entity, which in turn knows both and is capable of migration.
Most of the behavioural aspects are mapped into the process-protocols. In fact, the identified processes are almost directly adopted into process-protocols. The transitions of the eHornet workflows are turned into AgAcs, which also include the rules for their execution. In general, each process-protocol will either be executed by the entity which was created from the responsible actor (e.g. the child entity for the child workflow) or by an additional entity if the workflow cannot be clearly assigned to one of the identified actors. The latter might be the case in a more collaborative scenario, in which a workflow is executed by many different resources and not owned by one in particular. One important change from the eHornet workflows to the process-protocol is the handling of communication. In the eHornets the communication is handled through merging the nets through named places. This is replaced in the Paffin-system with agent-like message communication. At each merging point an AgAc modelling the communication is added. This particular AgAc sends a message to the designated partner or receives and processes a message from a partner. This does not affect the structure of the process. For this paper’s example the resulting process-protocols are child for the child entity and mother/father for the mother/father entities respectively. The places mum/mum’/dad/dad’ are replaced with Agent Activities for communication.
To illustrate the mapping Figure 8 shows the original eHornet and resulting father process-protocol. The recurring net structure in that figure is the AgAc9. The inscriptions connect to the technical backend provided by the executing Paffin. At this point the coarseness of the mapping becomes evident. The mapping prescribes that merged places and transitions of the eHornet system are mapped onto AgAcs. However, as is visible in the example these AgAcs are simple and contain only one agent action each (in sequence: receive message (from kid), think, create answer, send answer (to kid)). These actions could be better summarised into one AgAc, since they are semantically related. For now, issues like this are at the discretion of the modeller who has to decide which AgAcs to combine and which to possibly extend. Capturing these reasonable combinations is part of the future work regarding the refinement of the mapping approach.
The additional aspects are mostly mapped into the knowledge and decision making mechanisms of the individual entities. The ontology is made known to the knowledge base of the Paffins. Adaption rules can be incorporated in two ways, depending on the extent of the changes. If the changes only affect one task/action, they are incorporated directly into the corresponding AgAc. AgAcs support templates for actions, which are chosen depending on parameters defined in the inscriptions of the AgAc. If the changes are more extensive the adaption is moved to a decision making mechanism within the entity. This constantly active mechanism monitors the on-going process-protocols and can intervene and replace them if it decides upon this necessity. The process-protocols state is saved and a new process-protocol instantiated and moved to the previously saved state. In the example the latter is the case. The decision making mechanism can monitor the child process-protocol and, when the mother doesn’t allow the candy, replace the process-protocol with the adapted version. 5
The Paffin-system is directly related to [
Improvements of agents with workflow principles and workflows with agent
principles, which we consider to be partial integrations, have been thoroughly
researched before. For example, [
Such partial integrations do not offer the degree of integration the Paffinsystem adopts. They still exclusively offer only agents or workflows as modelling constructs, and do not combine the concepts on the modeller’s abstraction level. They do, however, use the respective other concept in the background, which allows some properties to be translated.
Adaptivity and flexibility in workflows have been the topic in many
publications, e.g. [
There is some research that shows a larger degree of integration e.g. [
The paper presented a mapping between the eHornets formalism and the Paffin-system, a hybrid agent and workflow system. The mapping retains aspects from the eHornets, such as mobility and adaptivity, while applying a formal basis to the hybrid Paffin-system.
The mapping creates a bridge between the two modelling approaches from which both can benefit. The eHornets are provided with a more practically oriented execution potential. Paffin applications are aimed at distributed systems with complex structures and behaviours. The possibility to make eHornets available in these kinds of systems is desirable. Paffins on the other hand benefit from the formal basis introduced by the eHornets. The ability to model an eHornet system with certain formal properties (e.g. liveness, deadlock-freeness) and mapping that eHornet system onto a Paffin application can make the use of Paffins more viable in practical situations. This paper presented the first step towards realising these advantages and benefits. The coarse mapping presented in this paper creates the foundation on which the practical mechanisms of Paffins and formal basis of eHornets can be incorporated.
Future work will address and build upon this coarse approach and refine it to fully exploit these intended benefits and advantages. Direct, short-term goals still focus on extending the modelling support and usability of the Paffinsystem prototype. The long-term goals relate to actually exploiting the eHornet mapping for purposes of verification. The ability to ascertain properties in the formal model (e.g. liveness, deadlock-freeness) for the practical execution is a highly desirable feature. Examining the conditions under which these properties are retained in the mapping and adapting the mapping to directly enforce these conditions are important results in the near future. Coupled with an envisioned, fully automated mapping between eHornets and the hybrid system, the results could be used to easily create formally verified practical systems. This future work also includes the vision of a reverse mapping from Paffins to eHornets. Such a mapping would make exploiting the formal basis for validation and verification introduced in this paper even simpler. Finally the extension from eHornets to Hornets will allow more expressive models, but has to be balanced with the formal verification restrictions.
In conclusion, the presented mapping opens up the dynamic and formal nature of eHornets for a practical system. The Paffin-system itself combines agents and workflows on a fundamental and essential level. The idea to provide agents and workflows on the same level of abstraction naturally supports the complex relation between processes and the beings/objects that execute those processes in the real world. Consequently, the full integration proposed within the approach is a powerful, yet complex and difficult to handle mechanism. Establishing a formal basis for it is an important milestone towards the Paffin integration approach becoming a validated and well grasped modelling technique.