RULE-BASED ORCHESTRATION OF AGENT-SOCIETIES

Karl-Heinz Krempels and Christoph Terwelp

Databases and Information Systems, RWTH Aachen University, Aachen, Germany

Keywords:

Agent societies, Orchestration, Rule-based system.

Abstract:

Composing heterogeneous agent-based applications is mostly a complex task due to speciﬁc requirements of

agents and existing dependencies among agents and societies. Resolving such dependency-networks is subject

of agent and agent-society deployment and monitoring. The orchestration task covers automatic deployment,

conﬁguration, monitoring and reconﬁguration of agent-based applications.

Existing approaches provide static mapping of dependencies and constraints of agent and agent-society de-

scriptions. This leads to a high modiﬁcation effort, which requires very specialised developer’s know-how

and can be very complex as well as error-prone, not only when distributing agents over several hosts, but also

when launching agents locally.

In this paper a reference model of a deployment infrastructure, a description model for agents and agent-so-

cieties and a knowledge-based mechanism for the orchestration of agent and agent-societies are presented with

the aim to overcome the disadvantages of the considered existing approaches.

1 INTRODUCTION

Multiagent systems (MAS) are composed of au-

tonomous, interacting, more or less intelligent enti-

ties. The agent metaphor has provento be a promising

choice for building complex and adaptive software

applications, as it addresses key issues for making

complexity manageable at conceptual level (Jennings,

2001). Furthermore, agent technology can be seen as

a natural successor of the object-oriented paradigm

that enriches the world of passive objects with the

notion of autonomous actors. Even though agent ap-

plications are developed in various domains, most of

them are specialised solutions that are deployed in at

most one setting. This is caused by the fact that com-

position and deployment of agent-based applications

is not considered by agent-oriented software engi-

neering methods and therefore neither by multiagent

system development frameworks. In consequence, a

methodology is chosen independently for each appli-

cation without consideration of the possibility to inte-

grate the development process or making the effort to

derive a commonly accepted methodology.

For object-oriented distributed systems the de-

ployment process is speciﬁed in systematical guide-

lines describing mechanisms for all activities con-

cerned herewith. These guidelines ensure that a prop-

erly developed distributed application can be pack-

aged into a reusable, maintainable, and conﬁgurable

piece of software. However, multiagent systems com-

posed of autonomous proactively (inter-)acting enti-

ties differ considerably from distributed systems and

the issue of appropriate deployment techniques for

MAS has not yet been researched further.

The aim of this paper is to specify agent-based ap-

plications at a high-level using dependencies to de-

clare which recommended properties have to be ful-

ﬁlled for the application to start and run properly. In a

ﬁrst step towards this high-level deployment for MAS

a referencemodel for launching, conﬁguration, recon-

ﬁguration and monitoring of distributed multiagent

applications is proposed which speciﬁes applications

by declaring which and how many agent or agent-

society instances shall be instantiated at a time and in

which order. A generic meta-model for the speciﬁca-

tion of agent-based applications is described as part of

the reference model. It consists of two layers one for

the deﬁnition of agent types and one for the composi-

tion of agent and agent-society instances belonging to

a certain agent-based application scenario.

After an overview of the state of the art in sec-

tion 2 and a description of the identiﬁed requirements

in section 3, the model is mapped to a knowledge-

base providing the basis for the development of the

orchestration capability of agents and agent-based ap-

plication tools in section 4. In section 5 the approach

and some conclusion for future work are summarized.

367

Krempels K. and Terwelp C..

RULE-BASED ORCHESTRATION OF AGENT-SOCIETIES.

DOI: 10.5220/0003113103670371

In Proceedings of the 3rd International Conference on Agents and Artiﬁcial Intelligence (ICAART-2011), pages 367-371

ISBN: 978-989-8425-41-6

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

2 BACKGROUND

The process of deployment is well speciﬁed for dis-

tributed systems and consists of many phases, identi-

ﬁed by the

Object Management Group

(OMG) (Ob-

ject Management Group, 2003).

For agent-based applications, this process is more

