HYBRID AGENT & COMPONENT-BASED MANAGEMENT OF

BACKCHANNELS

M. Dragone, G. M. P. O’Hare

CLARITY Centre for Sensor Web Techologies, University College Dublin, Belﬁeld, Dublin 4, Ireland

D. Lillis, R. W. Collier

School of Computer Science and Informatics, University College Dublin, Belﬁeld, Dublin 4, Ireland

Keywords:

Agent-oriented software engineering, Component based software engineering, Multi-agent systems.

Abstract:

This paper describes the use of the SoSAA software framework to implement the hybrid management of

communication channels (backchannels) across a distributed software system. SoSAA is a new integrated

architectural solution enabling context-aware, open and adaptive software while preserving system modu-

larity and promoting the re-use of existing component-based and agent-oriented frameworks and associated

methodologies. In particular, we show how SoSAA can be used to orchestrate the adoption of network adapter

components to bind functional components that are distributed across different component contexts. Both the

performance of the different computational nodes involved and the efﬁciencies and faults in the underlying

transport layers are taken into account when deciding which transport mechanisms to use.

1 INTRODUCTION

Agent-Oriented Software Engineering (AOSE) is

viewed as a general-purpose paradigm advocating the

engineering of complex distributed software applica-

tions as Multi Agent Systems (MASs), i.e. loosely-

coupled, autonomous, situated and social agents. For

example, agents can be instrumental in confronting

the high degree of variability and dynamicity in mod-

ern pervasive computing applications.

The idea that MAS features, such as goal-based

reasoning, standardized agent communication lan-

guages (ACL) and associated protocols, can support

ﬂexible and adaptive management of system distribu-

tion over multiple and potentially heterogeneous com-

putational nodes, was ﬁrst proposed for RETSINA

(Sycara et al., 2003), whose hybrid communication

style provides ACL-level, implementation-agnostic

speciﬁcations of the coordination activities necessary

to orchestrate secondary (non-ACL) communication

channels (backchannels).

To aid the development of systems that address

context-aware, open and adaptive software while pre-

serving system modularity and promoting the re-use

of existing frameworks and methodologies, we have

proposed the Socially Situated Agent Architecture

(SoSAA) (Dragone, 2007; Dragone et al., 2009).

SoSAA builds on both Component Based Soft-

ware Engineering (CBSE) and AOSE to provide a

complete construction process with its associated

software framework. The key focus is on the inter-

action between the component and agent layers of

the framework. In this paper we brieﬂy summarise

the most important characteristics of SoSAA and de-

scribe its application to ground RETSINA-style spec-

iﬁcations by providing a set of concrete operators

and by deﬁning a simple but extendable service for

backchannel management.

2 AGENT-BASED

BACKCHANNEL

MANAGEMENT

The ability to combine different communication

mechanisms is an important feature requirement in

order to support system’s adaptation in modern dis-

tributed and heterogeneous software systems. Often,

the differences between the type of data exchanged

within a single application (e.g. in terms of con-

tent, rates and bandwidth requirements) cannot be

153

Dragone M., M. P. O’Hare G., Lillis D. and W. Collier R. (2009).

HYBRID AGENT & COMPONENT-BASED MANAGEMENT OF BACKCHANNELS.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 153-158

DOI: 10.5220/0002259901530158

 SciTePress

handled by a single toolkit or communication mech-

anism. For example, one system may need to com-

bine CORBA communication mechanisms with mid-

dleware that speciﬁcally addresses the distribution of

media data (e.g. video/sound), or combine data dis-

covery mechanisms, e.g. based upon data dissemina-

tion techniques such as multicast, with point-to-point

agent communication systems. All these communi-

cation mechanisms provide dedicated and optimum

solutions to speciﬁc problems or provide access to a

large base of associated tools and libraries and should

be integrated for opportunistically satisfying all the

systems needs and constraints.

