ATALK: A Decentralized Agent Platform for EngineeringOpen and Dynamic Organizations

Ning Guib,a,∗, Vincenzo De Florioc, Tom Holvoeta

aDistrinet Lab, University of Leuven, BelgiumbDepartment of Computer Science, Zhejiang Sci-Tech University, China

cPATS group, University of Antwerp, Belgiumand iMinds research institute, Ghent-Ledeberg, Belgium

Abstract

In recent years the concept of “organization” has been gradually accepted as a suitable abstraction for the developmentof open multi-agent systems with dynamic agents. By modelling interactions based on roles, this abstraction allowsan organization to be modelled independently of its participating agents so as to support agent dynamicity. A naturalrequirement 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 decentralizedand dynamic environment is still an open issue. This paper addresses this problem by presenting ATALK, a noveldecentralized agent middleware that fulfills the above requirements. A role component model is designed to facilitaterole deployment, reflection and uniform role interaction. In order to support role dynamicity, a compositional agentarchitecture allowing dynamic role integration and enactment is proposed. Moreover, ATALK allows agents to hand overtheir role to other agents of a same organization with their run-time states. Thus, agents can dynamically relinquishtheir roles without jeopardizing the normal execution of the organization. This paper also evaluates our design andcurrent prototypic implementation through both qualitative analysis and simulations. Our results show that ATALKachieves 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 ofheterogeneous devices with different computing power, sen-sors, functions, and degree of availability. In order toachieve their design goals, those devices have to be or-ganized and coordinated. The dynamic and decentralizednature of those devices demands support of open systemsable to accommodate for changes affecting the constituentdevices (Boissier et al., 2007). Multi-agent Systems (MAS)are gaining increasing popularity as a tool to create suchopen and decentralized systems in that MAS can dynam-ically reorganize themselves when system goals or partici-pating agents change (Weyns et al., 2010b).

A recent and increasingly widespread trend of agent re-search communities is the use of the concept of organiza-tion (also referred to as “society” (Dastani et al., 2003),“institution” (Esteva et al., 2004) and other terms) asa tool to structure and manage the interactions in openMAS. In organizations, the interactions between agents

∗Corresponding authorEmail addresses: ninggui@gmail.com (Ning Gui),

vincenzo.deflorio@uantwerpen.be (Vincenzo De Florio),tom.holvoet@cs.kuleuven.be (Tom Holvoet)

are modeled in terms of a set of roles rather than a col-lection of agents. Each role is responsible for a partic-ular functionality of an organization and is to be playedby any agent satisfying its requirements. Using dynam-ically assignable roles rather than actual agents providesthe designer with a higher level of abstraction that allowsan organization and its roles to be developed separatelyfrom the agents that will play them (Tinnemeier et al.,2009). This feature facilitates considerably the develop-ment of open systems—systems that is in which heteroge-neous agents might join or leave the organization at will. Anatural requirement resulting from this abstraction, how-ever, requires the participating agents to be “organizationaware”, meaning that they have to be able to inquire, im-port, and execute roles from the organization they belongto. Enabling these processes is further complicated by thedynamic and decentralized nature of open systems. Dueto the dynamic availability of the devices they are builtupon, it is hard and makes little sense to foresee a fixeddevice for hosting organization services.

This paper provides a novel approach to the above prob-lems by tackling the following issues:

� Allowing agents to access the roles of an organiza-tion in a decentralized environment. When an agent

Preprint submitted to Engineering Applications of Artificial Intelligence October 7, 2013

joins an organization, role specifications of this or-ganization should be made available to the agent fordeployment. Due to the open and decentralized na-ture, such role deployment must be performed with-out the existence of a central control point.

� Enabling agents to dynamically integrate and exe-cute external roles. When an agent acquires a rolefrom an organization, it has to adjust itself so asto integrate the features of the role (Dastani et al.,2003). As agents are to play independently-developedroles, this integration process should be general todifferent types of roles.

� Supporting run-time role relocation. This featuremakes sure that the organization is not disrupted byagents leaving the organization abruptly. In order toachieve this objective software agents are made ableto hand over their roles to other agents at the stageof their enactment.

Our answer to the above issues is given by the ATALKmiddleware platform. In order to simplify the role deploy-ment process, ATALK explicitly represents roles as service-oriented 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 introduc-tion of a compositional agent architecture. Said architec-ture provides an event-based role execution environmentfor its enacting roles. One important feature of ATALKis its support of fully-decentralized role deployment andstateful role relocation among participating agents. Thisfeature is supported by a decentralized role repository forthe organization-level role deployment and a role mobilityservice enabling the role relocation process.

This paper presents the ATALK agent platform as well asa set of qualitative evaluations of the current prototypicalimplementation. The evaluation is carried out within aset of contexts: dynamic role deployment; a self-repairingprocess; and self-organization of robots. Our analysis andsimulation results show that ATALK achieves high orga-nization reconfigurability with little additional overhead.

The rest of the paper is organized as follows. Section 2describes a motivational example to introduce the conceptsof decentralized role deployment and relocation. Section3 presents the design as well as the key components ofATALK. Our current prototypical implementation, as wellas comparisons with existing frameworks, constitute thesubject of Section 4. Related work is discussed in Section5. Our preliminary conclusions and a view to some futurework are provided in Section 6.

2. Motivational Example

In what follows we introduce a case study so as to motivatethe requirements pointed out in Sect. 1. Our case study

depicts a swarm of heterogeneous robots that self-organizeto 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 unitcapable of processing the monitored data; a unit that en-ables communication with nearby robots. Robots are het-erogeneous in terms of hardware specification and availableresources, e.g. different battery characteristics, CPU andcommunication capabilities. For simplicity of treatise weassume that each robot hardware device is managed andrepresented by a software agent of the same name. Asan example, Robot A shall be used to represent both therobotic device as well as the software agents that managethat device.

In what follows, we assume those robots are coordinatedthrough the definition of an ”organization”. The organi-zation is designed to optimize the ore exploration processwith a dynamic set of robots. In order to achieve theorganizational goal, three roles are introduced: Coordina-tor, Worker, and Attractor. 1) The Coordinator assignstasks to all the Workers within the organization; processesthe data sensed by the Workers; draws an ore distributionmap. 2) The Worker receives task assignments from theCoordinator; wanders around and identifies ore location byprocessing data from its sensors; transfers ore location tothe Coordinator. 3) The Attractor broadcasts invitationmessages to all robots in range. In addition to those roles,the organization also comprises laws expressing structuralconstraints, e.g. only one robot may play the coordinatorrole.

