Stéphane Galland
email: stephane.galland@utbm.fr

Sebastian Rodriguez

Nicolas Gaud

Run-time Environment for the SARL Agent-Programming Language: the Example of the Janus platform

Keywords: SARL agent-programming language, Run-time Environment, Janus platform

SARL is a general-purpose agent-oriented programming language. This language aims at providing the fundamental abstractions for dealing with concurrency, distribution, interaction, decentralization, reactivity, autonomy and dynamic reconfiguration that are usually considered as essential for implementing agent-based applications. Every programming language specifies an execution model. For SARL, this run-time model is supported by a SARL run-time environment. The goals of this paper are to highlight the key principles for creating a SARL run-time environment, and its concrete implementation into the Janus agent platform.

Introduction

In past years, multi-agent systems (MAS) have taken their place in our society. Application fields include robotics, artificial intelligence, cinema, video games. This evolution is the answer to increasingly complex projects, which require "intelligent" systems. Multi-agent systems allow to implement solutions with intelligence, capable of reasoning, learning and interacting between different agents. These systems represent a totally different way of looking at things. This way of designing systems resulted in new tools, methodologies and architectures, better suited to MAS modeling, e.g. ASPECS [START_REF] Cossentino | How to control emergence of behaviours in a holarchy[END_REF], MaSE [START_REF] Deloach | The MaSE Methodology[END_REF] or even Gaia [START_REF] Wooldridge | The Gaia Methodology for Agent-Oriented Analysis and Design[END_REF]. These methodologies are complemented by agent platforms for supporting the run-time execution of the designed models. There are several dozens, e.g. Jade [START_REF] Bellifemine | Developing Multi-Agent Systems with JADE[END_REF], NetLogo [START_REF] Wilensky | NetLogo, Tech. Rep[END_REF], GAMA [START_REF] Grignard | GAMA 1.6: Advancing the Art of Complex Agent-Based Modeling and Simulation[END_REF], or Janus [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF].

On one hand, these solutions are highly interesting because they frame and provide tools for the development of agent-based systems. On the other hand, these systems are very complex to implement, and the conventional programming languages (Java, etc.) are not suited. There is therefore a real need for programming languages dedicated to MAS, which would offer more clarity to developers, and simplify developments. Several agent-programming languages have been proposed. Most of them are domain-specific languages, e.g. GAML [START_REF] Grignard | GAMA 1.6: Advancing the Art of Complex Agent-Based Modeling and Simulation[END_REF], MARS [START_REF] Glake | Modeling Through Model Transformation with MARS 2.0[END_REF], or Jason [START_REF] Bordini | Programming Multi-Agent Systems in AgentSpeak using Jason[END_REF]. Several of these languages are general-purpose, e.g. SARL [START_REF] Rodriguez | SARL: A General-Purpose Agent-Oriented Programming Language[END_REF]. SARL [START_REF] Rodriguez | SARL: A General-Purpose Agent-Oriented Programming Language[END_REF] is a new general-purpose agent-oriented programming language (APL). SARL tries to set up adaptive and modular principles for developing multi-agent systems.

Every programming language specifies an execution model, and many implement at least part of that model in a runtime system [START_REF] Aho | Compilers: Principles, Techniques, and Tools[END_REF]. For a SARL program being executed, a specific run-time environment must be defined. The goals of this paper are to highlight: (i) the key principles for creating a SARL run-time environment, and (ii) its concrete implementation within the Janus agent platform [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF]. Neither the relationship between the above methodologies and SARL, nor the one between these methodologies and Janus are the purpose of this paper. Our motivations are: i) to enable Researchers, Engineers and Students to create a run-time environment for SARL. The key principles and features to be considered for designing this run-time environment are provided to them; and ii) to give a proof of concept based on the Janus platform. This platform already provides an implementation for holonic multi-agent systems, which are also a core concept within SARL. In this paper, the Janus meta-model and software architecture are updated in order to fit the SARL requirements.

This paper is structured as follow. Section 2 explains the fundamentals of the SARL language. Section 3 presents the compilation and execution tool-chain for SARL. Section 4 details the key principles for creating a SARL run-time environment that handles any SARL program. Several existing agent platforms are presented in Section 5. Section 6 gives details on the re-implementation of the Janus platform in order to create a SARL run-time environment. Section 7 describes the performance evaluation of the Janus implementation. Finally, Section 8 concludes this paper and provides perspectives to this work.

SARL Agent-Programming Language

SARL1 is a general-purpose agent-oriented programming language [START_REF] Rodriguez | SARL: A General-Purpose Agent-Oriented Programming Language[END_REF]. It aims at providing the fundamental abstractions for dealing with standard agent features: concurrency, distribution, interaction, decentralization, reactivity, autonomy and dynamic reconfiguration. The main perspective that guided the creation of SARL is the establishment of an open and easily extensible language. Such language should thus provide a reduced set of key concepts that focuses solely on the principles considered as essential to implement a multi-agent system. The major concepts of SARL are explained below, and illustrated in Figure 1.

Action

An action is a specification of a transformation of a part of the designed system or its environment. This transformation guarantees resulting properties if the system before the transformation satisfies a set of constraints. An action a ∈ A is defined by its prototype and its body, as illustrated by Equation 1. The prototype is composed by the name n a of the action, a sequence P a of formal parameters, and the type r a of the returned values. The body B a is a sequence of expressions -a subset of the language constructs for describing evaluable expressions -that represents transformations. These two parts of the action's definition are represented respectively by the Action Prototype and Action in Figure 1.