Supporting ubiquitous and mobile systems adds

an element of dynamicity that is also difﬁcult to han-

dle. Contrary to static and ofﬂine integration scenar-

ios, where all the communication links can be pre-

conﬁgured, in open / ubiquitous environments, the

different elements are dynamically distributed. This

makes it vital to be able to alter communication path-

ways at run-time, e.g. by contacting different servers

while the user moves within a ubiquitous infrastruc-

ture or interacting on-demand through portable and/or

wearable devices that can be characterized by differ-

ent computational, network and presentation capabil-

ities. In these cases using multiple communication

mechanisms may be instrumental in guaranteeing the

adaptability of the system to such an environment.

However, in addition to the complexity of manag-

ing distinct data-exchange formats, combining multi-

ple communication mechanisms also adds the over-

head of managing their their relationships, for exam-

ple, to guarantee some global policies, such as poli-

cies for security or resource management. For in-

stance, it might be appropriate for all the mechanisms

employed to respect some high-level run-time policy

dictated by a speciﬁc application. For example, in

tele-conferencing systems, session termination may

require the closure of all the single connections that

were established in the process. In general, limited

resources in terms of memory, network bandwidth,

CPU, etc, often posits a conservative approach con-

sisting of shutting down unused modules and gener-

ally releasing resources after use is usually preferable.

Conversely, if one data connection carrying one type

of data terminates prematurely, e.g. for a problem iso-

lated to a speciﬁc transport layer, it should be possible

to detect the condition and re-establish the communi-

cation, e.g. to restore a session, or to support more

sophisticated error-recovery procedures.

Such an approach is advocated in the RETSINA

architecture. RETSINA supports the speciﬁcation (in

an agent communication language such as KQML

or FIPA-ACL) of the conversational policies agents

should adhere to in their interactions and the rel-

evant ontologies for achieving semantic interoper-

ability. Crucially, the ACL-level is used to coordi-

nate multiple heterogeneous communication systems

in order to bind together different functional compo-

nents and support agent-based applications running

under a wide variety of conditions, e.g. different op-

erating systems, devices and programming languages.

This approach results in a two tiered communication

strategy, in which low-level communications, called

backchannels, are represented and coordinated in the

ACL level. However, RETSINA provides only ACL-

level, implementation-agnostic speciﬁcations which

can lead to the development of such features.

3 SoSAA

SoSAA incorporates modularity by applying the prin-

ciples of hybrid agent control architectures. Popu-

larised by their use in robotics (e.g. in (Gat, 1992)),

hybrid control architectures are layered architectures

combining low-level behaviour-based systems with

high-level, deliberative reasoning apparatus. From

a control perspective, this enables the delegation of

many of the details of the agent’s control to the be-

haviour system, which closely monitors the agent’s

sensory-motor apparatus without symbolic reasoning.

The original solution advocated by SoSAA is to

apply a hybrid integration strategy to the system’s in-

frastructure, as illustrated in Fig. 1. SoSAA com-

bines a low-level component-based framework with

a MAS-based high-level framework. The low-level

framework operates by imposing clear boundaries be-

tween architectural modules (the components) and

guiding the developers in assembling these compo-

nents into a system architecture. It then provides a

run-time computational environment to the high-level

framework, which then augments it with its multi-

agent organisation, ACL-level interaction, and goal-

oriented reasoning capabilities.

The fundamental motivation behind such an ap-

proach is that application agents in SoSAA do not

just collaborate to carry out the different objectives of

the system, e.g. championing different sub-goals by

attending to different functional requirements. Each

agent is ﬁrst of all a member of an agent community

inhabiting the same computational environment. As

such, it may be required to compete with the other

agents for the computational resources in the system.

Under this perspective, SoSAA provides a platform

from which these agents can access the system’s re-

sources (e.g. hardware, CPU, data, network), coordi-

nate their activities and resolve possible conﬂicts aris-

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

154

ing at this level.

