DISTRIBUTED BUSINESS PROCESSES IN OPEN AGENT

ENVIRONMENTS

Christine Reese, Kolja Markwardt, Sven Offermann and Daniel Moldt

Department of Informatics, University of Hamburg, Germany

Keywords:

Inter-organisational Business Processes, Agents, Reference Nets, Distribution, Agent Networks.

Abstract:

In the context of multi-agent systems, a general aim is the inter-operability of agents. One problem remaining

unsolved is the control of processes between agents. The need for workﬂow technology to support business

processes on the level of agents becomes obvious. We provide concepts for distributed WFMS where the dis-

tribution is realised within the architecture. Given the formal background of Petri nets, this work is innovative

regarding the interplay of agent and workﬂow technologies.

1 INTRODUCTION

In the context of multi-agent systems, a general aim

is the interoperability of agents. The standardisa-

tion committee FIPA as well as the European project

Agentcities and its successor openNet provide stan-

dards and de-facto standards. One problem remaining

unsolved is the control of processes between agents.

FIPA interaction protocols provide general interaction

patterns that are specialised in the speciﬁc case. An-

other level of support is provided with process de-

scription languages like BPEL or OWL-S. It is desir-

able to develop process-oriented applications. There-

fore the need for workﬂow technology on an agent

level to support Business Processes becomes obvious.

Conceptually, the techniques of agents and work-

ﬂows are combined by using concepts of both for

the perception of a complex system. By this, vari-

ous characteristics of complex systems like control,

monitoring, autonomy, encapsulation and ﬂexibility

are combined systematically. We envision to use a

common WFMS-Ontology.

In this paper we present our architecture: an

agent-based system for inter-organisational Business

Processes, which is based on reference nets.

2 BUSINESS PROCESSES

Today, organisations try to analyse and model their

business activities in a process-oriented way, focus-

ing on their core Business Processes, while explor-

ing possibilities to source out activities that could

be accomplished more efﬁciently by external part-

ners (Riedl, 2003). For this purpose business process

management (BPM) tools are necessary to design,

analyse, and execute these processes.

Inter-Organisational Business Processes It is de-

sirable that each organisation can use their own

WFMS for their internal processes and link it together

with the WFMSs of the partners’ organisation to form

a large, inter-organisational system, sharing only the

parts that need to be shared. It is thus necessary to

have a hierarchical form of inter-WFMS structure,

where encapsulated, autonomous parts represent the

participating organisations.

Petri Nets for Business Processes A common way

to model Business Processes is the use of Petri nets.

This formalism offers the notion of states and activi-

ties, a solid formal foundation in the ﬁeld of concur-

rent processes as well as many tools to deﬁne, analyse

and execute the process deﬁnitions.

However, usually Petri net models focus mainly on

the process aspect of Business Processes, describing

the order in which activities are to be executed. Other

Reese C., Markwardt K., Offermann S. and Moldt D. (2006).

DISTRIBUTED BUSINESS PROCESSES IN OPEN AGENT ENVIRONMENTS.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - SAIC, pages 81-86

DOI: 10.5220/0002460900810086

 SciTePress

aspects like the deﬁnition of activities, the roles and

permissions involved and resources associated with

the business process are often ignored in these mod-

els. And so, for the actual execution of the process

in the productive context, other programs have to be

used, that offer a better integration into the business

context. This often means that instead of the actual

Petri net models derived forms are used for the execu-

tion as well as for modiﬁcations. These derived forms

cannot be formally veriﬁed, which later on might lead

to unsound processes.

This is where reference nets and the R

ENEW tool

can show their strengths

. Reference nets are a spe-

cial kind of high-level Petri nets, that allow the use

of references as tokens in the Petri net. These tokens

can be Java Objects and, more interestingly, other nets

that can be synchronised with each other. Jacob shows

in (Jacob, 2002) how reference nets can be used to

model a multi-layered workﬂow management system,

that integrates the different aspects mentioned above

into a workﬂow net.

Jacob’s plug-in for R

ENEW that we use as basis for

this architecture provides, besides the common fea-

tures of a workﬂow enactment service, roles and other