Without loss of generality, we assume Robot A initiallyruns a copy of the organization specification and takesboth the Attractor and Coordinator roles. In order toachieve the organization goal, as Coordinator, Robot Aopens several positions for Workers to attract other robots.Here, a role position represents a call for roles (Serrano andOssowski, 2004). At a later point, a second robot, RobotB, is deployed and joins the organization by acquiring acopy of the organization specification. Thus, the organiza-tion extends to two robots, each robot maintaining a copyof the organization specification as well as its current state.The consistence of the replicated organization can be guar-anteed through a synchronization service, which has beenextensively discussed in our previous work (Weyns et al.,2010b).

Role deployment and integration. By acquiring acopy of the specification as well as the state of the organi-zation, Robot B becomes aware of the positions currentlyopen. As a result, it chooses to take the Worker positionby sending a request to the organization. If the request isallowed, a role contract is signed between the organizationand Robot B. Once this is done the Worker specificationcurrently located in Robot A is transferred to Robot B.When the latter receives the role specification, said role isembodied. This results in an instantiation of the role—referred in what follows as a role instance. Robot B then

2

(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, andD as Workers; (b) Robot B as Coordinator, Robot C as both Worker and Attractor, and Robot D as worker.

modifies itself to integrate the new role instance.

It is worth noting how multiple robots may hold the samerole—and therefore exhibit similar behaviors—though theircorresponding role instances shall be in general in differentstates. Figure 1(a) shows the organization configurationwith three Workers who are assigned with different explo-ration areas.

Role relocation. Due to resource fluctuations or avail-ability considerations, a robot, for instance Robot A, maybecome unable to fulfill its roles. As a consequence, itmay want to dismiss some or all of its enacting roles. Nor-mally, the corresponding role instances should be immedi-ately destroyed after the role dismission. However, certainrole instances, as for instance the Coordinator, may man-age run-time data that is not replicated in any other roleinstance. Examples of such data may include, e.g., taskassignments, territory explored so far, or a partial mapof the territory. Because of this unicity Robot A can-not directly dismiss the Coordinator role instance, lest thewhole organization would lose track of the current explo-ration process and fail to achieve its goal. In order toguarantee the correct execution of the organization, it isimportant to allow Robot A to hand over its Coordinatorrole to another robot, together with the current state ofthe corresponding role instance. Only once this is doneRobot A may leave the organization without disruptingthe organizational mission. Figure 1(b) shows one pos-sible configuration with Robot B taking the Coordinatorrole and a new robot, say Robot C, taking the attractorrole.

Formal definitions of the core notions such as role, agent,organization, role position, role contract etc. are specifiedin our previous work. Readers who are interested in the

formal definitions of those concepts can refer to (Weynset al., 2010a).

3. Middleware Architecture

In this section we describe the architectural design of ATALK.We firstly analyze the design requirements that underpinthe ATALK software architecture. Then we describe thelayered software architecture as well as its key elements.

3.1. Requirement Analysis

From the motivational example, a set of requirements areidentified.

� Role representation. The motivational exampleshows that roles can be designed out of the scope ofagents 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; Gu-nasekera et al., 2009), pointed out that roles shouldbe represented as first-class citizens and explicitlyimplemented as software entities, rather than puremodeling concepts as in (Brian and Conor, 2009).In order to support the dynamic role inquiry, eachrole should contain meta-data for agents to evaluateits requirements. As an agent should be able to in-teract with un-prescribed roles, it is important thatall those roles can be accessed in a uniform way. Fur-thermore, roles should be designed to facilitate theprocess of run-time deployment and execution.

3

Figure 2: Layered view of an ATALK system

� Agent-level role management. In an organiza-tion, agents need to be able to assume, manage, anddismiss roles during run-time. When an agent beginsto play a role, it modifies itself to integrate the role-specific knowledge and strategies so as to become“aware” of role-specific events and takes correspond-ing actions according to its enacting role’s strategies.An agent can play simultaneously multiple roles andits enacting roles might change throughout its entirelife-cycle. Thus, a basic requirement for agents is therun-time role management support.

� Organization-level role deployment & reloca-tion. As shown in the motivational example, oneorganization may be distributed across a dynamicset of hosts with no prescribed central control point.With the change of the constituent hosts, roles of anorganization might reside on different hosts at differ-ent times. It is often difficult and in some cases un-feasible for agents to track the current location of allorganizational roles. Thus, a organization-level roledeployment service is needed to allow agents to ac-cess the organization specification in a uniform way.Furthermore, it is also vital to allow agents to handover their enacting role instances to other agents to-gether with their current states. As a consequence,the agent platform must support the role relocationprocess in a decentralized way.

The ATALK middleware platform is designed taking theabove requirements into account.

3.2. Layered View of an ATALK System

Figure 2 shows a layered view of an ATALK system de-ployed across multiple hosts. This system consists of four

layers. Of those four layers, the two in the middle consti-tute the ATALK middleware.

� Domain agent layer. This layer contains agents de-signed for application specific goals (denoted as do-main agent). Each agent embodies its own objectivesand goals and decides autonomously whether to joinor how to participate in an organization. When a do-main agent decides to play a role, a new role instanceis initialized. The agent exhibits its role-specific be-havior by forwarding role-related events to its roleinstances and performs actions issued by said in-stances. When an agent chooses to dismiss one ofits roles, the corresponding role instance is deacti-vated. As a consequence the agent stops receivingevents related to the dismissed role.

� Agent-level role management layer. For any agent toparticipate in a given organization, it must be ableto access role evaluation, management, and execu-tion services. This layer provides an abstraction be-tween domain agents and their enacting roles withimportant role management services, e.g., the re-quirements evaluation service and the role executionservice. The introduction of this layer shields domainagent developers from the complexity needed to pro-vide ad-hoc “role management” and allows them tofocus on the development of agent domain logic.

� Organizational layer. This layer provides role man-agement services in the organization level. As shownin Fig. 2, an organization might cover multiple hosts.Each host contains a (partial) copy of the organiza-tion instance. Different organization instances aresynchronized periodically to keep a coherent recordof the organization. The registry service is designedso as to provide a consistent view to the organization

4

configuration across multiple hosts. In order to re-duce the resource usage in term of transmission andstorage, a decentralized role repository is defined tostore role components across multiple hosts. The roleimport service is defined for agents to retrieve rolecomponents from the organization to the local host.The role relocation process is supported by the rolemobility service. The organization layer also enforcesconstraints and rules specific to the referred organi-zation. For instance, in the scenario discussed inprevious section, the organization layer is to ensurethat only one robot may play the Coordinator role.This layer may also contain other logic—for instanceto optimize role assignment within the organization.