A number of widely-used mechanisms in the

CBSE community are supported by SoSAA’s low-

level framework:

• Support for different component collaboration

styles, such as event notiﬁcation, data messaging

or procedural calls (services).

• Reﬂection features, which can be used to deﬁne

speciﬁc component collaborations in terms of pro-

vided (outgoing) and requested (ingoing) inter-

faces.

• Container-type functionalities, used to load, un-

load, activate, de-activate, conﬁgure, and query

the set of functional components loaded in the

system.

• Brokering services, which can be used as late-

binding mechanisms by the components to locate

suitable collaboration partners at run-time for ev-

ery collaboration style supported by the frame-

work.

• Binding operations, with which the client-side in-

terfaces (e.g. event listeners, data consumers, ser-

vice clients) of one component can be program-

matically bounded to server-side interfaces (e.g.

event sources, data producers, service providers)

of other components.

• Provision of framework-wide mechanisms, such

as logging, life-cycle management, and schedul-

ing/control injection of process-type components.

Additionally, the high-level framework employs

meta-level sensors and effectors that collectively de-

ﬁne an interface, namely the SoSAA Adapter Service,

that can be used to sense and act upon elements and

mechanisms of the low-level framework by loading,

unloading, conﬁguring and binding components.

The other mechanism adopted for implementing

the SoSAA hybrid strategy is a callback design pat-

tern with which dedicated SoSAA component agents

can collaborate with the low-level framework by mon-

itoring it and by registering themselves as controllers

for speciﬁc events. In this manner, these agents are

then able to override the default behaviour of the

mechanisms provided by the low-level infrastructure,

and thus take more informed, context-sensitive deci-

sions. Crucially, while this can be done by taking into

consideration application-speciﬁc situations, as both

infrastructure and application-level issues are equally

addressed at the ACL-level, these two levels can now

be confronted by different agents. Instead of over-

loading one agent with both types of concerns, such

an approach enables the deﬁnition of distinct agents

Figure 1: SoSAA Hybrid Integration Strategy.

that focus only on certain aspects and that address

conﬂicts and inter-dependencies at the ACL-level.

Figure 1 illustrates this point by showing the re-

sulting multiagent organization in a typical SoSAA

node. Speciﬁcally, the low-level framework provides

the interface for operating both at the application and

at the infrastructure level. Accordingly, depending

on their interests, SoSAA component agents can be

distinguished between application and infrastructure

agents. Such a clear separation is fundamental for

promoting not only the efﬁciency and the portability

of the resulting systems, but also for separating the

different concerns at design time in order to facilitate

the adoption of a modular development process.

From an integration perspective, the SoSAA hy-

brid approach favors the distinct evolution of the soft-

ware systems it combines, thus more adequately sat-

isfying the requirements for extensibility demanded

of the overall framework. Since the adapter service

is deﬁned in terms of both standard agent capabilities

and a core component model, SoSAA’s design facili-

tates the use of different agent toolkits and component

frameworks. While the former can be programmed

according to different cognitive models, domain and

application-speciﬁc issues can be accounted for in the

design of the underlying functional components.

The current instantiation of SoSAA is based on

two open-source toolkits, namely: (1) Agent Fac-

tory (AF) (Collier et al., 2003) is a modular, ex-

tensible, open source framework for the develop-

ment of FIPA-compliant Multi Agent Systems whose

constituent agents are implemented in a purpose-

built Agent-Oriented Programming language known

as AFAPL that supports programming of agents in

HYBRID AGENT & COMPONENT-BASED MANAGEMENT OF BACKCHANNELS

155

terms of beliefs, commitments and goals (Collier and

O’Hare, 2009); and (2) the Java Modular Component

Framework (JMCF), a java-based library developed

in UCD and used to integrate SoSAA with different

component-enabling technologies, such as Java Beans

and OSGi. JMCF comes with a package of built-

in component types and base-class implementations,