security and safety features. It is based on a persis-

tently working engine as introduced in (Jacob et al.,

2001).

Agent based BPM Agents and multi-agent systems

offer a software development paradigm, that focuses

on autonomous entities interacting with each other to

reach their goals.

A special characteristic of the applied agent frame-

work C

APA (“Concurrent Architecture for a Multi-

agent Platform”, see (Duvigneau et al., 2003)) is that

the platform is implemented as an agent itself. Such

a platform agent contains all agents. This concept is

used to develop the WFMS agents. The basic agent

in C

APA is modelled as a reference net which enables

basic agent features like sending and receiving mes-

sages and accessing a knowledge base. The behaviour

of an agent is deﬁned on the one hand by protocol

nets which usually have workﬂow-like structure and

on the other hand by a decision component net which

encapsulates the complex knowledge of an agent.

3 OPEN AGENT ENVIRONMENTS

The standards of FIPA are “intended to promote the

interoperation of heterogeneous agents and the ser-

vices that they can represent” (FIPA, 2005). In

Reference nets published in (Kummer, 2002), detailed

introduction in (Kummer, 2001). R

ENEW software, user

guide, and literature freely available at (Renew, 2005).

this standardisation process there were test-beds and

experiments to connect heterogeneous but standard-

compliant agents to networks. Since 2000 this

was coordinated within a European research project,

Agentcities, and since 2004 within openNet, its suc-

cessor. “OpenNet is dedicated to facilitating collabo-

ration between research projects developing, applying

and above all deploying Agent, Semantic Web, Web

Service Grid and similar networked application tech-

nologies in large-scale open environments such as the

public Internet” (openNet, 2005).

The network services were increasing from the ﬁrst

FIPA test network up to the openNet environment:

FIPA provided basic interaction standards, like a com-

munication language, FIPA agent management ontol-

ogy, and transport protocols; a reference model of

software agents as autonomous components commu-

nicating via messages; and speciﬁcations of basic di-

rectory services. Using these, Agentcities developed

a mechanism to provide centralised non-hierarchical

directory services for platforms, agents and services

provided by agents. The naming conventions for plat-

forms introduced by Agentcities were extended by the

successor openNet to have Internet-like hierarchical

domain names. openNet introduced a non-accessible

background platform where only top-level domains

can register to avoid the central bottleneck.

Each platform is represented within the network by

a platform service agent which is able to test other

platforms on a request. Network service agents gather

such information.

The services of Agentcities and openNet are com-

binable, since the access to network status data is not

speciﬁed separately by openNet, while the gathering

of such data is elaborated in openNet.

The aim of Scholz et al. in (Scholz et al., 2005)

is to enable the cooperation of heterogeneous agent

systems, on a methodological level: Their proposal

is to join several multi-agent systems (MASs) with

a design goal each using gateway agents that repre-

sent one MAS at a time. Interaction between these

gateway agents forms a logical MAS on top of other

MASs. The resulting system is called a Multi-MAS, a

Multi-Multi-Agent-System (called Agent.Enterprise).

Scholz et al. assume that each simple MAS is a closed

system and provide an example where a supply chain

application is realised by joining solutions for the dif-

ferent levels and systems.

This effort as well as several projects that where

hosted and supported within the Agentcities and

openNet projects aim at enabling the cooperation of

heterogeneous and autonomous components. This re-

quires syntactical and semantical standards as well

as process coordination. Syntactical aspects are ad-

dressed by FIPA-ACL, or by the more widespread al-

ternative SOAP. The problem of deﬁning adequate se-

ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING

mantics is only partly solved by ontology support, but

is not addressed here. We address the process coor-

dination by providing concepts to integrate workﬂow

technology with agent environments as openNet.

We can use the hierarchical infrastructure of open-

Net, the directories concepts provided by Agentcities.

What is needed is the control for processes. So, our

proposal is to supply openNet with an agent-based

WFMS. Special attention is given to the agent inter-

face: It should be possible to join WFMS parts of dif-

ferent providers within the network.

4 INFRASTRUCTURE

This section describes the structural elements of our

proposed system.

Relation between Workﬂows and Agents Usually,