dynamic and ﬂexible, because the application consti-

tuting elements are autonomous agents instead of pas-

sive components. Launching multiagent-based appli-

cations differs from starting a distributed component-

based application. Component-based applications are

hierarchical structured and are usually launched using

a single starting point, that creates all needed subcom-

ponents. In contrast, agent-based applications con-

sist of a bundle of autonomous actors that are self-

dependent after launching. A minimum requirement

for the description of agent-based applications at in-

stance level is the speciﬁcation of agent instances,

of agent-society instances and dependencies among

them.

2.1 Terminology

Before going into details some terms used in this pa-

per are deﬁned. Conﬁgurations can be deﬁned at

two levels: Component level and application level

(Castaldi, 2004). For agent-based systems, the agent

level and the application level can be distinguished.

Considering a single agent a distinction can be made

between the static implementation and the running in-

stance. When emphasizing this distinction the former

is referred to as

agent type

and the latter as

agent in-

stance

. This distinction can also be made on the appli-

cation level. The term

society type

refers to the static

properties of a multiagent application. A society type

is a composition of agent types, supplemented with

some (e.g. interaction) constraints. A

society instance

refers to the instantiation of a society, and is com-

posed of single agent instances and concrete depen-

dencies between those instances. The model is recur-

sively deﬁned to allow societies to be part of larger

societies on type and instance level.

2.2 Existing Approaches

In (Ricordel and Demazeau, 2000) several agent de-

velopment frameworks are compared with respect

to their capability to support the phases: analysis,

design, implementation and deployment of software

development processes. It shows that only a few

frameworks are addressing the issue of deployment.

ZEUS

(Nwana et al., 1999),

AgentFactory

(Col-

lier, 2001),

Agent Builder

(Acronymics, Inc, 2004)

and the

Agent-Society Conﬁguration Manager and

Launcher (ASCML)

(Bade et al., 2007; Braubach

et al., 2005; Lilienthal and Widyadharma, 2006) are

positive exceptions. Agent Academy and AgentFac-

tory framework allow to specify agent applications.

They offer support to parametrize agent instances

from deﬁned agent types. When launching the appli-

cation, all agent instances are started at once. ZEUS

and AgentFactory use human readable starting scripts

that contain commands for starting agents. All these

approaches suffer from lack of concepts to describe

agent-societies and dependencies between agents and

societies. The dependencies have to be resolved by

the administrator of an agent-based application before

the application is launched. The ASCML deﬁnes con-

cepts for agent types, agent instances, society types

and society instances. Also the deﬁnition of depen-

dencies between these entities is possible. But it can

only handle six generic dependency types and appli-

cation based extensions can only be achieved by mod-

iﬁcation of the ASCML.

Tools like

editION

(dos Santos Ferreira J´unior

et al., 2006), a calligraphic interface for managing

agents for the ION agent framework, concentrate on

supporting the administrator in designing agent-based

applications and does not allow reconﬁguration at

runtime.

3 REQUIREMENTS

From the presented state of the art in deploying mul-

tiagent applications a lack of concepts, standards and

tools can be identiﬁed, in particular for

launching

and

dynamic

reconﬁguration

of agent-based applications.

In the following desirable features to achieve dy-

namic reconﬁguration and manageable launching are

introduced.

A management tool for the deployment of agent-

based applications must provide support for the intro-

duced models for agents, societies and dependencies

descriptions. Furthermore, it must provide basic ser-

vices to edit and modify these entities as well as start-

ing and stopping services for agents and agent soci-

eties. Additionally, these services must be available

remotely to enable the launching of distributed appli-

cations. Therefore, issues of security accounting and

write management have to be considered (Sloman,

1995). A launch-process management is required by

the basic services to ensure that the right agents and

agent-societies are launched at the speciﬁed nodes at

the correct time. This can be achieved by deﬁning

dependencies among agent instances of a society and

solving these dependencies at launch time to deter-

ICAART 2011 - 3rd International Conference on Agents and Artificial Intelligence

368

mine the right launch time and order for every agent.

