Programming Distributed Multi-Agent Systems in simpAL Andrea Santi Alessandro Ricci DEIS, University of Bologna DEIS, University of Bologna Cesena, Italy Cesena, Italy Email: a.santi@unibo.it Email: a.ricci@unibo.it Abstract—Distribution is one of the essential features char- first-class abstractions to define agents – based on a BDI-like acterizing multi-agent systems (MASs), giving developers the model [16] – and the distributed environment where the agents opportunity to seamlessly conceive and then engineer a physically are logically situated, in terms of artifacts and workspaces. distributed application as a MAS spread among different network nodes. Nevertheless, the current support given by state-of-the-art Concerning distributed programming in particular, simpAL Agent Programming Languages (APLs) and related platforms provides specific language abstractions such as the notion of for programming distributed multi-agent systems as well as organization and workspace and related runtime support that for handling distribution when deploying, running, debugging ease the programming as well as the deployment and execution the distributed MAS is still quite primitive. In this paper we of distributed MASs. tackle this problem by introducing simpAL, a new agent-oriented programming language and platform which has been conceived The remainder of the paper is organized as follows: in from the beginning to provide a more comprehensive support Section II we provide the background of this contribution for programming, deploying and executing physically distributed by relating the current support of state-of-the-art APLs for MASs. realizing physically distributed MASs with the one we want to obtain in simpAL. In Section III we present the main concepts I. I NTRODUCTION of the language, and then we describe how a distributed multi- Multi-Agent Systems (MASs) are a main paradigm for agent system can be programmed in simpAL (Section IV) designing and developing complex software systems [12], and executed on the simpAL distributed runtime infrastructure distributed systems in particular. Agent programming lan- (Section V). Finally, we conclude the paper by highlighting guages (APLs) have been introduced to ease the development the main good points of the approach (Section VI) as well of MASs, providing agent-oriented first-class abstractions di- as its current limitations and related ongoing and future work rectly at the language level [4], [5], [6]. To deal with distri- (Section VII). bution – i.e., programming physically distributed MASs – the support provided by state-of-the-art APLs is typically limited II. BACKGROUND to mechanisms enabling the communication among agents and Many APLs have been proposed so far in literature for the by services available at runtime that provide facilities such as programming of agents and multi-agent systems [4], [5], [6]. agent discovery, message routing, ontology management, and Recently, a strong effort has been put in devising practical so on. The program of a distributed MAS is typically given languages, i.e. thought to be used primarily for concretely pro- then by a set of separate MASs programs, to be deployed, gramming MASs and not (only) for theoretical investigations. run and managed by hand or by using OS scripts on the Main examples include Jason [3], GOAL [10], 2APL [8], distinct network nodes. This makes the programming as well AFAPL [19], JACK [11]. as the deployment and execution of physically distributed Such languages and platforms provide a good support for MASs using state-of-the-art APLs significantly harder than the developing agent and multi-agent programs running on a single centralized case, i.e. MASs running on the same host. host; conversely, the support provided for the engineering, de- In this paper we aim at tackling this problem and, finally, ployment, execution and management of physically distributed easing the programming of physically distributed MASs, by MASs – i.e., MASs running on multiple network nodes – is devising at the language level proper abstractions and mech- still quite primitive [7]. It is essentially limited to: anisms suitably supported by the runtime. To this purpose, • enabling direct communication among agents based on we will use a novel agent-oriented programming language some agent communication languages – such as FIPA called simpAL. simpAL has been devised with the purpose of ACL [1] or KQML [9] – or indirect ones, based on some exploring agent-oriented programming as a high-level general coordination abstractions or the environment [15]; purpose programming paradigm for concurrent and distributed • exploiting some well-known services, typically repre- programming, as a natural evolution of object-oriented and sented by facilitator agents, provided by default by the actor-based approaches [17]. The language is based on the runtime infrastructure to help agent discovery, message A&A (Agents and Artifacts) meta-model [14], thus providing routing, interoperability, ontology management, etc. 1 /* .mas2g file related to the MAS1 */ 1 /* .mas2g file related to MAS2 */ 2 agentfiles { 2 agentfiles { 3 "agent0.goal". 3 "agent1.goal". 4 } 4 "agent2.goal". 5 launchpolicy { 5 } 6 launch a0:agent0. 6 launchpolicy { 7 } 7 launch a1:agent1. 8 launch a2:agent2. 9 } 1 /* agent a0 */ 2 init module { 3 beliefs{ 1 /* agent a1 */ 4 started(true). 2 ... 5 } 3 event module { 6 ... 4 forall bel(received(Sender, hello_msg)) 7 } 5 then insert(helloMsgReceived(Sender)). 8 main module { 6 } 9 if bel(started(true)) then sendonce (a1, helloMsg) 10 + insert (sentMsgToA1). 1 /* agent a2 */ 11 if bel(sentMsgToA1) then sendonce (ag2, hello_msg) 2 ... 12 + insert (sentFirstMsgToA2). 3 event module { 13 if bel(sentFirstMsgToA2) then sendonce (a2, !do_job). 4 forall bel(received(Sender, imp(doJob))) 14 ... 5 then insert(newDoJobGoalDelegated(Sender)). 15 } 6 } Fig. 1. An example of physically distributed MAS programmed in GOAL highlighting: (i) the need to define a separate MAS (in this case two) for each node in which the distributed application needs to execute, and (ii) typical programming errors related to message-based interactions that can be detected only at runtime (i.e., the sending of wrong messages to agents (bottom-left line 9), the use of misspelled agents identifiers (bottom-left line 11), the assignment of wrong goals to agents (bottom-left line 13)). To this end, almost all APLs in the state-of-the-art are problem is not related to physical distribution, but simply provided with a FIPA-compliant platform, often based on distribution (of control) among multiple agents that need to existing middleware such as JADE [2]. Given this support, interact. An example of the problem is shown in Fig. 1 using programming a physically distributed MAS on these APLs GOAL. In GOAL all the errors related to message-based concretely means creating a collection of separate programs, interactions such as the sending of wrong messages to agents each one meant to be run on a different host. Each program (Fig. 1 bottom-left line 9 where helloMsg is used instead of will spawn then agents that eventually will locate themselves hello_msg), the use of misspelled agents identifiers (Fig. 1 at runtime by exploiting discovery services and will com- bottom-left line 11 where ag2 is used instead of a2), the municate by exchanging ACL messages. A concrete example assignment of wrong goals to agents (Fig. 1 bottom-left line written in GOAL – other APLs could have been chosen as 13 where do_job is used instead of doJob), etc. can be only well since the support they provide to program a physically detected at runtime. distributed MAS is analogous – is reported in Fig. 1, in which Discovering these kinds of errors only by running the MASs a physically distributed MAS is programmed defining two makes the development hard and time-consuming, especially separated MASs (i.e., MAS1 and MAS2). In the example agent when the MASs are physically distributed. To this purpose, a0, part of MAS1, interacts via speech acts with both agent we aim at having suitable abstractions at the language level a1 and agent a2, part of MAS2, which is in execution in a that would allow to detect such programming errors statically separated network node. and systematically, in order to: (i) reduce the cost of errors On the one side, this approach is quite effective to handle detection from both a temporal and economic point of view, dynamism and openness giving hence MASs the opportunity and (ii) avoid complicated – and possibly long – debugging to evolve freely, on the basis of the interaction dynamics sessions for detecting errors at run-time—e.g., an error that experienced at runtime. For example: (i) new parts can be occurs only after several complex computations and long dynamically added to running applications by simply launch- interaction dynamics. ing new MASs and then making them interact with existing From the point of view of the management of MASs ones, (ii) new agents, possibly unknown at design time, can deployment and execution, we want the runtime to hide all be instantiated, made interact with MASs already in execution the complexities related to the physical distribution, so that and also dynamically looked up by the original agents of the physically distributed MASs are launched, terminated and MASs through the exploitation of discovery services. managed in the same way of MASs that are running on a On the other side, this approach makes the programming single node. This is not possible in current APL, where this as well as the deployment and execution management of kind of management still need to be done by hand. In fact, in distributed MASs quite complicated and troublesome jobs [7]. order to deploy and run a physically distributed MAS, one has From the programming point of view, a main problem is typically to deploy by hand on the different nodes the various the lack of proper abstractions and mechanisms that allow parts that constitute the MAS, and then execute the whole for discovering errors related to message-based interactions program by launching in proper order the different parts—i.e., among agents before running the MAS. In this case the taking into account application-specific constraints in order to guarantee a correct initialization of the whole system. To stop the best actions to perform and when to do them, reacting to the MAS, one needs typically to terminate by hand all the relevant events from their environment, fully encapsulating the individual parts. control of their behavior. For instance, taking Jason to make a concrete example – The environment plays a key role in mediating and sup- but as well as in GOAL, AFAPL, etc. – the runtime execution porting members’ individual and cooperative tasks. In simpAL of a whole physically distributed MAS is managed exploiting – as well as in A&A – the environment is modularized into a FIPA-compliant agent platform – JADE in this case – in a dynamic set of first-class computational abstractions called order to create a distributed runtime infrastructure among the artifacts, which represent the resources and tools that agents interested network nodes. To this end, a typical execution of share and may exploit concurrently and cooperatively. Arti- a distributed MAS in Jason follows this dynamics. First, the facts are useful to directly model non-autonomous software program is manually deployed in the target network nodes. components, encapsulating and modularizing functionalities Terminated the deploy process, the first part of the distributed that can be suitably exploited by agents. Examples of artifacts MAS to be executed is launched, manually, and the related are bounded buffers, a clock, a database, an external web Jason runtime takes in charge the creation of a main JADE service, etc. Like artifacts in the human case, artifacts in container for the distributed application. Then, all the other simpAL can be dynamically instantiated and disposed (by parts are launched in the desired order, manually one by one, agents), and, when needed, designed to be composed so as and for each of them the dedicated Jason runtime creates to create complex artifacts by connecting simpler ones. under the hood a new JADE container linked to the main one, Then, a further concept is needed in order to explicitly in order to create the distributed runtime platform that has in define the overall structure of the program which can be charge the execution of the whole program. Also application physically distributed over (possibly) different network nodes. termination needs to be managed by hand, manually shutting To this end, in simpAL we introduce the notion of workspace. down on each node the different Jason applications. The overall set of agents and artifacts of an organization may Dealing with these processes by hand is both tiresome – i.e., be partitioned into a set of workspaces as logical containers, the steps described above need to be repeated at each launch possibly running on different nodes of the network, defining – and error-prone – e.g., miss the deployment of updated the logical structure of the application. Actually, while being sources in some node, wrong initialization sequence of the located in a specific workspace, an agent can work concur- different application parts, etc. – thus calling for a better, rently and transparently also with agents and artifacts of other possibly automatized, support for their management. We argue workspaces belonging to its organization. that this goal can be made easier by having specific first- Finally, pure objects – as defined in modern OOP – are used class abstractions/constructs at the language level that make it to define the data model (and related purely transformational possible describe a MAS along with its (possibly) physically computations, e.g. retrieving the value of an object field) of distributed structure. The introduction of such constructs can programs. That is, agents, artifacts and workspaces are meant then make APLs’ runtime infrastructures aware of all those to be used as coarse grained abstractions to define the shape information required to manage the deployment and the coor- of the organization (i.e., of the program), in particular of dinated launch/termination of physically distributed MASs in the control part of it (decentralized, distributed). Objects are a automatized manner, limiting as much as possible developers then the basic data structures used inside agents, artifacts and intervention, since the information needed to manage such related communications and interactions. processes has become part of the program itself. In the following, we discuss how all the issues concerning IV. P ROGRAMMING D ISTRIBUTED MAS S IN SIMPAL the programming and execution management of physically distributed MASs introduced in this section are managed by In simpAL, a physically distributed multi-agent system is simpAL both at the programming and runtime/infrastructure programmed as an organization whose logical structure is level. defined in terms of workspaces distributed among different network nodes. In this perspective, the notion of workspace III. P ROGRAMMING M ODEL OVERVIEW represents the key to conceive and model the logical structure The programming model adopted in simpAL for designing of the MAS, by properly grouping, on the basis of both and implementing MASs integrates concepts defined in the application requirements and decisions made at design time, A&A (Agents and Artifacts) conceptual model [14] and the agents and artifacts in the set of workspaces that define the BDI (Belief-Desire-Intention) agent model [16]. A distributed organization. This grouping is meant to define only the logical MAS is designed and programmed as an organization of structure of the application – i.e. the organization – abstracting agents working together inside a shared possibly distributed from all the details concerning its deployment, which is instead environment organized in workspaces. managed through the definition of a run/deploy configuration, Agents in simpAL are task-oriented entities designed to specified into a dedicated configuration file (see the next sub- perform autonomously some tasks, possibly interacting with section). other agents via message-passing and with the environment In this section we show how a distributed multi-agent where they are situated. They pro-actively decide what are system can be programmed in simpAL using a guiding toy Action Communication println (msg: String) monitor agent Perception console main workspace p1 c1 theBuffer theCounter theGUI 92.10.45.40:8000 nItemsAvailable 3 count 100 stopPressed false p2 put (it: int) stop inc get (it: int #out) c2 consumers workspace SimpleProdCons producers workspace 137.204.107.188:8000 67.104.7.88:8000 Fig. 2. An abstract view of the producers-consumers organization, distributed among three different simpAL nodes. example, based on a slightly revised producer-consumer ar- context of that organization. chitecture (see Fig. 2). The source code of the example is Fig. 3 shows a simple example of an organization model available for download on the simpAL website, as part of its definition that refers to our producer-consumer sample. As a standard distribution. In the example, a set of producer agents design choice we decided to structure the topology of our have the task of producing continuously some items that must application in three workspaces (but other topologies could be consumed by a bunch of consumer agents. Consumer agents have been chosen as well): producers, consumers, and must stop their activities as soon as the total number of items main—the latter is available by default in every organization. processed is greater than a certain value. Also, producer agents The workspace producers hosts a couple of producer must stop the production as soon as the user stops it through a agents (p1,p2) and the GUI artifact (theGUI), while the GUI. A monitor agent – observing the overall activities – may workspace consumers hosts a couple of consumer agents communicate directly to the producer agents that more items (c1,c2), the counter and the buffer artifacts (theCounter, need to be produced. Some artifacts are exploited to support theBuffer). Finally, the main workspace hosts the monitor agent work and coordination: a bounded buffer artifact (with agent (monitor) and a console artifact used for purely the obvious functionalities), a counter (used by consumers to logging functionalities. keep track of the overall number of items processed) and a An organization can contain further agents/artifacts in- GUI (used by producers to observe user inputs). stances besides those statically declared in the organization In the following we proceed top-down. First we focus on model—since both agents and artifacts can be dynamically the programming of the organization, defining the distributed spawned and created by agents by means of specific actions. structure of the system, and then we introduce the program- The static case is useful anyway to specify the identifier of ming of agents and artifacts as basic components of a simpAL those components whose name and type must be known at the program. organizational level, in other words to define global symbols that can be resolved, in a transparent manner w.r.t. where they A. Defining the Organization will be actually deployed, and checked in that simpAL sources Following the basic principle of separation between inter- explicitly declared in the context of an organization of this type face and implementation, the definition of a simpAL orga- (see next subsection). nization is characterized on the one side by the notion of Then, the definition of a concrete organization accounts organization model, which is introduced for specifying the for specifying the concrete instances of agents and artifacts description of the abstract structure of the overall program, declared in the organization model. For artifacts, the artifact and on the other side by the notion of a concrete organization template – i.e., the name of the source containing the artifact which allows instead to define a concrete application instance implementation, see Section IV-C – is provided, possibly referring to an existing organization model. An organization including also the value of some parameters required by the model is identified by a proper name and it defines: artifact initialization operation. For agents, the initial script • The workspace-based logic structure of the organization, (see Section IV-B) to be loaded must be specified, possibly in which, for each workspace, it is possible to define, including parameters needed to boot the script, along with the statically, the name (identifier) and the type of agents initial task to do, and task initial parameters. Fig. 5 shows an and artifacts that, for that workspace, will be automat- example of a SimpleProdCons organization for the case ically instantiated and initialized at each launch of the of our producer-consumer sample, where the agents/artifacts organization. Dynamic instantiation is addressed later on. declared into the ProdConsOrg organization model are • The set of roles and the set of artifact models defining here properly initialized in order to characterize the specific the types that can be used, for agents and artifacts, in the SimpleProdCons organization instance. 1 /* ProdConsOrg organization model */ 1 /* SimpleProdCons organization */ 2 org-model ProdConsOrg { 2 org SimpleProdCons implements ProdConsOrg { 3 3 4 roles: Producer, Consumer, ProductionMonitor; 4 workspace producers { 5 interfaces: Console, GUI, Buffer, Counter; 5 theGui = SimpleGUI () 6 6 p1 = SimpleProducer(bufferToUse: theBuffer@consumers) 7 workspace producers { 7 init-task: Producing(numItems: 20) 8 p1, p2: Producer 8 p2 = SimpleProducer(bufferToUse: theBuffer@consumers) 9 theGUI: GUI 9 init-task: Producing(numItems: 20) 10 } 10 } 11 11 12 workspace consumers { 12 workspace consumers { 13 c1, c2: Consumer 13 theCounter = Counter(startValue: 0) 14 theCounter: Counter 14 theBuffer = SimpleBuffer(maxElems: 10) 15 theBuffer: Buffer 15 c1 = SimpleConsumer() 16 } 16 init-task: Consuming(maxItemsToProcess: 40) 17 17 c2 = SimpleConsumer() 18 workspace main { 18 init-task: Consuming(maxItemsToProcess: 40) 19 console: Console 19 } 20 monitor: ProductionMonitor 20 21 } 21 workspace main { 22 } 22 console = Console() 23 monitor = SimpleProductionMonitor Fig. 3. Example of a simple organization model. 24 init-task: Monitor(buff: theBuffer@consumers) 25 } 1 /* SimpleProdCons organization deployment file */ 26 } 2 workspace-addresses { 3 main = localhost 4 producers = localhost:1000 5 consumers = 137.204.107.188:8000 6 } Fig. 4. Example of deployment configuration file. Fig. 5. The implementation of a concrete organization. Finally, the deployment configuration of an organization MAS as a (local) standalone application. (details about the deploy process are given in Section V) is managed through a dedicated deployment configuration file. B. Programming the Agents Such file is used in order to specify the binding of the logical Analogously to the organization case, the agent program- workspace-based structure of the organization into the proper ming model separates the definition of the agents’ interface set of simpAL nodes targeted for hosting its execution. A from their concrete implementation. For this purpose on the simpAL node is a generic machine available on the net- one side is introduced the notion of roles, which are used work, on top of which the simpAL kernel has been properly to explicitly define the type of tasks that all the agents that installed and launched (see Section V for further details). declare to play those roles are capable to do, and on the other An example configuration file for the SimpleProdCons side the notion of agent scripts, containing the implementation organization is reported in Fig. 4. In this case we distribute of concrete plans useful to accomplish the tasks related to one the organization on top of three different simpAL nodes or multiple roles. (i.e., 137.204.107.188:8000, 92.10.45.40:8000, Fig. 6 shows both an example of definition of role 67.104.7.88:8000). The model easily allows to swap one (Producer) and an example of a script implementing that configuration file with another giving hence the opportunity role (SimpleProducer). A role is identified by a name to change, even radically, the whole deployment model of a and includes the definition of a set of task types. Each task distributed application—e.g., moving, for the same applica- type (e.g. Producing, lines 3-8) is defined by a name and tion, from a deployment configuration with all the workspaces the declaration of a set of typed parameters (e.g. maxItems, hosted on local host to another one in which each workspace line 4), representing information about the task to do. Besides is hosted on a different remote simpAL node. parameters, the definition of a task type can include a set of It is up to developers decide how to organize both the predefined attributes to refine task type specification. Among logical and physical topology of the application, by taking the others, understands makes it possible to specify into account both available hardware resources and appli- the beliefs that can be told to agents performing the task cation requirements—e.g., an application in which a set of (e.g., Producer agents can be told about the value of independent tasks are managed by a group of agents and newItemsToProduce belief, line 6). So roles define the artifacts located in separated and dedicated workspaces can type of agents, used for typing the reference or identifier of be deployed, to exploits concurrency at its best, either on a an agent. This allows for doing a set of error checking controls set of normal desktops machines or on a server with high at compile time. For instance it is possible verifying, statically, computing capabilities. that an agent is assigned only of those tasks which is capable Applications that do not require to be distributed over the to do or receive only messages that it can understand (because network can simply avoid to specify a deployment configu- they are both specified in the role the agent is meant to play). ration file. In this case the simpAL runtime will execute the It is worth remarking that the notion of role in simpAL is used to type both local and remote agents references, so this give 1 /* Definition of the Producer role */ 2 role Producer { us the opportunity to perform the above mentioned checks in a 3 task Producing { transparent manner, without the need to take into the account 4 maxItems: int; 5 understands { the actual location of the agents. 6 newItemsToProduce: int; A script represents a module of agent behavior, containing 7 } 8 } both the definition of a set of plans useful to accomplish the 9 ... tasks of the role declared to be implemented by the script, and 10 } 11 a set of beliefs that can be accessed by all the plans declared 12 /* Definition of the SimpleProducer script */ in that script. Beliefs in simpAL have a value and a type— 13 agent-script SimpleProducer implements Producer 14 in ProdConsOrg{ ranging from primitive data types, objects instances of class, 15 /* global beliefs */ or references to specific simpAL abstractions (agents/artifacts, 16 buffer: Buffer tasks, etc.)1 . 17 18 /* plans */ The SimpleProducer shown in Fig. 6 has a global belief 19 plan-for Booting (bufferToUse: Buffer) { 20 buffer = bufferToUse – buffer, used to keep track of the buffer to be used in 21 } doing its job – and a couple of plans: one for handling the 22 23 plan-for Producing { Producing task (lines 23-52) and one for the predefined 24 Booting task (lines 19-21), which is executed by default 25 noMoreItemsToProduce: boolean = false; 26 item: int = 0; when the script is loaded the first time. Moreover, being 27 nItemsTodo: int = maxItems; the SimpleProducer script declared in the context of the 28 29 completed-when: noMoreItemsToProduce ProdConsOrg organization model (Fig. 6 line 14), it is 30 using: buffer, theGui@producers { possible to directly refer inside the script all the agents and 31 32 /* purely active part */ artifacts, both locals and remotes w.r.t the node in which 33 repeat-until items > nItemsTodo { a SimpleProducer agent is located, declared in such a 34 item = item + 1 35 put(item: item) on buffer model as literals (e.g., console@main at line 41 and 47, or 36 } theGui@producers at line 30). 37 noMoreItemsToProduce = true 38 The definition of a plan includes the specification of the 39 /* reactive part */ type of task for which the plan can be used (e.g. Producing, 40 when changed stopPressed in theGui@producers => 41 using: console@main { line 23) and a plan body, containing a specification of the 42 println(msg: "stopped!") procedural knowledge that the agent can use in order to 43 noMoreItemsToProduce = true 44 } accomplish the task. Such a knowledge can be specified in 45 terms of action rules, that are ECA-like rules each specifying 46 every-time told newItemsToProduce => 47 using: console@main { an action todo along with the event and condition specifying 48 println(msg: "new items todo: "+newItemsToProduce) when the action must be done. An action rule block – which 49 nItemsTodo = nItemsTodo + newItemsToProduce } constitutes the body of a plan, denoted by { ... } – is a 50 51 } set of action rules, possibly including also the definition of 52 } 53 } local beliefs, i.e. beliefs whose scope is the block. In the most general case, an action rule is of the kind: Fig. 6. Definition of the Producer role and of the SimpleProducer script. (every-time | when) Ev : Cond => Act #Lbl or rather time passing. Actions can be either internal – i.e., meaning that the specified action Act can be executed affecting the agent internal state like a belief assignment every-time or once that (when) the specified event Ev or update – or external—i.e., or given operations provided occurs and the specified condition Cond – which is a boolean by some artifact (e.g. put, (line 35) or println (line expression of the agent beliefs base, including local beliefs 42 and 48)), or communicative actions, to asynchronously – holds. If not specified, the default value of the condition send messages to other agents (tell, ask, do-task, is true. Events, coming transparently from both local and drop-task, suspend-task, etc.). In the former case, remote workspaces, concern percepts related to either the such event is immediately enqueued with the execution of environment (e.g., the rule at line 40 reacts to the change of the action itself. In the latter case instead, the completion of theGUI artifact stopPressed observable property), or the actions (with success or failure) may arrive in the future, messages sent by agents (e.g. line 46), or actions execution, as an asynchronous event enqueued in the external event 1 It is worth remarking that in existing agent-oriented languages beliefs queue. The action rule model has been specifically devised to are typically represented by first-order logic literals, denoting information ease the definition of blocks of behavior which may need to that can be used by reasoning engines. However the logic representation is integrate and mix the execution of some workflow of actions not necessarily part of the belief concept, as remarked by Rao and Georgeff along with the reactions to some events or condition over the in [16]:“[beliefs] can be viewed as the informative component of the system state” and “[beliefs] may be implemented as a variable, a database, a set of state of the agent (e.g. lines 29-51). logical expressions, or some other data structure”([16], p. 313). As mentioned before, actions execution can fail, causing the generation of proper failures that an agent may perceive 1 /* Buffer usage interface */ 2 interface Buffer { as asynchronous events (like in the case of action completion 3 obs-prop nAvailItems: int; with success), to which it can suitably react. As in previous 4 operation put (item: int); 5 operation get (?item: int); cases, distribution issues, in this case concerning actions 6 } execution and related failures – i.e., external actions involving 7 8 /* Counter usage interface */ operation execution over remote artifacts or communications 9 interface Counter { with remote agents – are managed under the hood by the 10 obs-prop count: int; 11 operation inc(); simpAL runtime infrastructure, hence they remain completely 12 operation reset(); transparent from the point of view of the simpAL program- 13 } ming model, which allows, for example, to use the same Fig. 7. Examples of artifact usage interfaces. code to invoke external actions and react to action failures concerning either local or remote components. Some attributes can be specified for an action rule block alities from their concrete implementation, defining artifact to further control its execution and behavior. using: specify structure and behavior. The former is specified in artifact the list of the identifiers of the artifacts, used inside the block models, defining the usage interface (e.g., Fig. 7 shows the (lines 30, 41, 47). At runtime, when entering a block where an Buffer and Counter usage interfaces) of all the artifacts artifact is used, automatically the observable properties of the implementing that model. Such interface includes (i) a set artifact are continuously perceived and their value is stored in of operations, that correspond to the set of actions available corresponding beliefs in the belief base. Like in the previous to agents for using artifacts (so the repertoire of an agent’s cases, also the mapping of observable properties to the agent actions at runtime depends on the artifacts that the agent beliefs is managed transparently by the simpAL runtime knows and can use); and (ii) observable properties, as variable- infrastructure, shielding the programmer from any possible like information items storing those properties of an artifact complexities required for dealing with remote artifacts. The which may be perceived and exploited by the agents using completed-when: attribute can be used to specify the the artifact. Artifact models are used to define the type of condition for which the action rule block execution can be artifacts, used for instance in beliefs on the agent side keeping considered completed (line 29). track of artifacts to be used. Analogously to the agent case, Agents’ behavior is managed by a proper control architec- this allows to do a proper set of checks at compile time. For ture, that allows for integrating both an active, task-driven and instance, on the agent side, given a typed artifact reference it reactive, event-driven behavior and then the execution cycle (or is possible verifying errors about the actions – i.e., external control loop) that conceptually defines such behavior. Such actions can refer only to artifacts operations specified in the architecture is inspired to the reasoning cycle of BDI agents, artifact interface (e.g. put, Fig. 6 line 35) – and percepts— and can be framed here as an extension of the basic event loop i.e., belief references related to the observable state of the found in actors [13]. Conceptually, an agent is a computational artifact can refer only to the observable properties defined in entity executing continuously a loop which involves three the artifact models (e.g., the reference to the stopPressed distinct stages executed in sequence: a sense stage, in which observable property in Fig. 6 at line 40). As in the case of the agent fetches percepts (inputs) from the environment – roles, being the notion of artifact model used to type both local available in an event queue – updating its internal state, a plan and remote artifact references, the static checks just presented stage in which, given the current state and the set of current apply transparently to any artifact reference, independently tasks that the agent is actually pursuing, the set of actions to from the actual location of the referenced artifact. do is selected, and finally an act stage in which the selected The implementation of an artifact is defined in artifact actions are executed. From a conceptual point of view, an agent templates. The definition of an artifact template includes a is never blocked: it is continuously looping on these stages, name, the declaration of the implemented artifact model, the possibly without choosing any action to perform if there are concrete implementation of operations and the definition of no active tasks or there is nothing to do in a specific moment those internal variables that are used in operation implemen- in the tasks it is pursuing. tations. Fig. 8 shows the implementation of a simple buffer and of a counter. Like classes in OOP, artifact templates are a C. Programming Artifact-Based Environments blueprint for creating instances of artifacts. On the agent side, The programming model of artifacts is definitely simpler a specific action (make-artifact) is available for creating than the agents’ one, more similar to the model used for a new artifact, specifying initial parameters and a belief where classic passive entities, such as monitors or objects. Artifacts to store the reference to the artifact created. are simple modules encapsulating the implementation and Operation behavior is given by a simple sequence of state- execution of sets of operations as actions that the artifact ments, in pure imperative style, using classic control flow makes it available to agents, and a set of observable properties constructs, assignment operators, etc. Besides classic state- that agents using the artifact may perceive. ments, specific primitives are introduced to control operation Analogously to the agent case, also for artifact programming execution. For instance, the await statement – used in the we separate the abstract description of the artifact function- get and put operations – allows for suspending the operation 1 artifact SimpleBuffer implements Buffer { 2 3 /* hidden state variables */ 4 int maxNumElems; 5 java.util.LinkedList elems; 6 1 artifact CounterImpl implements Counter { 7 /* constructor */ 2 c0: int; 8 init (maxElems: int) { 3 9 count = startValue; 4 init (startCount: int) { 10 nAvailItems = 0; 5 count = startCount; 11 maxNumElems = maxElems; 6 c0 = startCount; 12 elems = new java.util.LinkedList(); 7 } 13 } 8 14 9 operation inc() { 15 /* operations */ 10 count = count + 1 16 operation put (item: int) { 11 } 17 await nAvailItems < maxNumElems; 12 18 elems.add(item); 13 operation reset(){ 19 nAvailItems = nAvailableItems + 1; 14 count = c0; 20 } 15 } 21 16 } 22 operation get (?item: int) { 23 await nAvailItems > 0; 24 nAvailItems = nAvailableItems - 1; 25 item = elems.remove(); 26 } 27 } Fig. 8. Source code of the artifact templates SimpleBuffer and CounterImpl. until the specified condition is met (allowing then other assumes the role of launch manager. Once the launch starts, the operations to be executed). As in the case of monitors, only manager, using the information specified into the application one operation can be in execution: so if multiple suspended deployment configuration file (if any), properly distributes the operations can be resumed a certain time, only one is selected. simpAL program, in its compiled version, among the others Operation execution in artifacts is transactional, in the sense target nodes. It is worth remarking that the simpAL runtime that they are executed in a mutually exclusive way and the infrastructure guarantees the consistency and the alignment of changes to the observable state of the artifact (properties) are programs’ sources either in the case of multiple local launches done atomically. Changes are perceived by agents observing and in the case of distributed ones—i.e., only the up-to-date the artifact only when an operation completes (with success). version of the compiled sources is loaded or distributed among the interested nodes. Since this phase does not involve any kind V. T HE SIMP AL D ISTRIBUTED RUNTIME of logical dependency, is done in a concurrent manner to speed I NFRASTRUCTURE up the boot process. Then, when the simpAL kernels installed The deployment, execution and life-cycle management of in the interested nodes receive their part of the application, programs written in simpAL are in charge of a distributed each one of them autonomously starts the booting by properly runtime infrastructure, developed in Java, which has been initializing the workspaces that need to be hosted in that node. explicitly devised for managing all this issues transparently During this process, the simpAL kernels communicate with with respect to distribution. The background idea that guided each others using a simple handshake protocol in order to keep the development process of this infrastructure is: the execution track of the current status of the application and to guarantee and management of distributed MASs should be, from a a proper initialization of the MAS. Finally, only when all the developer perspective, as simple as the case of centralized, workspaces have been deployed and all the static artifacts not distributed ones. contained in them properly created, the agents are spawned To this end the notions of simpAL kernel and simpAL and then the MAS can start its execution. node have been introduced. The former is in charge of the The termination of a running application can be triggered concrete execution of simpAL programs or parts of them (in from any of the simpAL nodes in which it is hosted. Once case of distributed execution). The latter instead is a generic triggered, the termination is managed, exploiting a proper network node in which the simpAL kernel is installed and shutdown protocol, in a coordinated manner by all the kernels executed – typically like a demon running in background, involved in the shutdown process. launched when the machine boots – used as the basic building block for providing a robust and flexible distributed runtime VI. D ISCUSSION infrastructure for executing MASs—i.e., a simpAL node can Given the presentation of both the simpAL runtime infras- be considered as a generic network node on top of which a tructure and programming model, in this section we provide user may want to host the execution of simpAL programs, or a critical discussion about some relevant points, in relation to parts of them. the programming, deployment and management of distributed Once the kernel is up and running in all the interested multi-agent systems in simpAL. network nodes, a user can start the execution of a simpAL The first one concerns the support given by the simpAL application by launching it from a generic simpAL node that programming model to handle distribution when programming an application. simpAL has been conceived from the beginning system for enabling some kind of basic error checks. However, for (also) distributed programming, hence distribution is a in this APLs part of the abstractions characterizing the agent- feature which is directly part of its agent-oriented program- oriented paradigm (goals, messages exchanged, etc.) can not ming model. This allows, on the one side to have first class be explicitly modeled at the language level (i.e., they are abstractions to conceive and define, in a explicit manner during not part of the OO programming model), and therefore this the design phase, the application structure from both a logical limits the compile-time error checking mechanisms that can and physical point of view. To authors’ knowledge, there are be introduced in such languages, in particular the ones related not other APLs in the state-of-the-art that give this opportunity. to the interactions with distributed components (e.g., checks Indeed, usually the application structure is implicit, depicted for detecting wrong goals assignment to agents). almost entirely into developers’ minds, and it is possible to Finally, the last point we consider, concerns the easy man- have a clear picture of it only at runtime when all the MAS’s agement of the deployment and execution of distributed MASs. parts have been properly deployed and initialized. On the other We argue that the infrastructural support given by current side, the programming model makes it possible to get a full state-of-the-art APLs makes these tasks quite troublesome, transparency with respect to distribution when programming causing developers to manually manage specific deploy/launch agents and artifacts—e.g., the code that one needs to write procedures that can be instead automatized and taken in for implementing an agent communicating with (or spawning) charge by APLs’ runtime infrastructures. Accordingly, sim- other agents, or an agent using/observing/creating artifacts is pAL provides both a programming model and a distributed the same in spite of the fact that agents/artifacts are in the runtime infrastructure aimed at giving developers the means to same workspace (node) or not. A similar transparency level is manage distributed applications like local ones. However, even provided by JADE and by all the APLs in the state-of-the-art if from the one side several efforts have been made in order that exploit some generic agent platform to enable transparent to engineer a distributed infrastructure that goes beyond the message-based interactions among local and remote agents ones provided by state-of-the-art APLs – e.g., no more need (e.g., Jason, AFAPL, etc.). However, usually, transparency to manually deploy / initialize / terminate the different parts related to distribution issues is limited to message exchanges of a distributed application, trivial management of different among agents, while instead interactions with other language deployment configurations for the same application, etc. – specific components (e.g. Platform Services in AFAPL) still on the other side such infrastructure is still at the prototype need to be handled in an ad-hoc manner, taking into account level, therefore, it can not be considered as mature and robust the actual location of such components. as reference agent-based ones, e.g. like the one provided by The second point concerns instead the capability to detect JADE, used also in industrial contexts. programming errors, in particular related to the interactions with distributed components, at compile-time. Indeed, be- VII. O NGOING AND F UTURE W ORK ing simpAL a statically typed programming language, it is Ongoing and future work concern both topics and arguments possible to detect statically, before running the system, a which are related to the main contribution of this article, and proper set of errors: the referencing of non-existing symbols other ones which are instead outside of this scope and hence, due to typos, sending to an agent a message that it can not discussed here—e.g., enriching the task model, definition not understand, invoking an artifact operation with wrong of social tasks, extending the type system in oder to support arguments types, etc. In particular, as described in detail in sub-typing and inheritance, etc. Section IV, the presence of a proper type system and the First, we want to improve the current implementation of the transparency provided by the simpAL programming model, simpAL runtime platform in order to make it more robust and give us the opportunity to seamlessly perform a vast set of mature for the execution and management of distributed multi- compile-time error checks concerning the interaction with both agent systems. The seamless management of faults that can local and remote components, without having the burden to occur at runtime – e.g., network delays, unexpected shutdown deal with distribution issues. A comprehensive description of of network nodes, etc. – is a key issue in the general context all the compile-time checks that can be performed in simpAL of distributed systems and related infrastructures that support is outside the scope of the paper. Interested readers can find their execution. So far, in simpAL the only support provided further details here [18]. Others state-of-the-art APLs provide, for dealing with faults at runtime is at the programming in general, a quite weak typing support. Some languages – level, where programmers can deal with the different kind e.g., Jason, GOAL, AFAPL – do not support at all a notion of network problems that can occur by properly reacting to of type, therefore is not possible perform compile-time errors action failures perceived by the agents (see Section IV-B). detection neither for what concerns classical programming We aim at improving the current basic support for handling errors (e.g., assign to a belief meant to store integer numbers faults at runtime, trying to shield programmers as much as a string value) nor for the ones concerning interactions with possible from their management. The final objective of this distributed components (e.g., requesting the achievement of enhancements is the realization of a fault-tolerant runtime goals unknown to the agents) [18]. Other ones instead (e.g. infrastructure able to manage in a quite seamless manner: JADE), being frameworks realized on top of mainstream OO- temporary node unreachability, dynamic addition / shutdown based programming languages, exploit the underlying type of simpAL nodes, workspace migration, etc. Another main improvement we aim at investigating in the [2] F. L. Bellifemine, G. Caire, and D. Greenwood. Developing Multi-Agent near future concerns the study of a proper extension in order Systems with JADE. Wiley, 2007. [3] R. Bordini, J. Hübner, and M. Wooldridge. Programming Multi-Agent to provide a better support for openness and dynamism in Systems in AgentSpeak Using Jason. John Wiley & Sons, Ltd, 2007. simpAL programs. These are two of the key features of multi- [4] R. H. Bordini, M. Dastani, J. Dix, and A. El Fallah Seghrouchni. Special agent systems, giving the opportunity to design applications issue: Multi-agent programming. Autonomous Agents and Multi-Agent Systems, 23 (2), 2011. that can change, adapt and evolve at runtime. Currently [5] R. H. Bordini, M. Dastani, and A. El Fallah Seghrouchni, editors. Multi- simpAL provides a quite weak support for realizing appli- Agent Programming Languages, Platforms and Applications - Volume cations able to express this kind of behavior. Indeed, as a 1, volume 15. Springer, 2005. [6] R. H. Bordini, M. Dastani, A. El Fallah Seghrouchni, and J. Dix, editors. design choice, for enabling strict compile-time error checking Multi-Agent Programming Languages, Platforms and Applications - mechanisms, the set of allowed types in an organization is Volume 2. Springer, 2009. determined statically (see Section IV). As a consequence, [7] L. Braubach, A. Pokahr, D. Bade, K. Krempels, and W. Lamersdorf. Deployment of distributed multi-agent systems. Engineering Societies situations involving the interaction with components exter- in the Agents World V, pages 898–898, 2005. nal to the organization, whose type can be unknown, are [8] M. Dastani. 2APL: a practical agent programming language. Au- not allowed, hence limiting the openness and dynamism of tonomous Agents and Multi-Agent Systems, 16(3):214–248, 2008. [9] T. Finin, R. Fritzson, D. McKay, and R. McEntire. Kqml as an agent simpAL programs. We want to overcome this weakness by communication language. In Proceedings of the third international studying a proper extension of the simpAL organizational conference on Information and knowledge management, pages 456–463. model, maintaining however our current application model – ACM, 1994. [10] K. V. Hindriks. Programming rational agents in GOAL. In R. H. Bordini, i.e., an application is seen as an organization structured in term M. Dastani, J. Dix, and A. El Fallah Seghrouchni, editors, Multi-Agent of workspaces – and without renouncing to the possibility of Programming: Languages, Platforms and Applications (2nd volume), performing compile-time error checks. pages 3–37. Springer-Verlag, 2009. [11] N. Howden, R. Rönnquist, A. Hodgson, and A. Lucas. JACK intelligent Finally, other efforts will be dedicated in the realization agentsTM — summary of an agent infrastructure. In Proc. of 2nd Int. and improvement of proper tools for debugging, monitoring, Workshop on Infrastructure for Agents, MAS, and Scalable MAS, 2001. and profiling distributed simpAL programs. Currently simpAL [12] N. R. Jennings. An agent-based approach for building complex software systems. Communication of ACM, 44(4):35–41, 2001. comes along with a simple debugger which allows to inspect [13] M. Miller, E. Tribble, and J. Shapiro. Concurrency among strangers. In agent execution on a step-by-step basis. However this tool is R. De Nicola and D. Sangiorgi, editors, Trustworthy Global Computing, quite simple and, so far, it does not support breakpoint at the volume 3705 of Lecture Notes in Computer Science, pages 195–229. Springer Berlin / Heidelberg, 2005. artifact/workspace/node level. Therefore, we intend to enrich [14] A. Omicini, A. Ricci, and M. Viroli. Artifacts in the A&A meta-model the current debugger and also develop further tools that will for multi-agent systems. Autonomous Agents and Multi-Agent Systems, allow to inspect and monitor simpAL programs in a more agile 17 (3):432–456, Dec. 2008. [15] A. Omicini, A. Ricci, M. Viroli, C. Castelfranchi, and L. Tummolini. and comprehensive way. Coordination artifacts: Environment-based coordination for intelligent agents. In Proc. of the 3rd Int. Joint Conf. on Autonomous Agents and VIII. C ONCLUSION Multi-Agent Systems (AAMAS’04), volume 1, pages 286–293, New York, USA, 19–23July 2004. ACM. The availability of proper APLs and related runtime plat- [16] A. S. Rao and M. P. Georgeff. BDI Agents: From Theory to Practice. forms able to support a seamless engineering, deployment and In First International Conference on Multi Agent Systems (ICMAS95), 1995. execution of distributed multi-agent systems is a key factor [17] A. Ricci and A. Santi. Designing a general-purpose programming for their successful realization. Accordingly, in this paper we language based on agent-oriented abstractions: the simpAL project. presented simpAL, an agent-oriented programming language In Proc. of the compilation of the co-located workshops on DSM’11, TMC’11, AGERE!’11, AOOPES’11, NEAT’11, VMIL’11, SPLASH ’11 providing both a programming model and a distributed runtime Workshops, pages 159–170, New York, NY, USA, 2011. ACM. platform aiming at making the programming and execution [18] A. Ricci and A. Santi. Typing multi-agent programs in simpAL. In of multi-agent systems quite transparent with respect to their Proceedings of the Int. Workshop on Programming Multi-Agent Systems (ProMAS’12), Valencia, Spain, 2012. distribution. [19] R. J. Ross, R. W. Collier, and G. M. P. O’Hare. AF-APL - bridging A guiding toy example has been used for introducing the principles and practice in agent oriented languages. In Programming support provided by simpAL for dealing with distribution Multi-Agent Systems, volume 3346 of Lecture Notes in Computer Science, pages 66–88. Springer, 2004. issues at the programming and execution levels, and also for highlighting the main aspects of the simpAL programming model. Finally, a critical analisys has been provided for pointing out the improvements made in handling distribution issues in simpAL, in relation with the current support given by APLs in the state-of-the-art, and current weaknesses and limitations of both its programming model and distributed runtime platform, along with the plan for their overcome with future work. R EFERENCES [1] FIPA Agent Communication Language specification – http://www.fipa. org/repository/aclspecs.html, last retrieved: July 18th 2012.