1. ATALK: A Decentralized Agent Platform for Engineering
Open and Dynamic Organizations
Ning Guib,a,∗, Vincenzo De Florioc , Tom Holvoeta
a Distrinet
Lab, University of Leuven, Belgium
of Computer Science, Zhejiang Sci-Tech University, China
c PATS group, University of Antwerp, Belgium
and iMinds research institute, Ghent-Ledeberg, Belgium
b Department
Abstract
In recent years the concept of “organization” has been gradually accepted as a suitable abstraction for the development
of open multi-agent systems with dynamic agents. By modelling interactions based on roles, this abstraction allows
an organization to be modelled independently of its participating agents so as to support agent dynamicity. A natural
requirement from the abstraction is that agents need to be “organization aware”—that is they must be able to inquire,
import, and execute roles from the organization. However, how to adequately support those processes in a decentralized
and dynamic environment is still an open issue. This paper addresses this problem by presenting ATALK, a novel
decentralized agent middleware that fulfills the above requirements. A role component model is designed to facilitate
role deployment, reflection and uniform role interaction. In order to support role dynamicity, a compositional agent
architecture allowing dynamic role integration and enactment is proposed. Moreover, ATALK allows agents to hand over
their role to other agents of a same organization with their run-time states. Thus, agents can dynamically relinquish
their roles without jeopardizing the normal execution of the organization. This paper also evaluates our design and
current prototypic implementation through both qualitative analysis and simulations. Our results show that ATALK
achieves remarkable organization reconfigurability with little additional overhead.
Keywords: Multiagent systems; Organization; Dynamic reorganization; Service-oriented architecture
1. Introduction
More and more systems are being constructed on top of
heterogeneous devices with different computing power, sensors, functions, and degree of availability. In order to
achieve their design goals, those devices have to be organized and coordinated. The dynamic and decentralized
nature of those devices demands support of open systems
able to accommodate for changes affecting the constituent
devices (Boissier et al., 2007). Multi-agent Systems (MAS)
are gaining increasing popularity as a tool to create such
open and decentralized systems in that MAS can dynamically reorganize themselves when system goals or participating agents change (Weyns et al., 2010b).
A recent and increasingly widespread trend of agent research communities is the use of the concept of organization (also referred to as “society” (Dastani et al., 2003),
“institution” (Esteva et al., 2004) and other terms) as
a tool to structure and manage the interactions in open
MAS. In organizations, the interactions between agents
∗ Corresponding
author
Email addresses: ninggui@gmail.com (Ning Gui),
vincenzo.deflorio@uantwerpen.be (Vincenzo De Florio),
tom.holvoet@cs.kuleuven.be (Tom Holvoet)
Preprint submitted to Engineering Applications of Artificial Intelligence
are modeled in terms of a set of roles rather than a collection of agents. Each role is responsible for a particular functionality of an organization and is to be played
by any agent satisfying its requirements. Using dynamically assignable roles rather than actual agents provides
the designer with a higher level of abstraction that allows
an organization and its roles to be developed separately
from the agents that will play them (Tinnemeier et al.,
2009). This feature facilitates considerably the development of open systems—systems that is in which heterogeneous agents might join or leave the organization at will. A
natural requirement resulting from this abstraction, however, requires the participating agents to be “organization
aware”, meaning that they have to be able to inquire, import, and execute roles from the organization they belong
to. Enabling these processes is further complicated by the
dynamic and decentralized nature of open systems. Due
to the dynamic availability of the devices they are built
upon, it is hard and makes little sense to foresee a fixed
device for hosting organization services.
This paper provides a novel approach to the above problems by tackling the following issues:
ˆ Allowing agents to access the roles of an organization in a decentralized environment. When an agent
October 7, 2013

2. joins an organization, role specifications of this organization should be made available to the agent for
deployment. Due to the open and decentralized nature, such role deployment must be performed without the existence of a central control point.
depicts a swarm of heterogeneous robots that self-organize
to draw an ore distribution map in an unknown territory.
Each robot is equipped with motors for moving around;
spectrum sensors for ore detection; a data processing unit
capable of processing the monitored data; a unit that enables communication with nearby robots. Robots are heterogeneous in terms of hardware specification and available
resources, e.g. different battery characteristics, CPU and
communication capabilities. For simplicity of treatise we
assume that each robot hardware device is managed and
represented by a software agent of the same name. As
an example, Robot A shall be used to represent both the
robotic device as well as the software agents that manage
that device.
ˆ Enabling agents to dynamically integrate and execute external roles. When an agent acquires a role
from an organization, it has to adjust itself so as
to integrate the features of the role (Dastani et al.,
2003). As agents are to play independently-developed
roles, this integration process should be general to
different types of roles.
ˆ Supporting run-time role relocation. This feature
makes sure that the organization is not disrupted by
agents leaving the organization abruptly. In order to
achieve this objective software agents are made able
to hand over their roles to other agents at the stage
of their enactment.
In what follows, we assume those robots are coordinated
through the definition of an ”organization”. The organization is designed to optimize the ore exploration process
with a dynamic set of robots. In order to achieve the
organizational goal, three roles are introduced: Coordinator, Worker, and Attractor. 1) The Coordinator assigns
tasks to all the Workers within the organization; processes
the data sensed by the Workers; draws an ore distribution
map. 2) The Worker receives task assignments from the
Coordinator; wanders around and identifies ore location by
processing data from its sensors; transfers ore location to
the Coordinator. 3) The Attractor broadcasts invitation
messages to all robots in range. In addition to those roles,
the organization also comprises laws expressing structural
constraints, e.g. only one robot may play the coordinator
role.
Our answer to the above issues is given by the ATALK
middleware platform. In order to simplify the role deployment process, ATALK explicitly represents roles as serviceoriented components that can be deployed at run-time.
With the definition of a uniform role interface definition,
agents can interact with different, possibly unknown roles.
The role integration process is supported by the introduction of a compositional agent architecture. Said architecture provides an event-based role execution environment
for its enacting roles. One important feature of ATALK
is its support of fully-decentralized role deployment and
stateful role relocation among participating agents. This
feature is supported by a decentralized role repository for
the organization-level role deployment and a role mobility
service enabling the role relocation process.
Without loss of generality, we assume Robot A initially
runs a copy of the organization specification and takes
both the Attractor and Coordinator roles. In order to
achieve the organization goal, as Coordinator, Robot A
opens several positions for Workers to attract other robots.
Here, a role position represents a call for roles (Serrano and
Ossowski, 2004). At a later point, a second robot, Robot
B, is deployed and joins the organization by acquiring a
copy of the organization specification. Thus, the organization extends to two robots, each robot maintaining a copy
of the organization specification as well as its current state.
The consistence of the replicated organization can be guaranteed through a synchronization service, which has been
extensively discussed in our previous work (Weyns et al.,
2010b).
This paper presents the ATALK agent platform as well as
a set of qualitative evaluations of the current prototypical
implementation. The evaluation is carried out within a
set of contexts: dynamic role deployment; a self-repairing
process; and self-organization of robots. Our analysis and
simulation results show that ATALK achieves high organization reconfigurability with little additional overhead.
The rest of the paper is organized as follows. Section 2
describes a motivational example to introduce the concepts
of decentralized role deployment and relocation. Section
3 presents the design as well as the key components of
ATALK. Our current prototypical implementation, as well
as comparisons with existing frameworks, constitute the
subject of Section 4. Related work is discussed in Section
5. Our preliminary conclusions and a view to some future
work are provided in Section 6.
Role deployment and integration. By acquiring a
copy of the specification as well as the state of the organization, Robot B becomes aware of the positions currently
open. As a result, it chooses to take the Worker position
by sending a request to the organization. If the request is
allowed, a role contract is signed between the organization
and Robot B. Once this is done the Worker specification
currently located in Robot A is transferred to Robot B.
When the latter receives the role specification, said role is
embodied. This results in an instantiation of the role—
referred in what follows as a role instance. Robot B then
2. Motivational Example
In what follows we introduce a case study so as to motivate
the requirements pointed out in Sect. 1. Our case study
2