� Communication Layer. The communication layerconnects all components within an organization byproviding common communication services and basicsupport for distribution.

The layered design is commonly used in many organiza-tional agent middleware (Gutknecht and Ferber, 2001; Es-teva et al., 2004; Hubner et al., 2010; Weyns et al., 2010b)as it provides a strict isolation between different designconcerns and allows for a modular implementation. How-ever, those approaches normally focus on separating theorganization management complexity from agent develop-ment. Little discussion has been provided on how agentsand the organization can effectively manage the role in andecentralized environments.

In comparison, ATALK is designed with special attentionto the supports of role deployment, run-time role inte-gration, and relocation processes in decentralized and dy-namic environments. Those processes are supported bythe following peculiar design choices: 1) A service-orientedrole component model to facilitate run-time role deploy-ment and interaction; 2) a compositional agent architec-ture for run-time role integration and execution; 3) orga-nizational support for decentralized role deployment andrelocation. The following sections provide detailed intro-duction to each of the above aspects.

3.3. The ATALK Role Component Model

Similarly to many existing approaches, e.g. BRAIN (Cabriet al., 2003), ATALK models roles through a so-calledEvent-Action model. Accordingly, a role is sensible toparticular type of events and responds with a set of cor-responding actions depending on its logic. In this sectionwe focus on the design of a role component model whichallows for role inquiry, run-time deployment and uniforminteractions.

3.3.1. Service component role model

In order to provide a light-weight and simple role inte-gration support, a component model based on the Ser-vice Component Architecture (SCA) has been designed.

Figure 3: The service component model of roles.

Said component model supports the run-time deploymentof role components, thus making it possible to dynamicallyintroduce new role components to the agent. When a rolecomponent is deployed and initialized, the reference to theprovided service will be registered in the service registryand can be queried, bound, and unbound by the agentduring the run-time. Figure 3 shows this dynamic bindingprocess.

As agents need to work with different possibly unknownroles, the general service component model needs to beextended to provide support for uniform role interactionand for role requirement description. In order to addressthese two issues, a role interface and a meta-data formathave been defined.

General role interface for interaction

Open systems require that an agent plays possibly un-known roles, possibly developed by third parties. Thus,it is very important that a role component could be ac-cessed and managed in a uniform way. As a consequence,a uniform interface—IRole—has been defined and needsto be implemented by all role components. Said interfaceincludes methods for both life-cycle management (for in-stance, to start or stop a role) and event-based interactions(e.g., event process methods) as well as methods for rolerelocation by saving and restoring the state of the role in-stance. A detailed definition for the IRole interface can befound in (Gui and De Florio, 2013).

Meta-data for role description

Because of the separation of concerns between roles andagents, role components must be described in a mannerthat allows agents to search and evaluate them—for in-stance checking whether the required capabilities are sat-isfied by an agent. This calls for enabling the exposureof a role component’s both functional and non-functionalrequirements. In ATALK, functional requirements are de-signed based on the OSGi Service Component Model (OSGi).For the non-functional requirements, a simple resource re-quirement format, similar to the one in (Fujii and Suda,2009), was adopted. The following codes describes an ex-ample of resource requirements for a Worker’s capability

5

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 enactmentdoes not only require enacting agents but also introducesrequirements to other agents. Thus, ATALK introducesthe Scope keyword to specify requirements towards dif-ferent organization entities. In the first part of the aboveexample the agent enacting the Coordinator role states itrequires a minimal communication bandwidth of 100kpbsfor each Worker it coordinates. The second part statesthat the Worker role requires its enacting agent—denotedby “hostagent”—to have the following features: mobility,30% or more of residual CPU, and at least 100kbps ofresidual bandwidth. Only when both the agent and Coor-dinator satisfy all those conditions the agent can assumethe corresponding role.

Discussions

Although most researchers agree that roles should be rep-resented as first-class citizens and explicitly implementedas software entities, there is still lack of consensus on howto engineer them. Existing approaches implement rolesby using either object-oriented programming (OOP) (as,e.g., in ROPE (Michael, 1999) and the meta-class imple-mentation (Dahchour et al., 2004)) or aspect-oriented pro-gramming (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 pro-vides no native reference management, ad-hoc solutionsfor object reference management are needed. In the latterstream of approaches, roles are implemented as aspectsand can be dynamically weaved into agents during run-time with certain hot-spot AOP run-time, as e.g. in JBossAOP (JBoss Community, 2011). This weaving processeliminates the need to provide dynamic reference manage-ment. However, as aspects (roles) are directly weaved intoagents at source code level, role developers need to haveaccurate information about the codes of the agents. Thisstrong coupling between role aspects and agents makes therole modules very hard to be reused across agents.

In comparison, existing off-the-shelf service component run-times already provide rich support for run-time compo-nent deployment and dynamic reference management, asit is the case, e.g., for the service component run-timein the declarative service (OSGi), in the Apache Tuscanyproject (Tuscany, 2011), and in our previous work (Guiet al., 2008). Implementing roles as service componentscan largely facilitate reusing those services and eliminatesthe need to provide ad-hoc solutions for reference manage-ment. As agents and roles can interact through pre-defined

Figure 4: Role component state changes with agent actions.

role interface, the source-code level coupling exhibited byAOP-based approaches is eliminated.

3.3.2. Lifecycle Definition

As discussed in the motivational example, a role compo-nent can be deployed from the organization, checked forconstraints, and integrated into its enacting agent. Duringthese processes, role states change. Figure 4 illustrates thelife-cycle of a role component.

As shown in Fig. 4, the lifecycle changes of role compo-nents are driven by the following entities: the domainagent, role management services, and the organization. Inparticular, the organization manages the role deploymentand undeployment process within the organization whilethe local role manager checks capability constraints on be-half of agents. If the constraints are satisfied, it signifiesthat the agent satisfies all its requirements and the role isready to be assumed. On the contrary, the role managersets its state to ”unsatisfied”. Domain agents in particu-lar only focus on whether to take the “satisfied” roles ordismiss unwanted roles. This separation helps agent de-velopers focus on the development of the domain-specificlogic.

Compared to other service-oriented component models,one distinguished feature of the ATALK role component isthe introduction of the ”serialized” state. In this state, arole pauses its execution and stores its run-time states intopersistent storage (viz., files). This state is introduced tofacilitate the role relocation process.

3.4. Compositional Agent Architecture

One of the basic requirements for organizational agentsis the capability to play roles defined in the organization.This includes the ability to sense role availability, to rea-son about role requirements, and to interact with roles.

6

Figure 5: Diagram of an agent’s internal architecture.

Although such functionality is not related to the agent’score application logic, it accounts for a considerable shareof the agent development complexity. Because of this, weintroduce the compositional agent architecture with twopre-defined services: “requirement verification” and “roleexecution”.

Agent internal architecture. Similarly to the case of roledefinition, an ATALK agent is also modeled through theevent-action model. An agent receives events and issuesactions to make changes according to its application logicas well as its enacting roles. Figure 5 shows the design ofthe agent’s internal architecture.

In this design, an ATALK agent constitutes a domain-specific logic (denoted as domain agent), with reusableservice modules such as requirement verification serviceand role execution services, and organization-related roles.Those modules are driven by the events received by theagent. Some events are sent from the organization—suchas the messages of agent participation or departure—whileothers come from other agents or from role instances playedby other agents. Those events are dispatched by the “roleexecution service” to the agent or specific roles. Then, theagent and its enacting roles can issue their correspondingactions for execution. The AgentContext takes track ofthe agent’s run-time status and is organized as a set of“(property, value)” couples.

Requirement verification service. Through this functionthe role manager verifies whether an agent has the capabil-ities necessary to perform the current role. This is similarto the function provided by GateKeeper (van Riemsdijket al., 2011) and the match-maker in Larks (Sycara et al.,2002). The validation is conditioned to the role compo-nent’s meta-data and the agent’s current status, as storedin the AgentContext. The state of the role component ischanged according to the result of the verification.

As an example, if the AgentContext of a robot, e.g. RobotC, is as follows:

(capability.moving,true), (resource.CPU.available,50),(resource.bandwidth.available,300),

then when the organization opens a new role worker posi-tion, this service can check the requirements of this posi-tion on behalf of the robot. In the exemplified case RobotC clearly satisfies all the requirement. As a consequence,this service changes the status of the worker componentto “satisfied”. When the context changes, the agent mightnot be able to fulfill a role. In such a case this service willlabel the role component as “unsatisfied” and remove itfrom the list of active roles.

Role execution service. In ATALK, both agents and rolesare driven by events. The process coordinator pattern (Gor-ton, 2006) is adopted to implement role execution services.As shown in Fig. 5, this service provides an itinerary ex-ecution behavior which runs throughout the whole life-cycle of the agent. It delivers all received messages andorganization events to the individual event receiver (roles,agent decision logic). Each event is handled in two majorsteps: 1) Firstly, the event is dispatched to event-handlersfrom the agent itself. For instance, an agent should handleevents pertaining to, e.g., a new role position available, arole becoming “unsatisfied”, and so on. 2) Secondly, whenall handlers have processed the event, the event will behandled by all active roles assumed by the hosting agent.Different roles might respond to different events. The ex-ecution service first verifies if the incoming event pertainsto an existing role. If so, the dispatcher distributes theevent to the role through the method defined in the roleinterface. This method returns a set of “actions” for exe-cution.