Monitoring and reconﬁguration services have to

be offered by a management agent of agent-based ap-

plications. In this way the management agent is en-

abled to control the whole application. Once an ap-

plication has been started its administrator has to be

informed about its state, resulting from the lifecycles

of its entities.

A reconﬁguration capability is necessary to en-

able the management agent to adapt the application

according to changing demands. E.g. to start more

agents in case of unused computing power. By de-

tecting failures and relaunching agents, as well as de-

tecting agents which are not used by an application

anymore, the monitoring service can increase the reli-

ability of agent-based applications and save comput-

ing power.

To describe and launch agent-based application

there is a need to adapt the agent, the society and

the dependency concept. In the ASCML approach six

generic dependencies for application independent use

have been introduced to model speciﬁc dependencies

for a given application.

For durable applications concepts for extensibility

at design- and runtime must be provided. Otherwise a

redesign of the application is necessary to change its

conﬁguration.

4 APPROACH

This approach for distributed deployment of multia-

gent applications is based on the idea of specialised

service agents that are responsible for launching and

managing agents and societies on their own plat-

form. These service agents are called IASCML (Intel-

ligent Agent-Society Conﬁguration Management and

Launcher).

4.1 Deployment Reference Model

The deployment reference model used here is sim-

ilar to the model of the ASCML agent (Braubach

et al., 2005) and assumes a running IASCML agent on

each platform. Each IASCML agent controls an agent

repository containing archives with agent and agent-

society applications. The archives contain descrip-

tion ﬁles for each launchable agent included. These

description ﬁles simplify the launching and conﬁgu-

ration task as they enable developers to map special

agent conﬁgurationparameters to well deﬁned param-

eters of the agent description model. A welcome ef-

fect of this is that we hide special agent conﬁgurations

from the user of the agent. This also ensures that an

agent archive can be used in the same way on all the

agent platforms running an IASCML agent.

Agent-societies can be handled similarly since

they are build on top of well deﬁned agent descrip-

tions in this model.

4.2 XML-Model-Description

A uniform description for agents and agent-societies

is ensured by concepts based on the ASCML XML-

schema (Braubach et al., 2005). The concept

states/assumes that agent description ﬁles end with

the sufﬁx

*.agent.xml

and agent-society description

ﬁles with

*.society.xml

. This enables the IASCML

agent to identify agent and agent-society descriptions

in all the archives from its repository.

Parameter

Parameterset

Agent

Parameters

Servicedescriptions

Agentdescriptions

value

constraint

value

constraint

Figure 1: XML agent description model.

Figure 1 depicts the structure of an agent type

speciﬁcation. The root agent tag captures important

properties of an agent such as the agent type, the im-

plementation class, and the platform type. Within

the

servicedescriptions

- and

agentdescriptions

-tags

FIPA-compliant descriptions for the agent itself and

the services offered by the agent can be declared.

The

parameter

-tag encloses single-valued parameters

and multi-valued parameter sets that are passed as

key=value

-arguments to the main class of the agent

at creation time. Parameters speciﬁed by the agent

type can be declared mandatory or optional. Parame-

ter values may be provided as default settings. All pa-

rameters speciﬁed for an agent type are inherited by

corresponding agent instances. The agent instances

have to provide parameter values for all mandatory

parameters for which the agent type provides no val-

ues. Predeﬁned values of agent type can also be over-

written with new values.

Besides the agent types meta-model there is also a

meta-model for society types deﬁned.

Figure 2 depicts the XML root-element of a soci-

ety type followed by a set of child tags. The

imports

agenttypes

- and

societytypes

-tags specify lists of

referenced elements. The

societyinstances

-tag is the

only mandatory tag. Within this tag one or more so-

ciety instances representing different application set-

tings can be listed.

RULE-BASED ORCHESTRATION OF AGENT-SOCIETIES

369

society

imports

import

agenttypes

agenttype

societytypes

societyinstances

societyinstance

Figure 2: XML society description model.

The elements constituting a society instance are

shown in Figure 3. A set of agent instances which