3. (a)
(b)
Figure 1: The configuration of robots with respect to role assignment: (a) Robot A as both Coordinator and Attractor and Robot B, C, and
D as Workers; (b) Robot B as Coordinator, Robot C as both Worker and Attractor, and Robot D as worker.
formal definitions of those concepts can refer to (Weyns
et al., 2010a).
modifies itself to integrate the new role instance.
It is worth noting how multiple robots may hold the same
role—and therefore exhibit similar behaviors—though their
corresponding role instances shall be in general in different
states. Figure 1(a) shows the organization configuration
with three Workers who are assigned with different exploration areas.
3. Middleware Architecture
In this section we describe the architectural design of ATALK.
We firstly analyze the design requirements that underpin
the ATALK software architecture. Then we describe the
layered software architecture as well as its key elements.
Role relocation. Due to resource fluctuations or availability considerations, a robot, for instance Robot A, may
become unable to fulfill its roles. As a consequence, it
may want to dismiss some or all of its enacting roles. Normally, the corresponding role instances should be immediately destroyed after the role dismission. However, certain
role instances, as for instance the Coordinator, may manage run-time data that is not replicated in any other role
instance. Examples of such data may include, e.g., task
assignments, territory explored so far, or a partial map
of the territory. Because of this unicity Robot A cannot directly dismiss the Coordinator role instance, lest the
whole organization would lose track of the current exploration process and fail to achieve its goal. In order to
guarantee the correct execution of the organization, it is
important to allow Robot A to hand over its Coordinator
role to another robot, together with the current state of
the corresponding role instance. Only once this is done
Robot A may leave the organization without disrupting
the organizational mission. Figure 1(b) shows one possible configuration with Robot B taking the Coordinator
role and a new robot, say Robot C, taking the attractor
role.
3.1. Requirement Analysis
From the motivational example, a set of requirements are
identified.
ˆ Role representation. The motivational example
shows that roles can be designed out of the scope of
agents and have to be run-time deploy-able to agents.
In order to support this feature, some researchers,
e.g. in (Kendall, 2000; Weyns et al., 2010b; Gunasekera et al., 2009), pointed out that roles should
be represented as first-class citizens and explicitly
implemented as software entities, rather than pure
modeling concepts as in (Brian and Conor, 2009).
In order to support the dynamic role inquiry, each
role should contain meta-data for agents to evaluate
its requirements. As an agent should be able to interact with un-prescribed roles, it is important that
all those roles can be accessed in a uniform way. Furthermore, roles should be designed to facilitate the
process of run-time deployment and execution.
Formal definitions of the core notions such as role, agent,
organization, role position, role contract etc. are specified
in our previous work. Readers who are interested in the
3

4. Figure 2: Layered view of an ATALK system
ˆ Agent-level role management. In an organization, agents need to be able to assume, manage, and
dismiss roles during run-time. When an agent begins
to play a role, it modifies itself to integrate the rolespecific knowledge and strategies so as to become
“aware” of role-specific events and takes corresponding actions according to its enacting role’s strategies.
An agent can play simultaneously multiple roles and
its enacting roles might change throughout its entire
life-cycle. Thus, a basic requirement for agents is the
run-time role management support.
layers. Of those four layers, the two in the middle constitute the ATALK middleware.
ˆ Domain agent layer. This layer contains agents designed for application specific goals (denoted as domain agent). Each agent embodies its own objectives
and goals and decides autonomously whether to join
or how to participate in an organization. When a domain agent decides to play a role, a new role instance
is initialized. The agent exhibits its role-specific behavior by forwarding role-related events to its role
instances and performs actions issued by said instances. When an agent chooses to dismiss one of
its roles, the corresponding role instance is deactivated. As a consequence the agent stops receiving
events related to the dismissed role.
ˆ Organization-level role deployment & relocation. As shown in the motivational example, one
organization may be distributed across a dynamic
set of hosts with no prescribed central control point.
With the change of the constituent hosts, roles of an
organization might reside on different hosts at different times. It is often difficult and in some cases unfeasible for agents to track the current location of all
organizational roles. Thus, a organization-level role
deployment service is needed to allow agents to access the organization specification in a uniform way.
Furthermore, it is also vital to allow agents to hand
over their enacting role instances to other agents together with their current states. As a consequence,
the agent platform must support the role relocation
process in a decentralized way.
ˆ Agent-level role management layer. For any agent to
participate in a given organization, it must be able
to access role evaluation, management, and execution services. This layer provides an abstraction between domain agents and their enacting roles with
important role management services, e.g., the requirements evaluation service and the role execution
service. The introduction of this layer shields domain
agent developers from the complexity needed to provide ad-hoc “role management” and allows them to
focus on the development of agent domain logic.
ˆ Organizational layer. This layer provides role management services in the organization level. As shown
in Fig. 2, an organization might cover multiple hosts.
Each host contains a (partial) copy of the organization instance. Different organization instances are
synchronized periodically to keep a coherent record
of the organization. The registry service is designed
so as to provide a consistent view to the organization
The ATALK middleware platform is designed taking the
above requirements into account.
3.2. Layered View of an ATALK System
Figure 2 shows a layered view of an ATALK system deployed across multiple hosts. This system consists of four
4

