=Paper=
{{Paper
|id=None
|storemode=property
|title=Programming Distributed Multi-Agent Systems in simpAL
|pdfUrl=https://ceur-ws.org/Vol-892/paper5.pdf
|volume=Vol-892
|dblpUrl=https://dblp.org/rec/conf/woa/SantiR12
}}
==Programming Distributed Multi-Agent Systems in simpAL ==
https://ceur-ws.org/Vol-892/paper5.pdf
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.