a = n a , P a , r a , B a (1)
For pedagogical reasons, the SARL action concept could be linked to method concept into the object-oriented paradigm: both concepts represent the same language construct.

Capacity and Skill

A capacity c ∈ C is the specification of a collection P c of actions' prototypes, as defined in Equation 2. A capacity could be used to specify what an agent can do, and what a behavior requires for its execution.

c = S c , P c , F c (2)
This specification makes no assumptions about its implementation. So that, the bodies of the actions are not defined into the capacity: ∀p ∈ P c ⊆ A, B p = ∅. The capacity c could inherit a part of its definition from another capacities S c . The fully expanded set F c of actions that are defined into the capacity c is defined by:

F c = P c ∪ {F s /s ∈ S c }.
A skill s ∈ S is a possible implementation of capacities C s fulfilling all the constraints of these specifications, as defined by Equation 3.

s = s s , C s , A s , F s (3)
A s is the set implementations of the actions from the capacities C s , such that ∀a ∈ A s , B a = ∅ and A s ⊆ c∈Cs F c . Similarly to a capacity, a skill s could inherit a part of its definition from another skill s s . The fully expanded sequence F s of actions that are defined into the skill s is defined by: F s = A s ∪F ss . Skill s provides an implementation for each capacity action:

a ∈ F s /∀a ∈ A c , ∀c ∈ C s .
An agent can dynamically evolve by learning or acquiring new capacities. It can also dynamically change the skill associated to a given capacity [START_REF] Rodriguez | An analysis and design concept for self-organization in Holonic Multi-Agent Systems[END_REF][START_REF] Cossentino | How to control emergence of behaviours in a holarchy[END_REF]. Acquiring new capacities also enables an agent to get access to new behaviors requiring these capacities. This provides agents with a self-adaptation mechanism that allow them to dynamically change their architecture according to their current needs and goals.

Context and Spaces

A space p ∈ P is the support of the interaction between agents, respecting the rules defined in an associated space specification. SARL natively defines a particular type of space, namely the event space to provide a support to eventdriven interactions. Within an event space, agents communicate using events. Nevertheless, it is possible to define programmatically new types of spaces that are not event-based. Equation 4 provides the definition of a space p. M p is the set of agents, which are participating to the interaction within the space, i.o.w. the members of this space. R p is the functional definition of the interaction mechanism that is supported by the space. It may be a routing algorithm of messages between the space's participants, or the interaction specification among agents and artifacts [START_REF] Ricci | Programming MAS with Artifacts[END_REF].

p = M p , R p (4)
A context c ∈ O defines the perimeter/boundary of a sub-system, and gathers a collection S c of spaces, as defined in Equation 5.

c = S c , d c (5)
Since their creation, agents are incorporated into a context called the default context (see the upper part of Figure 2, level n). The notion of context makes complete sense when agents are considered composed or holonic (see Section 2.6 for details).

In each context, there is at least one particular space d c ∈ S c , called default space, to which all agents in context c belong. This ensures the existence of a common shared space to all agents in the same context. Each agent can then create specific public or private spaces to achieve its personal goals.

The concept of environment, as defined by Weyns et al. [START_REF] Weyns | Environment as a First-class Abstraction in Multi-Agent Systems[END_REF] could be linked to the concept of context in SARL. The spaces into a context become views to the environment [START_REF] Galland | A multidimensional environment implementation for enhancing agent interaction[END_REF]. Consequently, spaces restrict how agents perceive and act in the environment. Rodriguez et al. [START_REF] Rodriguez | A New Perspective on Multi-Agent Environment with SARL[END_REF] have proposed to model the environment by defining a context, a space, and specific agents that are supporting the endogenous dynamics of the environment. This last type of agent is mandatory because there is no syntactic way within SARL for defining a context: only spaces and agents could be programmed.

When an agent is created, it belongs to a context, named its default context. During its life, an agent may join or leave other external contexts, as illustrated by Figure 2 with agent A. The invariant condition is each agent belongs to a default context, whenever this default context is not the one in which the agent was created. Figure 1 illustrates this membership relation by the "member of" association between Agent and Space. In other words, an agent belongs to a context if, and only if, it is member of the default space of this context. The direct relation between the agent and context concepts is related to the inner context, which is detailed in Section 2.6.

Agent and Behavior

An agent a ∈ T is an autonomous entity having a set B a of behaviors, and a set S a of skills to realize the capacities it exhibits. It is defined in Equation 6, and represented by the Agent type in Figure 1.

a = B a , S a , M a , d a , C a , i a (6)
Agent a has a set S a of individual skills that may be used for building the agent's behaviors. Agent a defines the mapping M a : C → S from one capacity to a single skill implementation. From this definition, the agent a is able to determine which skill should be used when a capacity's action is invoked. A set of capacity-skill pairs, named the built-in capacities (BIC) is defined into the SARL specifications [START_REF] Rodriguez | SARL: A General-Purpose Agent-Oriented Programming Language[END_REF]. They are considered as essential to respect the commonly accepted competences of agents, such autonomy, reactivity, pro-activity and social capacities. The full set of BICs are presented in Section 4 because they must be implemented into, and provided by the SARL run-time environment. Among these BICs, the DefaultContextInteractions and ExternalContextAccess capacities are defined.