5. configuration across multiple hosts. In order to reduce the resource usage in term of transmission and
storage, a decentralized role repository is defined to
store role components across multiple hosts. The role
import service is defined for agents to retrieve role
components from the organization to the local host.
The role relocation process is supported by the role
mobility service. The organization layer also enforces
constraints and rules specific to the referred organization. For instance, in the scenario discussed in
previous section, the organization layer is to ensure
that only one robot may play the Coordinator role.
This layer may also contain other logic—for instance
to optimize role assignment within the organization.
Figure 3: The service component model of roles.
ˆ Communication Layer. The communication layer
connects all components within an organization by
providing common communication services and basic
support for distribution.
Said component model supports the run-time deployment
of role components, thus making it possible to dynamically
introduce new role components to the agent. When a role
component is deployed and initialized, the reference to the
provided service will be registered in the service registry
and can be queried, bound, and unbound by the agent
during the run-time. Figure 3 shows this dynamic binding
process.
The layered design is commonly used in many organizational agent middleware (Gutknecht and Ferber, 2001; Esteva et al., 2004; H¨bner et al., 2010; Weyns et al., 2010b)
u
as it provides a strict isolation between different design
concerns and allows for a modular implementation. However, those approaches normally focus on separating the
organization management complexity from agent development. Little discussion has been provided on how agents
and the organization can effectively manage the role in an
decentralized environments.
As agents need to work with different possibly unknown
roles, the general service component model needs to be
extended to provide support for uniform role interaction
and for role requirement description. In order to address
these two issues, a role interface and a meta-data format
have been defined.
In comparison, ATALK is designed with special attention
to the supports of role deployment, run-time role integration, and relocation processes in decentralized and dynamic environments. Those processes are supported by
the following peculiar design choices: 1) A service-oriented
role component model to facilitate run-time role deployment and interaction; 2) a compositional agent architecture for run-time role integration and execution; 3) organizational support for decentralized role deployment and
relocation. The following sections provide detailed introduction to each of the above aspects.
General role interface for interaction
Open systems require that an agent plays possibly unknown roles, possibly developed by third parties. Thus,
it is very important that a role component could be accessed and managed in a uniform way. As a consequence,
a uniform interface—IRole—has been defined and needs
to be implemented by all role components. Said interface
includes methods for both life-cycle management (for instance, to start or stop a role) and event-based interactions
(e.g., event process methods) as well as methods for role
relocation by saving and restoring the state of the role instance. A detailed definition for the IRole interface can be
found in (Gui and De Florio, 2013).
3.3. The ATALK Role Component Model
Similarly to many existing approaches, e.g. BRAIN (Cabri
et al., 2003), ATALK models roles through a so-called
Event-Action model. Accordingly, a role is sensible to
particular type of events and responds with a set of corresponding actions depending on its logic. In this section
we focus on the design of a role component model which
allows for role inquiry, run-time deployment and uniform
interactions.
Meta-data for role description
Because of the separation of concerns between roles and
agents, role components must be described in a manner
that allows agents to search and evaluate them—for instance checking whether the required capabilities are satisfied by an agent. This calls for enabling the exposure
of a role component’s both functional and non-functional
requirements. In ATALK, functional requirements are designed based on the OSGi Service Component Model (OSGi).
For the non-functional requirements, a simple resource requirement format, similar to the one in (Fujii and Suda,
2009), was adopted. The following codes describes an example of resource requirements for a Worker’s capability
3.3.1. Service component role model
In order to provide a light-weight and simple role integration support, a component model based on the Service Component Architecture (SCA) has been designed.
5

6. requirements:
Scope: Coordinator ;
resource.bandwidth.available > 100;
Scope: Hostagent ;
capability.moving == true;
resource.CPU.available > 30;
resource.bandwidth.available > 100;
As suggested by the motivational example, role enactment
does not only require enacting agents but also introduces
requirements to other agents. Thus, ATALK introduces
the Scope keyword to specify requirements towards different organization entities. In the first part of the above
example the agent enacting the Coordinator role states it
requires a minimal communication bandwidth of 100kpbs
for each Worker it coordinates. The second part states
that the Worker role requires its enacting agent—denoted
by “hostagent”—to have the following features: mobility,
30% or more of residual CPU, and at least 100kbps of
residual bandwidth. Only when both the agent and Coordinator satisfy all those conditions the agent can assume
the corresponding role.
Figure 4: Role component state changes with agent actions.
role interface, the source-code level coupling exhibited by
AOP-based approaches is eliminated.
3.3.2. Lifecycle Definition
Discussions
As discussed in the motivational example, a role component can be deployed from the organization, checked for
constraints, and integrated into its enacting agent. During
these processes, role states change. Figure 4 illustrates the
life-cycle of a role component.
Although most researchers agree that roles should be represented as first-class citizens and explicitly implemented
as software entities, there is still lack of consensus on how
to engineer them. Existing approaches implement roles
by using either object-oriented programming (OOP) (as,
e.g., in ROPE (Michael, 1999) and the meta-class implementation (Dahchour et al., 2004)) or aspect-oriented programming (AOP) (as, e.g., in BRAIN (Cabri et al., 2003),
Malaca (Amor and Fuentes, 2009) as well as in (Kendall,
2000)). In the former family of approaches, as OOP provides no native reference management, ad-hoc solutions
for object reference management are needed. In the latter
stream of approaches, roles are implemented as aspects
and can be dynamically weaved into agents during runtime with certain hot-spot AOP run-time, as e.g. in JBoss
AOP (JBoss Community, 2011). This weaving process
eliminates the need to provide dynamic reference management. However, as aspects (roles) are directly weaved into
agents at source code level, role developers need to have
accurate information about the codes of the agents. This
strong coupling between role aspects and agents makes the
role modules very hard to be reused across agents.
As shown in Fig. 4, the lifecycle changes of role components are driven by the following entities: the domain
agent, role management services, and the organization. In
particular, the organization manages the role deployment
and undeployment process within the organization while
the local role manager checks capability constraints on behalf of agents. If the constraints are satisfied, it signifies
that the agent satisfies all its requirements and the role is
ready to be assumed. On the contrary, the role manager
sets its state to ”unsatisfied”. Domain agents in particular only focus on whether to take the “satisfied” roles or
dismiss unwanted roles. This separation helps agent developers focus on the development of the domain-specific
logic.
Compared to other service-oriented component models,
one distinguished feature of the ATALK role component is
the introduction of the ”serialized” state. In this state, a
role pauses its execution and stores its run-time states into
persistent storage (viz., files). This state is introduced to
facilitate the role relocation process.
In comparison, existing off-the-shelf service component runtimes already provide rich support for run-time component deployment and dynamic reference management, as
it is the case, e.g., for the service component run-time
in the declarative service (OSGi), in the Apache Tuscany
project (Tuscany, 2011), and in our previous work (Gui
et al., 2008). Implementing roles as service components
can largely facilitate reusing those services and eliminates
the need to provide ad-hoc solutions for reference management. As agents and roles can interact through pre-defined
3.4. Compositional Agent Architecture
One of the basic requirements for organizational agents
is the capability to play roles defined in the organization.
This includes the ability to sense role availability, to reason about role requirements, and to interact with roles.
6