have to be created on the local agent platform on start

of the society instance can be speciﬁed. Every agent

instance can optionally be provided with parameter

values. In addition to that a set of agent platform

dependent tool options can be speciﬁed. These tool

options are used to start special tool agents (e.g. snif-

fer or logger) at once with the agent instances and to

agent.

societyinstance

agentinstances

agentinstance

dependencies

parameterset

tooloption

parameter

societyinstancerefs

agentinstanceref

dependencies

launcher

address

dependencies

invariant

functional

Figure 3: XML society instance description model.

Besides the agent instances a society instance can

contain an arbitrary number of subsocieties which

again can contain further subsocieties. This allows a

recursive deﬁnition of applications and facilitates the

creation of distributed multiagent applications. Each

referenced subsociety instance refers to a concrete so-

ciety instance, which itself belongs to a declared so-

ciety speciﬁcation. For the purpose of starting a re-

mote society, a so-called launcher identiﬁer can be de-

clared. This identiﬁer designates the remote IASCML

agent responsible for starting the corresponding re-

mote society instance. At last a society instance can

be declared when to be functional by specifying a set

of dependencies and invariants that have to be ful-

ﬁlled. The IASCML supervises these dependencies

and invariants at runtime and for dependencies being

marked as active it engages autonomously in restart-

ing the non-functional parts.

The last focus is on the meta-model for dependen-

cies (Braubach et al., 2005). As shown in the society

instance scheme above, dependencies can be deﬁned

for agent instances, society instances, and to describe

the functional state. Figure 4 depicts the different

dependencies

agenttypedependency

agentinstancedependency

provider

servicedependency

servicedescription

provider

address

societyinstancedependency

provider

societytypedependency

delaydependency

Figure 4: XML dependency description model.

types of dependencies. An agent type dependencycan

e.g. be used to wait for an arbitrary number of agents

of a speciﬁed type to be running, while an agent in-

stance dependency exactly refers to one designated

agent, identiﬁed by its unique agent id. Both kinds

of dependencies also exist for the society element.

4.3 Knowledge-based Model

Description Processing

Processing the agent and society descriptions by an

ASCML agent as proposed in (Braubach et al., 2005)

suffers from one main disadvantage, the processing

of static description modes. This restricts a developer

to specifying the conﬁguration of an agent or agent-

society exclusively at design time.

To overcome this disadvantage a knowledge-

based processing of agent and society descriptions is

proposed in this approach. This provides the pos-

sibility to introduce additional dependency types for

agents at runtime, and to deﬁne them at a ﬁner granu-

larity. E.g., to use a description property of an agent,

a service description property or even a boolean ex-

pression on any of the above as a dependency target.

Therefore, a rule-based engine is used providing a

knowledge base and a declarative programming lan-

guage operating on it. For a rule-based deployment

and management of agents and agent societies a map-

ping of the introduced XML-model descriptions to a

knowledge-based representation is necessary, captur-

ing the concepts described above.

To orchestrate a society based on its description

model from the knowledge base all the dependencies

are mapped to rules. Additionally rules are deﬁned

for each society to control its lifecycle.

Dependencies for remote agents or subsocieties

are mapped to special rules producing an interaction

among IASCML agents (when they are activated) re-

questing the launch of an agent or subsociety.

ICAART 2011 - 3rd International Conference on Agents and Artificial Intelligence

370

5 CONCLUSIONS & OUTLOOK

In this paper an extension of the ASCML approach

from (Bade et al., 2007; Braubach et al., 2005) is dis-

cussed. The extension provides runtime adaptivity for

agent-society structures and more accurate modelling

possibilities.

The IASCML approachwas implemented with the

help of the rule-based system

Jamocha

that provides

the required modelling and processing capabilities for

knowledge-based models. The approach was tested

in a lab showing that the orchestration of agents and

agent-societies is improved in comparison to the AS-

CML approach.

Feedback from ASCML users regarding the us-

ability of the ASCML’s GUI, in particular the creation

and modiﬁcation process of agent and agent-society