the workﬂow itself exists as a data structure in the

WFMS. Wrapped by an agent, a workﬂow is concep-

tually only accessible via its message interface (we

do not discuss general security problems in the agent

area here) and thus a certain level of autonomy and

mobility is enabled within the architecture.

Workﬂows are represented by agents. In the usual

case of a “local” workﬂow, where “local” means in-

side a kind of closed system, this WF agent does not

hold much autonomy. It just provides access to its

process deﬁnition. In a more complicated case, the

WF agent interacts with the Workﬂow Engine.

Agent Types Figure 1 shows all agent types that

belong to the WFMS. The runtime environment R

E-

NEW contains diverse plug-ins, including the basic

reference net editor, an AUML editor, a workﬂow

plug-in and the agent platform C

APA.CAPA con-

tains the Agent Management System (AMS), the Di-

rectory Facilitator (DF) as speciﬁed by the FIPA and

the C

APA platform agent. Plug-ins for CAPA may

add further agents as the Web Service gateway agent

(shown in Figure 1 near “other agents”). The WFMS

platform agent runs within C

APA and is provided by

a WFMS plug-in. It contains the Client Interaction

Agent, Administration Agent, Workﬂow Deﬁnition

Agent, Monitoring Agent, and Workﬂow Enactment

Service Platform Agent (WFES). These have a gate-

way functionality. They form the interface of the

WFMS, as described by the Workﬂow Management

Coalition (WfMC, 2005). They separate and connect

the agent WFMS with the basic local WFMS func-

tionality provided by the Workﬂow plug-in for R

E-

NEW and with any application domain components

not shown in the ﬁgure. The Workﬂow and Workﬂow

Fragment Agents (WF and WFF) as well as Workﬂow

Engine Platform Agents (WFE) and Task Agents are

dynamically instantiated during runtime as described

in Section 5. The agents Remote Communication and

Distribution Agent are explained there, also.

In the course of workﬂow execution different

pieces of information are collected, partly as control

data for the workﬂow, partly as case data for use in the

workﬂow tasks. This data is in the case of an unfrag-

mented workﬂow stored within the knowledge base

of the workﬂow agent. In the case of a fragmented

workﬂow, data is stored throughout all the workﬂow

fragment agents and the data needs to be shared be-

tween the fragments on synchronisation points.

reference net

editor

...further tools

integrated

within Renew

runtime environment Renew

gateway

other

agents

AMS DF

platform

agent

agent platform CAPA

definition

client

interaction

WFE 1

WFF b

(travelling)

WFES platform agent

WFMS platform agent

WFE 2

WFF a

WF 1

remote

commun.

task

agent

distribution

agent

monitoring

agent

admin

agent

workflow

management

tool, including:

tool for

workflow

definition

other

WFMS parts

AUML

diagramm tool

Figure 1: Components within each platform.

Workﬂow Management for Open Agent Networks

Within open agent networks, the described agent

types could be distributed using network services like

up-to-date directory services. Because the agent types

are interfaces and because for the data format for

these interfaces various agreed and spread standards

exist, parts of this WFMS can be distributed arbitrar-

ily across the network. In this way, the different func-

tions of a WFMS like deﬁnition of new workﬂows or

monitoring can be implemented externally and run at

the ofﬁce they belong to. If one of the administrators

visits another company, he can log into the monitor-

ing system by searching within the current agent net-

DISTRIBUTED BUSINESS PROCESSES IN OPEN AGENT ENVIRONMENTS

work for an agent enabled monitoring service. This

means, he searches for a monitoring service that im-

plements the monitoring interface and either is able to

communicate these messages via ACL or a Web Ser-

vice gateway is available.

Within an open agent network, several providers of

the service “workﬂow administration” can be regis-

tered as well as several providers for “workﬂow mon-

itoring” or “workﬂow deﬁnition” etc. These take as

argument for their services contact information to the

desired WFMS together with the data content, which

they either help to create (by providing e.g. a GUI to

draw a workﬂow deﬁnition) or which they take from a

given source. These service providers contact the ap-

propriate interface agents within the desired WFMS