The compositional agent architecture and the two servicesprovide basic support for requirement validation, role man-agement and execution. This design allows agent devel-opers to focus on implementing their application logic—for instance, logic specifying in what condition the agentshould take which roles.

3.5. Organization Layer

In ATALK, a decentralized organization layer is designed.This layer provides a virtual environment for the agentto access the organizational services (e.g the coordinationservice to keep the organization in a consistent state, asdone in (Omicini et al., 2008; Weyns et al., 2010b)) orthe re-organization service that improves the current con-figuration through its optimization rules—as done, e.g.,in (Artikis, 2012). As this layer has been extensively dis-cussed in many existing approaches, here we shall focus onthe support of role deployment and relocation.

7

Figure 6: Decentralized role repository.

3.5.1. Distributed role repository

As pointed out in (Ward and Henderson-Sellers, 2009), inorder to achieve reusability of roles, it is important to pro-vide an extensible role reusability infrastructure. Insteadof placing all role components in one central repository,ATALK designs a decentralized role repository extendingto all the host devices within the organization. Each hostkeeps a local copy of the component-location record, whichconsists of a list of all role components, their meta-datadescriptions, and URLs for accessing the role components.Records in different hosts are synchronized periodically.As shown in Fig. 6, the actual role components are scat-tered across multiple hosts. A host might manage but afraction of all the role components used in the organiza-tion. A repository management interface is provided withrole management functions such as inquiring available rolecomponents and adding/removing a copy of role compo-nents to/from a given host.

Figure 6 also shows that one role component can have mul-tiple copies. This feature allows the repository to toleratehost failures to a certain degree. When a host crashes,agents in other hosts can still access the role componentsthat reside in other nodes. Compared to approaches inwhich one hosts contains all possible roles, this design isalso resource-efficient. However, how to make a best bal-ance between fault-tolerance and resource efficiency is aresearch topic in itself and is out of scope of this paper.

3.5.2. Role Import Service

The Role import service (RIS) imports role componentsfrom organization to the local host. When called with areference to a role component, the RIS returns the URLs ofthis role from the index of role repository. If the local hostcontains a copy of this role component, RIS retrieves therole component from the local host, otherwise it importsthe role component through the remote URL. After thisrole import process, RIS adds the role component to thelocal role repository and then updates the index of global

role repository. The adoption of RIS shields the agentsfrom the details of the actual locations of role componentsand provides a uniform interface for role deployment.

3.5.3. Role Mobility service

In most agent platforms, only agents are mobile. In orderto support role relocation within an organization, ATALKextends mobility to roles as well. In essence, the processsupporting role mobility across multiple hosts reduces it-self to a particular case of code mobility (Fuggetta et al.,1998). In ATALK the role relocation process involves boththe migration of the binary code and the transfer of thestate of the role instance (stateful migration).

Any role component that may need to be migrated-with-state must implement the IMobility interface. Said inter-face allows role components to save state data to a persis-tent file and later to restore the state information. When arole instance is about to move, it firstly stores its run-timedata. After this, the migration service packs role-specificcodes, meta-data, and run-time states into a single com-ponent that can be transferred to its remote destination.Once this is done, the receiving agent can assume this rolevia the RIS and load the received state information ontothe newly started role instance.

From the implementation point of view, the role migrationis quite similar to agent migration. However, they havea major difference. In the role-based relocation, a roleinstance can only exist when an agent assumes it. It issubordinated to the agent and the organization. Thus,only the agent or the organization is allowed to initiate therole relocation process. On the contrary, in agent-basedmigration, an agent decide autonomously when and whereto migrate. This feature highlights an important differencebetween an agent and its roles: an agent migrates of itsown volition, while a role relocates only because its playerso decides.

3.6. Intra-organizational Role Relocation

Figure 7 shows the activity diagram of the different entitiesinvolved in relocating a role from one agent to another.

