Atalk eaai


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Atalk eaai

  1. 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: (Ning Gui), (Vincenzo De Florio), (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. 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. 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. 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. 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. 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. 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. 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. 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 “” 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 9
  10. 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. 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( 2) query feature to query the number of available hosts ( ) a commanding interface responding to external commands ( 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. 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. 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. 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. 15. environments. Computer Journal 52, 210–239. JBoss Community, 2011. Jboss aspect-oriented programming. http: // 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 Committee, 2011. Open gateway service specification. http: // 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. 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: // 15