where the actual effect is produced, as described in

Section 5.

This is the “centralised WFES” view on our pro-

posed architecture, which is a translation and spe-

cialisation of the WfMC model to agent communica-

tion regarding interfaces number 1, 2, 3, and 5. Now

please regard Figure 2. This shows another view on

the system. Each of the coloured boxes represents

one agent within an agent network, as just described.

Some of these (i.e. the WF Engines) form a virtual

WFES, while the Workﬂow Fragment Agents form a

virtual WF Agent. So the objective is to implement an

agent using multiple agents within the network. The

virtual WFES acts as a distributed environment for

WFE agents which acts in whole like a central ser-

vice.

The WF agent sends a representative to be cre-

ated within the WFE platform and through this trusted

channel all communication that is necessary to solve

that workﬂow is routed. To save the autonomy of

the WF agent, it remains the possibility to use other

communication channels than through the WFE agent

(this is shown in Figure 2).

5 OPERATIONAL SEQUENCES

In the last chapter the structural elements of the agent-

based WFMS were described. Now we are going to

discuss in more detail the interactions between the

different agents that form the system.

In the following, typical events are described that

occur in the envisioned system.

These interactions do not refer to general services

within open agent networks like directory search, be-

cause this is not developed but taken for encapsulated

functionality provided by the agent network.

Explanatory note Each interaction with a user is

handled by the Client Interaction Agent. It provides

the users work list as well as functionality according

to the access rights of the user. Choosing the func-

tion “Deﬁne new Workﬂow” will cause the process

described in the next subsection to happen etc.

Each of the following subsections represents one

process within the WFMS which is triggered (in most

cases) by the Client Interaction agent and executed

until the system is “quiet” again and waiting for the

next event.

Each time the Client Interaction agent causes an-

other agent to invoke an application according to the

rights of the user, the user communicates logically di-

rectly with that application or agent. Practically this

communication is projected on a tunnelled and thus

trusted and secure communication (or the other way

round: the mediated communication can be projected

to direct communication). Please compare with Fig-

ure 2.

The following abbreviations are used:

CLI Client Interaction Agent

DEF Workﬂow Deﬁnition Agent

ADA Administration Agent

WFES Workﬂow Enactment Service Agent

DIS Distribution Agent

WFE Workﬂow Engine Agent

WF Workﬂow Agent

WFF Workﬂow Fragment Agent

TASK Task Agent

REM Remote Agent

MON Monitoring Agent

User or Role Deﬁnition CLI calls ADA (“I would

like to introduce a new User/Role”). ADA checks his

own knowledge base to verify that CLI has the rights

to do so. If successful, ADA invokes an application

with which CLI can specify the desired data, which

ADA then stores in its knowledge base.

Workﬂow Deﬁnition CLI calls DEF (“I would like

to deﬁne a new WF”). DEF asks ADA if CLI has

the rights to insert a new WF into the system. If yes,

DEF starts an application that provides ﬁle upload (for

previously deﬁned process description) as well as the

possibility to launch the R

ENEW WF deﬁnition tool.

DEF then stores the process deﬁnition.

Workﬂow Execution

1. Instantiation

CLI calls WFES (“I would like to instantiate a

WF”). WFES asks ADA if CLI has the rights to

instantiate a new WF. If yes, WFES asks DEF for

ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING

EPPO Workflow descriptions agent.

Holds all WFs of EPPO that are used

within this virtual WFMS. Also the example.

EPPO Client Agent.

Controls and Triggers Worfklow

execution by pushing, pulling, chosing,

rejecting or completing tasks.

EPPO Application Agent.

Provides Funcionality / Services that

are application specific.

EPPO WF Engine

IPM Workflow descriptions agent.

Holds all WFs of IPM that are used

within this virtual WFMS. Also the example.

IPM Client Agent.

Controls and Triggers Worfklow

execution by pushing, pulling, chosing,

rejecting or completing tasks.

IPB Application Agent.

Provides Funcionality / Services that

are application specific.

IPM WF Engine

HL Workflow descriptions agent.

Holds all WFs of HL that are used

within this virtual WFMS. Also the example.