As shown in this figure, when an agent, say agent a, wantsto delegate a role instance, say r, to another agent withrun-time states, the following sequence of actions typicallytakes place: a) Agent a firstly calls the Role Mobility ser-vice from the organization and parses the reference to r;b) the Packaging service is called to package role r’s bi-nary codes and its state information into one deployablecomponent; c) the generated role component (with state)is added to the Role Repository and a corresponding URLis returned to agent a; d) Agent a creates a new role po-sition in the organization with the URL and meta-datarelated to role r; e) the organization sends a “new roleavailable” message to other agents; f) a second agent, sayAgent b, checks the requirements of r; g) if requirements

8

Figure 7: Activity Diagram for Role Relocation.

are satisfied and b decides to play role r, it sends a roleassumption request to the organization; h) the organiza-tion decides which agent shall take role r; let us supposehere that agent b is selected; i) The Role Import service iscalled to deploy the role components to the host on whichagent b is executing; the role r becomes “loaded”; j) therequirement verification service checks the requirementsagain; k) if satisfied, the state of role r is reinitialized andits execution is resumed.

It is worth noting that the process introduced here adoptsan agent-centered approach in which agents initialize therole relocation process. In other approaches, it is possiblethat the organization instead of agents initializes this rolerelocation process. These two models represent two differ-ent design alternatives regarding where to place the reor-ganization logic (Boissier et al., 2007). ATALK is designedto support both models. System designers can choose anappropriate model according to their specific requirementsto implement their systems.

4. Implementation and Evaluation

In what follows we introduce the current implementationof ATALK and we evaluate it from different perspectives.

4.1. System Implementation

We use the OSGi framework (OSGi Committee) as ourimplementation platform. OSGi provides a lightweightservice-oriented middleware platform with an easily exten-sible component model. Equinox is used as our basic devel-opment platform. This component model is based on ourprevious work on declarative & reflective service compo-nent (Gui et al., 2011) which is extended from the declar-ative component model firstly proposed in (Cervantes and

Hall, 2004). This model is a service-oriented componentmodel and provides native support for dynamic referencemanagement. In order to describe role components’ non-functional prerequisites for execution, each role componentis associated with a “role.mf” file to specify its capabilitiesrequirements1.

For component sharing, the Jetty HTTP service providedby the OSGi framework is used to share components withinthe organization. Each host runs one Http service whichare used for role import and mobility services. The roleimport service is implemented based on OSGi continuousdeployment services, which allow components to be de-ployed via a URL address. Thus, one role componentcan be deployed once (namely, on a single host) whilebeing accessible from all the nodes within the whole or-ganization. When roles need to migrate-with-state, theXStream (Xstream, 2012) package is used to serialize rolestates into XML. Similarly to what done in (Ibrahim andZhao, 2009), a one-shot approach is adopted in packagingand relocating components. Other agents can get all therequired data with one single software package.

In order to provide a consistent organization image toagents, different hosts in the ATALK are synchronizedthrough a simple synchronization protocol based on themaster-slave model. In the current implementation, eachhost in the organization is assigned with a host ID. Thehost with minimal host ID in the organization is selected asthe master while all other hosts are slaves. Only the mas-ter host can make changes to the organization configura-tion and periodically send state updates. When an actionmay change the organization configuration—for instance,an agent opens a role position or signs a contract with theorganization—the slave host will send the correspondingrequest to the master host and wait for confirmation fromthe master. Obviously such a simple protocol may be re-placed with a more failure-resilient one such as (De Florioet al., 2000).

As for the communication protocol, ATALK designed asimple, custom agent communication protocol based onmulticast message transmission. We are currently work-ing on distributed hash table based approaches so as torealize a decentralized key-value infrastructure for sharinginformation e.g. open role positions, taken roles.

4.2. Performance Evaluation

In this section, the performance of our prototype is as-sessed from different perspectives. Firstly, the time forthe role relocation process is examined. Then, a quantita-tive comparison between agent-based migration and role-based relocation is carried out. Finally, we demonstratehow role-based relocation can help the organization self-organize into a more resource-efficient configuration.

1Source code can be download at http://code.google.com/p/osgi-agents-code-exchanging/

9

4.2.1. Role deployment and relocation

What we deem as one of the key features of ATALK liesin its support for decentralized role deployment and state-ful role relocation. As the latter process is more complexand covers all the activities involved in the role deploy-ment process, we focus our attention here solely on rolerelocation. As discussed in Sect. 3.6, the role relocationprocess involves five major steps: 1) serialization of thestate information into a local file; 2) packaging of the rolecomponent with its states; 3) exchange of messages withthe organization (including those to arrange open role po-sitions, agents replies, as well as for signing contracts withthe organization); 4) retrieval of the role component fromremote host; 5) local installation.

The results reported in what follows have been obtainedby deploying ATALK on a local network with 7 PCs usedas hosts. Each PC is equipped with an Intel T6400 CPU,2GB memory, a 100 Mbps LAN interface, and is runningthe Window XP OS. The adopted JVM version is 1.7. Asingle agent is deployed on each host. The performanceof role deployment is evaluated through the time for de-ploying a role component to all participating agents, withrespect to the size of the migrating component and thenumber of involved agents. In this simulation, the sizeof each role component takes the following values: 8KB;50KB; 173KB; and 370KB, while the number of agentswho want to assume a role ranges from 1 to 6.

Of the above five processes, serialization and packagingare independent of the number of Worker agents. Thus,Fig. 8 shows the performance of those processes when thesize of role components changes. As can be seen from thatfigure, the role component spends around 6ms to serializetwo variables into a XML file. The serialization processis only affected by the size of serialized data and will notchange with respect to the size of role components. Incomparison, the time consumed by the packaging processgradually raises from 15ms to 54ms when the size of roleincreases from 8KB to 370KB. These two processes areonly needed when an agent wants to relocate its role in-stance, together with its states, to other agents. When anagent only wants to deploy a new role component into thelocal host, the mentioned two steps will not be needed.

Figure 9 shows the execution time when relocating a rolecomponent to a varying number of agents. The value is thearithmetic mean of 100 runs of the experiment. The lowerand upper bound shows their standard deviations of thoseexecution time. In this simulation, all agents are designedwith logic to assume the role as soon as it receives notifi-cation from the organization. The execution time is cal-culated from the time the agent decides to relocate a roleto the time when all other agents assume that role. Thewhole process includes serialization, packaging, messaging,importing, and installing the role component. As shown inthis figure, the deployment time increases with respect toboth the number of agents and the size of the role compo-

Figure 8: Execution time for serialization & packaging.

Figure 9: Role relocation time with different number of agents.