7. As an example, if the AgentContext of a robot, e.g. Robot
C, is as follows:
(capability.moving,true), (resource.CPU.available,50),
(resource.bandwidth.available,300),
then when the organization opens a new role worker position, this service can check the requirements of this position on behalf of the robot. In the exemplified case Robot
C clearly satisfies all the requirement. As a consequence,
this service changes the status of the worker component
to “satisfied”. When the context changes, the agent might
not be able to fulfill a role. In such a case this service will
label the role component as “unsatisfied” and remove it
from the list of active roles.
Role execution service. In ATALK, both agents and roles
are driven by events. The process coordinator pattern (Gorton, 2006) is adopted to implement role execution services.
As shown in Fig. 5, this service provides an itinerary execution behavior which runs throughout the whole lifecycle of the agent. It delivers all received messages and
organization events to the individual event receiver (roles,
agent decision logic). Each event is handled in two major
steps: 1) Firstly, the event is dispatched to event-handlers
from the agent itself. For instance, an agent should handle
events pertaining to, e.g., a new role position available, a
role becoming “unsatisfied”, and so on. 2) Secondly, when
all handlers have processed the event, the event will be
handled by all active roles assumed by the hosting agent.
Different roles might respond to different events. The execution service first verifies if the incoming event pertains
to an existing role. If so, the dispatcher distributes the
event to the role through the method defined in the role
interface. This method returns a set of “actions” for execution.
Figure 5: Diagram of an agent’s internal architecture.
Although such functionality is not related to the agent’s
core application logic, it accounts for a considerable share
of the agent development complexity. Because of this, we
introduce the compositional agent architecture with two
pre-defined services: “requirement verification” and “role
execution”.
Agent internal architecture. Similarly to the case of role
definition, an ATALK agent is also modeled through the
event-action model. An agent receives events and issues
actions to make changes according to its application logic
as well as its enacting roles. Figure 5 shows the design of
the agent’s internal architecture.
In this design, an ATALK agent constitutes a domainspecific logic (denoted as domain agent), with reusable
service modules such as requirement verification service
and role execution services, and organization-related roles.
Those modules are driven by the events received by the
agent. Some events are sent from the organization—such
as the messages of agent participation or departure—while
others come from other agents or from role instances played
by other agents. Those events are dispatched by the “role
execution service” to the agent or specific roles. Then, the
agent and its enacting roles can issue their corresponding
actions for execution. The AgentContext takes track of
the agent’s run-time status and is organized as a set of
“(property, value)” couples.
The compositional agent architecture and the two services
provide basic support for requirement validation, role management and execution. This design allows agent developers to focus on implementing their application logic—
for instance, logic specifying in what condition the agent
should take which roles.
3.5. Organization Layer
In ATALK, a decentralized organization layer is designed.
This layer provides a virtual environment for the agent
to access the organizational services (e.g the coordination
service to keep the organization in a consistent state, as
done in (Omicini et al., 2008; Weyns et al., 2010b)) or
the re-organization service that improves the current configuration through its optimization rules—as done, e.g.,
in (Artikis, 2012). As this layer has been extensively discussed in many existing approaches, here we shall focus on
the support of role deployment and relocation.
Requirement verification service. Through this function
the role manager verifies whether an agent has the capabilities necessary to perform the current role. This is similar
to the function provided by GateKeeper (van Riemsdijk
et al., 2011) and the match-maker in Larks (Sycara et al.,
2002). The validation is conditioned to the role component’s meta-data and the agent’s current status, as stored
in the AgentContext. The state of the role component is
changed according to the result of the verification.
7

8. role repository. The adoption of RIS shields the agents
from the details of the actual locations of role components
and provides a uniform interface for role deployment.
3.5.3. Role Mobility service
In most agent platforms, only agents are mobile. In order
to support role relocation within an organization, ATALK
extends mobility to roles as well. In essence, the process
supporting role mobility across multiple hosts reduces itself to a particular case of code mobility (Fuggetta et al.,
1998). In ATALK the role relocation process involves both
the migration of the binary code and the transfer of the
state of the role instance (stateful migration).
Any role component that may need to be migrated-withstate must implement the IMobility interface. Said interface allows role components to save state data to a persistent file and later to restore the state information. When a
role instance is about to move, it firstly stores its run-time
data. After this, the migration service packs role-specific
codes, meta-data, and run-time states into a single component that can be transferred to its remote destination.
Once this is done, the receiving agent can assume this role
via the RIS and load the received state information onto
the newly started role instance.
Figure 6: Decentralized role repository.
3.5.1. Distributed role repository
As pointed out in (Ward and Henderson-Sellers, 2009), in
order to achieve reusability of roles, it is important to provide an extensible role reusability infrastructure. Instead
of placing all role components in one central repository,
ATALK designs a decentralized role repository extending
to all the host devices within the organization. Each host
keeps a local copy of the component-location record, which
consists of a list of all role components, their meta-data
descriptions, and URLs for accessing the role components.
Records in different hosts are synchronized periodically.
As shown in Fig. 6, the actual role components are scattered across multiple hosts. A host might manage but a
fraction of all the role components used in the organization. A repository management interface is provided with
role management functions such as inquiring available role
components and adding/removing a copy of role components to/from a given host.
From the implementation point of view, the role migration
is quite similar to agent migration. However, they have
a major difference. In the role-based relocation, a role
instance can only exist when an agent assumes it. It is
subordinated to the agent and the organization. Thus,
only the agent or the organization is allowed to initiate the
role relocation process. On the contrary, in agent-based
migration, an agent decide autonomously when and where
to migrate. This feature highlights an important difference
between an agent and its roles: an agent migrates of its
own volition, while a role relocates only because its player
so decides.
Figure 6 also shows that one role component can have multiple copies. This feature allows the repository to tolerate
host failures to a certain degree. When a host crashes,
agents in other hosts can still access the role components
that reside in other nodes. Compared to approaches in
which one hosts contains all possible roles, this design is
also resource-efficient. However, how to make a best balance between fault-tolerance and resource efficiency is a
research topic in itself and is out of scope of this paper.
3.6. Intra-organizational Role Relocation
Figure 7 shows the activity diagram of the different entities
involved in relocating a role from one agent to another.
As shown in this figure, when an agent, say agent a, wants
to delegate a role instance, say r, to another agent with
run-time states, the following sequence of actions typically
takes place: a) Agent a firstly calls the Role Mobility service from the organization and parses the reference to r;
b) the Packaging service is called to package role r’s binary codes and its state information into one deployable
component; c) the generated role component (with state)
is added to the Role Repository and a corresponding URL
is returned to agent a; d) Agent a creates a new role position in the organization with the URL and meta-data
related to role r; e) the organization sends a “new role
available” message to other agents; f) a second agent, say
Agent b, checks the requirements of r; g) if requirements
3.5.2. Role Import Service
The Role import service (RIS) imports role components
from organization to the local host. When called with a
reference to a role component, the RIS returns the URLs of
this role from the index of role repository. If the local host
contains a copy of this role component, RIS retrieves the
role component from the local host, otherwise it imports
the role component through the remote URL. After this
role import process, RIS adds the role component to the
local role repository and then updates the index of global
8