HL Admin Agent.

Provides information

on users rights and

roles.

HL Client Agent.

Controls and Triggers Workflow

execution by pushing, pulling, choosing,

rejecting or completing tasks.

HL Application Agent.

Provides Funcionality / Services that

are application specific.

HL WF Engine

virtual WFES

EPPO

IPM

virtual WF agent

virtual WF agent - Agent

representative

logical communication

Imagine the fantasy names EPPO,

IPM and HL to be short names for

internationally operating concerns

that want to cooperate within some

joint project.

Figure 2: Virtual WFES.

a summary of available process deﬁnitions. These

are forwarded to CLI. CLI chooses the desired

WF. WFES calls DIS to create WFE, WF and WFF

agents.

Any changes to available Tasks that arise from this

action are detected by step 2 in Section “Workﬂow

Execution”.

2. For each process step

WFE, WF and WFF agents interact with each other

and with possibly activated TASK agents, with the

result of further TASK agents being activated ac-

cording to the workﬂow (that means it is then in

the status of a work item). This may require re-

mote communication due to distributed workﬂows,

so REM is used as a gateway to other WFE, WF,

WFF agents. TASK calls appropriate applications

to solve the task. This may be an appropriate CLI to

tell about available tasks, or some other application

as speciﬁed.

3. End of a workﬂow

If the workﬂow termination criteria are reached,

WFE or WF contacts WFES which terminates

WFE and WF.

User Choosing a Task CLI calls the TASK (“I

would like to handle that task”). TASK asks ADA

if the CLI has the rights to handle the task. If yes,

TASK gets into the state of an activity and tries to pro-

vide information to complete the task by contacting

the WFES. TASK now either invokes the appropri-

ate application involving user interaction, or provides

CLI with information to invoke an application itself.

Any changes to available Tasks that arise from this

action are detected by step 2 in “Workﬂow Instantia-

tion”.

Terminating a Task CLI or the invoked application

calls TASK (“I am done with my work”, or “I cannot

do the work”). TASK asks ADA if CLI has the rights

to terminate the task. If yes, TASK takes termination

data (such as state or application data) from CLI and

forwards these to the appropriate WF, WFF, or WFE

agent.

Any changes to available Tasks that arise from this

action are detected by step 2 in Section “Workﬂow

Execution”.

Monitoring and Inﬂuencing Running Workﬂows

CLI calls MON (“I would like to view the status of

a workﬂow”, or “I would like to manually change the

state of a workﬂow”). MON asks ADA if CLI has

sufﬁcient rights to do that. If yes, MON gathers the

information or requests the change by communicating

to the appropriate WFE, WF, or TASK agent.

Any changes to available Tasks that arise from this

action are detected by step 2 in Section “Workﬂow

Execution”.

DISTRIBUTED BUSINESS PROCESSES IN OPEN AGENT ENVIRONMENTS

6 CONCLUSION

This paper contributes to the process-oriented appli-

cation development with workﬂow technology on an

abstract level. We provide concepts for modelling and

implementation of distributed WFMS where the dis-

tribution is realised within the architecture. The tech-

nologies used and parts of the architecture are based

on existing work. This paper extends the work in

(Reese et al., 2005) in such a way that we embed our

distributed WFMS in open agent environments. It is

innovative regarding the interplay of technologies us-

ing the formal method of Petri nets.

Realisation The agent framework C

APA has been

used to develop complex, Petri net based agent sys-

tems for several years (e.g. (Offermann et al., 2005)).

This framework is supported by an efﬁcient develop-

ment environment for Petri nets (Renew, 2005), which

provides plug-ins for code generation, monitoring,

logging, and debugging. The Petri net-based work-

ﬂow engine from Jacob (Jacob, 2002) is able to con-

tinuously update data on available activities to client

PDAs. It was extended here for distributed systems

and implemented as a prototype in a student project.

The described system is meant to be used in open

agent environments, with special attention to auton-

omy, encapsulation, and ﬂexibility as found in such

systems.

Outlook A general aim of our work is the devel-

opment of a collaborative integrated development en-

vironment (C

IDE) for which a prototype exists. The