nent. The execution time increases very slowly when thecomponent size is small and comparably faster when thecomponent size grows. The major reason contributing tothis increase is the time for importing the role componentinto the local host. In this scenario, all agents immedi-ately assume the role position as soon as they are notified.Due to the short interval, the corresponding record in thedecentralized role component repository have not been up-dated. Thus, all the agents try to access the role compo-nent from the same remote host almost at the same time.This creates a burst of requests and makes the installationtime increase with the number of agents—thus artificiallycreating a worst case scenario. In practice, only a limitednumber of agents take a role position and in general thisdoes not happen at the same time. As a consequence theinstallation time shall often be comparable to the perfor-mance of the single agent case—less than 400ms for a rolecomponent of 370KB.

10

Table 1: Comparison between ATALK and JADE in terms of mobil-ity support

ATALK Role mi-gration

JADE MobileAgent

Migration domainWithin organiza-tion

Point-to-point

Migration entitiesRole component +state

Agent + behav-iors + state

Migration size 8KB 33 KBMigration Time(code only)

145.3ms 252ms

MTTR (withstates and reinit)

171.7 ms 1141ms

Agent behaviorRun-time reconfig-urable

Pre-defined

4.2.2. Role relocation vs. agent-based migration

In this section we compare the performance of role reloca-tion with the agent-based migration in JADE(Bellifemineet al., 2009) with a self-repairing scenario based on the“mobile” demo provided with the JADE platform. anagent moves some functionaries to another host due tothe changes of its residing host’s availability. The agentcontains three major function units: 1) a counting featureincrements a counter every second(countingbehavior.java)2) query feature to query the number of available hosts(GetAvailableLocationsBehavior.java)3 ) a commanding in-terface responding to external commands (ServeIncomingMes-sagesBehavior.java). In JADE, those features are imple-mented as agent behaviors while in ATALK those differentbehaviors are implemented as re-deployable role compo-nents.

From a certain time, an agent moves some functionariesto another host due to the changes of its residing host’savailability. In such scenario, an agent moves some func-tionaries to another host due to the changes of its residinghost’s availability. We remark how, in an agent platformsuch as JADE, such scenario would result in the agentmigrating to another host with all enacting roles. In com-parison, the ATALK agent can choose to migrate a sub-set of its functionality—a portion of its enacting roles—toother agents residing in other hosts. The time needed forthe agents to resume the execution of the role enacted byinvolving agents is counted as repair time. Mean-time-to-repair (MTTR) for the two implementations is collectedand compared. The value is obtained from the average of10 simulation runs.

Table 1 shows the comparison between ATALK and JADEwhen recovering the counting behavior with two hosts.Each host has one agent deployed. In JADE, as the agent’sbehavior is statically embedded in the agent itself, thewhole agent needs to be migrated. This includes codes forthe agent, three counts of agent behaviors, and the agentstate. In contrast, in our platform, only the counting be-havior (role) needs to be migrated—the other functionsare either provided by the hosts or by the basic agent im-plementation, which is not needed for migration.

As a result, migration takes about 145.3ms in ATALK

while in JADE it calls for about 252ms. The JADE ap-proach takes more time as it requires more code to betransferred compared to the role-based relocation (33KBvs. 8KB). A second reason contributing to this result isthe model of migration. In JADE, when an agent wantsto migrate, it does so by marking itself as moveable. Theactual migration is performed by the JADE system aftersome delay. When counting the state transferring time,ATALK achieves an even better performance (171.7 msvs. 1141ms). This is due to the fact that our platformonly needs to restore the state of the role, while JADEneeds to restore all the state of the agent. The “pull-per-class” strategy used by the JADE platform also con-tributes to the comparably larger migration time. Suchstrategy checks which classes are going to be needed andretrieves them one by one. In comparison, ATALK mi-grates the counting role component, together with its state,in one package which demands far less communications.Consequently ATALK can achieve much less MTTR withrespect to JADE.

Of course, ATALK currently does not include all the fea-tures of JADE—for instance it does not support the FIPAcommunication specifications. This might not accuratelyreflect the performance differences between ATALK andJADE. However, we argue that allowing only a fraction ofthe agent to be transferred shall result in a better perfor-mance.

4.2.3. Role-Based Self-Organization

In this section, the motivational scenario presented in Sect. 2is implemented with simulated robots and roles. For thesake of simplicity only two types of roles are introduced:Coordinator and Worker. The definition of those roles isconsistent with those provided in our motivational exam-ple. In this scenario, four robots join the organization atdifferent times. Each robot is assumed to be heteroge-neous in communication and processing capabilities. Ta-ble 2 shows the arbitrarily values assigned to the robots aswell as times for joining the organization.

As described in Sect. 3.3, different roles might require dif-ferent capabilities to the systems. Here, when an agenttakes the Coordinator role, this corresponds to a require-ment of about 100kbps communication bandwidth per man-aged Worker. When an agent takes the Worker role, thisaccounts for about 30% CPU time and 100KBps of com-munication bandwidth. Here, in order to avoid fluctu-ations when measuring resource consumption, predefinedconsumption rates are simulated rather than collected fromactual data. We also assume that an agent takes anyopen role position whenever it has the necessary resources.However, the actual role assignment is decided by organi-zation rules.

Due to the diversity in available resources, it is easy to seethat depending on which robot is Coordinator the system

11

Table 2: Agent properties and participation time

RobotCPU (per-centage)

Bandwidth(Kbps)

Time in enteringorganization(s)

A 40 200 0B 30 150 50C 10 400 60D 30 200 100

shall support a different number of Workers. As an exam-ple, a choice of Robot A results in at most two Workers asA can only sustain a communication bandwidth of up to200Kbps, while the superior communication capability ofC allows it to support at most four Workers.

In order to better optimize system resources, two rules aredefined in the organization.

1. The organization assigns a new Worker contract toan available robot only if the current coordinator hasenough resources to support this new position.

2. The Coordinator role is assigned to the requestingagent that can support the largest amount of Work-ers.

When Robot A just joins the organization, it is the onlyone agent that can play Coordinator. Thus, the maximumnumber of supported Workers is 3. Figure 10 shows the fi-nal organization configuration when the agents are definedwithout (a) or with (b) role migration logic at simulationtime 120 seconds—20 seconds after all four agents havejoined the organization—when the organization reaches astable state.

Case (a): Role relocation disabled. According to itsdefinition, the Coordinator keeps track of the current pro-cess in task assignments and it is vital for the functionof the collective task at hand. In this case, it is impos-sible for the agent to dismiss its Coordinator role. Thus,if Robot A assumes this role, it has to continue to enactit until the organization decides otherwise lest the wholecomputation process would fail. As Robot A has limitedcommunication capability that allow it to support up totwo external workers, Robot D cannot take any role andkeeps idle. Organization resources cannot be effectivelyused. The system then “locks in” to the configurationshown in Fig. 10(a).