description ﬁles has been received. This motivates

the redesign of the ASCML GUI and its functionality.

The intention is to movethe creation and modiﬁcation

task of agent and agent-society descriptions to a new

developed plugin for Prot´eg´e (Gennari et al., 2002).

The usability of the new IASCML GUI needs to re-

worked to provide for a convenient way of handling

distributed agent-based applications.

The speciﬁcation of agent-platforms is not sup-

ported by the IASCML yet. This is would very useful

to deﬁne dependencies between agents and platforms

and to extend the ASCML agent with load balancing

capabilities among network nodes. Thus it will sub-

ject of further research and development.

To provide the IASCML agent to the agent

community we will contribute the code to the

JADE (JADE, 2010) developer team. Furthermore,

we are going to contribute the agent and agent-society

description models to FIPA with the aim to include it

in a FIPA speciﬁcation document.

Our longterm vision is to provide an orchestration

tool for agent-based applications and to simplify the

deployment and orchestration process of agents and

agent-societies. This will help agent-based applica-

tions to become (re)usable to a broad community.

REFERENCES

Acronymics, Inc (2004). Agentbuilder - user guide v1.4.

http://www.agentbuilder.com/.

Bade, D., Lilienthal, S., Krempels, K.-H., and Widyad-

harma, A. S. M. (2007). Agent-society conﬁgura-

tion manager and launcher. In Bellifemine, F., Caire,

G., and Greenwood, D., editors, Developing Multi-

Agent Systems with JADE, pages 207–223, West Sus-

sex, England. John Wiley & Sons, Ltd.

Braubach, L., Pokahr, A., Bade, D., Krempels, K.-H., and

Lamersdorf, W. (2005). Deployment of distributed

multi-agent systems. In Marie-Pierre Gleizes, An-

drea Omicini, F. Z., editor, ESAW 2005, pages 261–

276. Springer-Verlag GmbH.

Castaldi, M. (2004). Dynamic Reconﬁguration of Compo-

nent Based Applications. PhD thesis, Department of

Computer Science, University of L’Aquila, Italy.

Collier, R. W. (2001). Agent Factory: A Framework for

the Engineering of Agent-Oriented Applications. PhD

thesis, University College Dublin.

dos Santos Ferreira J´unior, A. M., Vala, M., Pereira, J.

A. M., Jorge, J. A. P., and Paiva, A. (2006). A cal-

ligraphic interface for managing agents. WSCG 2006,

pages 25–31.

Gennari, J. H., Musen, M. A., Fergerson, R. W., Grosso,

W. E., Crubzy, M., Eriksson, H., Noy, N. F., and Tu,

S. W. (2002). The Evolution of Prot´eg´e: An Environ-

ment for Knowledge-Based Systems Development.

JADE (2010). The JADE Project Home Page.

http://jade.tilab.com/.

Jennings, N. R. (2001). An agent-based approach for

building complex software systems. Commun. ACM,

44(4):35–41.

Lilienthal, S. and Widyadharma, S. (2006). Agent society

conﬁguration manager and launcher. In Informatik-

tage 2006, pages 1–4.

Nwana, H. S., Ndumu, D. T., Lee, L. C., and Collis, J. C.

(1999). Zeus: a toolkit and approach for building

distributed multi-agent systems. In AGENTS ’99:

Proceedings of the third annual conference on Au-

tonomous Agents, pages 360–361, New York, NY,

USA. ACM Press.

Object Management Group (2003). Deployment and con-

ﬁguration of component-based distributed applica-

tions speciﬁcation.

Ricordel, P.-M. and Demazeau, Y. (2000). From analysis

to deployment: A multi-agent platform survey. In

ESAW 2000, pages 93–105, London, UK. Springer-

Verlag GmbH.

Sloman, M. (1995). Management issues for distributed ser-

vices. In Proc. of the 2nd Int. Workshop on Services in

Distributed and Networked Environments, pages 52–

55. IEEE.

RULE-BASED ORCHESTRATION OF AGENT-SOCIETIES

371