9. Hall, 2004). This model is a service-oriented component
model and provides native support for dynamic reference
management. In order to describe role components’ nonfunctional prerequisites for execution, each role component
is associated with a “role.mf” file to specify its capabilities
requirements1 .
For component sharing, the Jetty HTTP service provided
by the OSGi framework is used to share components within
the organization. Each host runs one Http service which
are used for role import and mobility services. The role
import service is implemented based on OSGi continuous
deployment services, which allow components to be deployed via a URL address. Thus, one role component
can be deployed once (namely, on a single host) while
being accessible from all the nodes within the whole organization. When roles need to migrate-with-state, the
XStream (Xstream, 2012) package is used to serialize role
states into XML. Similarly to what done in (Ibrahim and
Zhao, 2009), a one-shot approach is adopted in packaging
and relocating components. Other agents can get all the
required data with one single software package.
Figure 7: Activity Diagram for Role Relocation.
are satisfied and b decides to play role r, it sends a role
assumption request to the organization; h) the organization decides which agent shall take role r; let us suppose
here that agent b is selected; i) The Role Import service is
called to deploy the role components to the host on which
agent b is executing; the role r becomes “loaded”; j) the
requirement verification service checks the requirements
again; k) if satisfied, the state of role r is reinitialized and
its execution is resumed.
In order to provide a consistent organization image to
agents, different hosts in the ATALK are synchronized
through a simple synchronization protocol based on the
master-slave model. In the current implementation, each
host in the organization is assigned with a host ID. The
host with minimal host ID in the organization is selected as
the master while all other hosts are slaves. Only the master host can make changes to the organization configuration and periodically send state updates. When an action
may change the organization configuration—for instance,
an agent opens a role position or signs a contract with the
organization—the slave host will send the corresponding
request to the master host and wait for confirmation from
the master. Obviously such a simple protocol may be replaced with a more failure-resilient one such as (De Florio
et al., 2000).
It is worth noting that the process introduced here adopts
an agent-centered approach in which agents initialize the
role relocation process. In other approaches, it is possible
that the organization instead of agents initializes this role
relocation process. These two models represent two different design alternatives regarding where to place the reorganization logic (Boissier et al., 2007). ATALK is designed
to support both models. System designers can choose an
appropriate model according to their specific requirements
to implement their systems.
As for the communication protocol, ATALK designed a
simple, custom agent communication protocol based on
multicast message transmission. We are currently working on distributed hash table based approaches so as to
realize a decentralized key-value infrastructure for sharing
information e.g. open role positions, taken roles.
4. Implementation and Evaluation
In what follows we introduce the current implementation
of ATALK and we evaluate it from different perspectives.
4.2. Performance Evaluation
In this section, the performance of our prototype is assessed from different perspectives. Firstly, the time for
the role relocation process is examined. Then, a quantitative comparison between agent-based migration and rolebased relocation is carried out. Finally, we demonstrate
how role-based relocation can help the organization selforganize into a more resource-efficient configuration.
4.1. System Implementation
We use the OSGi framework (OSGi Committee) as our
implementation platform. OSGi provides a lightweight
service-oriented middleware platform with an easily extensible component model. Equinox is used as our basic development platform. This component model is based on our
previous work on declarative & reflective service component (Gui et al., 2011) which is extended from the declarative component model firstly proposed in (Cervantes and
1 Source code can be download at http://code.google.com/p/osgiagents-code-exchanging/
9

10. 4.2.1. Role deployment and relocation
What we deem as one of the key features of ATALK lies
in its support for decentralized role deployment and stateful role relocation. As the latter process is more complex
and covers all the activities involved in the role deployment process, we focus our attention here solely on role
relocation. As discussed in Sect. 3.6, the role relocation
process involves five major steps: 1) serialization of the
state information into a local file; 2) packaging of the role
component with its states; 3) exchange of messages with
the organization (including those to arrange open role positions, agents replies, as well as for signing contracts with
the organization); 4) retrieval of the role component from
remote host; 5) local installation.
The results reported in what follows have been obtained
by deploying ATALK on a local network with 7 PCs used
as hosts. Each PC is equipped with an Intel T6400 CPU,
2GB memory, a 100 Mbps LAN interface, and is running
the Window XP OS. The adopted JVM version is 1.7. A
single agent is deployed on each host. The performance
of role deployment is evaluated through the time for deploying a role component to all participating agents, with
respect to the size of the migrating component and the
number of involved agents. In this simulation, the size
of each role component takes the following values: 8KB;
50KB; 173KB; and 370KB, while the number of agents
who want to assume a role ranges from 1 to 6.
Figure 8: Execution time for serialization & packaging.
Of the above five processes, serialization and packaging
are independent of the number of Worker agents. Thus,
Fig. 8 shows the performance of those processes when the
size of role components changes. As can be seen from that
figure, the role component spends around 6ms to serialize
two variables into a XML file. The serialization process
is only affected by the size of serialized data and will not
change with respect to the size of role components. In
comparison, the time consumed by the packaging process
gradually raises from 15ms to 54ms when the size of role
increases from 8KB to 370KB. These two processes are
only needed when an agent wants to relocate its role instance, together with its states, to other agents. When an
agent only wants to deploy a new role component into the
local host, the mentioned two steps will not be needed.
Figure 9: Role relocation time with different number of agents.
nent. The execution time increases very slowly when the
component size is small and comparably faster when the
component size grows. The major reason contributing to
this increase is the time for importing the role component
into the local host. In this scenario, all agents immediately assume the role position as soon as they are notified.
Due to the short interval, the corresponding record in the
decentralized role component repository have not been updated. Thus, all the agents try to access the role component from the same remote host almost at the same time.
This creates a burst of requests and makes the installation
time increase with the number of agents—thus artificially
creating a worst case scenario. In practice, only a limited
number of agents take a role position and in general this
does not happen at the same time. As a consequence the
installation time shall often be comparable to the performance of the single agent case—less than 400ms for a role
component of 370KB.
Figure 9 shows the execution time when relocating a role
component to a varying number of agents. The value is the
arithmetic mean of 100 runs of the experiment. The lower
and upper bound shows their standard deviations of those
execution time. In this simulation, all agents are designed
with logic to assume the role as soon as it receives notification from the organization. The execution time is calculated from the time the agent decides to relocate a role
to the time when all other agents assume that role. The
whole process includes serialization, packaging, messaging,
importing, and installing the role component. As shown in
this figure, the deployment time increases with respect to
both the number of agents and the size of the role compo10