Case (b): Role relocation enabled. When role relo-cation is enabled, robots can handover its role to otherparticipating robots. As an example, when Robot D joinsthe organization at 100s, Robot A finds it can not supportmore workers. By using ATALK it is possible for it tochoose to hand over its Coordinator role to other agents.Robot A then opens a new Coordinator role position andwaits for other agents to assume that position. Then, theorganization signs a Coordinator role contract with RobotC as it supports the largest amount of workers (4 work-ers). As soon as the contract is signed, role and states arepackaged together and transferred to C. After this pro-cess A dismisses the Coordinator role and only plays its

(a) Without role relocation

(b) With role relocation

Figure 10: Organization configuration after about 120s.

Worker role. The new Coordinator, Robot C, can supportmore than 3 Workers, therefore it opens a new position forWorker. This allows Robot D to assume the Worker posi-tion. After this reorganization process, the system movesinto the state shown in Fig. 10(b).

What is apparent from the above scenario is that, by en-abling agents to exchange their enacting roles, ATALK canhelp organizations self-organize into more efficient config-urations with little additional complexity. Although theadaptation rules specified here are very simple and only fordemonstration purposes, ATALK allows other mechanisms—as for instance the cost-aware transition of (Alberola et al.,2013)—to be used to provide more general reorganizationstrategies without jeopardizing the consistence of the or-ganization.

5. Related Work

In this section, existing role-based agent platforms arebriefly presented and compared with respect to severalmetrics. The comparison results are shown in Table 3.

As can be seen in Table 3, most reviewed organization-based agent platforms provide similar support for role dy-namicity and openness. All reviewed approaches providesupport on the role dynamicity and most approaches, withthe exception of MACODO, support an agent to interactwith possibly unknown roles.

However, with reference to how roles are engineered, twomajor streams of techniques are adopted. One stream,including e.g. RICA-J (Serrano and Ossowski, 2004), S-moise+ (Hubner et al., 2006, 2010) and THOMAS (Ro-driguez et al., 2011), adopts role specification languages

12

Table 3: Comparisons with existing organization infrastructures: - represents not clearGeneral Design Role Implementation Agent Archtecture Organization

DynamicRoles

Openness Role ModelRoleNota-tion

InternalArch.

RoleManag.

Decentr.arch.

Role De-ployment

RoleRelo-cation

BRAIN Yes, AOPRun-timeweaving

Aspects Yes Yes Yes Yes No No

RICA-JYes, Javarefl.

Dynamicbinding

Java ob-jects

No No No No No No

Kendall Yes, AOPRun-timeweaving

Aspects No No No No No No

MACODOYes, rolefacade

NoJava Ob-jects

No No No Yes No No

S-moise+Yes, Org-Box

ParsingRole lan-guage

- No No Yes - No

THOMASYes,roleproxy

ParsingRole lan-guage

- No No No - No

ATALKYes,dynamicbinding

Run-timebinding

SOA Yes YesYes,SOA

Yes Yes Yes

to describe roles and their norms. Agents have to parsethose role descriptions and act upon them. The capabil-ity of roles are limited by the descriptive power of thoserole description languages. However, the more sophisti-cated the language, the more the execution power it willbe spent in parsing the role descriptions. The second ma-jor stream of works explicitly represent roles as softwareentities. Agents can play the roles by directly operatingthe software entities. This technique is comparably eas-ier to implement and demands less resoures compared toapproaches in the first stream. Due to these positive fea-tures, this technique is widely adopted in many projects.The practical implementation of their software entities,however, varies from pure object-based, aspect-orientedto component-based approaches in order to support roledynamicity.

Some approaches, such as RICA-J, use object-orientedprogramming to implement roles. As the object-orientedmodel lacks support on dynamic role reference manage-ment, OOP-based approaches need a custom design toovercome this limitation. The AOP techniques can weaveroles into agents during run-time which can alleviate theneeds of dynamic role reference management. However, asit has been discussed in Sect. 3.3, the use of AOP leads topossible reusability problems. Furthermore, as aspects canbe weaved anywhere in the code, the agent will have nocontrol on the weaved-in roles. This limitation makes thoseweaved-in roles very hard to manage and coordinate. Incontrast to those approaches, ATALK adopts SOA, whichprovides native support for role dynamicity. The bind-ing between agents and roles can be easily built throughservice-binding.

Apart from Role language based approaches, only BRAINand ATALK explicitly provide role annotation definitions.Missing this information makes it difficult for agents tochoose among roles. As we already discussed, ATALKfeatures an agent annotation format that allows functionaland non-functional capability requirements to be expressedand reasoned upon. This allows agents to infer whetherthey have the capabilities required to play a role.

For the agent architecture, many approaches, e.g. S-moise+,THOMAS, adopt the black-box model to model agents. Intheory, those systems allow any agent to be used regard-less its internal structure. However, this black-box modelmakes it very hard for agents to integrate roles from theorganization. In order to participate in the organization,those approaches normally require agents to be ”organiza-tion aware” which, to some extent, also contradicts the ba-sic assumption of the black-box model. Furthermore, ex-isting approaches provide little discussion on how to man-age assumed roles. In those approaches, roles are solelymanaged by the organization and the agents have littlecontrol on role management.

With respect to the organizational architecture, we ob-serve that most existing approaches provide no clear sup-port for decentralization, despite its being a typical traitof many open MAS. Centralized designs commonly fore-see one pre-defined host to provide blackboard services.In contrast, the decentralized architecture of ATALK al-lows it to be deployed on a dynamic number of hostswith no need for a central control point. This featuremakes ATALK particularly suitable in changing environ-ment with a dynamically varying set of hosts. Anotherdistinguishing feature of ATALK in the organization de-sign is its support of role relocation among agents. Thisfeature has not been discussed in other organization-basedagent platforms. Without this support, it is very hard forother approaches to support scenarios in which an agentdismisses its enacting role.

6. Conclusion

Our main focus in this paper is the problem of how todeploy effectively organization specifications to participat-ing agents in a fully decentralized and open environment.In order to simplify the deployment of role specificationsfrom an organization to its agents we proposed ATALK,a service-oriented decentralized middleware. In ATALKroles are explicitly presented as service components. Withthe definition of a role functional interface as well as with

13

its meta-data description, agents can query, reason, andinteract with different roles. The whole life-cycle of rolecomponents is explicitly defined. Based on the service-oriented role component model, a compositional agent ar-chitecture has been defined to facilitate the run-time rolemanagement.