They give respectively the access to the agent's default context d a , and the set C a of contexts in which the agents belong to, such that d a ∈ C a . i a represents the internal context of the agent, which is detailed in Section 2.6.

Another BIC is the Behaviors capacity. It enables an agent to incorporate a collection B a ⊂ B of behaviors that will determine its global conduct. A behavior b ∈ B maps a collection of perceptions represented by events to a sequence of actions. O b : E → P(A) is the mapping function in Equation 7.

b = O b (7)
An agent has also a default behavior directly described within its definition. It is illustrated by the relationship between Agent and Action types in Figure 1. By default, the various behaviors of an agent communicate using an eventdriven approach. An event e ∈ E is the specification of anything that happens in a space s, and may potentially trigger effects by a listener, e.g. agent, behavior.

Example of SARL Program

For clarity reasons, let the definition of an agent, named FactorialAgent that is able to compute a factorial. This example is simple enough for illustrated the basics properties and features of the SARL language. Nevertheless, more complex implementation of multi-agent systems with SARL could be found in [START_REF] Cich | Addressing the Challenges of Conservative Event Synchronization for the SARL Agent-Programming Language[END_REF][START_REF] Lizondo | Multiagent Model for Distributed Peak Shaving System with Demand-Side Management Approach[END_REF][START_REF] Feraud | First Comparison of SARL to Other Agent-Programming Languages and Frameworks[END_REF][START_REF] Galland | Environnement multidimensionnel pour contextualiser les interactions des agents. Application à la simulation du trafic routier urbain[END_REF][START_REF] Cich | Towards an Agent-based Model for Demand-Responsive Transport Serving Thin Flows[END_REF][START_REF] Basso | Engineering multi-agent systems using feedback loops and holarchies[END_REF][START_REF] Galland | Organizational and Holonic Modelling of a Simulated and Synthetic Spatial Environment, E4MAS 2014 -10 years later[END_REF][START_REF] Galland | Contextualize Agent Interactions by Combining Social and Physical Dimensions in the Environment[END_REF].

FactorialAgent agent waits for other agent's request to calculate (Calculate event) a factorial. Once computed, it is notifying the result using the ComputationDone event. An agent is declared with the agent keyword (line 12). In the agent's body block, we can declare mental states (in the form of attributes), actions (or functions and event handlers). Actions that an agent can perform could be specified by capacities or natively inside the agent definition. Keyword uses imports the actions defined in capacities, so that, they can be accessed directly as an agent native function.

Agent perceptions and the sequence of actions the agent wants to perform for each perception are defined. This is achieved using the clause on <perception > [<guard>] {<body>}. FactorialAgent declares three behavioral event handlers (lines 14, 21, and 25). Perceptions for SARL agents take the form of events, and they can be declared using the event keyword. For instance, the Calculate event is defined at line 6. An event can carry information, in our case the number we want the factorial for.

When the Calculate event is perceived (line 25), the agent can access the event's instance using the occurrence keyword. At line 27, it sets the upto attribute using the information for the Calculate event occurrence.

From this point, the agent starts computing the factorial. The Behaviors built-in capacity provides the agent with mechanisms to (un)register new behaviors, and fire new internal events (wake action). For calculating the factorial, the agent fires an internal event of type Factorial using the wake action.

Two behaviors are declared for Factorial event (lines 14 and 21). When an event is perceived, SARL agents execute all their behaviors for that event type concurrently. Behaviors can declare guards to prevent their execution if required. So, the behavior at line 14 is only executed if occurrence.number < occurrence.upto evaluates to true. This behavior simply calculates the factorial for the next integer, and fires a Factorial event again. As illustrated, the guard's expression may reference the received event or any of its attributes. Nevertheless, any variable that is declared into the enclosing type (agent, behavior, etc.) of the guard, or any statically accessible variable or function may be referenced too.

Likewise, when the factorial for the requested number (stored in upto attribute) is found, the behavior at line 21 is executed. The emit action fires an event in the default space of the default context for notifying the computation is finished. After that, the agent stops its execution using the killMe action from the Lifecycle capacity.

It is necessary to clearly understand the difference between wake and emit actions. Wake fires an internal event within the agent that may be perceived by its own behaviors, and its members when it is composed by other agents. Emit action enables to fire an event in a given space that is outside the agent itself.

Recursive Agent and Hierarchical Multiagent System