11. Table 1: Comparison between ATALK and JADE in terms of mobility support
Migration domain
Migration entities
Migration size
Migration
Time
(code only)
MTTR
(with
states and reinit)
Agent behavior
ATALK Role migration
Within
organization
Role component +
state
8KB
JADE
Agent
Mobile
145.3ms
252ms
171.7 ms
1141ms
Run-time reconfigurable
Pre-defined
Point-to-point
Agent + behaviors + state
33 KB
4.2.2. Role relocation vs. agent-based migration
In this section we compare the performance of role relocation with the agent-based migration in JADE(Bellifemine
et al., 2009) with a self-repairing scenario based on the
“mobile” demo provided with the JADE platform. an
agent moves some functionaries to another host due to
the changes of its residing host’s availability. The agent
contains three major function units: 1) a counting feature
increments a counter every second(countingbehavior.java)
2) query feature to query the number of available hosts
(GetAvailableLocationsBehavior.java)3 ) a commanding interface responding to external commands (ServeIncomingMessagesBehavior.java). In JADE, those features are implemented as agent behaviors while in ATALK those different
behaviors are implemented as re-deployable role components.
From a certain time, an agent moves some functionaries
to another host due to the changes of its residing host’s
availability. In such scenario, an agent moves some functionaries to another host due to the changes of its residing
host’s availability. We remark how, in an agent platform
such as JADE, such scenario would result in the agent
migrating to another host with all enacting roles. In comparison, the ATALK agent can choose to migrate a subset of its functionality—a portion of its enacting roles—to
other agents residing in other hosts. The time needed for
the agents to resume the execution of the role enacted by
involving agents is counted as repair time. Mean-time-torepair (MTTR) for the two implementations is collected
and compared. The value is obtained from the average of
10 simulation runs.
while in JADE it calls for about 252ms. The JADE approach takes more time as it requires more code to be
transferred compared to the role-based relocation (33KB
vs. 8KB). A second reason contributing to this result is
the model of migration. In JADE, when an agent wants
to migrate, it does so by marking itself as moveable. The
actual migration is performed by the JADE system after
some delay. When counting the state transferring time,
ATALK achieves an even better performance (171.7 ms
vs. 1141ms). This is due to the fact that our platform
only needs to restore the state of the role, while JADE
needs to restore all the state of the agent. The “pullper-class” strategy used by the JADE platform also contributes to the comparably larger migration time. Such
strategy checks which classes are going to be needed and
retrieves them one by one. In comparison, ATALK migrates the counting role component, together with its state,
in one package which demands far less communications.
Consequently ATALK can achieve much less MTTR with
respect to JADE.
Of course, ATALK currently does not include all the features of JADE—for instance it does not support the FIPA
communication specifications. This might not accurately
reflect the performance differences between ATALK and
JADE. However, we argue that allowing only a fraction of
the agent to be transferred shall result in a better performance.
4.2.3. Role-Based Self-Organization
In this section, the motivational scenario presented in Sect. 2
is implemented with simulated robots and roles. For the
sake of simplicity only two types of roles are introduced:
Coordinator and Worker. The definition of those roles is
consistent with those provided in our motivational example. In this scenario, four robots join the organization at
different times. Each robot is assumed to be heterogeneous in communication and processing capabilities. Table 2 shows the arbitrarily values assigned to the robots as
well as times for joining the organization.
As described in Sect. 3.3, different roles might require different capabilities to the systems. Here, when an agent
takes the Coordinator role, this corresponds to a requirement of about 100kbps communication bandwidth per managed Worker. When an agent takes the Worker role, this
accounts for about 30% CPU time and 100KBps of communication bandwidth. Here, in order to avoid fluctuations when measuring resource consumption, predefined
consumption rates are simulated rather than collected from
actual data. We also assume that an agent takes any
open role position whenever it has the necessary resources.
However, the actual role assignment is decided by organization rules.
Table 1 shows the comparison between ATALK and JADE
when recovering the counting behavior with two hosts.
Each host has one agent deployed. In JADE, as the agent’s
behavior is statically embedded in the agent itself, the
whole agent needs to be migrated. This includes codes for
the agent, three counts of agent behaviors, and the agent
state. In contrast, in our platform, only the counting behavior (role) needs to be migrated—the other functions
are either provided by the hosts or by the basic agent implementation, which is not needed for migration.
Due to the diversity in available resources, it is easy to see
that depending on which robot is Coordinator the system
As a result, migration takes about 145.3ms in ATALK
11

12. Table 2: Agent properties and participation time
Robot
A
B
C
D
CPU (percentage)
40
30
10
30
Bandwidth
(Kbps)
200
150
400
200
Time in entering
organization(s)
0
50
60
100
shall support a different number of Workers. As an example, a choice of Robot A results in at most two Workers as
A can only sustain a communication bandwidth of up to
200Kbps, while the superior communication capability of
C allows it to support at most four Workers.
(a) Without role relocation
In order to better optimize system resources, two rules are
defined in the organization.
1. The organization assigns a new Worker contract to
an available robot only if the current coordinator has
enough resources to support this new position.
2. The Coordinator role is assigned to the requesting
agent that can support the largest amount of Workers.
(b) With role relocation
Figure 10: Organization configuration after about 120s.
Worker role. The new Coordinator, Robot C, can support
more than 3 Workers, therefore it opens a new position for
Worker. This allows Robot D to assume the Worker position. After this reorganization process, the system moves
into the state shown in Fig. 10(b).
When Robot A just joins the organization, it is the only
one agent that can play Coordinator. Thus, the maximum
number of supported Workers is 3. Figure 10 shows the final organization configuration when the agents are defined
without (a) or with (b) role migration logic at simulation
time 120 seconds—20 seconds after all four agents have
joined the organization—when the organization reaches a
stable state.
What is apparent from the above scenario is that, by enabling agents to exchange their enacting roles, ATALK can
help organizations self-organize into more efficient configurations with little additional complexity. Although the
adaptation rules specified here are very simple and only for
demonstration purposes, ATALK allows other mechanisms—
as for instance the cost-aware transition of (Alberola et al.,
2013)—to be used to provide more general reorganization
strategies without jeopardizing the consistence of the organization.
Case (a): Role relocation disabled. According to its
definition, the Coordinator keeps track of the current process in task assignments and it is vital for the function
of the collective task at hand. In this case, it is impossible for the agent to dismiss its Coordinator role. Thus,
if Robot A assumes this role, it has to continue to enact
it until the organization decides otherwise lest the whole
computation process would fail. As Robot A has limited
communication capability that allow it to support up to
two external workers, Robot D cannot take any role and
keeps idle. Organization resources cannot be effectively
used. The system then “locks in” to the configuration
shown in Fig. 10(a).
5. Related Work
In this section, existing role-based agent platforms are
briefly presented and compared with respect to several
metrics. The comparison results are shown in Table 3.
Case (b): Role relocation enabled. When role relocation is enabled, robots can handover its role to other
participating robots. As an example, when Robot D joins
the organization at 100s, Robot A finds it can not support
more workers. By using ATALK it is possible for it to
choose to hand over its Coordinator role to other agents.
Robot A then opens a new Coordinator role position and
waits for other agents to assume that position. Then, the
organization signs a Coordinator role contract with Robot
C as it supports the largest amount of workers (4 workers). As soon as the contract is signed, role and states are
packaged together and transferred to C. After this process A dismisses the Coordinator role and only plays its
As can be seen in Table 3, most reviewed organizationbased agent platforms provide similar support for role dynamicity and openness. All reviewed approaches provide
support on the role dynamicity and most approaches, with
the exception of MACODO, support an agent to interact
with possibly unknown roles.
However, with reference to how roles are engineered, two
major streams of techniques are adopted. One stream,
including e.g. RICA-J (Serrano and Ossowski, 2004), Smoise+ (H¨bner et al., 2006, 2010) and THOMAS (Rou
driguez et al., 2011), adopts role specification languages
12