each providing (i) component-container functionali-

ties (e.g. loading/unloading/conﬁguration of compo-

nents), (ii) brokering functionalities to register and

ﬁnd component services, and (iii) support for the run-

time execution of active (process-type) components.

Further details on JMCF can be found in (Dragone

et al., 2009).

4 SoSAA HYBRID

COMMUNICATION

It is relatively easy to satisfy the requirements set on

the SoSAA low-level framework for a single plat-

form, as brokering and container functions can use

inter-process (e.g. memory sharing) communication.

Figure 2: SoSAA Backchannel Management.

Figure 2 helps to illustrate the realisation of the

hybrid backchannel management in SoSAA. Inter-

face adapter components provide the bridge between

the standard interface classes used for inter-process

component collaboration and the backchannels used

to connect the corresponding components’ interfaces

across the network. In the example depicted in Fig-

ure 2, two components (client and server) are re-

motely connected through a Pull data interface. Local

connectivity is resolved by simply assigning, on the

client-side, a reference to a server-side implementa-

tion of the Pull interface, which is deﬁned as a single

pull() method returning a Java Object.

A remote connection between these components

is achieved by interposing a TcpPullServer, which

is bound to the server component exporting the Pull

interface, and a TcpPullClient component, which is

bound to the client component requiring it. Figure

2 also shows how the control of the backchannel is

shared among application component agents and sys-

tem component agents (called transport managers) in

the respective nodes. Speciﬁcally, whenever the client

application agent wants one of its components (the

client component in the example) to start exchanging

data with a remote one, it will issue an ACL request to

the remote agent requesting it to ﬁnd a suitable part-

ner (the server component in the example).

In general, application agents will use application-

speciﬁc protocols (e.g. auction based) to agree on

a collaboration between their respective functional

components before delegating the details of the con-

nection to their respective transport managers (see

Figure 3). To reduce the need to negotiate speciﬁc

transport mechanisms for each collaboration, each

transport manager uses a heartbeat protocol to in-

troduce themselves to each other. This protocol is

also used to exchange information concerning the ac-

tual transport mechanisms supported by each node,

together with the relevant (transport-speciﬁc) details

required to open new connections (e.g. the port for an

TCPIP backchannel).

Figure 3: Interaction Diagram, Application and Transport

Manager Agents.

In order to trade-off the impact of this communi-

cation with the scalability and the ability of the sys-

tem to adapt to dynamic resources, due for instance,

to failures in the underlining transport layers, this in-

formation is then cached by each transport manager.

Each entry in the cache is also supplemented with us-

age statistics, including the total number of interfaces

established toward each collaborating node, their lat-

est throughput, and the last time they were success-

fully (or unsuccessfully) used. Collectively, this in-

formation enables the deﬁnition of transport selection

strategies addressing QoS optimization and system’s

adaptation to changing environmental conditions.

The ﬁnal selection of the respective transport

adapters, their conﬁguration and their wiring to the lo-

cal functional components is coordinated between the

two transport managers through the use of a connec-

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

156

tion dialogue plan called setupRemoteConnection.

Each transport manager activates a copy of this plan,

partially illustrated in Figure 4, as soon as an appli-

cation agent requests the creation of a connection be-

tween a local and a remote component. Each instance

of this plan is then used to keep track of all the in-

termediate steps necessary to create the desired con-

nection, by sending requests to the remote transport

manager, and by mapping incoming requests and re-

sponses to a series of states, captured by sub-goals

and sub-plans that correspond to the dialogues state.

Initially, each transport manager queries (through

the SoSAA Adapter) its local components to ﬁnd out

if the local interface is a client- or a server-side inter-

face and also to ﬁnd out the associated Java interface

class (TcpPull in the example in Figure /refFig2). In

the ﬁrst case, the transport manager adopts the goal