In order to support open systems with dynamic host par-ticipation and departure, our middleware is designed to befully decentralized. Role deployment within an ATALK or-ganization is supported through a decentralized role repos-itory. Each host only contains a subset of all role com-ponents. The ATALK middleware provides explicit sup-port for role deployment and relocation through the def-inition of the role import and mobility services. Thosetwo services allow role instance to migrate within the or-ganization, possibly together with their run-time states.We conjecture that changing the focus from agents toroles may greatly improve the efficiency when migratingtasks between nodes. Preliminary evidence to this factwas brought by comparing a self-healing scenario betweenpurely agent-based approaches and ATALK. Moreover, weobserved how this decoupling allows the organization toavoid lock-ins and inefficiencies while managing self-orga-nization.

We identify the following areas open for further research:

Firstly, our role model shall be extended. In ATALK cur-rently an agent can perform a role as long as it satisfies allcapability requirements. This solution actually assumesthat the agent is always consistent with its enacting roles.However, as pointed out in many approaches, agents mighthave goals conflicting with those of its enacted roles. Sim-ilar conflicts may also arise between two or more roles en-acted by the same agent. We are currently working to-wards effective methods to detect and resolve goal con-flicts among agents and their enacted roles based on ourprevious work (Gui and De Florio, 2013).

Secondly, we are aware that in the current prototypicalimplementation the coherence of the overall organizationspecification may be jeopardized by host departures orcrashes. We are now tackling this aspect by integratingour previous work (De Florio et al., 2000).

Finally, our current implementation is based on a customcommunication protocol and therefore has limited inter-operability. We intend to tackle this issue by adopting theFIPA protocol for agent communication.

References

Alberola, J.M., Julian, V., Garcia-Fornes, A., 2013. Using cost-awaretransitions for reorganizing multiagent systems. Engineering Ap-plications of Artificial Intelligence 26, 63–75.

Amor, M., Fuentes, L., 2009. Malaca: A component and aspect-oriented agent architecture. Information and Software Technology51, 1052–1065.

Artikis, A., 2012. Dynamic specification of open agent systems. Jour-nal of Logic and Computation 22, 1301–1334.

Bellifemine, F., Giovanni Caire, T.T., Rimassa, G., 2009. JADEPROGRAMMERS GUIDE. Telecom Italia S.p.A.

Boissier, O., Hubner, J.F., Sichman, J.S., 2007. Organization ori-ented programming: From closed to open organizations. Engi-neering 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 frameworkfor flexible role-based interactions in multiagent systems. On theMove to Meaningful Internet Systems 2003: Coopis, Doa, andOdbase 2888, 145–161.

Cervantes, H., Hall, R.S., 2004. Autonomous adaptation to dynamicavailability using a service-oriented component model, in: Pro-ceedings of the 26th International Conference on Software Engi-neering (ICSE 2004), pp. 614–623.

Dahchour, M., Pirotte, A., Zimnyi, E., 2004. A role model and itsmetaclass implementation. Information Systems 29, 235–270.

Dastani, M., Dignum, V., Dignum, F., 2003. Role-assignment inopen agent societies, in: Proceedings of the second internationaljoint conference on Autonomous agents and multiagent systems,ACM. pp. 489–496.

De Florio, V., Deconinck, G., Lauwereins, R., 2000. An algorithm fortolerating crash failures in distributed systems, in: Proc. of the7th Annual IEEE International Conference and Workshop on theEngineering 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 Au-tonomous Agents and Multiagent Systems - Volume 1, IEEE Com-puter Society. pp. 236–243.

Fuggetta, A., Picco, G.P., Vigna, G., 1998. Understanding codemobility. IEEE Transactions on Software Engineering 24, 342–361.

Fujii, K., Suda, T., 2009. Semantics-based context-aware dynamicservice composition. ACM Transactions on Autonomous andAdaptive 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 frame-work with contextual adaptation behavior composition support.Software Practice & Experience 43, 937–967.

Gui, N., De Florio, V., Sun, H., Blondia, C., 2008. A frameworkfor adaptive real-time applications: the declarative real-time osgicomponent model, in: Proceedings of the 7th Workshop on Adap-tive and Reflective Middleware(ARM), pp. 1–8.

Gui, N., De Florio, V., Sun, H., Blondia, C., 2011. Towardarchitecture-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 perva-sive computing environments, in: Proceedings of the 2009 Inter-national Conference on Pervasive services, ACM. pp. 123–132.

Gutknecht, O., Ferber, J., 2001. The madkit agent platform architec-ture, in: Proceedings of the International Workshop on Infrastruc-ture for Multi-Agent Systems: Infrastructure for Agents, Multi-Agent Systems, and Scalable Multi-Agent Systems, Springer-Verlag. pp. 48–55.

Hubner, J., Boissier, O., Kitio, R., Ricci, A., 2010. Instrumentingmulti-agent organisations with organisational artifacts and agents.Autonomous Agents and Multi-Agent Systems 20, 369–400.

Hubner, J.F., Sichman, J.S., Boissier, O., 2006. S-moise(+): A mid-dleware for developing organised multi-agent systems. Coordi-nation, Organizations, Institutions, and Norms in Multi-AgentSystems 3913, 64–77.

Ibrahim, A., Zhao, L.P., 2009. Supporting the OSGi service plat-form with mobility and service distribution in ubiquitous home

14

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 Coopera-tive Information Systems, pp. 325–333.

Omicini, A., Ricci, A., Viroli, M., 2008. Artifacts in the a & ameta-model for multi-agent systems. Autonomous Agents andMulti-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., Julian, V., Bajo, J., Carrascosa, C., Botti, V., Cor-

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 commu-nication languages on the implementation of agent systems, in:Klusch, M., Ossowski, S., Kashyap, V., Unland, R. (Eds.), Co-operative 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 normsfor programming agent organizations, in: Proceedings of The 8thInternational Conference on Autonomous Agents and MultiagentSystems - Volume 1, International Foundation for AutonomousAgents 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: Pro-ceedings of the 2011 IEEE/WIC/ACM International Conferenceson Web Intelligence and Intelligent Agent Technology - Volume02, IEEE Computer Society. pp. 133–140.

Ward, C.B., Henderson-Sellers, B., 2009. Utilizing dynamic roles foragents. Journal of Object Technology 8, 177–198.

Weyns, D., Haesevoets, R., Helleboogh, A., 2010a. The Macodo or-ganization 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 agentorganizations. ACM Trans. Auton. Adapt. Syst. 5, 1–28.

Xstream, 2012. A simple library to serialize objects to xml. http:

//xstream.codehaus.org.

15