13. Table 3: Comparisons with existing organization infrastructures: - represents not clear
General Design
Dynamic
Roles
BRAIN
Yes, AOP
RICA-J
Yes,
refl.
Kendall
Yes, AOP
MACODO
S-moise+
THOMAS
ATALK
Java
Yes, role
facade
Yes, OrgBox
Yes,role
proxy
Yes,dynamic
binding
Openness
Run-time
weaving
Dynamic
binding
Run-time
weaving
No
Parsing
Parsing
Run-time
binding
Role Implementation
Role
Role Model
Notation
Agent Archtecture
Internal
Arch.
Role
Manag.
Decentr.
arch.
Role Deployment
Role
Relocation
Aspects
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
No
No
-
No
No
Yes
-
No
-
No
No
No
-
No
Yes
Yes,
SOA
Yes
Yes
Yes
Java
jects
ob-
Aspects
Java
Objects
Role
language
Role
language
SOA
Yes
to describe roles and their norms. Agents have to parse
those role descriptions and act upon them. The capability of roles are limited by the descriptive power of those
role description languages. However, the more sophisticated the language, the more the execution power it will
be spent in parsing the role descriptions. The second major stream of works explicitly represent roles as software
entities. Agents can play the roles by directly operating
the software entities. This technique is comparably easier to implement and demands less resoures compared to
approaches in the first stream. Due to these positive features, this technique is widely adopted in many projects.
The practical implementation of their software entities,
however, varies from pure object-based, aspect-oriented
to component-based approaches in order to support role
dynamicity.
Organization
For the agent architecture, many approaches, e.g. S-moise+,
THOMAS, adopt the black-box model to model agents. In
theory, those systems allow any agent to be used regardless its internal structure. However, this black-box model
makes it very hard for agents to integrate roles from the
organization. In order to participate in the organization,
those approaches normally require agents to be ”organization aware” which, to some extent, also contradicts the basic assumption of the black-box model. Furthermore, existing approaches provide little discussion on how to manage assumed roles. In those approaches, roles are solely
managed by the organization and the agents have little
control on role management.
With respect to the organizational architecture, we observe that most existing approaches provide no clear support for decentralization, despite its being a typical trait
of many open MAS. Centralized designs commonly foresee one pre-defined host to provide blackboard services.
In contrast, the decentralized architecture of ATALK allows it to be deployed on a dynamic number of hosts
with no need for a central control point. This feature
makes ATALK particularly suitable in changing environment with a dynamically varying set of hosts. Another
distinguishing feature of ATALK in the organization design is its support of role relocation among agents. This
feature has not been discussed in other organization-based
agent platforms. Without this support, it is very hard for
other approaches to support scenarios in which an agent
dismisses its enacting role.
Some approaches, such as RICA-J, use object-oriented
programming to implement roles. As the object-oriented
model lacks support on dynamic role reference management, OOP-based approaches need a custom design to
overcome this limitation. The AOP techniques can weave
roles into agents during run-time which can alleviate the
needs of dynamic role reference management. However, as
it has been discussed in Sect. 3.3, the use of AOP leads to
possible reusability problems. Furthermore, as aspects can
be weaved anywhere in the code, the agent will have no
control on the weaved-in roles. This limitation makes those
weaved-in roles very hard to manage and coordinate. In
contrast to those approaches, ATALK adopts SOA, which
provides native support for role dynamicity. The binding between agents and roles can be easily built through
service-binding.
6. Conclusion
Apart from Role language based approaches, only BRAIN
and ATALK explicitly provide role annotation definitions.
Missing this information makes it difficult for agents to
choose among roles. As we already discussed, ATALK
features an agent annotation format that allows functional
and non-functional capability requirements to be expressed
and reasoned upon. This allows agents to infer whether
they have the capabilities required to play a role.
Our main focus in this paper is the problem of how to
deploy effectively organization specifications to participating agents in a fully decentralized and open environment.
In order to simplify the deployment of role specifications
from an organization to its agents we proposed ATALK,
a service-oriented decentralized middleware. In ATALK
roles are explicitly presented as service components. With
the definition of a role functional interface as well as with
13

