Coordination Technology for the Development of

Multi-Agent Systems on the Web

Enrico Denti, Andrea Omicini, and Vladimiro Toschi

LIA - Laboratorio di Informatica Avanzata

DEIS - Universit�a di Bologna

Viale Risorgimento, 2 40136 { Bologna, Italy

fedenti,aomicini,vtoschig@deis.unibo.it

Abstract. The development of multi-agent systems on the Web requires

powerful and e�ective coordination models, languages and patterns. Even

more, it calls for an e�ective coordination technology, not only imple-

menting a coordination model, but also supporting its metaphors at the

development system level, and enabling developers to work at any time

at the abstraction level required.

This paper presents the LuCe coordination system for the development of

multi-agent systems on the WWW. Based on the full integration of Java

and Prolog technologies, LuCe implements a coordination model based

on the notion of logic tuple centre, a coordination medium which is also

exploited as the core of the development system. The power of the LuCe

coordination technology is �rst discussed in general, then shown in the

context of an application example, a TicTacToe game among intelligent

software agents and human players on the Web.

Keywords: Multi-Agent Systems, Web Agents, Coordination Models,

Tuple Centres

1 Introduction

The design and development of Web-based applications calls for new technologies and

powerful abstractions coming from the Arti�cial Intelligence, the Distributed Software

Engineering, and the GUI �elds. Multi-agent technology enables autonomous and het-

erogeneous components to be combined so as to bring intelligence into Web-based

applications. Software composition in a distributed environment requires powerful and

expressive coordination models, languages and patterns in order to guarantee the e�ec-

tive integration of components. However, no model, no abstraction can actually help

in the development of highly interactive [18] applications, like the Web ones, unless

supported by both a suitable development system and a exible and usable adminis-

tration environment. As clearly emerging from the research on coordination (see [2, 7]

among the others), and as implicitly endorsed by the recent work from Sun [13] and

IBM [9], the deployment of multi-component software systems calls for the adoption of

suitable coordination models. We argue that no coordination model can be e�ectively

exploited at its best without a well-designed coordination system.

This paper focuses on the issue of coordination technology [1] and of its full ex-

ploitation for the development of complex multi-agent systems on the WWW. Since

the design process in Web application development is typically as critical as application

maintenance and incremental development, the availability of a suitable coordination

technology turns out to be as essential as the choice of the coordination model. From

this viewpoint, we claim that the mere implementation of a coordination model is not

enough for a coordination system. Instead (apart from obviously supporting all the

abstractions and mechanisms provided by its coordination model), a coordination sys-

tem should (i) fully exploit the model's metaphors to provide specialised development

tools, and (ii) enable application developers to deploy, maintain and incrementally de-

velop Web-based applications choosing at any time the desired abstraction level over

the system.

In this context, this paper presents the LuCe coordination system (from Logic Tuple

Centres) for the development of multi-agent applications on the WWW. LuCe exploits

a coordination model based on logic tuple centres, which are basically tuple spaces with

logic tuples enhanced with the notion of behaviour speci�cation. As shown in [5], this

makes it possible to keep the agent's perception of the interaction space distinguished

from the actual state of the coordination media, and relate them according to the

required coordination laws.

From the architectural viewpoint, the LuCe system relies on the notion of cell as a

topological abstraction, which partitions the interaction space according to the network

topology. Each cell is associated to a network node, and contains both coordination

entities and media. By implicitly promoting local communication, cells minimise the

cost of coordination transparency.

At the development system level, LuCe support tools are built upon its coordi-

nation media. For instance, three kinds of tuple centre tracers (for tuples, communi-

cation operations, and behaviour speci�cations) make it possible to adopt either the

communication viewpoint (in either a data-oriented or a control-oriented fashion [12],

respectively) or the coordination viewpoint, depending on the abstraction level which

at any time best �ts the current phase of a multi-agent system development.

From the technology viewpoint, LuCe exploits and integrates both Java and Prolog

technologies: the Java object-oriented architecture is used for the basic LuCe system's

development, while Java standardisation provides for hardware and software architec-

ture heterogeneity of the Web nodes, as well as for the Web interface. Prolog consti-

tutes the basic LuCe communication language, so that �rst-order logic can be naturally

exploited to mediate among heterogeneous Web agents. In addition, the core of a Java-

based Prolog engine is used to build the LuCe top-level, and makes it possible to exploit

the inferential capabilities of Prolog for the construction of intelligent agents.

This paper is structured as follows. Section 2 presents the coordination model on

which LuCe is based, by discussing the core notion of logic tuple centre in short. Sec-

tion 3 describes the LuCe system at the architectural level and outlines the system

implementation. Section 4 illustrates the LuCe development system, and discusses its

support tools. LuCe system features are then further discussed in Section 5, by present-

ing a simple application where some logic-based intelligent agents play against human

players interacting through the LuCe system on the Web.

2 Coordination in LuCe

In LuCe, agents interact by exchanging logic tuples through a multiplicity of commu-

nication abstractions, called tuple centres. The LuCe communication language is based

on �rst-order logic: a tuple is a Prolog ground fact, any unitary Prolog clause is an

2

admissible tuple template, and uni�cation is the tuple matching mechanism. Agents

perceive a LuCe tuple centre as a logic tuple space, which can be accessed through the

typical Linda-like [8] read/write/consume operations over logic tuples (out, in, rd, inp,

rdp). Each tuple centre is uniquely identi�ed by a ground Prolog term, and any ground

term can be used to denote a tuple centre. Since LuCe is coordination transparent [10],

agents do not have to care about tuple centre existence and creation.

What makes a tuple centre di�erent from a tuple space is the notion of behaviour

speci�cation, which de�nes how a tuple centre reacts to an incoming/outgoing com-

munication event. From the agent's viewpoint, a tuple centre looks like a tuple space,

since it is accessed through the same interface: however, unlike a tuple space, the tuple

centre's behaviour in response to communication events can be de�ned so as to embed

the coordination laws into the coordination medium [4]. In particular, LuCe adopts the

tuple centre model de�ned in [5], where reactions in response to communication events

are de�ned by means of �rst-order logic tuples, called speci�cation tuples.

This naturally suggests two levels of abstraction over the space of agent interaction:

the communication viewpoint and the coordination one. By representing at any time

the current state of agent interaction, the state of the space of (ordinary) tuples provides

for the communication viewpoint: each tuple space can then be seen as representing a

portion of the global interaction space, where inter-agent communication takes place.

On the other hand, the space of the speci�cation tuples provides for the coordination

viewpoint, since the behaviour speci�cation of a tuple centre governs inter-agent com-

munication, and speci�cation tuples actually de�ne agent coordination rules. Thus,

shifting from the tuple space part to the speci�cation part of a tuple centre actually

corresponds to lifting the abstraction level from communication to coordination.

3 The LuCe Architecture

The LuCe architecture is rooted on the notion of cell. Generally speaking, a cell de�nes

a local interaction space, that is, a collection of interacting entities hosted by a physical

node of the distributed system. A LuCe interacting entity can be either an agent or a

tuple centre.

A LuCe (interaction) space consists of a collection of cells possibly spread over the

Internet, and includes all the cells' local interaction spaces. Every LuCe space is denoted

by a globally unique identi�er, and is characterised by a set of properties evolving over

time (such as the collection of the cells participating to the space), which we capture

with the notion of environment of a LuCe space. Multiple LuCe spaces may be active

at the same time, but each cell belongs to one LuCe space, which is declared once and

for all when the cell is started up. Instead, a node may well hold multiple cells, each

participating to a possibly di�erent LuCe space, independently of any other cell.

Agents and tuple centres of the same LuCe space interact by means of the LuCe

coordination language. Interaction takes place in a fully transparent way: information

such as the name and location of each cell, the name and location of each interacting

entity, and so on, constitutes a LuCe space environment, which is charged upon an ad-

hoc environment process, transparently to the agents. While some of such information

is of system use only, other information may also be made available to the agents:

for instance, a mobile agent might ask for the physical location of a tuple centre and

decide to move there instead of accessing it remotely, provided that it is authorised

to do so. In principle, this allows the classical trade-o� between network transparency

and network-awareness to be faced on a case-by-case and agent basis.

3

The existence of an environment process characterises the existence of a LuCe space.

For this reason, the �rst cell willing to join a previously-unnamed LuCe space also

causes the corresponding environment process to be created. According to the locality

principle, such a process is created as a ow of control of the �rst cell, which is then

referred to as the LuCe space's main cell. A cell is implemented as a process executed

locally to a node. Cells join a given LuCe space by connecting to the corresponding

environment process, which is denoted by the LuCe space identi�er. Each interacting

entity of a cell (either an agent or a tuple centre) is a single thread of control of the

cell process.

This leads to implement the environment process as a tuple centre of the main

cell, where all the information about a LuCe interaction space is recorded in form

of logic tuples, too. However, even though structurally homogeneous with the other

tuple centres, the environment tuple centre is not accessed through the standard LuCe

coordination primitives, but using instead the specialised outEnv, inEnv, rdEnv, inpEnv

and rdpEnv primitives. This is because the environment process does not participate

to the LuCe interaction space it describes, coherently with its nature of a meta-level

information structure. The environment tuple centre is then accessed either explicitly,

by (authorised) agents, or implicitly, whenever some of its information is needed by

the underlying support (e.g., to resolve the name of a previously unused tuple centre).

In order to achieve platform independence and actual portability, LuCe is all de-

veloped in Java. Since logic tuple centres require the support of a logic language, the

MicroProlog interpreter [17], entirely written in Java, has also been embedded in the

LuCe system. In particular, Prolog terms, used for communication, are instances of

the Java class mpTerm, provided with methods for terms comparison and uni�cation.

Cells are instances of the Java class LuCeCell. Agents and tuple centres belonging to

a cell are de�ned as new Java threads of the same basic process: agents are instances

of (a subclass of) the Java class LuCeAgent, providing agents with the LuCe coordina-

tion language, while tuple centres are instances of the Java class mpTCServer. Users

can then easily write new classes of LuCe agents by simply de�ning a new subclass of

LuCeAgent.

4 Development in LuCe

A new LuCe space is created by �rst starting up its main cell. This creates the corre-

sponding environment tuple centre whose hostname/hostport pair is set according to

the user input (Fig. 1), and represents the global unique ID of the new space. Ordinary

(non-main) cells may join any LuCe space by specifying its unique ID at creation time.

Whenever a new cell joins a LuCe space, its console appears (Fig. 2) providing the user

with a command line interface to activate agents and tools.

Since a tuple centre is characterised by three sets { the set T of its tuples, the setW

of its pending queries waiting to be served, and the set S of its reaction speci�cations {

the LuCe system comes with a set of specialised LuCe agents to view, edit and control

tuple centres both from the data, the pending query and the speci�cation viewpoints:

the T, W and S Inspectors. By enabling tuples' observability, the T Inspector provides

for the abstraction level of communication in a data-oriented fashion, while the W In-

spector, supporting communication events' observability, provides for the abstraction

level of communication in a control-oriented fashion. Finally, by making speci�cation

tuples observable, the S Inspector provides for the abstraction level of coordination.

4

Fig. 1. Starting a LuCe main cell

Fig. 2. The LuCe console

Fig. 3. A LuCe T Inspector at work

5

4.1 The T Inspector

The T Inspector is the tuple tracer/editor, activated by issuing a tinspect(Inspector ,

TC ) command from the cell console (see Fig. 2 for an example), where Inspector is the

name of the inspector agent, and TC is the tuple centre to be inspected. As a tracer,

it can capture all the state transitions of a tuple centre, and show the current state of

the space of tuples. As an editor, it allows the user to add, read or remove tuples by

means of the standard LuCe communication primitives out, in, rd, etc.

Since di�erent debugging activities may require di�erent views over a system, the

tracer behaviour may be con�gured according to the user needs. In fact, (i) tracing

has a cost (both from the network tra�c and from the system speed viewpoints), and

(ii) a too �ne-grained trace may sometimes result confusing, making it di�cult to �nd

the relevant events among a plethora of tracing messages. For this reason, the Freq

�eld allows the user to de�ne the refresh ratio (that is, how often the view should be

updated, in terms of observable tuple centre transitions), while the Pattern �eld allows

the user to specify a �lter template, so that only matching (unifying) tuples are shown.

Independently of the refresh ratio, the user is free to force an update of the tracing

view at any time, by means of the Update button.

As a tuple editor, the T Inspector allows the user to directly perform tuple opera-

tions: the involved tuple is �rst written on the Request �eld, then the proper operation

is triggered by pressing the proper button (Out , Rd , Rdp , In , Inp ): the Answer �eld

shows the operation result, if any. For instance, Fig. 3 shows the result of a rd(p(X)) op-

eration. User-triggered operations are observationally indistinguishable from any other

agent-triggered operations, and activate the related reactions, if any, according to the

current behaviour speci�cation. This is an essential feature to make tracing e�ective,

since it allows the tuple centre's behaviour to be tested separately from agents.

4.2 The W Inspector

The W Inspector is the pending query tracer. This tool is activated from the console

with a winspect(Inspector,TC ) command, and works similarly to the T Inspector,

allowing tuple centre's incoming communication events to be fully monitored. More-

over, by means of the Out , Rd , Rdp , In , and Inp buttons, the W Inspector allows new

communication events to be triggered, so that the behaviour of a tuple centre can be

tested by observing the evolution of the pending query queue.

4.3 The S Inspector

The S Inspector is the speci�cation editor, and is launched from the LuCe console

by issuing a sinspect(Inspector,TC ) command. Unlike the T and W Inspectors,

this tool does not provide the Out , Rd , Rdp , In , Inp buttons for speci�cation tuples.

Instead, it means to capture the typical programmer's \way of doing", based on writing

programs (reactions) in a �le, edit them, and reload the new speci�cations when done.

Accordingly, it provides the programmer with controls to Consult , Edit , Update and

Save a behaviour speci�cation, along with syntax checking capabilities.

5 TicTacToe in LuCe

In this section we put the LuCe architecture and support tools to the test, by discussing

the design and implementation of the classical TicTacToe game. In its basic version,

6

the game is played on a grid of 3� 3 cells by two players, identi�ed by circles (o) and

crosses (x). Each player aims to put three pieces of his/hers so as to �ll a line of the

grid (vertically, horizontally or diagonally), while trying to prevent the other player

from doing the same. The application scenario is a Web-based TicTacToe arena, where

any human player can at any time ask to enter a game, and is ensured to �nd a game

and an opponent { a human one, if available, or a software agent, if needed.

Human players are represented by GUI agents, written in Java, which constitute

the graphical interface for human players towards the LuCe-coordinated application.

GUI agents show the classical TicTacToe grid, and let human players make a move,

ask for a suggestion, or leave the game, mapping user commands onto tuple operations.

Expert agents are intelligent agents, written in Prolog, which (i) encapsulate the

TicTacToe rules and strategies, (ii) validate human player's moves, and (iii) suggest

the next best possible move if requested to do so by a human player. In addition, an

expert agent (iv) can play a game when no human opponent is available, so that a

human player may join or leave a game at will, transparently with respect to the other

human players.

Despite of its simplicity, this application demonstrates the e�ectiveness of the LuCe

coordination model and technology in the design and development of multi-agent ap-

plications over the Web. First, as discussed in [6], it shows that the neat separation

between computation and coordination provided by the model makes it possible to de-

sign agents around very straightforward communication protocols. Moreover, it shows

how heterogeneous agents, such as human players (represented by GUI Java agents)

and intelligent (Prolog) agents can be e�ectively coordinated in LuCe, and how the LuCe

coordination technology can be exploited to manage the design and implementation of

a multi-agent system on the Web.

5.1 Design Choices

The structure of any LuCe application is designed around tuple centres, working as the

core of the interaction space. All the information about TicTacToe games is stored in

the tictactoe tuple centre, which is in charge of handling all the interactions among

human-driven and software agents. More precisely, the tictactoe tuple centre is at

any time in charge of coordinating (i) one GUI (Java) agent for each human being

currently playing, (ii) one expert (Prolog) agent for each game currently played, and

(iii) a single master agent in charge of initialising tictactoe and activating a new

expert agent for every newly-created game.

From the system design viewpoint, what is worth to be pointed out is that the LuCe

coordination model allows each agent (i) to adopt the interaction protocol which is the

most suited to its task and abstraction level, and (ii) to uncouple it from the domain

representation, which can then be chosen according to knowledge representation cri-

teria only, independently of the agents' viewpoints. It is then up to the tuple centre's

behaviour speci�cation to bridge the gap between the di�erent agent perceptions and

the game representation, embodying all the required coordination laws.

5.2 Knowledge Representation

All the information about TicTacToe games is stored in the tictactoe tuple centre

in form of logic tuples. Games are labelled progressively with an integer value, so that

a gameStatus(ID,MoveNo,Status,Next ) tuple in tictactoe represents the current

7

Status of the game ID after move MoveNo has been performed, while waiting for the

next move from player Next (x or o). Status is either an s/9 term representing the

state of the 9 grid's cells by means of n (no sign yet), x or o constants, or an end/2

term denoting the game end, where end(s,FS ), end(x,FS ) and end(o,FS ) represent,

respectively, the even game (stalemate), the win by x, and the win by o, with �nal

status FS , in turn represented as an s/9 term.

A move(ID ,MoveNo ,Player ,Role ,on(X,Y )) tuple records move MoveNo of game

ID performed by player Player acting as Role and putting its sign (x or o) on the grid

cell (X,Y ). A freeRole(ID,Role ) in tictactoe tuple indicates that no human player

is currently playing as Role (x or o) in game ID : so, a human player asking to enter a

game can freely join game ID , and play as Role . The tuple id(ID ) records the label

for the next game to be started, which is initialised as id(1) and then incremented

at any new game creation. The term representing the initial status for any TicTacToe

game is recorded by the initialStatus(s(n,n,n,n,n,n,n,n,n)) tuple.

5.3 The Agent Tasks and Protocols

Once agents are assigned a task, their interaction protocols can be de�ned according

to simple information-oriented criteria: which information can be made available, and

when, which information is needed, and when, how information is to be represented

and accessed, and so on. Since any interaction occurs via the tictactoe tuple centre,

designing the agent protocols amounts at de�ning how agents exchange tuples with

tictactoe. For the sake of simplicity, we will omit in the following the tuple centre

name from the operation syntax: so, op(T) will stand for tictactoe?op(T).

The Master Agent. The master agent is simply in charge of (i) initialising the

tictactoe tuple centre and (ii) starting a new expert agent for every newly-created

game. Thus, it �rst initialises tictactoe by means of an out(initialise) operation,

then it starts its working cycle, by repeatedly performing an in(newGame(ID )). When-

ever such a tuple is found, the master agent consumes it, and correspondingly activates

a new expert agent for the newly-created game ID .

The Expert Agent. Each expert agent is dedicated to a single TicTacToe game, and is

in charge of three tasks: (i) validating human players' moves, (ii) playing in place of a

human player, if needed, and (iii) suggesting moves, if required. However, expert agents

have no need to know whether they are actually playing a game or simply suggesting

a move to a human player, since the underlying logic is the same. So, the same simple

interaction protocol can be exploited for the two cases, making expert agent play

and de�ning coordination rules (in terms of tictactoe's speci�cation tuples) which

discriminate between the two distinct expert agent's tasks and produce the required

system behaviour. Expert agents are written in Prolog and have no GUI: they just

perform a polling loop, which iterates an in over expertTask/3 tuples and ends when

rdp(gameOn(ID )) fails. More precisely:

{ an expertTask(ID ,Status ,validate(X ,Y )) tuple represents the request for val-

idating a move on cell (X ,Y ). The expert agent answers by emitting either an

invalid(ID ,on(X ,Y )) tuple if the move is not valid, or a valid(ID ,on(X ,Y ),

NewStatus ) tuple otherwise, where NewStatus is either an s/9 or an end/2 term,

in the same way as the Status argument in the gameStatus/4 tuple.

{ an expertTask(ID ,Status ,play(Role )) tuple makes the expert agent evalu-

ate game Status and respond by emitting an expertMove(ID ,Role ,on(X ,Y ),

NewStatus ) tuple, representing its move (X ,Y ) as a Role player.

8

Fig. 4. Playing TicTacToe: before and after asking for a suggestion

The GUI Agent. A GUI agent is started by a human player willing to enter a game,

typically via an Internet browser. On startup, the GUI agent gets a role in a TicTacToe

game by performing an in(joinGame(ID,Role )) which assigns role Role in game ID

to the new player. Then the main agent's loop begins, getting the game status by means

of a rd(gameStatus(ID,Status,Next )), and showing it to the human player. If Next

is not Role , it is the opponent's turn to move. The GUI agent restarts its main loop,

unless the player decides to quit the game and closes the GUI window, thus causing a

leaveGame(ID,Role ) tuple to be output and the GUI agent to quit. If, instead, Next

is Role , it is the player's turn to move, and three commands are made available:

{ try to put Role 's sign on cell (X,Y ) of the game ID grid. An in(humanMove(ID ,

Role ,on(X ,Y ),OK )) operation signals the user's desired move, and makes the

agent wait for validation by the expert agent. If the move is accepted, OK is true

in the answer tuple, and the agent's main loop restarts. Otherwise, OK is false, the

game status is unmodi�ed, and the GUI agent waits for the next player's command.{ ask for a suggestion. An in(suggest(ID,Role,SuggestedMove ) is performed, and

the answer tuple contains the move on(X,Y ) suggested by the expert agent. The

suggested move is visualised (as an `S') by the GUI agent on the grid, then the

GUI agent keeps waiting for the player's new command. (Fig. 4 shows the GUI

agent before and after the human player asked for a suggestion.){ quit the game. An out(leaveGame(ID,Role )) operation is performed, then the

GUI agent quits.

5.4 The Coordination Laws

The tictactoe tuple centre is programmed so as to coordinate the di�erent agent

protocols and their heterogeneous perceptions of the TicTacToe arena. Agents are

designed according to high-level, straightforward protocols:

{ Master agent �rst emits an initialise/0 tuple in tictactoe, then repeatedly

consumes newGame/1 tuples.{ Expert agents repeatedly check for gameOn/1 tuples, consume expertTask/3 tuples,

and respond with valid/3, invalid/2, and expertMove/4 tuples.{ GUI agents �rst consume a joinGame/2 tuple, then loop by repeatedly reading

a gameStatus/3 tuple and consuming either a humanMove/4 or a suggest/3 tu-

ple according to the human player's command, and �nally quit by emitting a

leaveGame/2 tuple.

9

It is up to the tictactoe behaviour speci�cation to bridge the gap between master,

expert and GUI agents' interaction protocols and the domain representation in terms

of tuples, implementing the coordination laws embodying the system logic.

In the following, we discuss some relevant portions of the tictactoe's behaviour

speci�cation. For the full speci�cation, we forward the reader to the URL http://

www-lia.deis.unibo.it/Research/LuCe/SampleApp/TicTacToe/.

Knowledge Representation. One of the aims of the tictactoe's behaviour speci�ca-

tion is to handle the logic tuples representing the application domain. The tictactoe

tuple centre is initialised when the tuple initialise is emitted by an out, according to

the �rst reaction below, which inserts the required id/1 and initialStatus/1 tuples

transparently to the master agent. The second reaction updates game ID information

transparently to GUI agents, automatically incrementing the ID each time an id/1

tuple is consumed by reactions.

reaction(out(initialise), ( in_r(initialise),

out_r(id(1)), out_r(initialStatus(s(n,n,n,n,n,n,n,n,n))) )).

reaction(in_r(id(_)), ( post, current_tuple(id(OldID)),

NewID is OldID+1, out_r(id(NewID)) )).

Agent Protocol Handling. The design of the agent interaction protocol is based on

the agent perception of the interaction space, determined in LuCe by the tuple centre

behaviour speci�cation.

In our sample multi-agent system, for instance, expert agents perceive tictactoe as

containing one gameOn(ID ) tuple, denoting that game ID is still going on. Even though

this tuple is not part of the domain representation, it is just produced by tictactoe

in response to the agent request to consume it, according to the game status recorded

in the related gameStatus/4 tuple (which is not perceived by the expert agent, either).

This is achieved by the following reaction, which succeeds only if the game ID is still

open, according to the gameStatus/4 tuple.

reaction(inp(gameOn(ID)), ( pre, out_r(gameOn(ID)),

rd_r(gameStatus(ID,_,s(_,_,_,_,_,_,_,_,_),_)) )).

Inter-Agent Coordination. Since a tuple centre is the space where interaction occurs,

and is programmable, it is the most natural place where to embed coordination laws:

so, its behaviour can be used to rule agent mutual interaction.

For instance, in our sample system, a GUI agent asking for a free role in a game

by means of an in(joinGame(ID,Role)) may either involve a new game creation

(out r(newGame(ID))), or, alternatively, allow the human player to replace an expert

agent via the GUI agent in an open game. This coordination policy is promoted by the

following tictactoe's behaviour speci�cation tuples:

reaction(in(joinGame(_,_)), ( pre, no_r(freeRole(_,_)),

in_r(id(ID)), out_r(newGame(ID)) )).

reaction(in(joinGame(_,_)), ( pre, in_r(freeRole(ID,Role)),

out_r(joinGame(ID,Role)) )).

reaction(in(newGame(_)), ( post, current_tuple(newGame(ID)),

out_r(freeRole(ID,x)), out_r(freeRole(ID,o)),

in_r(freeRole(ID,Role)), out_r(joinGame(ID,Role)),

rd_r(initialStatus(IS)), out_r(gameStatus(ID,0,IS,Role)) )).

10

There, freeRole/2 tuples are used to denote roles played by expert agents in open

games. When no freeRole/2 tuples are available, a new game is created: so, a new

game ID is obtained, and a newGame/1 tuple is inserted, making the master agent trigger

a new expert agent for the newly-created game. When such a tuple is consumed, a role

is assigned to the entering player as the �rst game player, while the opponent's role is

initially left free by means of a freeRole/2 tuple which may then be taken by another

human player, if any, or by the dedicated expert agent. The gameStatus/4 tuple and

the joinGame/2 answer tuple for the GUI agent are �nally inserted in tictactoe. If,

instead, there is a freeRole/2 tuple denoting the availability of an open game with

one human player only, there is no need for a new game creation: the freeRole/2 tuple

is removed, the role is assigned to the human player, and the joinGame/2 answer tuple

for the GUI agent is emitted.

All the other coordination policies (such as handling game end, move validation

and suggestion, a human player replacing an expert agent or quitting an open game)

are implemented in a similar way, as the interested reader can verify at the LuCe home

site.

5.5 Exploiting LuCe Technology

Developing the TicTacToe multi-agent system implied the exploitation of the whole

LuCe coordination technology. Obviously, we cannot describe here the whole develop-

ment process, so we will just discuss the system setup and administration.

In order to set up the TicTacToe system, we �rst start a LuCe console (see Fig. 1

on page 5), then we invoke the S Inspector on the tictactoe tuple centre with a

command like sinspect(specAgent,tictactoe). The tictactoe behaviour can now

be de�ned by loading its speci�cation tuples from the �le TicTacToe.tcs by issu-

ing a Consult command from the specAgent S Inspector. Then, a prolog(master,

"TicTacToe.p",master(tictactoe)) command from the console activates the (Prolog)

master agent, whose clause database and initial goal are, respectively, "TicTacToe.p"

and ?- master(tictactoe).

The TicTacToe system is now ready. Although everything may seem idle, the Prolog

master agent has already initialised tictactoe (as we may observe via the T Inspector)

and is waiting for new games to be created (as we may observe via the W Inspector).

A new game is created when a human player starts a GUI agent through a command

like agent(enea,'TicTacToe'(tictactoe)) from his/her console, which activates a

new Java agent enea executing the TicTacToe Java class code on the tictactoe tuple

centre.

Further human players can join the game from every LuCe cell on the Internet

connected to this LuCe space: for instance, if a second player joins the TicTacToe sys-

tem with an agent(chiara,'TicTacToe'(tictactoe)) command, the Prolog expert,

currently playing against enea, will be automatically excluded leaving the opponent's

role to the human player represented by chiara.

6 Related Works and Conclusions

The issue of coordination technology [1] on the Web is a currently hot research topic,

as demonstrated by the recent work by Sun [13] and IBM [9]. Both Sun JavaSpaces

and IBM T Spaces enrich the Java framework with Linda-style coordination, aimed at

supporting and facilitating the design of distributed applications over the Web.

11

Like LuCe, PageSpace [3] focuses on combining coordination technology and the

Web, and relies on a tuple-based coordination model. PageSpace is a reference archi-

tecture for Web agents, de�ning several agent classes. In particular, agents like kernel

agents are used in PageSpace to provide for global system features, unlike LuCe, which

exploits for the same purpose the behaviour of the coordination media.

Integrating logic-based and object-oriented technology for Web-based coordination

is the starting point of LogiMOO [16] and Jinni [15], too. LogiMOO [16] exploits

BinProlog's [14] support for virtual distributed blackboards to build virtual worlds

for distributed group-work over the Internet, using Linda-style coordination. There,

logic programming is used to provide programmable, intelligent avatars, which interact

through a multi-paradigm and multi-platform environment. Jinni [15] (Java Inference

Engine and Networked Interactor) is a light-weight, multi-threaded, pure logic pro-

gramming language to be used as a scripting tool to glue Java objects and knowledge

processing components together in networked applications, including Java applets. The

Jinni model is based on the metaphors of things, places and agents, completed with a

shared blackboard with Linda-style primitives as the communication and coordination

support. Like LuCe, Jinni exploits logic programming as the basic glue for elegant and

cost-e�ective Internet programming, and integrates it with Web technology by putting

logic programming on top of Java.

With respect to all the above approaches, the LuCe coordination system (freely

available at http://www-lia.deis.unibo.it/Research/LuCe/) focuses on exploiting

coordination technology to e�ectively support the development of Web-based multi-

agent systems. In particular, we claim that simply supporting a coordination model

is not enough to make coordination technology appealing and actually fruitful. Since

the issues of application maintenance and incremental development in Web-based sys-

tems are as critical as the application design one, the LuCe coordination system pro-

vides specialised development tools (the inspectors) based on the coordination model's

metaphors (the tuple centres), which enable developers of Web-based multi-agent sys-

tems to choose at any time the desired abstraction level over the agent interaction

space.

In cooperation with other research groups, we are currently addressing some of the

LuCe open problems (such as the support for mobility, security, and network topology)

in the context of the work on the TuCSoN coordination model [11], which is meant to

provide for a single, coherent framework where coordination is taken as the unifying

paradigm accounting for authentication, authorisation, and support for intelligent agent

exploration.

References

[1] P. Ciancarini. Coordination models and languages as software integrators. ACM

Computing Surveys, 28(2), June 1996.[2] P. Ciancarini and C. Hankin, editors. First International Conference on Coordi-

nation Languages and Models, Cesena, Italy, April 15{17, 1996, volume 1061 of

LNCS. Springer-Verlag, 1996.[3] P. Ciancarini, R. Tolksdorf, F. Vitali, D.Rossi, and A. Knoche. Coordinating

multiagent applications on the WWW: A reference architecture. IEEE Trans. on

Software Engineering, 24(5):362{375, 1998.[4] E. Denti, A. Natali, and A. Omicini. Programmable coordination media. In Coor-

dination Languages and Models, volume 1282 of LNCS, pages 274{288. Springer-

Verlag, 1997.

12

[5] E. Denti, A. Natali, and A. Omicini. On the expressive power of a language for

programming coordination media. In Proceedings of the 1998 ACM Symposium

on Applied Computing (SAC '98), Marriott Marquis, Atlanta, Georgia, U.S.A.,

February 27 - March 1 1998.

[6] E. Denti and A. Omicini. Designing multi-agent systems around an extensible com-

munication abstraction. In A. Cesta and P.-Y. Schobbens, editors, Proceedings of

the 4th ModelAge Workshop on Formal Models of Agents, Certosa di Pontignano,

Italy, January 15{18, 1997, pages 87{97. National Research Council of Italy, 1997.

To be published by Springer-Verlag in the LNAI Series.

[7] D. Garlan and D. Le M�etayer, editors. Second International Conference on Coor-

dination Languages and Models, Berlin, Germany, September 1997, volume 1282

of LNCS. Springer-Verlag, 1997.

[8] D. Gelernter. Generative communication in Linda. ACM Transactions on Pro-

gramming Languages and Systems, 7(1), January 1985.

[9] T.J. Lehman, S. McLaughry, and P. Wycko�. T Spaces: The next wave. http://

www.almaden.ibm.com/TSpaces/.

[10] A. Omicini. On the semantics of tuple-based coordination models. In Proceedings

of the 1999 ACM Symposium on Applied Computing, 1999.

[11] A. Omicini and F. Zambonelli. Coordination for Internet application development.

Autonomous Agents and Multi-Agent Systems, 1999. Special Issue on Coordination

Mechanisms and Patterns for Web Agents.

[12] G.A. Papadopoulos and F. Arbab. Coordination models and languages. Advances

in Computers, 46:The Engineering of Large Systems, August 1998. To appear.

[13] The JavaSpacesTM speci�cation. Technical report, Sun Microsystems, 1998.

[14] P. Tarau. BinProlog 7.0 Professional Edition: Advanced BinProlog and Extension

Guide. BinNet Corp., 1998. http://www.cs.unt.edu/ tarau/BinProlog.

[15] P. Tarau. Jinni: a lightweight Java-based logic engine for Internet programming.

In K. Sagonas, editor, Proceedings of JICSLP'98 Implementation of LP languages

Workshop. Manchester, U.K., June 1998. invited talk.

[16] P. Tarau and K. De Bosschere. Virtual world brokerage with BinProlog and

Netscape. In Proocedings of the 1st Workshop on Logic Programming Tools for

Internet Applications, JICSLP'96, Bonn (D), September 1996.

[17] V. Toschi. Un sistema di supporto all'interazione tra agenti Java/Prolog, 1998.

Laurea Thesis.

[18] P. Wegner. Why interaction is more powerful than computing. Communications

of the ACM, 40(5):80{91, May 1997.

13