In 1967, Koestler coined the term holon as an attempt to conciliate holistic and reductionist visions of the world. A holon represents a part-whole construct that can be seen as a component of a higher level system or as whole composed of other holons as substructures [START_REF] Koestler | The Ghost in the Machine[END_REF]. Holonic systems grew from the need to find comprehensive construct that could help to explain social phenomena. Since then, it came to be used in a wide range of domains, including philosophy [START_REF] Wilber | Sex, Ecology, Spirituality: The Spirit of Evolution[END_REF], manufacturing systems [START_REF] Van Leeuwen | Holons and holarchies [intelligent manufacturing systems[END_REF], and multi-agent systems [START_REF] Gerber | Holonic Multi-Agent Systems[END_REF].

Several works have studied this question, and they have proposed a number of models inspired from their experience in different domains. In many cases, the idea of agents composed of other agents could be found. Each researcher gives a specific name to this type of agent. Ferber [START_REF] Ferber | Multi-agent systems: an introduction to distributed artificial intelligence[END_REF] discusses individual and collective agents. Meta-agents are proposed by Holland [START_REF] Holland | Hidden order: how adaptation builds complexity[END_REF]. Agentified Groups are taken into account in the works of Odell et al. [START_REF] Odell | A Metamodel for Agents, Roles, and Groups[END_REF]. All of these are examples of how researchers have called these "aggregated" entities that are composed of lower level agents. More recently, the importance of holonic MAS has been recognize by different methodologies such as ASPECS [START_REF] Cossentino | ASPECS: an agent-oriented software process for engineering complex systems -How to design agent societies under a holonic perspective[END_REF] and O-MASE [START_REF] Case | Applying an O-MaSE Compliant Process to Develop a Holonic Multiagent System for the Evaluation of Intelligent Power Distribution Systems[END_REF].

In SARL, we recognize that agents can be composed of other agents. Therefore, SARL agents are in fact holons that can compose each other to define hierarchical or recursive MAS, called holarchies. In order to achieve this, SARL agents are structures that compose each other via their contexts. Each agent defines its own internal context, called inner context and it is part of one or more external contexts. For instance, in Figure 2, agent A is taking part of two external contexts, i.e. Default Context and External Context 1. The same agent has its own inner context where agents B, C, D and E evolve. Because, an agent may belong to a default and an external context at the same time, the resulting structure in not a simple hierarchy of agents (agent composed by agents). It is a directed graph of agents, with membership relations among them. In the SARL meta-model (Figure 1), these relations are formally supported by the "Member of" relation between an agent and a space.

Python program

SARL Tool-chain

The SARL tool-chain is the set of programming tools that are used to perform a multi-agent system with SARL. As illustrated by Figure 3, three types of tools are used in sequence in order to create and run an agent-based system:

• SARL Compiler: The SARL compiler transforms the source SARL language to the target language. Several target languages may be considered by this compiler. Because most of the agent frameworks are written with the Java language, the SARL compiler targets this object-oriented programming language by default, but not restricted to (a Python generator is also provided as proof-of-concept). The SARL compiler translates SARL statements into their object-oriented equivalent statements. Three different implementations of the SARL compiler are provided: a specific command-line tool (sarlc), the Eclipse development environment plugin, and a Maven plugin.

• Java Compiler: The files generated by the SARL compiler are standard Java files. They must be compiled with one of the standard tools that are available: eclipsec2 , javac3 , gcj 4 , or jikes5 . The result of the Java compilation is a collection of binary files (a.k.a. byte-code files) that may be run by a virtual machine.

• SARL Run-time Environment: The SARL Run-time Environment (SRE) is a collection of tools that enables running of an agent-based application written with SARL. Such an SRE must provide the implementation for each service and feature that are assumed to be provided by the runtime environment. Usually, a Java-based SRE is composed by the Java Run-time Environment (JRE) and a Java framework that supports the execution of the agents upon the JRE.

In order to create a valid SRE, it is mandatory to define the core features that are expected into a SRE implementation. Section 4 describes the key elements that should be considered for solving this specific point.

In order to give a Proof-of-Concept, a specific SRE implementation based on the Janus platform [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF] is provided in Section 6. Janus is a Java application, i.e. a Java virtual machine is used for running the program upon a specific Java library that provides the features dedicated to the SARL agents. Janus was selected because, since its creation in 2008, it provides the key features for implementing holonic multi-agent systems. Therefore, it is the best candidate for becoming a SRE.

Key Points for SRE Creation

In this section, the major key points that should be considered for creating a SARL Run-time Environment are explained: support to the agent's life-cycle, and implementation of the built-in capacities.

Agent's Lifecycle

SARL does not imposes a specific agent's control loop. Indeed, when agents are spawned, the SRE is in charge of creating the agent instance and installing the skills associated to the built-in capacities into the agents. Then, when an agent is ready to begin its execution, SRE fires an Initialize event occurrence. This occurrence contains the initialization parameters for the agent's instance. Likewise, when the agent has decided to stop its own execution (using the killMe action from the Lifecycle capacity), SRE fires an Destroy event occurrence. It enables the agent to release any resource it may still hold. It is important to notice that agents cannot kill other agents, not even those that they have spawned. One of the key characteristics of an agent is its autonomy. From its definition, no other agent should be able to stop its execution without its consent. The MAS designer is free to implement any control or authority protocol for their own application scenarios.

Built-in Capacities

Every agent in SARL has a set of built-in capacities (BIC) considered essential to respect the commonly accepted competences of agents. These capacities are considered the main building blocks on top of which other higher level capacities and skills can be constructed. They are defined in the SARL language specifications, but the skills implementing them are provided by the SRE. This latest is in charge for creating the BICs' skills, and injecting them into an agent, before its execution begins. Therefore, when the agent receives the Initialize event, they are already available. The current eight defined BICs, and the actions they provide along their action signatures are:

• ExternalContextAccess provides access to the contexts that the agent is a part of, and the actions required to join and leave new contexts. The external context of the agent A is shown at the top right part of Figure 2.

• InnerContextAccess provides access to the inner context of the agent. This is keystone for holonic agent implementation. The inner context of the agent A is shown at the bottom part of Figure 2.

• Behaviors As previously described, agent can dynamically (un)register behaviors and trigger them with the wake action. This capacity is closely related to the InnerContextAccess to enable a high-level abstraction on holonic MAS development.

• Lifecycle provides actions to spawn new agents on different external contexts (peers), and the inner context (as holonic members). It also provides the killMe action to stop the agent execution.

• Schedules enables the agent to schedule tasks for future or periodic execution.

• DefaultContextInteractions is actually provided for convenience. It assumes that the action is performed on the agent's default context (upper left part of Figure 2) and its default space. For instance, the emit action is a shortcut for defaultContext.defaultSpace.emit(...). Therefore, it is actually created on top of the other BICs.

• Logging provides the agents for writing messages on the agent's log. The messages may be shown according to a severity level, e.g. information, warning, error.

• Time provides the agents for accessing to the current time. The time may be the operating system time, or a simulation time, depending on the implementation of the BIC within the SRE.

Parallel Execution

In most of the agent frameworks, e.g. Jade [START_REF] Bellifemine | Developing Multi-Agent Systems with JADE[END_REF] and Janus [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF] (before its adaptation to SARL), each agent is run on a separate execution resource, i.e. a thread. This design choice enables each agent managing its own execution resource, and participates to its autonomy. On several other platforms, e.g. TinyMAS 6 , the agents are executed in turn in a loop. The parallel execution of the agents is therefore simulated.

SARL encourages a massively parallel execution of agents and behaviors. An agent entry point is a part of the agent behavior that is invoked from the outside of the agent. In SARL, the entry points are the behavior event handlers, specified by the on keyword. Each of these entry points is associated to a separate thread. Parallel execution of the pro-active behaviors of an agent is supported by the tasks that are launched with the Schedules built-in capacity.

Whatever the agent execution mechanism used by a SRE (thread-based or loop-based), a SARL developer always assumes that the agent's entry points are executed in parallel when he is writing the event handlers.

Selection of an Agent Framework as SRE Candidate

SARL language specifies a set of concepts and their relations. It defines on top of them a collection of Built-In Capacities for agents. However, the SARL project does not impose a particular execution infrastructure. We consider that many different implementations of these concepts can be provided, and it can help SARL be developed faster. In this section, four Java-based agent platforms are considered as candidates for implementing a SRE: Jade [START_REF] Bellifemine | Developing Multi-Agent Systems with JADE[END_REF], NetLogo [START_REF] Wilensky | NetLogo, Tech. Rep[END_REF], GAMA [START_REF] Grignard | GAMA 1.6: Advancing the Art of Complex Agent-Based Modeling and Simulation[END_REF], and Janus [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF].

According to the key points that are described in Section 4, several criteria are used to compare these agent frameworks:

• Application type: Multi-agent systems have a very wide scope of application, including 3D simulation, geography simulation, social simulation, video game.

• Agent Type Definition: Definition of a new agent may need to extend an existing feature or use specific language statements.

• Agent Behavior Definition: Definition of a new agent behavior may need to extend an existing feature or use specific language statements.

• Interaction Mechanism: This criterion indicates the type of interaction mechanism that is used by the agent framework: message exchanges, event-based interaction, stigmergy...

• Agent Initialization: This criterion indicates how an agent may be initialized.

• Agent Destruction: The destruction of an agent causes the release of resources. This criterion specifies the means for implementing a release function.

• Agent Execution: Agent execution mechanism is a key module of the agent platform. The type of mechanism may be synchronous; i.e. agents are run in a loop, or multi-threaded.

• Hierarchical Multiagent System: Hierarchical systems, and specifically holonic systems are a key principle behind the SARL agent programming language. This criterion indicates if, and how, a hierarchy of agents is supported by the agent framework.

Table 1 provides an overview of our agent framework comparison. Jade and Janus are both general purpose platforms: they could be used for building any agent-based application, including embedded system and simulation applications. NetLogo and GAMA are simulation platforms because they enables to build simulation software. We advocate that a general purpose platform fits better the needs for the SARL agents. Indeed, SARL does not target a specific application domain. It is defined for enabling the building of embedded and simulation-based applications, for instances.

SARL Key Concepts

Jade [START_REF] Bellifemine | Developing Multi-Agent Systems with JADE[END_REF] NetLogo [START_REF] Wilensky | NetLogo, Tech. Rep[END_REF] GAMA [START_REF] Grignard | GAMA 1.6: Advancing the Art of Complex Agent-Based Modeling and Simulation[END_REF] Janus [START_REF] Galland | Janus: Another Yet General-Purpose Multiagent Platform[END_REF] Application Type All the existing platforms that are included in this comparison provide a message-based interaction mechanism: agents are sending messages to other agents. The receiving agents decide to get the messages from their mail boxes. This approach corresponds to a pro-active behavior: consuming a message is a direct and explicit decision of the agent. The messages are not given to the agent as part of its reactive behavior. It does not fit the reactive interaction behavior, based on events, that is expected by the SARL developers. The creation of an SRE, based on all the above frameworks needs a complete recast of the data exchange mechanism.

The agent's life-cycle is almost supported in the same way by all the above platforms. Initialization and destruction functions are invoked at the beginning and end of the agent's life. In between, the agent's life is supported by a specific function that is called regularly by the agent framework. SARL specification does not assume the existence of this function. In order to make each platform compliant with SARL, this agent running function should read the agent mailbox and fires corresponding events, for example.

Agent execution is another key feature of an agent framework. The existing frameworks use a single thread to each agent. According to the execution mechanism that is expected by SARL, the execution mechanism should be adapted to enable threaded execution of the event handlers. Or, this parallel execution should be simulated in order to give the illusion to the agent's code that the event handlers are executed in parallel. Regarding the agent execution function mentioned above, it considered as the place where to specify the execution mechanism mapping.

The last criterion focuses on the support of hierarchical systems. Two agent frameworks support explicitly such systems, i.e. GAMA and Janus. Only Janus fully supports the concept of holon.

According to all these assessments, we have decided to adapt the Janus platform in order to create a run-time environment for the SARL applications. Indeed, Janus is the framework, which covers the largest amount of features that are expected by SARL developers. The key element that has been considered for taking this decision is the support of holonic multi-agent systems, which is the best within Janus, from our point of view. This decision is also taken according to the software development effort to be spent for creating a SRE: lower is the amount of code to be written, higher is our interest to the SRE candidate.

The Janus Platform as a SARL Run-time Environment

The Janus platform7 is re-designed and re-implemented in order to serve as the software execution environment for the SARL programs. This revised version of Janus implements all the required infrastructure to execute a MAS, which is programmed using SARL. It fulfills the SARL requirements, such as fully distributed execution of the agent's behaviors, and the automatic discovery . The main purpose of this work is to adapt Janus to become a SRE, and therefore provides an implementation to each of the built-in capacities.

General Service-based Architecture

A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components. The basic principles of SOA are independent of vendors, products and technologies [START_REF]Service-Oriented Architecture[END_REF]. A service is a discrete unit of features that can be accessed remotely, acted upon, and updated independently, such as retrieving a credit card statement on-line.

A service has four properties according the definition given by the Open Group 10 : (i) it logically represents a business activity with a specified outcome; (ii) it is self-contained; (iii) it is a black box for its consumers; and (iv) it may consist of other underlying services.

Different services can be used in conjunction to provide the functionality of a large software application [START_REF] Velte | Cloud Computing: A Practical Approach[END_REF]. So far, the definition could be a definition of modular programming in the 1970s. 8 Google Guice: https://code.google.com/p/google-guice/ 9 In-Memory Data Grid like Hazelcast: http://www.hazelcast.com 10 Service-Oriented Architecture Standards: http://www.opengroup.org/standards/soa Service-oriented architecture is less about how to modularize an application. It is more about how to compose an application by integration of distributed, separately-maintained and deployed software components. SOA is enabled by technologies and standards that make it easier for components to communicate and cooperate.

According to these principles, the Janus platform is redesigned in order to provide eight services. As illustrated by Figure 4, these services constitute the basis of the built-in capacity implementation. The Janus services are aggregated into two categories:

1. infrastructure services, which are managing the relationship with the underlying operation system and the virtual machine.

2. services that are managing features that are accessible to the built-in capacities.

These services are detailed in the following sections according to the given presentation template:

Description: Goal and activities that are carried by this service out.

Start-up:

Description of the activities that are executed at the startup of the service.

Shut-down:

Description of the activities that are executed at the shutdown of the service.

Functions:

Descriptions of the functions that are provided by the service in its public interface.

Events:

List of the events that are fired by the service, and that could be listened by external objects.

The rest of this section provides details on the height services defined within the Janus framework. This service provides the functions for launching tasks in parallel. The implementation is based on the Java Executors utility class, which provides tools for launching single-run and periodic tasks.

Start-up:

Create and initialize a Java executor service for single-run tasks, and one for periodic tasks.

Shut-down:

Stop the Java executor services. Functions:

• execute(r): execute the task r in parallel.

• executeMultipleTimesInParallelAndWaitFor-Termination(r, n): execute n instances of the task in parallel. • schedule(t, r): execute the task r in t milliseconds.

• scheduleAtFixedRate(t, r): execute the task r every t milli-seconds. • scheduleAtFixedDelay(t, r): execute the task r infinitely, and wait t milliseconds between each run.

Events: -

Context-Space Service

Description: This service is in charge of maintaining the repositories of the agent contexts and the agent interaction spaces that are created in the system. This service is also in charge of routing the events between agents through the spaces. The agent execution unit in Janus is the event handler: the part of the SARL agent that is executed when a specific event is received. Each of these units are executed in parallel to the other units, even within the same agent.

Start-up:

Synchronization of the context and space repositories with other Janus instances over the computer network. Shut-down:

-Functions:

• createContext(id): create a context with the given identifier.

• removeContext(id): remove the context with the given identifier, and destroy all the spaces inside the context. • getContexts(): return all the existing contexts.

• getContext(id): return the context with the given identifier. • createSpace(c, id): create a space in the context c with the given identifier. • removeSpace(c, id): remove the space with the given identifier from the context c. • getSpaces(c): return all the existing spaces in the context c. • getSpace(c, id): reply the context with the given identifier in the context c.

Events:

• ContextCreated, ContextDestroyed when a context was created or destroyed. • SpaceCreated, SpaceDestroyed when a space was created or destroyed.

Janus enables the distribution a SARL program over a network of (virtual) machines -(V)M's. From the SARL agent point of view, this distribution over (V)M's is hidden. Indeed, we argue that any SARL program runs on a big virtual machine that is covering all the connected (V)M's. These low-level machines are not visible to the SARL agent. Consequently, a context is seen as a single entity over the (V)M's by the agents. From the Janus point of view, each context instance is a shared object over the (V)M's. Thanks to the underlying Hazelcast in-memory data grid library, the different context instances are replicated and dynamically synchronized over the (V)M's. Spaces are also shared upon the same infrastructure.

A safety question arises when enabling (V)M communication: what happens when two (V)M's cannot communicate any more? Thanks to the Hazelcast library, no data is removed from the shared data structures (context list, space list, agent list, etc.) It means that the agents can continue to send events to agents that are at the other side of the lost connection. But, Janus does not send the events to the remote agent because of the connection loss. According to the Janus specification, there is no warranty that an event is delivered to another agent into a remote (V)M. Consequently, the agent communication protocol should take care of any loss of event. When the (V)M's connection is back, Hazelcast library synchronizes the local instances of the data structures with the remote instances.

Spawning Service Description:

This service is in charge of managing the agent's life-cycle. It creates instances of agents, and registers them to the other services of the framework. This service provides the functions for stopping the agents. An agent can be killed only if it has no member agent inside (see Section 2.6). The service ensures that the agent's life-cycle events are fired to the agent: Initialize and Destroy events.

Start-up:

-Shut-down:

Stop all the running agents. Functions:

• spawn(t, n): create n instances of agent of type t.

• killAgent(id): destroy the agent when the given identifier.

Events:

• AgentSpawned when an agent was created.

• AgentDestroy when an agent was destroyed.

6.1.6. Networking Services Three networking services are provided by the Janus platform: kernel discovery, distributed data, and network event routing services.

Performance Evaluation

In order to be able to measure the performance of the new Janus implementation, we created a very simple stigmergy-inspired ping-pong application [START_REF] Cich | Addressing the Challenges of Conservative Event Synchronization for the SARL Agent-Programming Language[END_REF]. A central agent representing the agent environment, as defined by Weyns et al. [START_REF] Weyns | Environment as a First-class Abstraction in Multi-Agent Systems[END_REF] and Galland and Gaud [START_REF] Galland | Organizational and Holonic Modelling of a Simulated and Synthetic Spatial Environment, E4MAS 2014 -10 years later[END_REF], is introduced as the mean of communication between the other Consequently, two agent types are considered: (i) the application agents, which are sending the ping-pong events, and (ii) the environment agent, which represents the environment in which the application agents are located. The times T 0 , T 1 , T A , T B , T C and T D mentioned below are simulated application time values.

In the time period starting at T 0 , every appplication agent has 20 % probability to emit a ping message to X other agents where X ∼ Uniform(1 : 100). The message needs to be delivered in the time period T d ∼ Uniform(T 1 : T e ) where T e denotes the end of simulated time. The measured time is illustrated in Figure 5. Where T 0 and T 1 denote the start and the end of the interval. T a denotes the end of the reception of the events sent by the environment agent to the application agents. T b is the end of "application level payload work" done by the simulation agents. And finally, T c is the end of delivering of the AgentIsReadyEvent events to the environment agent. For every time period, the amount of emitted messages is computed together with the total amount of time needed to execute this time period. Experiments are realized for 200 agents on a Linux Ubuntu 14.04LTS laptop with 8GB memory and a Intel Core i5-4210M CPU 2.60GHz × 4. The number of time periods that are simulated is 2 500. Experimental results are illustrated in the graph represented in Figure 6. In our experiments, all the application agents have the same actions to do. Consequently, they have approximately the same execution time. It is clear to see that the execution time follows a constant tendency, and hence seems to be independent of the number of processed events over the full range of observations. The execution time for a single period between two consecutive increments of simulated time includes: perception of the environment, application specific payload work and end-of-period notification. The duration required for the payload work : Graph that represents the total amount of events handled in a specific iteration (x-axis) against the total execution time for that iteration in ms (y-axis) for the case of 200 agents and 2 500 iterations [START_REF] Cich | Addressing the Challenges of Conservative Event Synchronization for the SARL Agent-Programming Language[END_REF].

in the experiment is negligible. The large variance of the execution time masks the expected dependency on the number of events.

Conclusion and Perspectives

SARL is a general-purpose agent-oriented programming language. This language aims at providing the fundamental abstractions for dealing with essential agent features: concurrency, distribution, interaction, decentralization, reactivity, autonomy and dynamic reconfiguration.

Every programming language specifies an execution model, and many implement at least part of that model in a runtime system. In the case of SARL programs, the SARL run-time environment (SRE) provides the tools and the features that are mandatory for running such a program. In this paper, we present the adaptation of the Janus platform for becoming the official and default SRE. Janus adopts the best practices in current software development, such as Inversion of Control, and benefits from new technologies like Distributed Data Structures.

The major perspectives of this work are listed below. First, Janus platform is a standard Java application for which the performances must be analyzed in detail, in order to be optimized accordingly. A comprehensive and systematic comparison of the existing agent frameworks and the new version of Janus will be realized.

Migration of agents over the different Janus kernels is not yet supported. A specific service will be added into Janus, and a built-in capacity provided within the SARL API, in order to query to migrate 12 .

Other agent-based platform may serve as SRE. GAMA platform [START_REF] Grignard | GAMA 1.6: Advancing the Art of Complex Agent-Based Modeling and Simulation[END_REF] is a possible candidate for creating a simulation environment for spatial and geographic applications. Gazebo platform [START_REF] Aguero | Inside the Virtual Robotics Challenge: Simulating Real-Time Robotic Disaster Response[END_REF][START_REF] Koenig | Design and Use Paradigms for Gazebo, An Open-Source Multi-Robot Simulator[END_REF] is another candidate for creating simulators of robots, including drones.

Finally, most of the embedded systems cannot execute a Java application. The need of a specific SARL compiler, which generates C/C++ program arises. A perspective of this work is to extend the SARL compiler for embedded systems, cloud platforms, and computer clusters, which are specific run-time environments.

Figure 1 :

 1 Figure 1: UML Class Diagram defining the major concepts in the SARL meta-model.

Listing 1 :

 1 event F a c t o r i a l { 2 var u p t o : i n t var n u m b e r : i n t 4 var v a l u e : i n t } 6 event C a l c u l a t e { var n u m b e r : i n t 8 } event C o m p u t a t i o n D o n e { 10 var r e s u l t : i n t } 12 agent F a c t o r i a l A g e n t { uses L i f e c y c l e , B e h a v i o r s , D e f a u l t C o n t e x t I n t e r a c t i o n s 14 on F a c t o r i a l [ occurrence . n u m b e r < occurrence . u p t o ] { w a k e (new F a c t o r i a l => [ 16 u p t o = occurrence . u p t o n u m b e r = occurrence . n u m b e r + 1 18 v a l u e = occurrence . v a l u e * ( occurrence . n u m b e r + 1 ) ] ) 20 } on F a c t o r i a l [ occurrence . n u m b e r == occurrence . u p t o ] { 22 e m i t (new C o m p u t a t i o n D o n e => [ r e s u l t = occurrence . v a l u e ] ) k i l l M e 24 } on C a l c u l a t e { 26 w a k e (new F a c t o r i a l => [ u p t o = occurrence . n u m b e Computation of Factorial with a SARL Agent

Figure 3 :

 3 Figure 3: Compilation and Run-time Toolchain for SARL

Figure 5 :

 5 Figure 5: An overview of the time measurement in our experiments.

  iteration (ms) Total amount of Events handled by All Agents Total amount of events handled tendency

Figure 6

 6 Figure 6: Graph that represents the total amount of events handled in a specific iteration (x-axis) against the total execution time for that iteration in ms (y-axis) for the case of 200 agents and 2 500 iterations[START_REF] Cich | Addressing the Challenges of Conservative Event Synchronization for the SARL Agent-Programming Language[END_REF].

Table 1 :

 1 Mapping of the SARL concepts to the existing agent platforms

  Architecture of the Janus platform of kernels. Janus adopts best practices in current software development, such as the Inversion of Control 8 . It also benefits from new technologies like Distributed Data Structures 9

				Agents
	InnerContext	InternalEventBus	Behaviors	Lifecycle
	DefaultContext	ExternalContext	Schedules	Logging	MicroKernel
	Distributed data	Executor	Logging	Spawn
	Context space	Network	Kernel Discovery
	Janus Kernel			Infrastructure
				Virtual Machine
				Operating System
		Figure 4:

Official website: http://www.sarl.io

Eclipse eclipsec: https://www.eclipse.org

Oracle JDK: http://www.oracle.com/technetwork/java/javase/overview/index.html

GNU Java Compiler: http://gcc.gnu.org

IBM jikes: http://jikes.sourceforge.net

TinyMAS Platform: http://www.arakhne.org/tinymas

Official website: http://www.janusproject.io

Agent migration feature: https://github.com/sarl/sarl/issues/747.

Acknowledgements

We would like to thank Glenn Cich and Luk Knapen, who have highly contributed to the performance evaluation of the new Janus platform [17].

Name:

Kernel discovery Description:

The kernel discovery service is in charge of maintaining a up-to-date list of the Janus kernels that are alive on a local computer network. This service uses the Hazelcast library, which is already maintaining a list of the Hazelcast nodes over the network.

Start-up:

Advertise the current kernel over the computer network.

Shut-down:

Notification of the disappearance of the current kernel to the other Janus kernels. Functions:

• getKernels(): return the list of the Janus kernels.

Events:

• KernelDiscovered when a Janus kernel was detected.

• KernelDisappeared when a Janus kernel is no more reachable.

Name:

Distributed data structures Description:

The distributed data service provides functions to create data structures (hash tables, lists, etc.) that are accessible and synchronized over the computer network. This service uses the Hazelcast library.

Start-up:

-Shut-down:

-Functions: newMap(id) and newList(id) are provided to create the data structures with the given identifiers. These functions replicate the data structures in all the kernel thanks to the Hazelcast library. Events:

-

Name:

Network event routing Description:

The network event routing service is in charge of routing the events that are fired by the agents to the agents that are hosted on a remote computer. This service opens a socket channel, based on the ZeroMQ library 11 to each remote Janus kernel. This channel will be used for sending events to the remotely hosted agents.

Start-up:

-Shut-down:

-Functions:

-Events:

• EventReceived when an event is received from a remote Janus kernel.

Built-in Capacity Implementation

SRE creates and injects the BICs in an agent before its execution begins. Janus platform provides an implementation for each BIC described in Section 4.2. Table 2 provides the mapping from a BIC to the Janus services that are used for its implementation. Indeed, the BICs call the Janus services in order to realize there behaviors. The concrete implementation code may be found on Github: https://github.com/sarl/sarl/tree/master/sre/io. janusproject/io.janusproject.plugin.

Built-in