14. its meta-data description, agents can query, reason, and
interact with different roles. The whole life-cycle of role
components is explicitly defined. Based on the serviceoriented role component model, a compositional agent architecture has been defined to facilitate the run-time role
management.
Artikis, A., 2012. Dynamic specification of open agent systems. Journal of Logic and Computation 22, 1301–1334.
Bellifemine, F., Giovanni Caire, T.T., Rimassa, G., 2009. JADE
PROGRAMMERS GUIDE. Telecom Italia S.p.A.
Boissier, O., H¨bner, J.F., Sichman, J.S., 2007. Organization oriu
ented programming: From closed to open organizations. Engineering Societies in the Agents World VII 4457, 86–105.
Brian, H.S., Conor, W., 2009. Utilizing dynamic roles for agents.
Journal of Object Technology 8, 177–198.
Cabri, G., Leonardi, L., Zambonelli, F., 2003. Brain: A framework
for flexible role-based interactions in multiagent systems. On the
Move to Meaningful Internet Systems 2003: Coopis, Doa, and
Odbase 2888, 145–161.
Cervantes, H., Hall, R.S., 2004. Autonomous adaptation to dynamic
availability using a service-oriented component model, in: Proceedings of the 26th International Conference on Software Engineering (ICSE 2004), pp. 614–623.
Dahchour, M., Pirotte, A., Zimnyi, E., 2004. A role model and its
metaclass implementation. Information Systems 29, 235–270.
Dastani, M., Dignum, V., Dignum, F., 2003. Role-assignment in
open agent societies, in: Proceedings of the second international
joint conference on Autonomous agents and multiagent systems,
ACM. pp. 489–496.
De Florio, V., Deconinck, G., Lauwereins, R., 2000. An algorithm for
tolerating crash failures in distributed systems, in: Proc. of the
7th Annual IEEE International Conference and Workshop on the
Engineering of Computer Based Systems (ECBS), IEEE Comp.
Soc. Press, Edinburgh, Scotland. pp. 9–17.
Esteva, M., Rosell, B., Rodriguez-Aguilar, J.A., Arcos, J.L., 2004.
Ameli: An agent-based middleware for electronic institutions, in:
Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems - Volume 1, IEEE Computer Society. pp. 236–243.
Fuggetta, A., Picco, G.P., Vigna, G., 1998. Understanding code
mobility. IEEE Transactions on Software Engineering 24, 342–
361.
Fujii, K., Suda, T., 2009. Semantics-based context-aware dynamic
service composition. ACM Transactions on Autonomous and
Adaptive Systems 4, 12–42.
Gorton, I., 2006. Essential software architecture. Springer, Berlin ;
New York.
Gui, N., De Florio, V., 2013. Atalk platform, in: Technical report,
Zhejiang Sci-Tech Univ.
Gui, N., De Florio, V., 2013. Transformer: an adaptation framework with contextual adaptation behavior composition support.
Software Practice & Experience 43, 937–967.
Gui, N., De Florio, V., Sun, H., Blondia, C., 2008. A framework
for adaptive real-time applications: the declarative real-time osgi
component model, in: Proceedings of the 7th Workshop on Adaptive and Reflective Middleware(ARM), pp. 1–8.
Gui, N., De Florio, V., Sun, H., Blondia, C., 2011. Toward
architecture-based context-aware deployment and adaptation.
Journal of Systems and Software 84, 185–197.
Gunasekera, K., Krishnaswamy, S., Loke, S.W., Zaslavsky, A., 2009.
Runtime efficiency of adaptive mobile software agents in pervasive computing environments, in: Proceedings of the 2009 International Conference on Pervasive services, ACM. pp. 123–132.
Gutknecht, O., Ferber, J., 2001. The madkit agent platform architecture, in: Proceedings of the International Workshop on Infrastructure for Multi-Agent Systems: Infrastructure for Agents, MultiAgent Systems, and Scalable Multi-Agent Systems, SpringerVerlag. pp. 48–55.
H¨bner, J., Boissier, O., Kitio, R., Ricci, A., 2010. Instrumenting
u
multi-agent organisations with organisational artifacts and agents.
Autonomous Agents and Multi-Agent Systems 20, 369–400.
H¨bner, J.F., Sichman, J.S., Boissier, O., 2006. S-moise(+): A midu
dleware for developing organised multi-agent systems. Coordination, Organizations, Institutions, and Norms in Multi-Agent
Systems 3913, 64–77.
Ibrahim, A., Zhao, L.P., 2009. Supporting the OSGi service platform with mobility and service distribution in ubiquitous home
In order to support open systems with dynamic host participation and departure, our middleware is designed to be
fully decentralized. Role deployment within an ATALK organization is supported through a decentralized role repository. Each host only contains a subset of all role components. The ATALK middleware provides explicit support for role deployment and relocation through the definition of the role import and mobility services. Those
two services allow role instance to migrate within the organization, possibly together with their run-time states.
We conjecture that changing the focus from agents to
roles may greatly improve the efficiency when migrating
tasks between nodes. Preliminary evidence to this fact
was brought by comparing a self-healing scenario between
purely agent-based approaches and ATALK. Moreover, we
observed how this decoupling allows the organization to
avoid lock-ins and inefficiencies while managing self-organization.
We identify the following areas open for further research:
Firstly, our role model shall be extended. In ATALK currently an agent can perform a role as long as it satisfies all
capability requirements. This solution actually assumes
that the agent is always consistent with its enacting roles.
However, as pointed out in many approaches, agents might
have goals conflicting with those of its enacted roles. Similar conflicts may also arise between two or more roles enacted by the same agent. We are currently working towards effective methods to detect and resolve goal conflicts among agents and their enacted roles based on our
previous work (Gui and De Florio, 2013).
Secondly, we are aware that in the current prototypical
implementation the coherence of the overall organization
specification may be jeopardized by host departures or
crashes. We are now tackling this aspect by integrating
our previous work (De Florio et al., 2000).
Finally, our current implementation is based on a custom
communication protocol and therefore has limited interoperability. We intend to tackle this issue by adopting the
FIPA protocol for agent communication.
References
Alberola, J.M., Julian, V., Garcia-Fornes, A., 2013. Using cost-aware
transitions for reorganizing multiagent systems. Engineering Applications of Artificial Intelligence 26, 63–75.
Amor, M., Fuentes, L., 2009. Malaca: A component and aspectoriented agent architecture. Information and Software Technology
51, 1052–1065.
14

15. environments. Computer Journal 52, 210–239.
JBoss Community, 2011. Jboss aspect-oriented programming. http:
//www.jboss.org/jbossaop/.
Kendall, E.A., 2000. Role modeling for agent system analysis, design,
and implementation. IEEE Concurrency 8, 34–41.
Michael, B., 1999. Rope: Role oriented programming environment
for multiagent systems, in: Thorsten, G., rgen, K., Matthias, M.
(Eds.), Proceedings of the International Conference on Cooperative Information Systems, pp. 325–333.
Omicini, A., Ricci, A., Viroli, M., 2008. Artifacts in the a & a
meta-model for multi-agent systems. Autonomous Agents and
Multi-Agent Systems 17, 432–456.
OSGi, 2011. Declarative service specification, v4.1. http://www.
osgi.org/.
OSGi Committee, 2011. Open gateway service specification. http:
//www.osgi.org/.
Rodriguez, S., Juli´n, V., Bajo, J., Carrascosa, C., Botti, V., Cora
chado, J.M., 2011. Agent-based virtual organization architecture.
Engineering Applications of Artificial Intelligence 24, 895–910.
Serrano, J., Ossowski, S., 2004. On the impact of agent communication languages on the implementation of agent systems, in:
Klusch, M., Ossowski, S., Kashyap, V., Unland, R. (Eds.), Cooperative Information Agents VIII, Springer Berlin / Heidelberg.
pp. 92–106.
Sycara, K., Widoff, S., Klusch, M., Lu, J.G., 2002. Larks: Dynamic
matchmaking among heterogeneous software agents in cyberspace.
Autonomous Agents and Multi-Agent Systems 5, 173–203.
Tinnemeier, N., Dastani, M., Meyer, J.J., 2009. Roles and norms
for programming agent organizations, in: Proceedings of The 8th
International Conference on Autonomous Agents and Multiagent
Systems - Volume 1, International Foundation for Autonomous
Agents and Multiagent Systems. pp. 121–128.
Tuscany, 2011. Apache tuscany project. http://http://tuscany.
apache.org//.
van Riemsdijk, M.B., Dignum, V., Jonker, C.M., Aldewereld, H.,
2011. Programming role enactment through reflection, in: Proceedings of the 2011 IEEE/WIC/ACM International Conferences
on Web Intelligence and Intelligent Agent Technology - Volume
02, IEEE Computer Society. pp. 133–140.
Ward, C.B., Henderson-Sellers, B., 2009. Utilizing dynamic roles for
agents. Journal of Object Technology 8, 177–198.
Weyns, D., Haesevoets, R., Helleboogh, A., 2010a. The Macodo organization model for context-driven dynamic agent organizations.
Acm Transactions on Autonomous and Adaptive Systems 5.
Weyns, D., Haesevoets, R., Helleboogh, A., Holvoet, T., Joosen, W.,
2010b. The Macodo middleware for context-driven dynamic agent
organizations. ACM Trans. Auton. Adapt. Syst. 5, 1–28.
Xstream, 2012. A simple library to serialize objects to xml. http:
//xstream.codehaus.org.
15