GOAL(clientConnection(<terms>...) while in

the second case the transport manager adopts the goal

GOAL(serverConnection(<terms>...). In both

cases, the terms posted with these goals specify the

name of the components and their interfaces and also

the Java interface class. However, they leave open

any details concerning the speciﬁc protocol and the

adapter to be used. These are represented in the goal

as variables to indicate that any possible instantiation

will sufﬁce to satisfy the goal. Further, these goals are

posted as MAINTAIN goals.

Once their role in the new connection has been

established, each transport manager adopts differ-

ent sub-plans to carry out that role. In the exam-

ple depicted in Figure 2, the left-hand agent takes

charge of the client-side connection by driving the

coordination with the the other transport manager.

First of all, the setupClientConnection plan is ex-

ploited, together with the AF plan-selection mecha-

nism, to ﬁnally identify a suitable transport mech-

anism. The postcondition of this plan matches

GOAL(clientConnection(...)) while its precon-

dition checks that both platforms can currently han-

dle the same transport protocol (without specifying

it). As such, upon posting the goal the AF reasoning

engine automatically generates a number of possible

options, all committing to the activation of the same

setupClientConnection plan but with different trans-

port protocols speciﬁed in their activation arguments.

Conversely, the transport manager in charge

of the server-side interface will activate the

setupRemoteConnection plan, and inform the

client-side manager that it is ready to setup the

connection. Once this message is received, the con-

nection protocol highlighted in ﬁgure 4 commences.

The client-side requests the server-side manager

to setup a server adapter for the transport protocol

selected. If nothing has changed since transmitting

its last heartbeat update, the server-side manager

will install the server-side adapter and inform the

client-side manager of the details needed to contact

it. Alternatively, if the given transport protocol

is not available any longer on the server-side, the

server-side will reject the request. This will cause

the failure of the client-side plan and the automatic

activation of the next available option. Finally, the ac-

tual connection creation is delegated to wiring plans

setupClientAdapter and setupServerAdapter

that account for the characteristics of the transport

protocol selected in the ﬁrst negotiation phase.

Noticeably, the standardized interface with the

component layer, which supports loading/conﬁguring

and binding of components, the wiring plans can use

declarative descriptions of the different wiring steps

rather than the steps being hard-coded in different

sub-plans. This makes much easier adding the support

for new transport protocols, and knowledge of these

wiring steps can be acquired by the agent at run-time,

or even exchanged through ACL messages among dif-

ferent agents. In general, this is a crucial feature

awarded by the SoSAA design which makes the agent

system capable of acquiring new capabilities at run-

time and in line with dynamic binding mechanisms

exploited in the speciﬁc component layer.

In the case of the TcpPull connection depicted

in Figure 2, the setupClientAdapter plan will:

(i) load the TcpPullClient component, (ii) bind it

with the local client component, and (iii) conﬁg-

ure it with the address of the server’s node and the

name of the remote server-side component. On the

server side, the setupServerAdapter plan must: (i)

load a TcpPullServer, and (ii) bind it to the server

component. In the current implementation, the ac-

tual initialization of the connection in the server

side is performed by a TcpTransport service compo-

nent, also depicted in Figure 2, which accepts all in-

coming requests on a single server socket and noti-

ﬁes the required TcpPullServer component with the

resulting client socket. In each case, the wiring

plan records the details of the connection by stor-

ing a Belief(client/serverConnection(...))

matching the goal posted at the beginning of the con-

nection dialogue plan.

This hierarchical organization between applica-

tion agents, transport managers, and components, is

designed to handle functional and non-functional re-

quirements in terms of goals with decreasing levels of

abstractions. Application agents are driven by higher-

level functional goals (e.g. ”componentA needs data

from componentB”), which are resolved with the se-

lection of suitable collaborating components. Trans-

HYBRID AGENT & COMPONENT-BASED MANAGEMENT OF BACKCHANNELS

157

Figure 4: AUML TransportManager’s dialogue plan (se-

tupRemoteConnection) Legend: P: Communication Proto-

col;A: Name of component A; AI: Name of interface for

component A; B: Name of component B; BI: Name of in-

terface for component B; BA: Name of network adapter for

component B.

port agents are driven by lower-level goals concerning

the initiation and the maintenance of concrete inter-

component connections. They are also responsible

for reacting in case of failure and for trying alterna-

tive transport mechanisms before notifying the appli-

cation level of the connection error. The component

layer is passive and carries out higher-level instruc-

tions and performs the default behaviour hard-coded

in the functional components (e.g. ”always provide

data to a pull request”) or system components (e.g.

”always accept an incoming TCPIP connection”).

By monitoring the adapter components, through

the focus operator, the SoSAA Adapter is aware of

the state of the underlining communications, which

also means that there is no need to exchange any more

messages between the transport manager, other than

the minimum three messages necessary to synchro-

nize and agree on the terms of the communication.

Errors in the transport protocols or unexpected

exceptions, such the closing of a socket, are sim-

ply reported to the local transport manager in form

of Belief(error(?Adapter, ?ErrorDetails)).

By dropping Belief(client/serverConnection)

from the agent’s beliefs, the AF reasoning engine

automatically tries to restore the connection, by re-

activating the connection dialogue plan.

Finally, the SoSAA Adapter can be used to de-

ﬁne bottom-up connection strategies, whose handling

connections that are initiated within the component-

layer. In the case of a TCPIP connection, the transport

manager can simply intercept the initiation of a new

connection (by overriding the event notiﬁcation be-

tween the TcpTransport and the TcpPullServer com-

ponent) and collaborate with one or more application-

level agents to take a more informed decision upon the

connection, e.g. in order to implement load-balancing

or application-speciﬁc security mechanisms.

5 CONCLUSIONS

This paper presents an approach to backchannel man-

agement built using the Agent Factory and JMCF im-

plementation of SoSAA. Further, it attempts to show

how both SoSAA and the backchannel management

mechanism can be used to construct hybrid agent-

component applications. A key advantage of our ap-

proach arises from the clear separation of concerns

that exists between the application logic agents and

transport manager agents that form part of the SoSAA

infrastructure, and which manage the creation, conﬁg-

uration, and maintenance of backchannels.

REFERENCES

Collier, R., O’Hare, G., Lowen, T., and Rooney, C. (2003).

Beyond Prototyping in the Factory of Agents. Multi-

Agent Systems and Application III: 3rd International

Central and Eastern European Conference on Multi-

Agent Systems, Ceemas 2003, Prague, Czech Repub-

lic, June 16-18, 2003: Proceedings.

Collier, R. W. and O’Hare, G. (2009). Handbook of Re-

search on Emerging Rule-Based Languages and Tech-

nologies: Open Solutions and Approaches, chapter

Modeling and Programming with Commitment Rules

in Agent Factory. IGI Publishing.

Dragone, M. (2007). An agent-based robot software frame-

work. PhD thesis, School of Computer Science and

Informatics, University College Dublin.

Dragone, M., Lillis, D., Collier, R. W., and O’Hare, G.

M. P. (2009). SoSAA: A Framework for Integrating

Agents & Components. In Proceedings of the 24th

Annual Symposium on Applied Computing (ACM SAC

2009), Special Track on Agent-Oriented Program-

ming, Systems, Languages, and Applications, Hon-

olulu, Hawaii, USA.

Gat, E. (1992). Atlantis: Integrating planning and react-

ing in a heterogeneous asynchronous architecture for

controlling real-world mobile robots. In Proceedings

of the Tenth National Conference on Artiﬁcial Intelli-

gence, pages 809–815.

Sycara, K., Paolucci, M., Van Velsen, M., and Giampapa, J.

(2003). The retsina mas infrastructure. Autonomous

agents and multi-agent systems, 7(1):29–48.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

158