next step is an evaluation of the prototype within

the openNet context, running a distributed change-

request-management application. To embed this

within the open agent environment community, a

FIPA-compliant ACL speciﬁcation of the WfMC in-

terface for WFMSs has to be provided.

REFERENCES

Duvigneau, M., Moldt, D., and R

olke, H. (2003). Con-

current architecture for a multi-agent platform. In

Giunchiglia, F., Odell, J., and Weiß, G., editors, AOSE

2002, Revised Papers and Invited Contributions, vol-

ume 2585 of LNCS, Berlin. Springer.

FIPA (2005). FIPA: Foundation for Intelligent Physical

Agents. Homepage. http://www.ﬁpa.org.

Jacob, T. (2002). Implementierung einer sicheren und rol-

lenbasierten Workﬂowmanagement-Komponente f

ein Petrinetzwerkzeug. Diplomarbeit, University of

Hamburg, Department of Informatics.

Jacob, T., Kummer, O., and Moldt, D. (2001). Persistent

Petri Net Execution. Petri Net Newsletter, 61:18–26.

Kummer, O. (2001). Introduction to Petri nets and reference

nets. Sozionik Aktuell, 1:1–9. ISSN 1617-2477.

Kummer, O. (2002). Referenznetze. Logos, Berlin.

Loock, H. (2005). Umwandlung von Petrinetzen in OWL-

S Ontologien. Diplomarbeit, Universit

at Hamburg,

Fachbereich Informatik.

Moldt, D., Offermann, S., and Ortmann, J. (2005). A

Petri Net-Based Architecture for Web Services. In

Cavedon, L., Kowalczyk, R., Maamar, Z., Martin, D.,

and M

uller, I., editors, Workshop on Service-Oriented

Computing and Agent-Based Engineering, SOCABE

2005, Utrecht, Netherland, July 26, 2005. Proceed-

ings, pages 33–40.

Moldt, D. and Ortmann, J. (2004). DaGen: A Tool for Auto-

matic Translation from DAML-S to High-Level Petri

Nets. In Wermelinger, M. and Margaria-Steffen, T.,

editors, Fundamental Approaches to Software Engi-

neering: FASE 2004. Held as Part of ETAPS 2004,

Barcelona, Spain, 2004. Proceedings, volume 2984,

pages 209–213, Berlin. Springer.

Offermann, S., Ortmann, J., and Reese, C. (2005).

Agent Based Settler Game. Available at: http://x-

opennet.org/netdemo/Demos2005/

aamas2005

netdemo settler.pdf. Part of NETDEMO.

openNet (2005). openNet project. http://www.x-

opennet.org/.

Ortmann, J. (2003). Prozeß-Ontologien in Multiagentensys-

temen – Eine prototypische Umsetzung von DAML-S

Beschreibungen in Petrinetzen und ihre Verwendung

in Mulan. Diplomarbeit, University of Hamburg, De-

partment of Informatics.

Reese, C., Ortmann, J., Moldt, D., Offermann, S.,

Lehmann, K., and Carl, T. (2005). Architecture for

distributed agent-based workﬂows. In Henderson-

Sellers, B. and Winikoff, M., editors, Proceedings

of the Seventh International Bi-Conference Workshop

on Agent-Oriented Information Systems (AOIS-2005),

Utrecht, Netherlands, as part of AAMAS 2005 (Au-

tonomous Agents and Multi Agent Systems), July

2005, pages 42–49.

Renew (2005). R

ENEW – the reference net workshop home-

page. URL http://www.renew.de/.

Riedl, R. (2003). Begrifﬂiche Grundlagen des Business

Process Outsourcing. Information Management &

Consulting, 18:6–10.

Scholz, T., Krempels, K.-H., Nimis, J., Schiemann, B.,

Woelk, P.-O., Braubach, L., and Pokahr, A. (2005).

www.AgentEnterprise.net – a MMAS-based web-

portal for supply chains managed by ASCML. In

openNet Networked Agents Demonstration for AA-

MAS 2005.

WfMC (2005). Workﬂow reference model. URL

http://www.wfmc.org/standards/model.htm.

ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING