Enabling Technologies for Wireless E-Business phần 6 doc

190 B. Yang and J. Li
u
f
itness value an a
g
ent has, the more ph
e
romone it will release. When a
g
ents move
to a crossroad, they
w
ill preferentially select the path with a denser concentration
of pheromone. A group of mobile ag
e
nts will solve the DOPS collectively through
a positive feedback mechanism: agents that can find o
p
timal
s
olutions will have
a

hi
g
h
er f
i
tness va
l
ue; t

h
e
i
r
routes w
ill

h
ave
d
enser p
h
eromone
l
eve
l
s, attract
i
ng
more a
g
ents to c
h
oose t
h
em; an
d

b
a

d
a
g
ents w
i
t
h
a
l
ower f
i
t
n
e
ss va
l
ue w
ill
a
dj
ust
t
h
e
i
r
di
rect
i
on of trave

l

(
or ot
h
er
b
e
h
av
i
ors
)

by
fo
ll
ow
i
n
g
t
h
e
g
oo
d
a
g
ents. Eventu-

all
y
, after a period of evolution controlled b
y
positive feedback, the entire s
y
stem
will reach an equilibrium state correspondin
g
to the desired optimal solution.
In this model, chan
g
es to a
g
ents’ fitness value embod
y
their self-adaptive behav-
i
ors as single entities, while the positive feedback system embodies the self-
organized behaviors of multiple agents.
8.5 Security
Wi
t
h
co
d
e m
ig
rat
i

on, t
h
e mo
bil
e a
g
ent para
dig
m
b
r
i
n
g
s
i
ncrease
d
performance
an
d
f
l
ex
ibili
t
y
to
di
str

ib
ute
d
s
y
stems. On t
h
e ot
h
er
h
an
d
, t
h
e a
bili
t
y
to move
i
n
i
tse
l
f
b
r
i
n

g
s s
ig
n
i
f
i
cant secur
i
t
y
t
h
reats, to
b
ot
h
a
g
ents an
d

h
osts. On
ly
a perfec
t

s
olution to these serious securit

y
problems would enable the mobile a
g
ent para-
di
g
m to become the mainstream software technique for constructin
g
lar
g
e-scale
distributed commercial a
pp
lications.
8.5.1 Issues and
C
ountermeasures
T
wo main types of threat need to be a
d
d
ressed: agent-to-syst
e
m and system-to-
agent attacks. Jansen et al. [27] present a good survey of the threats faced by the
mobile agent paradigm and the corresponding countermeasures.
Th
e agent-to-system category
i
nc

l
u
d
es t
h
e
ki
n
d
of t
h
reats
i
n w
h
i
c
h
agents ex
-
pl
o
i
t secur
i
ty wea
k
nesses to attac
k
an agent system. T

h
i
s group ma
i
n
l
y compr
i
ses
masquera
di
ng,
d
en
i
a
l
of serv
i
ce, an
d
unaut
h
or
i
ze
d
access. Converse
l
y, t

h
e system-
to-a
g
ent cate
g
or
y
includes threats in which s
y
stems attack a
g
ents that are situated
within them. A
g
ain, masqueradin
g
and denial of service form part of this
g
roup, as
additionall
y
do eavesdroppin
g
and alteration.
Many conventional security techniques used in traditional distributed a
pp
lica-
t
ions such as identity authenticati

o
n, encryption, integrity verification, authoriza
-
t
ion, access control, and so on are also useful as countermeasures within the
mo
bil
e agent para
di
gm. T
h
ere are a
l
so severa
l
e
xtens
i
ons to
th
ese convent
i
ona
l
t
ec
h
n
i
ques an

d
new met
h
o
d
s
d
ev
i
se
d
spec
i
f
i
ca
ll
y to con
t
ro
l
mo
bil
e agent secur
i
ty.
J
ansen et a
l
. [27] surve

y
some recent
ly

d
eve
l
ope
d
secur
i
t
y
tec
h
n
i
ques. Counter
-
measures a
i
me
d
at p
l
atform protect
i
on
i
nc

l
u
d
e software-
b
ase
d
fau
l
t
i
so
l
at
i
on, safe
co
d
e
i
nterpretat
i
on, s
ig
ne
d
co
d
e, aut
h

or
i
zat
i
on, an
d
attr
ib
ute cert
i
f
i
cates, state ap-
p
raisal,
p
ath histories, and
p
roof carrying code. Countermeasures
f
or agent protec-
t
ion include
p
artial result enca
p
sulation, mutual itinerary recording, itinerary
8 Mo
bil
e Agents: T

h
e State of t
h
e Art 191
recordin
g
with replication and votin
g
, execution tracin
g
, environmental ke
y

g
en-
e
ration, computing with encrypted functions, and obfuscated code.
8.5.2 Fac
i
l
i
ty
In this section we
p
resent a con
c
rete mobile agen
t

s

ecurity facility (MASF), which
we have ourselves develo
p
ed, in orde
r

to illustrate some of
the threats and coun-
f
termeasures
di
scusse
d
ear
li
er from a more pra
c
t
i
ca
l
an
d

i
mp
l
ementat
i
on-or

i
ente
d

p
o
i
nt of v
i
ew [28].
I
ssues
T
he securit
y
threats that ma
y
occur over the whole lifec
y
cle of a mobile a
g
ent
come from both malicious a
g
ents and the hosts to which a
g
ents mi
g
rate. Malicious
mobile a

g
ents ma
y
access and modif
y
data to which the
y
should not have access
or attem
p
t to interfere with t
h
e execution of their hosts. The
p
otential threats, fro
m

both the agent and host points of view, can be:
•
Be
f
ore mi
g
ration. T
h
reat A: Dur
i
n
g
mo

bil
e a
g
ent st
o
ra
g
e, t
h
e repos
i
tor
y

m
igh
t
b
e
i
nva
d
e
d
an
d
t
h
e co
d

e or c
l
ass for t
h
e mo
bil
e a
g
ent c
h
an
g
e
d

b
efore
i
n
i
t
i
at
i
on.
•
D
urin
g
mi

g
ration.
T
hreat B1: When a mobile a
g
ent mi
g
rates across net
-
w
orks are not controlled b
y
sender or receiver, while in possession of confi-
d
ential data, disclosure of this informati
o
n
cou
l
d

be
fatal
.
Thr
e
at B2
:
Th
e

execution logic of the mobile agent might also be changed by the interrupter,
w
hich might cause damage to the destination host.
•
After migration.
T
hreat C1: the supposed “destination” might in fact be
a

counterfe
i
t, create
d

b
y
a

b
us
i
ness r
i
va
l
to stea
l

i
mportant

i
nformat
i
on
b
e
i
ng
carr
i
e
d

b
y t
h
e mo
bil
e agent. T
h
reat C2: even
i
f t
h
e
d
est
i
nat
i

on
i
s correct, t
h
e
agent may st
ill

b
e
d
ece
i
ve
d

b
y a ma
li
c
i
ous
h
ost. For examp
l
e,
i
t m
i
g

h
t not
r
eceive the contracted services or resources, or mi
g
ht even be maliciousl
y

changed before going for another hop. Threa
t C3: At the same time, the land-
a
a
in
g
host of the mobile a
g
e
nt
s
h
ou
l
d
al
so

be

su
r

e
t
h
at th
e
in
co
m
e
r i
s
fr
o
m th
e

correct service contractor and will not cause it any damage. Threat C4: even
if the mobile agent does come from the correct peer, the host still needs to
keep itself informed about its behavior in case the agent does something tha
t
goes
b
eyon
d

i
ts contract or
i
ts r
i

g
h
ts on t
h
e system.
C
ountermeasures
T
o a
dd
ress suc
h
t
h
reats, a MASF must prov
id
e t
h
e fo
ll
ow
i
ng features:
• A
uthentication
.
This involves checkin
g
whether o
r

not an a
g
ent comes fro
m
a
trustworth
y
source. This can involve a
s
k
in
g
for the authentication details to
b
e sent from the site where the mobile agent was launched or from which i
t
last migrated. At the same
t
ime, authentication also e
n
ables the mobile agent
to be aware of the real identity of the receiver, which should be the prope
r

192 B. Yan
g
an
d
J. L
iu

service level a
g
reement (SLA) contractor. Authentication is mainl
y
used to
solve threats C1 and C3 as described earlier. It can also be used to check o
n
users who want to access the mobile agent repository, which also involves
threat A.
•
Confidentiality.
Wh
en a mo
bil
e agent tra
n
sports conf
id
ent
i
a
l

d
ata, t
h
e
transm
i
tte

d
a
g
ent must
b
e encr
y
pte
d
w
hil
e
i
n trans
i
t. T
hi
s ma
k
es
i
t use
l
ess to
a
n
y

h
ost, w

hi
c
h

d
oes not
k
now
h
ow to
d
ecr
y
pt
i
t
(
w
hi
c
h
s
h
ou
ld
on
ly

b
e t

h
e
designated server). Confidentiality, im
plemented by encryption/decryption,
m
m
c
an co
p
e with the
p
otential data disclosure of threat B1, and can
p
revent the
r
epositor
y
from attack (threat A).
•
Integrity
.
O
n reception, the mobile agent must be checked against any
m
odification or corru
p
tion due to netw
o
rk transmission errors or intentional
i

nvas
i
on. If t
h
e
i
ntegr
i
ty c
h
ec
k
fa
il
s, t
h
e rece
i
ver can as
k
t
h
e c
li
ent to repeat
t
h
e transm
i
ss

i
on. T
hi
s can protect t
h
emo
bil
e agent from t
h
e co
d
e mo
di
f
i
ca-
t
i
on attac
k
out
li
ne
d

i
n t
h
reat B2.
• A

utho
r
i
z
ation.
This determines the mobile a
g
ent’s access permissions to
h
ost resources. It is intended to
p
r
o
t
ec
t th
ose
r
esou
r
ces
fr
o
m
u
na
u
th
o
riz

ed

or

o
verused access. It indicates, for example, how man
y
times a resource can be
a
ccessed or how much it can be used, and what type of access the agent can
p
erform. For instance, one agent on b
e
half of a network administrator may
b
e able to read, write, and modify a given resource and have unlimited access
to
i
t, w
hil
st anot
h
er age
n
t represent
i
ng a norma
l
u
s

er may on
l
y
b
e a
bl
e to
r
ea
d
t
h
e resource an
d
access
i
t a
li
m
i
te
d
num
b
er of t
i
mes. Aut
h
or
i

zat
i
on
mainly deals with the runtime actions of
the mobile agen
f
t
. Usua
ll
y t
hi
s
i
s
a
chieved throu
g
h an access control polic
y
that
g
rants access to s
y
stem
r
esources based u
p
on different levels of trust. Authorization, empowered b
y
a

ccess control, can defeat threat C4.
•
L
ogging. This is a mechanism to keep track of any e
v
e
nts relevant to secu
-
r
ity, such as an agent trying to access system resources or the system itself,
a
s well as authentication failures. These
e
vents should be logged to a file fo
r

l
ater ana
l
ys
i
s. Logg
i
ng can, to some
d
egree,
d
etect an
d
t

h
erefore prevent
a
m
o
bil
e agent
b
e
i
ng
d
ece
i
ve
d

b
y t
h
e
h
ost, as
d
escr
ib
e
d

i

n t
h
reat C2.
Ar
c
hit
ec
t
u
r
e

T
he im
p
lementation of these features, for the
p
rotection of both mobile a
g
ent an
d

host, is achieved in the MASF, the arc
h
itecture of which is illustrated as Fi
g
. 8.6.
MASF architecture is functionall
y
divide

d

i
nto two la
y
ers, the
h
i
g
her bein
g
a
f
unction layer and the lower a base service layer. The components or services in
the latter are common function
a
l
ities used by the former.
Obviously, many services of
the function layer depen
f
d
on cryptographic func-
t
i
ons
b
ase
d
on e

i
t
h
er symmetr
i
c or asymmetr
i
c
k
eys to encrypt
/d
ecrypt an
d
s
i
gn
d
ata. T
h
erefore
,
MASF
h
as a cryptograp
h
y
lib
rary
i
nteg

r
ate
d

i
n
i
ts
b
ase serv
i
ce
l
ayer.
data inte
g
rit
y
and authentication services, usin
g
di
g
ital si
g
natures. The authentica
-
T
he ke
y
mana

g
ement service enables users to administer their own
p
ublic/
p
rivate ke
y
pairs and associate
d

ce
rtifi
c
at
es
f
o
r
use
in
se
lf-a
u
th
e
nti
c
ati
o
n

o
r
8 Mo
bil
e A
g
ents: T
h
e State of t
h
e Art 193
tion information includes both a se
q
uence (chain) of X.509 certificates, and an
associated private key, which is usually referenced as “alias”.
T
o achieve security, the MASF framework supports flexible security policies to
g
overn the interactions of agents with each other and with the available resources
i
n t
h
e execut
i
on s
i
tes. T
hi
s fun
c

t
i
on
i
s
i
mp
l
emente
d

b
yt
h
e po
li
cy managemen
t

s
erv
i
ce
i
n t
h
e
b
ase serv
i

ce
l
ayer. T
h
e
d
ef
i
n
i
t
i
o
n an
d
enforcement of appropr
i
ate
s
ecur
i
ty po
li
c
i
es can on
l
y procee
d
after a prec

i
se
id
ent
i
f
i
cat
i
on of t
h
e pr
i
nc
i
pa
l
s
(
i.e., the roles that can be authenticated).
Securit
y
lo
gg
in
g
service fulfils the lo
gg
in
g

requirement mentioned earlier.
Althou
g
h not specific to MASF, the location service is sometimes used b
y
MASF
t
o identify the user.
W
ork
f
low o
f
the MA
S
F
A
ll
t
h
e mo
bil
e a
g
ents’ c
l
asses or co
d
es are store
d

i
n
digi
ta
lly
s
ig
ne
d
arc
hi
ve f
il
es.
Whenever an administrator, or the software on his or her behalf, wants to fulfill
some tasks usin
g
mobile a
g
ents, t
h
e appropriate si
g
nature must firstl
y
be verified
before access can be
g
ranted to these a

g
ents, which are stored in a protected
repos
i
tory. T
h
e a
d
m
i
n
i
strator t
h
en s
i
gns t
h
e agent to s
h
ow t
h
e
i
n
i
t
i
ator, for
i

n
-
stance, t
h
e f
i
rst agent system. He or s
h
e can a
l
so supp
l
y t
h
e agent w
i
t
h
t
h
e neces-
sar
y
r
igh
ts.
If a mo
bil
e a
g

ent s
y
stem rece
i
ves an
ag
ent from t
h
e commun
i
cat
i
on networ
k

v
i
a a
g
ent transport protoco
l

(
ATP
)
,
i
t
d
ecr

y
pts
i
t an
d
tests t
h
e
i
nte
g
r
i
t
y
of t
h
e
d
ata
received b
y
checkin
g
the si
g
nature that the sender has appended. After success
-
f
ull

y
passin
g
the inte
g
rit
y
check, the next st
ep
is authentication. The mobile a
g
en
t

sy
stem verifies the si
g
nature and certificates attached to this mobile a
g
ent and
o
b
ta
i
ns furt
h
er
i
nformat
i

on suc
h
as w
h
o wrote
i
t an
d
w
h
o sent
i
t
(
e
i
t
h
er or
i
g
i
na
ll
y
or from t
h
e
i
nterme

di
ate
l
ocat
i
ons
)
. T
h
e
in
format
i
on can
b
e furt
h
er use
d
for aut
h
or
i
-
z
at
i
on an
d
access contro

l
. T
hi
s step w
ill

i
nvo
l
ve t
h
e secur
i
ty
d
ata
b
ase.
Once aut
h
ent
i
cate
d
, MASF aut
h
or
i
zes t
h

e a
g
ent, w
hi
c
h
means t
h
at
i
t attac
h
es
r
igh
ts to
i
t or
d
eterm
i
nes r
igh
ts
b
ase
d
o
n

s
ecur
i
t
y
po
li
c
i
es, w
hi
c
h

h
ave
b
een
d
ef
i
ne
d

i
n a
d
vance, pro
b
a

bly
v
i
a a SLA.
Fig. 8.6. Architecture of mobile agent security facility
194 B. Yan
g
and J. Li
u
T
he mobile a
g
ent can then be executed with care of access control to imple
-
ment its assigned task. When the mobile agent has finis
h
e
d its work and wants to
migrate to another location, the system stops the agent’s execution and packs i
t

with its current state, as normal. Depending on the agent’s task, t
h
e
rights’ adjust
-
i
ng mo
d
u

l
e may
b
e ca
ll
e
d
at t
hi
s moment to a
dj
ust
i
ts current r
i
g
h
ts, for examp
l
e,
t
o
i
ncrease t
h
ose to
b
e grante
d
at

i
ts next
l
ocat
i
on.
N
ext, t
h
e s
i
gner
/
encryptor mo
d
u
l
e
i
s ca
ll
e
d

b
y agency to s
i
gn t
h
e mo

bil
e agen
t

t
o conf
i
rm t
h
e execut
i
on or an
y
c
h
an
g
e
o
f a
g
ent. Encr
y
pt
i
on ma
y
a
l
so

b
e app
li
e
d

by
t
hi
s mo
d
u
l
e.
F
i
na
lly
, a
g
enc
y
opens a commun
i
cat
i
on c
h
anne
l

to t
h
e tar
g
et mo
bil
e a
g
ent s
y
s
-
t
em and sends the agent. The channel can be a secure one enhanced by secure
socket layer (SSL).
8.6 Summary
In t
hi
s c
h
apter we
h
ave
b
r
i
ef
ly

i

ntro
d
uce
d
t
h
e concept o
f
mobile agents and dis-
f
cusse
d
some of
i
ts a
d
vanta
g
es an
d
app
li
cat
i
ons. We
h
ave a
l
so
di

scusse
d
some
i
mportant tec
h
no
l
o
gi
es requ
i
re
d
for t
h
e
d
e
t
ail
e
d

i
mp
l
ementat
i
on of suc

h
a s
y
stem.
Althou
g
h this paradi
g
m could ease the dev
e
lopin
g
, testin
g
, and deplo
y
ment o
f

distributed a
pp
lications, and could also simplif
y
the understandin
g
and sustainin
g
of such s
y
stems, there are still man

y
open issues that need to be resolved perfectl
y

b
efore this can become an industrial software standard ready for commercial
applications in the same way as OOP and CORBA.
Besides issues such as
p
lann
i
ng, communication,
p
erformance, an
d
security, as
di
scusse
d
ear
li
er, t
h
ere
i
s t
h
e
i
mportant qu

e
st
i
on of stan
d
ar
di
zat
i
on.
O
M
G
MA
S
IF
(
mo
bil
e agent system
i
nteropera
b
ili
ty fac
ili
ty
)
[29] an
d

OMG MAFS
(
mo
bil
e
agent fac
ili
ty spec
i
f
i
cat
i
on
)
[11] are goo
d

i
n
i
t
i
a
l
efforts to a
dd
ress t
hi
s

i
ssue. How-
e
ver, the mobile a
g
ent co
m
munit
y
must take further steps
t
o develo
p
an industrial
standard for this paradi
g
m,
j
ust like the one in
use
in th
e
fi
e
l
d

o
f
d

i
s
tri
bu
t
ed

o
b
j
ects.
Furthermore, technologies and theories of artificial intelligence fields should be
i
ntegrated into the mobile agent paradig
m

s
o as to enable mo
b
i
le agents to become
smarter and more competent in highly complex tasks such as distributed o
p
timiza-
ti
on pro
bl
ems
i
n tru

l
y
di
str
ib
ute
d
,
l
arge-sca
l
e, open, an
d

d
ynam
i
c env
i
ronments
suc
h
as t
h
e Internet.
Fortunate
ly
, more an
d
more new tec

h
n
i
q
ues are now
b
e
i
n
g
exp
l
ore
d
, an
d
curren
t

wor
k

i
s prom
i
s
i
n
g
enou

gh
t
h
at, w
i
t
hi
n 10
y
ears or even sooner, t
h
e mo
bil
e-a
g
en
t

p
ara
dig
m w
ill

b
e w
id
e
ly
use

d

i
n man
y

di
str
ib
ute
d
an
d

i
nte
llig
ent app
li
cat
i
ons, espe-
cially in the ubiquitous computing environment.
Ubiquitous computing is said to be the third generation of computation after the
mainframe and personal computer (PC) eras. In this, the user is surrounded by lots
of
i
nv
i
s

ibl
e sma
ll
computers o
r
sensors, connected by ad
r
h
oc or w
i
re
l
ess networ
k
s.
U
bi
qu
i
tous comput
i
ng ma
i
n
l
y a
i
ms at
d
eve

l
op
i
ng new mo
d
e
l
s an
d
tec
h
no
l
og
i
es to
construct t
h
e u
bi
qu
it
ous soc
i
ety
(
U-soc
i
ety
)

, w
hi
c
h
can offer anyw
h
ere an
d
anyt
i
me
8 Mo
bil
e A
g
ents: T
h
e State of t
h
e Art 195
s
ervices, delivered throu
g
h an
y
devices, as required t
o
su
pp
ort an individual’s

d
aily life. In order to adapt to the dyna
m
i
c re
q
uirements of different
p
eo
p
le, the
U
-society requires personal information such as profiles, preferences, likes, and
habits. Since
p
eo
p
le often move around, such
p
ersonal information has to be sent
to t
h
e current
l
ocat
i
on. Bagc
i
et a
l

. [30] present two poss
ibl
e approac
h
es: e
i
t
h
e
r

t
h
e user carr
i
es t
h
e re
l
evant
i
nformat
i
on on
d
ev
i
ces w
i
t

h

hi
m
or
h
er, or t
h
e u
bi
qu
i-
tous system ta
k
es care of stor
i
ng an
d
sen
di
ng
i
t. O
b
v
i
ous
l
y, t
h

e
l
atter s
i
tuat
i
on,
i
n
w
hich a mobile user is alwa
y
s accompanied b
y
a ubiquitous a
g
ent, which serves as
a virtual reflection of the user and can
p
rovide the services, is
p
referred.
E
xistin
g
mobile a
g
en
t
s

y
stems for Internet applicati
o
ns such as A
g
let, More,
Grasshoppers, and D’Agent are very
h
e
avyweight and are no
t
suitable for ubi
q
ui-
tous computing. Bagci et al. [30] discuss the re
q
uirem
e
nts for the ubiquitous agent
p
ara
di
gm: u
bi
qu
i
tous agents cou
ld
use
b

ot
h
w
i
re
d
an
d
w
i
re
l
ess me
di
a for commu-
n
i
cat
i
on an
d
m
i
grat
i
on; t
h
e system s
h
ou

l
d

b
e p
l
atform
i
nd
epen
d
ent, s
i
nce software
an
d

h
ar
d
ware are
h
eterogeneous
i
n t
h
e U-
s
oc
i

ety; agents s
h
ou
l
d

b
e
li
g
h
twe
i
g
h
t so
that the
y
work not onl
y
on powerful PCs but also on batter
y
-operated and mem
-
or
y
-restricted PDAs, wearabl
e
computers, or tin
y

sensors; a
g
ents could use dif-
f
erent access mechanisms and protocols for accessin
g
information provided b
y

heterogeneous ubiquitous devices; agents should be context sensitive; and secu
-
rity, such as privacy protection, i
s
also an im
p
ortant re
q
uirement.
M
ultiagent teamwork has been widely studied i
n
the fields of distributed artifi-
c
i
a
l

i
nte
lli

gence. W
i
t
h
t
h
e emer
g
e
nce of u
bi
qu
i
tous comp
u
t
i
ng, u
bi
qu
i
tous agen
t

teamwor
k

b
ecomes a new c
h

a
ll
enge. T
h
e
ubiquitous agent comm
unity (UAC) is a
m
m
p
rom
i
s
i
ng approac
h
to t
h
e organ
i
zat
i
on of agents
i
nto a
j
o
i
nt
l

y funct
i
on
i
ng team.
Th
e s
ig
n
i
f
i
cant aspect of suc
h
a commun
i
t
y

i
s t
h
at
i
t w
ill
a
l
wa
y

s
h
ave one
g
oa
l
t
h
at
will
m
o
t
iv
at
e
an
d

d
r
ive

i
t
s
m
e
m
be

r
s
t
o
f
ul
f
ill
t
hei
r
i
n
dividu
a
l
ta
sks
an
d
f
u
n
c-
t
i
ons.
U
A
C

s w
i
t
h

di
fferent structures
h
ave
di
fferent funct
i
ons, an
d
t
hese

s
tr
uc
t
u
r
es
w
ill evolve autonomously according to the collective interactions of their mem
-
b
ers. Liu et al. [31]
p

resent one commu
n
ity structure, called the ubiquitous agent
community for rational competit
i
on and cooperation in the U-society.
A UAC
i
s essent
i
a
ll
y an
i
nte
lli
g
e
nt
i
nfrastructure t
h
a
t

e
na
bl
es agents to
l

oo
k

a
h
ea
d
to p
l
an an
d

d
e
li
ver w
h
at a user wants. It wor
k
s
j
ust
lik
e a persona
l
agency.
For
i
nstance
,

i
t can
he
l
p a user to effect
i
ve
ly
mana
g
e te
di
ous
d
a
ily
rout
i
ne act
i
v
i-
t
i
es suc
h
as process
i
n

g
ema
il
s, p
l
ac
i
n
g
or
d
ers, ma
ki
n
g
meet
i
n
g
arran
g
ements,
d
own
l
oa
di
n
g
news, an

d
so on. A UAC can
i
n
t
eract w
i
t
h
users
i
n var
i
ous wa
y
s. Fo
r

i
nstance, as a
p
erson uses a smart hand-held devi
c
e to enter a subwa
y
station on
the wa
y
to work, a UAC can seamlessl
y

upload list of thin
g
s to be done to that
d
evice. Alon
g
with each of the thin
g
s listed, the information provided b
y
the UAC
can a
l
so
i
nc
l
u
d
e t
h
e correspon
di
ng tas
k
s requ
i
re
d
. T

h
us,
i
ns
id
e t
h
e mov
i
ng su
b-
w
ay tra
i
n, t
h
e user w
ill

b
e a
bl
e to go t
h
roug
h
eac
h
of t
h

e recommen
d
e
d
tas
k

i
tems
an
d
furt
h
er ver
i
fy an
d

d
e
l
egate certa
i
n
j
o
b
s, su
c
h

as forwar
di
ng a report or ma
ki
ng
a meet
i
n
g
appo
i
ntment, to a commun
i
t
y
a
g
ent w
i
t
hi
n t
h
e UAC. Bes
id
es p
l
ann
i
n

g
an
d
execut
i
n
g
t
h
e
i
tems on a ca
l
en
d
ar, t
h
e user can a
l
so rece
i
ve ot
h
er persona
li
ze
d

s
erv

i
ces
b
ase
d
on
hi
s or
h
er prof
il
e, w
hi
c
h
m
a
y include sports news, urgent emails,
a
a
and specific documents prepared for the da
y
’s meetin
g
s. Fi
g
ure 8.7
g
ives an
196 B. Yan

g
an
d
J. L
iu
i
llustrative example of personal services that can be provided b
y
a communit
y
o
f

competing and cooperating agents.
F
ig. 8.7. Schematic illustrati
o
n
o
f
an UAC
[
31
]

A UAC conta
i
ns two types of agents: c-agents an
d
s-agents. T

h
e former ma
k
es
tas
k
p
l
ans as we
ll
as contract
i
ng
d
ec
i
s
i
ons on w
h
at an
d

wh
ere some tas
k
s w
ill

b

e
carr
i
e
d
out, w
h
ereas t
h
e
l
atter performs t
h
e
d
e
l
egate
d
tas
k
s. A
c
-agent carr
i
es ou
t

s
uc

h
funct
i
ons as tas
k
p
l
ann
i
ng
, tas
k

d
e
l
e
g
at
i
on, an
d
resu
l
t eva
l
uat
i
on, w
hil

e a
n
s
-a
g
ent
i
s respons
ibl
e for tas
k
execut
i
on, co
m
pet
i
t
i
on, an
d
cooperat
i
on. In t
h
e
ill
ustrat
i
ve examp

l
e
i
n F
ig
. 8.7, suppose a
use
r
w
r
i
t
es
a f
ew

wo
r
ds

o
n
his

o
r
her

PDA re
g

ardin
g
what he o
r

s
he plans to do. A c-a
g
e
n
t in the distributed UAC will
reco
g
nize the user’s intention an
d
fin
d

s
imilar
se
r
v
i
ce

c
a
ses
fr

o
m it
s

c
a
se

b
a
se.

T
hereafter, it will execute task plannin
g
based on the similarit
y
between the tasks
at
h
an
d
an
d
t
h
e prev
i
ous tas
k

s. Once t
h
e c-agent comp
l
etes t
hi
s process, a c
l
uste
r

of s-agents w
ill

b
e ca
ll
e
d
upon to
di
str
ib
u
t
e an
d
carry out t
h
e p

l
anne
d
su
b
tas
k
s.
E
ac
h
s-a
g
ent w
ill

h
ave
di
st
i
nct ro
l
e
(
s
)
an
d

will

coo
r
di
nat
e

i
t
s
a
c
t
i
o
n
s

wi
t
h
t
hose

of

ot
h
er s-a

g
ents
i
n a UAC. For
i
nstance, a ma
il
a
g
ent w
ill

b
e respons
ibl
e for mana
g
-
i
n
g
ema
il
s,
i
nvo
l
v
i
n

g
t
h
ree
di
st
i
nct ro
l
es: e
di
t
i
n
g
, sen
di
n
g
, an
d
rece
i
v
i
n
g
. As t
h
e

mail a
g
ent works, it will als
o
tak
e
int
o

co
n
s
i
de
rati
o
n th
e

wo
rk
s
tat
us

o
f r
e
lat
ed

s
-a
g
ents. In other words, i
t

w
ill decide, after communicatin
g
with other s-a
g
ents,
w
h
e
n t
o
r
ece
i
ve

o
r
se
n
d

e

mail
s
an
d

w
hat
co
nt
e
nt t
o
in
c
l
ude.

B
ecause many ubiquitous agents have been devised for different services and
f
unctions in the U-society, a solution for clustering them is necessary in order to
s
ummon these heterogeneous agents roaming across the entire U-society and
qu
i
c
kly
a
gg
re

g
ate t
h
em
i
n
t
o a seam
l
ess commun
i
t
y
, s
u
ch
as t
h
e UAC
,
w
hi
c
h
w
ill
comp
l
ete user-spec
i

f
i
e
d
tas
k
s. However, t
hi
s
i
s a nontr
i
v
i
a
l
c
h
a
ll
en
g
e, requ
i
r
i
n
g
as
i

t
d
oes an automat
i
c,
d
ecentra
li
ze
d
, an
d

i
ncrementa
l
UAC c
l
uster
i
n
g
a
lg
or
i
t
hm

rath

e
r than
o
n
e

w
hi
c
h is manual, centralized, and offline.
8 Mo
bil
e Agents: T
h
e State of t
h
e Art 197
References
1
.
D
.B. Lange, M. Os
hi
ma. Seven goo
d
reasons for mo
bil
e agents. Commun
i
-

c
at
i
ons of t
h
e ACM
,
1
9
99, 42
(
3
)
: 88–89.
2
.
D
. Lan
g
e M. Os
hi
ma. Pro
g
ramm
i
n
g
an
d
Dep

l
o
yi
n
g
Mo
bil
e A
g
ents w
i
t
h
A
gl
ets,
B
oston, MA: Addison-Wesle
y
, 1998.
3.
D
. Won
g
, N. Paciorek et al. Concordia: An infrastructure for collaboratin
g
m
obile a
g
ents. In K. Rothermel and R

.
Zeletin, editors, Mo
b
i
le A
g
ents: Firs
t

I
nternational Worksho
p
MA’97, LNCS 1
219
,
199
7,
86
.
4
. ObjectSpace Inc. ObjectSpace voyager core package technical overview,
1997,
j
e
ctspace.com/voyager/whitepapers.
5
. C. Bäumer, T. Mage
d
anz. Grass
h

opper
–
A mo
bil
e agent p
l
atform for act
i
ve
te
l
ecommun
i
cat
i
on. In Procee
di
ngs o
f

th
e T
hi
r
d
Internat
i
ona
l
Wor

k
s
h
op on
I
ntelli
g
ent A
g
ents fo
r
Telecommunication A
pp
lication
s
,
LNCS1699, 1999,
1
9
–32.
6
.
J.E. White. Telescript Technolo
gy
: The Foundation for the Electronic mar-
ketplace. White Paper, General Magic, Inc., 1994.
7
.
R
.S. Gray, G. Cybenko, D. Kotz et al. D’Agents: Applications and perform

-
ance of a mobile agent system. Software Practice and Experience, 2002,
3
2
(
6
)
: 543–573.
8
. H. Pe
i
ne, T. Sto
l
pmann. T
h
e arc
hi
tecture of t
h
e Ara p
l
atform for mo
bil
e
agents. In K. Rot
h
erme
l
an
d

R.
Z
e
l
et
i
n
,
e
di
tors
,
Mo
bil
e
A
gents: F
i
rst Inter
-
n
ational Worksho
p
MA’97, LNCS 1219, 1997, 50–61.
9
. L.F. Bic, M. Fukuda, M. Dillencourt. Distrib
u
t
ed computin
g

usin
g
autono-
mous ob
j
ects. IEEE Computer, 1996, 29(8): 55–61.
1
0
.
D. Johansen, R.V. Renesse, F. Schneide
r
. An introduction to the TACOMA
d
istributed system. Techn
i
cal Re
p
ort 95–23, University of Tromso, 1995.
1
1
.
Object Management Group, Inc. The Mobile Agent Facility Specification,
2000,

6
.
12.
K
. Rot
h

erme
l,
M. Sc
h
we
h
m. Mo
bil
e agents. In Encyc
l
ope
di
a for Compute
r

Sc
i
ence an
d
Tec
h
no
l
ogy. N
e
w Yor
k
: De
kk
er

,
1998.
1
3
.
F
u
gg
etta, G. P
i
cco, G. V
ig
na. Un
d
erstan
di
n
g
co
d
e mo
bili
t
y
. IEEE Transac
-
t
i
ons on Software En
gi

neer
i
n
g
, 1998, 24
(
5
)
: 352–361.
1
4
.
K
. Moizumi. The Mobile Agent Planning Problem. [PhD Thesis] Thayer
School of Engineering, Dartmouth College, 1998.
1
5
.
E. Jul, H. Levy, N. Hutchinson, A. Black.
F
ine-grained mobility in the Emer-
a
ld
System. ACM Transact
i
ons on Co
m
puter Systems, 1988, 6
(
2

)
: 109–133.
16.
A.L. Murp
h
y, G.P. P
i
cco. Re
li
a
bl
e commun
i
cat
i
on for
hi
g
hl
y mo
bil
e agents.
In P. Spr
i
ng an
d
D. M
il
o
ji

c
i
c, e
di
tors, Procee
di
ngs of t
h
e F
i
rst Internat
i
ona
l

S
y
mpos
i
um on A
g
ent S
y
stems an
d
A
p
pli
cat
i

ons. New Yor
k
: IEEE
Computer Soc
i
et
y
,
1
999
,
141–150.
17.
J
. Baumann et a
l
. Commun
i
cat
i
on concept
s
for mo
bil
e a
g
ent s
y
stems. In K.
R

othermel and R. Zeletin, editors, M
o
bile Agents: First I
n
t
ernational Work
-
sho
p
MA’97, LNCS 1
2
19, Berlin Heidelberg N
e
w
York: Springer, 1997,
123
–
13
5.
198 B. Yan
g
an
d
J. L
iu
18
.
M
. Straßer, M. Schwehm. A
p

erform
a
n
ce model for mobile a
g
ent s
y
stems.
I
n Proceeding of the Internationa
l
Con
f
erence on Parallel and Distribute
d

P
rocessing Techniques and Applications, 1997, 2: 1132–1140.
19. J. Liu, X.L. Jin, K.C. Tsui. Autonomy Oriented Computing. Dordrecht:
Kl
uwer
,
2005.
20
.
J. Liu, X. Jin, K.C. Tsui. Autonomy
oriented computing (AOC): Formulat-
y
i
ng computat

i
ona
l
systems w
i
t
h
a
u
t
onomous componen
t
s. IEEE Transac-
t
i
ons on S
y
stem, Man an
d
C
yb
ernet
i
cs
.
Part A:S
y
stem an
d
Humans

(i
n
p
ress
)
.
2
1
.
J. L
i
u, J. Han, Y.Y. Tan
g
. Mu
l
t
i
-a
g
ent
o
r
ie
nt
ed

co
n
s
tra

i
nt
s
at
is
fa
c
t
io
n
.
Art
i
-
ficial Intelligence, 2002,
1
3
6
(
1
)
: 101–144.
2
2. J. Liu, Y.Y. Tang. Adaptive segmentat
i
o
n with distributed behavior base
d

a

gents. IEEE Transact
i
ons on Pattern Ana
l
ys
i
s an
d
Mac
hi
ne Inte
lli
gence,
1999, 21
(
6
)
: 5
44
–55
1
.
23
.
G
. Ca
b
r
i
, L. Leonar

di
, F. Zam
b
one
lli
. How to coor
di
nate Internet app
li
cat
i
ons
b
ase
d
on mo
bil
e a
g
ents. Procee
di
n
g
s of t
h
e 1998 sevent
h
IEEE Internat
i
ona

l

W
or
k
s
h
op on Ena
bli
n
g

T
ec
h
no
l
o
gi
es: Infrastructure for Co
ll
a
b
orat
i
ve
Enterpr
i
ses, WET ICE, IEEE Computer Soc
i

a
l
Press, 1998, 104–109.
2
4
.
H
. Casanova, J. Hayes, Y. Yang. Algo
r
ithm an
d

so
ft
w
ar
e
t
o

sc
h
edu
l
e
an
d

d
eploy independent tasks in grid envir

o
nments. In Proceedings of the Work-
s
hop on Distributed Computing, Met
a
-computing, and Resource Globaliza-
t
i
on
,
Ausso
i
s
,
France
,
2002.
2
5
.
2
6
.
M
. Moses. A
g
ents
i
n e-commerce. Commun
i

cat
i
ons of t
h
e ACM
,
1999
,

4
2
(
3
)
: 79–91.
2
7
.
W
. Jansen, T. Kar
yg
iannis. Mobile a
g
ent securit
y
. NIST Special Publica
-
tion, 1999, 800–819.
28.
B. Yang, K. Yang, D.Y. L

i
u. Mo
bil
e
a
gent secur
i
ty fac
ili
ty for networ
k

management. Journa
l
o
f
So
f
tware
,
2003
,
14
(
10
)
: 1761–1767.
2
9.
D. M

il
o
ji
c
i
c et a
l
. MASIF: T
h
e OMG mo
bi
l
e a
g
ent s
y
stem
i
nteropera
bili
t
y
f
ac
ili
t
y
. In Procee
di
n

g
s of t
h
e Secon
d
Internat
i
ona
l
Wor
k
s
h
op on Mo
bil
e
A
g
ents, LNCS 1477, Ber
li
n He
id
e
lb
er
g
New Yor
k
: Spr
i

n
g
er, 1998, 50–61.
30
.
F. Ba
g
ci, J. Petzold, W. Trumler. Ubiquito
u
s
mobile a
g
ent s
y
stem in a P2P-
N
etwork. UbiS
y
s-Workshop at the Fift
h
Annual Conference on Ubi
q
uitous
Computin
g
, Seattle, 2003.
31.
J. Liu, C. Yao. Rational competition and
cooperation in
d

ubiquitous agen
t

communities. Knowledge-Based System,
2004,

1
7:
189
–
200
.
K.S. Teng, M. Maheswaran. Limited scope probing: A distributed approach
f
or QoS-based routing. In IEEE International Symposium on Networ
k
Comput
i
n
g
an
d
App
li
cat
i
ons
(
NCA’01
)

, Cam
b
r
idg
e: Massac
h
usetts, 2001,
3
5
0
–
3
5
4.

9 Multiagent Communication for e-Business using
Tuple Spaces
H.F. L
i
, T. Ra
dh
a
k
r
i
s
h
nan, an
d
Y. Z

h
ang
Department of Computer Sc
i
ence an
d
Software Eng
i
neer
i
ng
Concordia Universit
y
, Montreal, Canada H3G 1M8
9.1 Introduction
9
.1.1 Motivation
Th
e
g
rowt
h

i
n We
b
-
b
ase
d

app
li
cat
i
ons,
di
s
tr
ib
ute
d
comput
i
n
g
, an
d
a
g
ent-
b
ase
d

software technologies has created abunda
nt interest in various aspects of
a
a
e
-business. One such application supported b

y
these technolo
g
ies is e-commerce
i
n
w
hi
c
h
o
nlin
e
tran
s
a
c
ti
o
n
s
between a bu
y
er and a seller are su
pp
orted in various
s
ta
g
es of their tradin

g
(Gutman et al., 1998). E-commerce application s
y
stems
have to deal with a large number of int
e
racting autonomous tasks using heteroge-
neous information sources. These interacti
o
ns have a need to be well coordinate
d

and coordination re
q
uires efficient commun
i
cation among the entities. The dynamic
an
d
comp
l
ex nature of e-commerce requ
i
res a f
l
ex
ibl
e tec
h
no

l
og
i
ca
l

i
nfrastructure
to support
b
us
i
ness processes more eas
il
y an
d
effect
i
ve
l
y.
A
g
ent-based software technolo
gy
has become the sub
j
ect of much research in a
wide ran
g

e of fields, especiall
y
in d
i
stributed s
y
stem desi
gn
.
Multia
g
ent s
y
stems
are often used in a d
y
namic environment with autonomous problem solvin
g
enti
-
ties cooperating and coordinating with each other. A typical software agent has the
characteristics of autonomy, reactivity, proactivity and sociality, or structured
i
nteractions with other software agents. This makes the multiagent systems a natu-
ra
l
can
did
ate c
h

o
i
ce for
i
mp
l
ement
i
ng e-commerce app
li
cat
i
ons.
Bus
i
ness processes
i
n e-commerce may
b
e cons
i
d
ere
d
as a
ki
n
d
of coor
di

nate
d

mu
l
t
i
agent system
i
n w
hi
c
h
t
h
e software agents perform var
i
ous mar
k
et act
i
v
i
t
i
es
un
d
er
dy

nam
i
c partners
hi
ps. W
i
t
h
t
h
e
i
ncreas
i
n
g
comp
l
ex
i
t
y
of t
h
ese app
li
cat
i
ons,
we nee

d
pro
g
ramm
i
n
g
mo
d
e
l
s to
d
ea
l
w
i
t
h
t
h
e coor
di
nat
i
on of a
l
ar
g
e num

b
er o
f

concurrent
ly
act
i
ve ent
i
t
i
es. T
h
us, an
i
nfrastructure
fo
r
coo
r
di
nat
io
n
is
n
eeded
t
o

meet the complex and dynamic requirements. Tu
p
le s
p
ace that
s
u
pp
orts inter
-
agents coordination is
a
n attractive solution.
F
or this purpose, our research focuses on tuple space-based agent coordina
-
t
i
on an
d
tup
l
e space-
b
ase
d
agent programm
i
ng framewor
k

(
TSAF
)
t
h
at effec-
t
i
ve
l
y supports
b
u
ildi
ng agent app
li
cat
i
ons
i
n e-commerce. In t
h
e rest of t
hi
s
c
h
apter, we
di

scuss mu
l
t
i
agent
i
nteract
i
ons t
h
roug
h
tup
l
e space, present
i
ng
h
ow
tup
l
e space fac
ili
tates t
h
e
dy
nam
i
c coup

li
n
g
s amon
g
a
g
ents. We a
l
so present an
200

a
g
ent pro
g
rammin
g
model called TSAF, which
p
rovides no
t
onl
y
a
g
ent architec-
t
ure in abstraction, but also an easy-to-use programming environment for imple
-

menting the resulting design. The incor
p
oration of role models derived from
object-oriented methodologies into the design of agent behaviors supports the
ana
l
ys
i
s an
d

d
es
i
gn of mu
l
t
i
agent systems from t
h
e perspect
i
ve of agent-or
i
ente
d

software eng
i
neer

i
ng. In t
h
e
i
mp
l
emen
t
at
i
on
l
eve
l
, TSAF a
l
so supports tup
l
e
space-
b
ase
d
agent coup
li
ng mec
h
an
i

sm. T
h
e
b
enef
i
ts of t
hi
s framewor
k
are
i
llustrated throu
g
h a case stud
y
in e-commerce.
9
.1.2 Agent Coordination in Multiagent System
A
g
ents in a multia
g
ent s
y
stem have a
g
eneral need to communicate amon
g
s

t

t
hemselves, coordinate their activities, and
n
e
g
otiate once the
y
find themselves in
conflict. Coordination models for multiag
e
nt systems can be broadly classified
i
nto direct coordination m
o
del and indirect coordination model. Direct coordina-
ti
on means t
h
at agents exp
li
c
i
t
l
y
i
n
i

t
i
ate
a
commun
i
cat
i
on v
i
a message pass
i
ng
an
d
exp
li
c
i
t
l
y name t
h
e
i
nv
o
l
ve
d

partners
i
n t
h
e
i
r messa
g
es. In
i
n
di
rect coor
di
na-
t
i
on, agents
i
nteract v
i
a a s
h
are
d
space,
lik
e
bl
ac

kb
oar
d
, w
h
ere messages are
p
oste
d
an
d
retr
i
eve
d
. A
bl
ac
kb
oar
d
a
p
p
roac
h
uncoup
l
es a
g

ent-to-a
g
ent
i
nterac
-
t
i
ons
i
n t
i
me an
d
space. T
hi
s su
i
ts man
y
app
li
cat
i
on scenar
i
os w
h
ere a
g

ents
d
o no
t

k
now or care a
b
out t
h
e a
dd
ress of t
h
e co
ll
a
b
orators. T
h
e tu
pl
e s
p
ace-
b
ase
d
coor
di-

nation model promotes dynamic information sh
a
ring, so that information is avail
-
able to any intended agent and every authorized agent can modify the information
on the tuple space. The tuple spaces free the designer from the burden of keeping
trac
k
of exp
li
c
i
t or at
l
east
i
m
p
li
c
i
t a
dd
ress
i
ng
k
now
l
e

d
ge
i
n agent coup
li
ngs.
F
i
na
ll
y, t
h
e “react
i
ve tup
l
es” [1] of tup
l
e
s
pace can suppor
t
eve
n
t-
d
r
i
ven coor
di

na
-
t
i
on among agents
b
y tr
i
gge
r
i
ng t
h
e react
i
ons assoc
i
ate
d
w
i
t
h
suc
h
tup
l
es. T
h
ese

react
i
ons are norma
lly

d
ef
i
ne
d

b
ase
d
on t
h
e

di
ff
e
r
e
nt r
oles
t
h
at
a
n a

g
ent p
l
a
y
s. In
a
ddi
t
i
on, react
i
ons can a
d
apt t
h
e semant
i
cs of t
h
e
i
nteract
i
ons to t
h
e spec
i
f
i

c a
g
en
t

e
nv
i
ronment, t
h
us s
i
mp
li
f
yi
n
g
t
h
e a
g
ent pro
g
ramm
i
n
g
.
9.2 Computation and Tuple Spaces

A typical approach in designing multiagent systems is the use of “role models”
(
Bauer, 2001) [2] that ca
p
ture the differe
n
t functionalities in
t
he underlying appli
-
cation. The roles are assigned to different agents. An agent can be assigned multi
-
pl
e ro
l
es so t
h
at
i
t can cooperate w
i
t
h
ot
h
e
r

a
gents to comp

l
ete
di
fferent m
i
ss
i
ons
si
mu
l
taneous
l
y or at
di
fferent t
i
mes
i
n
i
ts
li
fe
li
ne. Cooperat
i
on requ
i
res

i
nterac
-
ti
o
n
s.
Th
e
tra
d
iti
o
nal f
o
rm
o
f int
e
ra
c
ti
o
n
i
s throu
g
h messa
g
e

co
mm
u
ni
c
ati
o
n
.
An
a
g
ent sends mission-specific messa
g
es to other a
g
ents involved in the same mis
-
s
ion at “o
pp
ortune times” in order to
c
omplete the common mission properl
y
.
W
hen viewed globally, a mission involving multiple agents can be represented by
the set of interaction
p

rotocols executed
b
y these agents together. Generic agen
t

H
.
F
.
Li
e
t al
.
201
communication lan
g
ua
g
e (ACL) protocols can be found in the FIPA librar
y
[3],
which su
pp
ort the agent application designs.
Message communication is one of the me
c
hanisms for su
p
porting agent interac-
t

ions. Agents can exchange and share i
n
formation by sending messages to each
ot
h
er. T
hi
s form of
i
nteract
i
on usua
ll
y
i
n
h
er
i
ts two
b
as
i
c restr
i
ct
i
ons
(
1

)
t
h
e
rece
i
ver must
b
e
k
nown to t
h
e sen
d
er an
d

(
2
)
t
h
e
i
nformat
i
on o
b
ta
i

ne
d

b
y t
h
e
rece
i
ver ref
l
ects on
l
y t
h
e
k
now
l
e
d
ge of t
h
e
sen
d
er at t
h
e t
i

m
e
w
h
en t
h
e message
was sent. The first restriction often leads to more static desi
g
ns. For example,
the
g
roup of a
g
ents involved in the mission ma
y
not chan
g
e d
y
namicall
y
in the mid
-
d
l
e

o
f an

occu
rr
e
n
ce

o
f t
h
e
mission. The second restriction leads to the knowled
g
e
of an agent to be space-time restricted. An agent causally acquires its knowledge
of the world by receiving messages from other agents. Such knowledge may no
t

b
e up to
d
ate an
d
may
i
n
d
ee
d

l

ea
d
t
o
i
ncons
i
stent v
i
e
w
s
among cooperat
i
ng
agents,
i
f t
h
e
i
nteract
i
on protoco
l
s
d
o no
t
ta

k
e care of sync
h
ron
i
zat
i
on proper
l
y.
Th
e former restr
i
ct
i
on affects t
h
e
f
l
ex
ibili
ty of t
h
e app
li
cat
io
n
d

es
i
gn. T
h
e
l
atte
r

restr
i
ct
i
on affects t
h
e ease w
i
t
h
w
hi
c
h
a correct
d
es
ig
n can
b
e constructe

d
an
d

eventua
lly

i
mp
l
emente
d
.
9
.2.1 Basics of a Tu
p
le S
p
ace
A
b
stract
ly
, a tup
l
e space stores an ar
bi
trar
y
set of ent

i
t
i
es
(
tup
l
es
)
t
h
at are s
h
are
d

b
y a community of agents. Each entity is identified by a tag (template). Conflicts
i
n tags are allowed. The pioneering ideas were developed in Linda [4]. Three
essential access primitives are associated with a typical Linda-based tuple space.
Insert
i
on of a tup
l
e can
b
e ac
hi
eve

d
us
i
ng o
u
t
(
tup
l
e_tag
)
. Remova
l
of a tup
l
e can
b
e ac
hi
eve
d
us
i
ng
i
n
(
tup
l
e_tag

)
, an
d
non
d
estruct
i
ve rea
d
out of a tup
l
e can
b
e per-
f
orme
d
us
i
ng rea
d

(
tup
l
e_tag
)
. F
i
g

ure 9.1
d
emonstrates t
hi
s use
i
n a tup
l
e space
t
h
at stores
i
tems on sa
l
e
i
n an e
l
ectron
i
c mar
k
et s
h
are
d

by
mu

l
t
i
p
l
e merc
h
ants.
F
ig. 9.1. Tup
l
e space w
i
t
h
an
i
mate
d

i
tems
9 Mu
l
t
i
agent Commun
i
cat
i

on for e-Bus
i
ness Us
i
ng Tup
l
e Spaces
20
2
In Fi
g
. 9.1, the tuple space window contains two TVs, two or three computers,
and two cameras, each entity can be made distinct with brand name and other
attributes (such as merchant,
p
rice).
A tuple space represents a globally consistent space shared by all agents instan
-
taneous
l
y at a
ll
t
i
mes. T
h
e correctness semant
i
cs of a tup
l

e space
i
s t
h
e same as
ot
h
er forms of s
h
are
d
memory,
i
.e., sequent
i
a
l
cons
i
stency [5]. State
d
s
i
mp
l
y, t
h
e
s
tate of t

h
e tup
l
e space at any t
i
me must
b
e as
i
f t
h
e accesses from t
h
e agents are
se
r
ved
in
so
m
e
int
e
r
l
e
aved (total) order consistent
w
ith th
e

l
oc
al
o
r
de
r
o
f th
e

accesses from each a
g
ent. As a result, as each a
g
ent pro
g
resses in its lifeline an
d

chan
g
es its knowled
g
e about the tuples in the tuple space, the
g
lobal chan
g
es i
n

the tu
p
le s
p
ace are ke
p
t consistent with the insta
n
taneous knowledge of each agent
at all times. Hence all relevant
k
nowledge needed by an ag
e
nt to advance is u
p
to
d
ate w
h
en a tup
l
e space
i
s use
d
. By access
i
ng t
h
e tup

l
e space, an agent can acqu
i
re
gl
o
b
a
ll
y cons
i
stent
i
nformat
i
on
i
n a s
i
ng
l
e access.
A tup
l
e space
di
ffers from convent
i
ona
l

s
h
are
d
memory
i
n two
i
mportant
aspects. (1) It is an associative memor
y
. Ta
gg
in
g
provides flexibilit
y
of access b
y

association rather than b
y
location address. Tolerance of ta
g
conflicts provides
f
lexibilit
y
in storin
g

a set of arbitrar
y

s
ize rather than a sin
g
leton at all times.
Hence a set of entities fitting the same descr
i
p
tion (tag) can be presented in a tuple
s
pace. (2) It allows destructive readout. Hence agent coordination can be made
easy when producer–consumer or mutual exclusion synchronization is require
d

among cooperat
i
ng agents. S
i
nce t
h
ese are t
h
e common forms of re
l
at
i
ons
hi

p
b
etween funct
i
ons performe
d

b
y agents, tup
l
e space
i
s a natura
l
me
di
um for
coor
di
nat
i
ng mu
l
t
i
agent act
i
v
i
t

i
es.
Extensions of Tu
p
le Primitives and Reactive Tu
p
les
In a
ddi
t
i
on to t
h
e
b
as
i
c pr
i
m
i
t
i
ves, severa
l
extens
i
ons
h
ave

b
een reporte
d
[6–8].
Co
ll
ect
i
ve
ly
, t
h
ese exte
n
s
i
ons prov
id
e a
ddi
t
i
ona
l
fl
ex
ibili
t
i
es

i
n tup
l
e accesses. A
“b
u
lk
” rea
d

[
9
]
ena
bl
es t
h
e retr
i
eva
l
of a
ll
tup
l
es w
i
t
h
a matc

hi
n
g
ta
g
. Hence one
can retrieve a whole set rather than one (arbitrar
y
) element of the set. This pro
-
vides flexibilit
y
to
g
ather all necessar
y
information without
g
oin
g
for it in multiple
rounds. To maximize flexibilit
y

i
n coordination, WCL
[7
]
introduces an additional
type of

i
nput ca
ll
e
d
non
bl
oc
ki
ng
(
async
h
ronous
)
tup
l
e access, represente
d
as “
i
np
(
tup
l
e_tag
)
”. In t
h
e n

o
nblocking case, in the absence of
a matching tuple, the agent
f
i
s free
d
to cont
i
nue w
i
t
h

i
ts future access w
i
t
h
out wa
i
t
i
n
g
for t
h
e “eventua
l
” return

of a matc
hi
n
g
tup
l
e t
h
at
i
s
i
nserte
d

i
nto t
h
e tup
l
e space
l
at
e
r
.
T
his
m
i

m
ics
n
o
n
-
bl
oc
ki
n
g
messa
g
e pass
i
n
g
an
d
ma
y

b
e use
d
for t
h
e purpose of en
h
anc

i
n
g
t
h
e per-
f
ormance. But, it requires a proper s
y
nchronizati
o
n in th
e

use

o
f th
e
“f
u
t
u
r
e
”
return of the access
y
et to be complet
e

d. Another notable extension of tu
p
le s
p
ace
p
rimitives is the use of lo
g
ic operators. An “and” or “or” o
p
erator can be used to
con
j
unct
i
ve
l
y or
di
s
j
unct
i
ve
l
y access mu
l
t
i
p

l
e tup
l
e spaces for matc
hi
ng tup
l
es. In
t
h
e “an
d
” case, eac
h
tup
l
e space must contr
ib
ute a matc
hi
ng tup
l
e, w
hil
e
i
n t
h
e
“or” case, at

l
east one tup
l
e space must return a matc
hi
ng tup
l
e to t
h
e access. T
hi
s
p
rov
id
es f
l
ex
ibili
t
y

i
n us
i
n
g
mu
l
t

i
p
l
e tup
l
e spaces for separate purposes
(
suc
h
as
H
.
F
.
Li
e
t al
.
203
different markets), rather than a sin
g
le tuple space with a possible de
g
radation in
p
er
f
ormance.
Reactivity of a tuple space is considered in MARS [6] by introducing the notion
of reactive tuples. An agent can program the tuple space to react to an event stimu

-
l
us
,
suc
h
as t
h
e retr
i
eva
l
of some tup
l
e. Upon occurrence of t
h
e event, a react
i
on
i
s
tr
i
ggere
d
,
l
ea
di
ng to a c

h
ange of t
h
e tup
l
e space, suc
h
as
i
nsert
i
on or mo
di
f
i
cat
i
on
of a tup
l
e. T
h
e react
i
on
i
s atom
i
c w
i

t
h
respect to t
h
e st
i
mu
l
us. Hence,
i
t
i
s poss
ibl
e
f
or the read to return a tu
p
le that is m
o
d
ified b
y
the reaction. Similarl
y
in out
(
tuple), if it tri
gg
ers a reaction, then the outcome ma

y
be a modified tuple that is
i
nserted into the tuple space. In a sli
gh
t
l
y
different manner, JavaSpace provides
reactivity by incorporating a notify primitive so th
a
t an agent may be notified by
the tu
p
le s
p
ace when some s
p
ecific event has occurred. The notification is
async
h
ronous. As a resu
l
t,
i
t
i
s poss
ibl
e upon react

i
on; t
h
e agent may not f
i
n
d
t
h
e
cause
(
suc
h
as t
h
e tup
l
e
)
t
h
at tr
i
ggers t
h
e react
i
on
i

n t
h
e tup
l
e space any more.
9
.2.3 Impl
i
cat
i
ons
i
n Us
i
n
g
Tuple
S
pace
T
up
l
es prov
id
e a
hi
g
h
er-
l

eve
l
a
b
stract
i
on t
h
at
i
s more powerfu
l
an
d
conven
i
ent to
use t
h
an po
i
nt-to-po
i
nt messa
g
e commun
i
cat
i
on. In cooperat

i
ve pro
bl
em so
l
v
i
n
g
,
a tup
l
e space acts
lik
e a
gl
o
b
a
l

b
u
ll
et
i
n
b
oar
d

t
h
at can
b
e f
l
ex
ibly
searc
h
e
d
an
d

up
d
ate
d

by
a
ll
part
i
c
i
pants w
i
t

h
out res
o
rt
i
n
g
to messa
g
e exc
h
an
g
es t
h
at are more
p
rivate and local. What must be consis
t
ently shared can be maintained by the
“
runtime system” automatically without
e
xplicit programming effort on the side of
the a
pp
lication develo
p
er. The tu
p

le s
p
ace
a
bstraction is easier to work with in
app
li
cat
i
on
d
es
i
gn. For examp
l
e, w
h
en
th
e
b
e
h
av
i
or of an agent
d
epen
d
s on some

gl
o
b
a
l
con
di
t
i
on o
f
t
h
e ent
i
re system, t
h
e
d
epen
d
en
c
y can
b
e reso
l
ve
d
an

d
t
h
e
agent a
d
vances forwar
d

b
y exam
i
n
i
ng t
h
e s
h
are
d
tup
l
e space. In turn,
i
f t
h
e act
i
on
of an a

g
ent ma
y
affect t
h
e pro
g
ress of some ot
h
er a
g
ents,
i
t ma
y
s
i
mp
ly
mo
di
f
y
t
h
e s
h
are
d
tup

l
e space to ref
l
ect t
h
e consequence of
i
ts act
i
on a
l
rea
dy
performe
d
.
Th
e a
g
ent
d
oes not
h
ave to as
k
aroun
d
a
b
out t

h
e

co
n
di
t
io
n
i
n t
he
f
i
r
s
t
c
a
se

i
n
o
r
der

to advance its behavior, nor does it have to tell ever
y
one of its action. This avoids

redundant
p
ush or
p
ull of information amon
g
the a
g
ents and what must be done is
done via the rather strict forward tuple access primitives. In
g
eneral, the pro
g
ram
-
ma
bili
ty
(
ease of program
d
eve
l
opment
)
of t
h
e p
l
atform

b
ase
d
on tup
l
e spaces
i
s
i
mprove
d
w
i
t
h
t
h
e support of t
hi
s s
h
are
d
me
di
um. Furt
h
er
d
emonstrat

i
on of t
hi
s
w
ill

b
e prov
id
e
d

i
n t
h
e
fo
ll
ow
i
n
g
sect
i
ons.
Th
ere
i
s a

l
so a pr
i
ce to
b
e pa
id
w
i
t
h
t
h
e use of tup
l
e spaces. T
h
e cons
i
stenc
y

requ
i
rement of a tup
l
e space
h
as certa
i

n performance
i
mp
li
cat
i
on
i
n
i
ts runt
i
me
sy
stem. To maintain consistenc
y
, it is diff
i
cult to exploit localit
y
b
y
replicatin
g
tuple spaces in a distributed s
y
stem. But with a sin
g
le tuple space servin
g

the
e
ntire s
y
stem, a bottleneck effect ma
y
arise. Hence tuple space does come with a
p
r
i
ce at runt
i
me. In ot
h
er
w
or
d
s, to support tup
l
e-
b
ase
d

i
nteract
i
ons eff
i

c
i
ent
l
y at
runt
i
me, t
h
e
d
es
i
gn of t
h
e tup
l
e space requ
i
r
es an eff
i
c
i
ent un
d
er
l
y
i

ng protoco
l
t
h
a
t

can promote concurrency
i
n accesses
b
y
di
str
ib
ut
i
ng tup
l
es across t
h
e p
h
ys
i
ca
l
networ
k
an

d
mana
g
e t
h
em correct
ly
, w
i
t
h
or
w
i
t
h
out se
l
ect
i
ve rep
li
cat
i
ons o
f

9 Mu
l
t

i
agent Commun
i
cat
i
on for e-Bus
i
ness Us
i
ng Tup
l
e Space
s
2
04
tuples. Otherwise, a tuple space can form a central bottleneck in the pro
g
ress o
f

t
he agents attempting to access it simultaneously.
9.3 Examples of Agent Coordination in e-Commerce
T
his section describes a few scenarios of agent coordination in e-commerce that is
f
acilitated with the use of tu
p
le s
p

aces. It should be noted that since tu
p
le s
p
ace is
a higher level abstraction and is act
ually implemented via message communication
t
t
i
n t
h
e runt
i
me system, t
h
e s
i
gn
i
f
i
cant return
i
n us
i
ng tup
l
es
i

n agen
t

c
oor
di
nat
i
on
li
es on
i
ts ease of use
i
n
b
ot
h
t
h
e app
li
cat
i
o
n
d
es
i
gn an

d
program
d
eve
l
opment. I
t

i
s also envisioned that tuple space provides
g
lobal information sharin
g
that often
le
a
ds
t
o

be
tt
e
r r
esu
lt
s
in a
pp
lications as consistent and instantaneous knowled

g
e
can be acquired directl
y
amon
g
the sharin
g
a
g
ents.
9
.3.1 Dynam
i
c Publ
i
c Auct
i
on
E
xisting auction protocols such as the sta
n
dard FIPA protocols for English and
Dutch auction [10] invo
l
ve a fixed set of
p
artici
p
ati

n
g
agents. A dynamic auction
i
n rea
l

li
fe may
i
nvo
l
ve a
d
ynam
i
ca
l
l
y c
h
ang
i
ng set of part
i
c
i
pants. Part
i
c

i
pants
can
j
o
i
n an
d

l
eave an auct
i
on any t
i
me
i
n t
h
e a
u
ct
i
on per
i
o
d
, prov
id
e
d

outstan
di
ng
obli
gat
i
ons rema
i
n comm
i
tte
d
. Suc
h
an auct
i
on can
b
e eas
il
y
i
mp
l
emente
d
us
i
ng
t

uple space, as depicted in Fi
g
. 9.2a, b.
F
ig
. 9.2.
Fi
g
ure 9.2a shows an animated auction involvin
g
a tuple space that holds an
a
nimated tu
p
le consisti
ng
of a paintin
g
and the current hi
g
hest bid price announce
d

b
y
the auctioneer, and a few newl
y
submitted bids (tu
p
les) from

p
artici
p
ants A, B,
C
. Figure 9.2b shows a future round wit
h
u
p
dated tu
p
les and
p
artici
p
ants A, D,
a
nd E. Obviously, participants have ch
a
nged. B and C give up in the auction,
H.F. L
i
et a
l
.
2
05
while D and E are newcomers beatin
g
the current hi

g
hest bid price (
$
420), whic
h
may be the bid price of A.
As can be observed in Fig. 9.2, part o
f

t
he tuple space has served as the physi-
cal auction medium for conducting the auct
i
o
n. The fact that this medium is glob
-
a
lly
cons
i
stent an
d
up to
d
ate w
i
t
h
respect to a
ll

part
i
c
i
pants ma
k
es
i
t eas
y
an
d
e
xtreme
ly
user fr
i
en
dly

i
n app
li
cat
i
on
d
es
i
g

n. Note t
h
at react
i
v
e
tup
l
es suc
h
as
th
ose supporte
d

by
MARS can ma
k
e t
h
ese even s
i
mp
l
er
by
a
ll
ow
i

n
g
new
bid
s to
u
pdate the hi
g
hest bid atomicall
y
and convenientl
y
in a sin
g
le tuple access.
Shopping in Multiple Markets
A sin
g
le electronic market can be visualized to be supported b
y
a tuple space. To
p
romote market efficienc
y
, different tuple spaces can be formed to support differ
-
e
nt markets. As a result, it is
p
ossible that the tu

p
le s
p
ace servers can o
p
erate con
-
currently without creating a server bottleneck. This follows the principles o
f

concurrency an
d

l
oca
li
ty of
i
nteract
i
on
i
n manag
i
ng system performance. How
-
e
ver,
i
t

i
s a
l
so conce
i
va
bl
e t
h
at a c
li
ent agent may
b
e
i
ntereste
d
to s
h
op across
mu
l
t
i
p
l
e mar
k
ets at t
h

e same t
i
me an
d

d
ec
id
e
i
ts purc
h
a
s
es s
i
mu
l
taneous
l
y. W
h
en
i
mplemented usin
g
messa
g
e passin
g

, this client a
g
ent will ha
ve
t
o

co
mm
u
ni
c
at
e
t
o
various market a
g
ents, conduct ne
g
otiations throu
g
h separate protocols, and even
-
t
uall
y
decide on its purchases. Meanwhile, consistenc
y
an

d

p
ersistence of avail
-
ability and pricing information mus
t

b
e maintained in the
p
artici
p
ants, and the
overall coordination inv
o
lving multiple parties and mu
l
ti
p
le sites of
p
urchases
may lead to complications in synchro
n
i
zation that ultimately affect the market
p
er
f

ormance.
F
i
g
. 9.3
.
Lo
g
ical template
Wh
en supporte
d

by
tup
l
e spaces, a s
i
mp
l
e extens
i
on of tup
l
e access
i
nvo
l
v
i

n
g
l
o
gi
ca
l
ta
g
s w
ill
s
ig
n
i
f
i
ca
n
t
ly
s
i
mp
li
f
y
t
h
e

i
nteract
i
on
s
requ
i
re
d
an
d
potent
i
a
lly
i
mprove the market efficienc
y
. This extension is im
p
lemented i
n
our ex
p
erimental
f
ramework detailed in Sect. 9.4. Conce
pt
ually, the client ag
t

t
e
nt
c
an i
ssue
a
9
Multiagent Communication for e-Business Using Tuple Space
s
2
06
l
o
g
ic
_
template
_
in() access. This access will enable him to retrieve, in a sin
g
le
s
te
p
, multi
p
le sets of tu
p
les from one o

r
more markets. In
o
t
her words, he may
choose to retrieve TVs and refrigerators that satisfy certain criteria from one or all
of the markets (tu
p
le s
p
aces) s
p
ec
i
f
ied in his access operation. Figure 9.3 illus-
trates suc
h
a use scenar
i
o. It
i
s o
b
v
i
ous t
h
at programm
i

ng effort requ
i
re
d
to
d
o
s
o
i
s s
i
gn
i
f
i
cant
l
y re
d
uce
d
w
hil
e g
l
o
b
a
l

cons
i
stent
i
nformat
i
on
i
n co
ll
ecte
d
or
consume
d
.
In Fi
g
. 9.3, there are two markets
(
tu
p
le s
p
aces: tsId1 and ts
I
d
2), each of which
contains few different t
y

pes of
T
Vs and refri
g
erators. A bu
y
er a
g
ent wants to
retrieve
p
roduct information from the tw
o
markets. From market1, he is intereste
d

i
n the TV product with the fields of “TV,” “Sony,” and “FlatScreen” in a search
tu
p
le; from market2, he wants to know t
h
e
information of refrigerators with the
fi
e
ld
s of “Refr
i
g,” “Ha

i
er,” an
d
“18.8Cu”
i
n anot
h
er searc
h
tup
l
e. F
i
rst,
i
t con-
s
tructs a searc
h
tup
l
e w
i
t
h
searc
h
requ
i
rements. T

h
en
it
constructs two searc
h
tem
-
pl
ates
(
temp
l
ate1 an
d
temp
l
ate2
)
for searc
hi
ng t
h
e pro
d
uct from eac
h
of t
h
e tup
l

e
s
paces. A lo
g
ic template combinin
g
the two templates is created usin
g
lo
g
ic opera-
tor “and.” Finall
y
, a bulk s
y
nchronous access operation is used to perform the
a
c
t
u
al
se
ar
c
h
.
Th
e
r
e

t
u
rn
ed
f
u
t
u
r
e

ob
ject contains a set of tuples.
b
//constructs different search tem
p
lates for different tu
p
le s
p
aces
T
emplate template1 = new Template (tsId1, search_tuple);
T
emplate template2 = new Template (tsId2, search_tuple);
//
constructs a
l
og
i

c temp
l
ate
L
og
i
cTemp
l
ate sLog
i
cTemp
l
ate = new Log
i
cTemp
l
ate
()
;
s
Log
i
cTemp
l
ate.an
d

(
temp
l

a
te1, temp
l
ate2
)
;
//
searc
h
es t
h
e
l
o
gi
c tup
l
es t
h
rou
gh

b
u
lk
pr
i
m
i
t

i
ve
M
u
l
t
i
p
l
eTup
l
eSet mu
l
t
i
TSet = m
y
A
g
e
nt.
b
u
lk
Rea
d
W
i
t
h

outWa
i
t sLo
gi
cTem
-
pl
ate
);
9
.3.3 Advert
i
sed
S
ales
/
Purchases
A conventional tu
p
le s
p
ace lacks re
s
ponsiveness provided b
y
direct messa
g
e
communication. In other words, unless
a

consumer is alread
y
waitin
g
for the pro-
duction of some needed data (tuple), it ma
y
not become aware of its existence
unt
il
muc
h

l
ater. Constant
l
y samp
li
ng t
h
e tup
l
e space us
i
ng non
d
estruct
i
ve rea
d

ou
t

affects performance
b
ecause of t
h
e potent
i
a
l
waste of t
i
me. To reme
d
y t
hi
s, reac
-
t
i
ve tup
l
e space
h
as
b
ecome a necessar
y
extens

i
on. React
i
ve tup
l
es
h
ave
b
een
i
mp
l
emente
d
a
l
so as
i
n MARS an
d
Jav
a
Space. In our exper
i
menta
l
framewor
k
d

eta
il
e
d

i
n Sect. 9.4, a s
ligh
t
ly

di
fferent react
i
ve tup
l
e
i
s
i
mp
l
emente
d
. Un
lik
e
MARS, the reaction in our case is a s
u
b-behavior of the agent that registers itself

u
with the tu
p
le s
p
ace. U
p
on the occurren
c
e
of the stimulus, atomicall
y
or non-
atomicall
y
, the reactive behavio
r
of the a
g
ent will be t
r
igg
ered and performed b
y
t
h
e agent. T
hi
s can
b

e
p
ut to use
i
n a
d
vert
i
se
d
sa
l
es or purc
h
ases. In an a
d
vert
i
se
d

s
a
l
e, a “s
h
opp
i
ng agent” may
r

eg
i
ster
i
tse
l
f w
i
t
h
t
h
e mar
k
e
t
(
tup
l
e space
)
so t
h
a
t

wh
en a correspon
di
ng tup

l
e
i
s
i
nserte
d

i
nto t
h
e tup
l
e space
b
y a “se
ll
er agent,” t
h
e
sh
opp
i
n
g
a
g
ent can
i
mme

di
ate
ly
react an
d
respon
d
to t
h
e state c
h
an
g
e.
H
.
F
.
Li
e
t al
.
20
7
9.4 A Tuple Space-Based Framework for Agent Communication
9
.4.1 Reactive Tu
p
le S
p

ace
T
his section
p
resents some details of our ex
p
erimental reactive tu
p
le s
p
ace [11]
i
mplemented on the JADE platform. Java agent development framework (JADE)
i
s a framewor
k
t
h
at fac
ili
tates t
h
e
d
eve
l
opmen
t
of mu
l

t
i
a
g
ent s
y
stems. It
d
ef
i
nes
an a
g
ent mo
d
e
l
from w
hi
c
h
a software
d
ev
e
l
oper can exten
d
to
i

nc
l
u
d
e spec
i
f
i
c
b
us
i
ness
l
o
gi
c. We furt
h
er exten
d
e
d
JADE [8, 12] to react
i
ve
t
uple space for the
t
t
s

upport of a
g
ent interactions. Fi
g
ure
9
.4 shows the overall architecture of the
J
ADE
p
latform.
Fig
. 9.4
.
J
ADE architecture
T
he JADE
p
latform is com
p
osed of several containers. Every con
t
ainer runs on
a Java virtual machine and can host zero or more agents. The platform can be
actua
ll
y
di
str

ib
ute
d
across severa
l

h
osts, an
d
an agent w
ill
not
h
ave to
k
now t
h
e
e
x
i
stence of t
h
e un
d
er
l
y
i
ng networ

k
as
J
ADE prov
id
es t
h
e
hi
g
h
-
l
eve
l
a
b
stract
i
on
ca
ll
e
d
‘conta
i
ner’ to
hid
e t
h

e comp
l
ex
i
ty
o
f
di
str
ib
ut
i
on. In JADE
,
t
h
ere are two
ki
n
d
s of
i
nterfaces to an a
g
ent. T
h
e f
i
rst
ki

n
d

i
s ca
ll
e
d
“
i
nterna
l

i
nterface,” w
hi
c
h

i
s
d
ef
i
ne
d

by
t
h

e conta
i
ner to prov
id
e
sy
stem serv
i
ces of
li
fe c
y
c
l
e mana
g
ement,
messa
g
e serv
i
ce, mo
bili
t
y
support, an
d
resource a
ll
ocat

i
on. An a
g
ent accesses t
h
e
s
ystem services through its container. The container then delegates these service
requests to the corresponding manager. The second kind is known as the “callbac
k

i
nterface.” This interface includes hooks that will be implemented by an agent
d
eve
l
oper an
d
ca
ll
e
d

b
ac
k

b
y t
h

e conta
i
ner at runt
i
me. T
h
e ca
llb
ac
k

i
nterfaces can
b
e furt
h
er c
l
ass
i
f
i
e
d

i
nto two su
b
categor
i

es: system or
i
ente
d
vs. app
li
cat
i
on or
i-
e
nte
d
. T
h
e system-or
i
ente
d

i
nterfaces a
ll
ow an agent to custom
i
ze t
h
e system
s
erv

i
ce, w
hil
e t
h
e app
li
cat
i
on-or
i
ente
d

i
nterfaces
h
e
l
p an a
g
ent to pro
g
ram
i
ts
b
us
i
ness

l
o
gi
c. T
h
e app
li
cat
i
on-or
i
ente
d

i
nterfaces are capture
d

by
t
h
e a
g
ent
b
e
h
av
i
or mo

d
e
l

i
n JADE
,
w
hi
c
h

ill
ustrate
d

i
n Sect. 9.4.2.
An a
g
ent is an active
o
b
j
ect and follows “a thread-per-a
g
e
n
t
concurrenc

y
model.” It means that there is a sin
g
le Java thread per a
g
ent t
o

e
x
ecu
t
e
all it
s
ta
s
k
s
concurrentl
y
. JADE also provides an “a
g
ent behavior model” in the form of abstrac
t

c
l
asses to support concurrent execut
i

on of agent
b
e
h
av
i
ors. An agent may
h
ave
mu
l
t
i
p
l
e
b
e
h
av
i
ors to mo
d
e
l
t
h
e un
d
e

r
l
y
i
ng tas
k
s. At runt
i
me, t
h
e em
b
e
dd
e
d

9 Mu
l
t
i
a
g
ent Commun
i
cat
i
on for e-Bus
i
ness Us

i
n
g
Tup
l
e Space
s
208

s
cheduler inside each a
g
ent
w
ill
sc
h
edu
l
e
an
d

e
x
ecu
t
e
th
e

v
ari
ous

be
ha
v
i
o
r
s
in a
round-robin manner. JADE provides message passing to support agent interac-
t
ions. It supports FIPA ACL specification to create messages.
F
i
g
. 9.5
.
Reactive tu
p
le s
p
ace architecture
Fi
g
ure 9.5 is the reactive tuple space architecture viewed in a hi
g

h-level abstrac
-
tion. The tuple space is desi
g
ned to be part of the JADE services. There are two
l
ayers
i
n t
hi
s a
b
stract arc
hi
tecture: t
h
e “tup
l
e space s
h
e
ll
” an
d
t
h
e “tup
l
e space
k

erne
l
.” Mu
l
t
i
p
l
e tup
l
e spaces are
di
str
ib
ute
d
over t
h
e
n
etwor
k
env
i
ronment. T
h
e
co
mm
u

n
ic
at
io
n
be
t
wee
n t
he

sh
ell
an
d
t
he

ke
rn
el

is
a
loc
a
l
m
e
t

hod

c
a
ll.
T
he

ke
r-
n
e
l
s
l
ocate
d

i
ns
id
e
di
fferent
J
ADE c
o
nta
i
n

e
r
s

co
mm
u
n
ic
at
e

wi
t
h

e
a
ch

o
t
he
r
t
h
rou
gh
RMI. T
h

e s
h
e
ll

i
s
i
n t
h
e a
g
ent
l
eve
l
an
d
supp
li
es sta
bl
e
i
nterfaces for
a
g
ents. In addition, there is a connector in the shell. The connector performs the
exchan
g

e and transformation of data between
a
n application a
g
ent and the kernel
l
evel. The kernel processes tuple accesses from the shell locall
y
or remotel
y
, and
returns a
pp
ro
p
riate res
p
onses. If th
e
re
q
uired tu
p
le s
p
ace is located in a remote
container, the kernel forwards the re
q
uest to the (tu
p

le) kernel in the remote con-
tainer. The kernel also includes a framework
t
o suppor
t
agen
t
reactive behaviors.
Thi
s framewor
k
prov
id
es t
h
e react
i
ve pro
g
ramma
bl
e
i
nterface
c
a
lled
IR
e
a

c
t
ive
f
o
r
a
g
ents an
d
w
ill
tr
igg
er
(
ex
e
cute
)
t
h
ese react
i
ve
b
e
ha
v
i

ors w
h
en t
h
e spec
i
f
i
e
d

e
vents occur. T
h
e
k
erne
l
uses rep
li
cat
i
on to ma
k
e t
h
e s
y
stem eff
i

c
i
ent.
Our desi
g
n follows the principle of minimal chan
g
e to the JADE source code.
T
he first chan
g
e is to extend the interfaces of the
J
ADE A
g
ent class so that an a
g
en
t

can access tuple spaces. The second is to handle a
g
ent mobilit
y
so that when a
n

agent migrates from one container to anot
her container, reacti
t

t
v
e behavior registra-
t
ion information can be updated b
y
the reaction manager. Thus, it can keep location
t
ransparency
f
or agent reactions. Finally, the initial
i
zation and termination handling
o
f JADE are mo
di
f
i
e
d
so t
h
at tup
l
e space serv
i
ces can start an
d
stop proper
l

y.
9.4.2 Tuple
S
pace-Based A
g
ent Interact
i
on Pr
i
m
i
t
i
ves
S
ome of t
h
e tup
l
e pr
i
m
i
t
i
ves are a
l
rea
d
y

hi
g
hli
g
h
te
d

i
n ear
li
er sect
i
ons. In t
hi
s sec-
t
ion, we present the full taxonom
y
of primitives
t
hat are incorporated in our desi
g
n.
H
.
F
.
Li

e
t al
.
209
T
he set of primitives supported throu
g
h tuple space can be classified into three
categories: synchronous, asy
n
chronous, and reactive
(
notification)
p
rimitives. In
addition, in order to facilitate programm
i
n
g as well as improve the resulting sys
-
t
em performance, we extend each synchronous or asynchronous primitive into
th
ree su
b
categor
i
es
(
1

)
s
i
ng
l
e
(
tup
l
e
)
access,
(
2
)

b
u
lk

(
tup
l
e
)
access, an
d

(
3

)

l
og
i
c
-
t
emp
l
ate-
b
ase
d
access. Bu
lk
access a
ll
ows mu
l
t
i
p
l
e tup
l
es to
b
e retr
i

eve
d

i
n a s
i
n-
gl
e operat
i
on. Log
i
c-temp
l
ate-
b
ase
d
access prov
id
es assoc
i
at
i
ve searc
h
of tup
l
es
v

ia a lo
g
ic-template to improve the flex
i
bilit
y
of a
g
ent collaboration
p
rotocols.
Fi
g
ure 9.6 outlines the set of
p
rimitives that we have
i
m
p
lemented in Java.
In the followin
g
, selective explanation is offered for some of the
p
rimitives
shown in Fig. 9.6.
F
ig. 9.6. Interaction
p
rimitives

9 Mu
l
t
i
a
g
ent Commun
i
cat
i
on for e-Bus
i
ness Us
i
n
g
Tup
l
e Space
s
2
1
0

8.
b
u
lk
InWit
h

outWait
(
Tup
l
eSpaceID tsI
d
, Tuple atemplate). It retr
i
eves a
ll

t
h
e tup
l
es t
h
at matc
h
w
i
t
h
temp
l
ate atemp
l
ate from tup
l
e space tsI

d
an
d

g
ets a Tup
l
eSet o
bj
ect t
h
at conta
i
ns a
ll
t
h
e matc
hi
n
g
tup
l
es
i
mme
di
ate
ly
. If

t
h
ere
i
s not even one matc
hi
n
g
tup
l
e, an empt
y
tup
l
e set
i
s returne
d
. As
1
. TSCreate(String name
)
. This
p
rimitive enables
a
n agent initially to create a
t
up
l

e space an
d
s
h
are w
i
t
h

i
ts group mem
b
ers. T
h
e group mem
b
ers w
ill
access t
h
e tup
l
e space
b
y name. T
h
e
l
ocat
i

on of tup
l
e space create
d

i
s
t
ransparen
t

t
o agen
t
s.
2.
TSFind(Strin
g
name
)
.
It f
i
n
d
s an ex
i
st
i
n

g
tup
l
e space
by
t
h
e
gi
ven name.
Thi
s pr
i
m
i
t
i
ve ena
bl
es an a
g
ent to
j
o
i
n a
g
roup of a
g
ents

i
f
i
t
i
s aware o
f

th
e name of t
h
e tup
l
e space.
3
.
in(Tu
p
leS
p
aceID tsI
d
, Tu
p
le atem
p
late
)
.
It ha

s
th
e

s
am
e

se
manti
cs
a
s
L
inda-like in
p
rimitive [4]. It retrieves
(
destructive read-out) a tu
p
le that
m
atches with the tem
p
late atem
p
late from tu
p
le s
p

ace tsId. Since the
p
rimi
-
ti
ve
i
s sync
h
rono
u
s
, t
h
e agent w
ill

bl
oc
k
unt
il
a matc
hi
ng tup
l
e
i
s ava
il

a
bl
e.
4
.
in(TupleSpaceID tsId, Tupl
e atemplate, long timeout)
l
l
.
It retr
i
eves
(d
estruc
-
ti
ve rea
d
-out
)
a tup
l
e t
h
at matc
h
es w
i
t

h
t
h
e temp
l
ate atemp
l
ate from tup
l
e
space tsI
d
. S
i
nce t
h
e pr
i
m
i
t
i
ve
i
s s
y
nc
h
ronous, t
h

e a
g
ent w
ill

bl
oc
k
unt
il

a
m
atc
hi
n
g
tup
l
e
i
s ava
il
a
bl
e or t
i
m
e
out

i
s tr
igg
ere
d
. T
hi
s pr
i
m
i
t
i
ve can
s
i
mu
l
ate t
h
e pro
bi
n
g
L
i
n
d
a pr
i

m
i
t
i
ve
i
np.
5.
r
ea
d
(Tu
p
leS
p
aceID tsI
d
, Tu
p
le atem
p
late
)
.
It ha
s
th
e

s

am
e

se
manti
c
a
s
in(tsId,atem
p
late)
p
rimitive exce
p
t
that the matchin
g
tuple is not removed.
6
.
asynIn(TupleSpaceID ts
Id, Tuple atemplate)
ss
.
It as
y
nchronousl
y
retrieves a
t

up
l
e t
h
at matc
h
es w
i
t
h
t
h
e temp
l
a
te atemp
l
ate from tup
l
e space tsI
d
. T
h
e
pr
i
m
i
t
i

ve
i
s async
h
ronous an
d
t
h
e age
n
t w
ill
not
b
e
bl
oc
k
e
d
. It returns
a

t
up
l
e-
h
o
ld

er o
bj
ect
(
ca
ll
e
d
future
)
. T
h
e a
g
ent can c
h
ec
k
t
h
e future o
bj
ect to
see
i
f t
h
e matc
hi
n

g
tup
l
e
h
as
b
ecome a
v
ailable and fetch it
from the future
t
obj
ect
l
oca
lly
. T
hi
s ena
bl
es an a
g
en
t
to as
y
nc
h
ronous

ly

i
nteract w
i
t
h
a
nother a
g
ent without stallin
g
when th
e
latter is not read
y
. For exam
-
ple, a bu
y
er a
g
ent ma
y
look for an item
y
et to appear in the market.
7
.
m

ove(TupleSpaceID ts
_
source, TupleSpaceID ts
_d
est, Tuple atemplate
)
.

I
t
m
oves a
ll
t
h
e tup
l
es t
h
at matc
h
temp
l
ate atemp
l
ate from tup
l
e space
t
s_source to tup

l
e space ts_
d
est. In fact,
i
t cons
i
sts of two operat
i
ons: one
i
s to retr
i
eve tup
l
es from source tup
l
e space, an
d
t
h
e ot
h
er
i
s to wr
i
te t
h
ese

t
up
l
es
i
nto t
h
e
d
est
i
nat
i
on tup
l
e space. It returns an
i
nte
g
er as t
h
e num
b
e
r

o
f tup
l
es t

h
at
h
as
b
een move
d
. T
hi
s p
r
i
m
i
t
i
ve ena
bl
es an a
g
ent to mana
g
e
th
e s
h
are
d
tup
l

es accor
di
n
g
to
i
ts ro
l
es. For examp
l
e, a ware
h
ouse mana
g
e
r

c
an move selected items from one warehouse to another easil
y
.
demonstrated earlier, this primitive is useful for collectin
g
items that match
a requ
i
rement toget
h
er as a set.
9

. asynRead(LogicTemplate alogic_template
)
. T
hi
s pr
i
m
i
t
i
ve rea
d
s t
h
ose
t
up
l
es t
h
at matc
h
w
i
t
h
t
h
e
l

og
i
c
t
emp
l
ate a
l
og
i
c
_
t
emp
l
ate async
h
ronous
l
y.
H.
F
.
Li
e
t al
.
211
T
his

p
rimitive enables an a
g
ent to read tuples across multiple clusters of
co
lla
bo
rati
o
n
s
im
u
ltan
e
o
usl
y
. To clarif
y
lo
g
ic-template, its s
y
ntax in BNF
notation is
g
iven here. Suppose tha
t

E
XP re
p
resents t
h
e
lo
g
ic-template:
<EXP> ::= <OP>
(
<ARGS>
)

<ARGS> ::= <ARG> | <ARG>,<ARGS>
<ARG> ::= (tsId, template)| <EXP>
<OP> ::= an
d

|
or
Th
e semant
i
cs of an
d
operator
i
s t
h

at
it

supports retrieval of
tuples from the
f
t
uple spaces identified b
y
both the left and the ri
g
ht statements. The semantic
o
f or o
p
erator is that it su
pp
orts retrieval of tu
p
les from the tu
p
le s
p
aces iden-
t
ified b
y
either the left or the ri
g
ht statements.

10.
r
egister(TupleSpaceID tsI
d
, Tuple atemplate, IReactive ref)
.
It registers a
reaction to tu
p
le s
p
ace tsI
d
.
The
p
rimitive retur
n
s a register identifier regis-
t
er_id. At runtime, if a tuple that matches the tem
p
late atem
p
late becomes
a
va
il
a
bl

e
i
n tup
l
e space tsI
d
, t
h
e react
i
on t
h
at
i
mp
l
ements IReact
i
ve
i
nter
-
f
ace
i
s tr
i
ggere
d
. If more t

h
an one agent reg
i
sters t
h
e same temp
l
ate, a
ll

reg
i
stere
d
react
i
ons w
ill

b
e tr
i
ggere
d
. T
hi
s pr
i
m
i

t
i
ve ena
bl
es t
h
e react
i
ve
p
arts of an a
g
ent to sense stimulus from other a
g
ents passivel
y
. Mean-
while, the tu
p
le s
p
ace mana
g
er takes over the res
p
onsibilit
y
of detectin
g

t
h
e

s
tim
u
l
us.
R
e
a
c
ti
o
n i
s
intr
oduced
to model a
g
ent reactive behaviors and
s
upport agent asynchron
o
u
s couplings. A reaction is defined through the
reactive interface called Ireactive, which has only one method reactTo
(AgentReactionEvent ev). It is mode
l

e
d as a serializable object collocate
d
w
i
t
h
t
h
e agent. T
h
e parameter AgentReact
i
onEvent prov
id
es t
h
e event an
d

i
ts source agent. An event
i
s a tup
l
e. For a programmer,
d
ef
i
n

i
ng a react
i
on
i
s to
i
mp
l
ement t
h
e Ireact
i
ve
i
nterface, an
d
correspon
di
ng co
d
e
i
mp
l
ements
th
e a
g
ent’s react

i
on. At runt
i
me, t
h
e
k
erne
l

k
eeps trac
k
of a
g
ent
l
ocat
i
on
an
d

k
n
ows

whe
r
e

t
he
n
o
t
i
f
ic
at
io
n
should

be

se
nt
.
9
.4.3 T
S
AF – Agent Framework
T
his section presents an agent model and the associated framework that we have
i
mplemented [13]. Agent-oriented programming relies on the assumption that
a

com
p

lex distributed softw
a
re system can be programm
a
ed as a set of interacting
s
oftware ent
i
t
i
es, ca
ll
e
d

(
software
)
agents. Gene
r
a
ll
y, agent-or
i
ente
d
met
h
o
d

o
l
o
-
gi
es
i
nc
l
u
d
e agent arc
hi
tecture an
d
agent programm
i
ng framewor
k
s t
h
at suppor
t

analysis, design, and implementation of
agent applications
f
at
di
fferent

l
eve
l
s.
Agent architecture is in the abstract level of
agent model, while an agent pro-
f
g
ramm
i
n
g
framewor
k

i
s
i
n t
h
e
i
mp
l
e
mentat
i
on
l
eve

l
an
d
supports
b
u
ildi
n
g
prac-
ti
ca
l
a
g
ent app
li
cat
i
ons
i
n software en
gi
neer
i
n
g
sense. Our TSAF
i
s suc

h
an
a
g
ent-oriented framewor
k

t
hat includes the a
g
ent architecture in the abstract level
9 Mu
l
t
i
agent Commun
i
cat
i
on for e-Bus
i
ness Us
i
ng Tup
l
e Space
s
2
12
and an a

g
ent pro
g
rammin
g
su
pp
ort in the im
p
lementation le
v
e
l for buildin
g
multi
-
agent systems. Besides, TSAF supports tuple space-based agent coupling mecha-
nism. The structure of TSAF
i
s shown in Fig. 9.7.
E
ven though different approaches to the construction of multiagent systems
i
mpose
di
fferent requ
i
rements on t
h
e

i
ndi
v
id
ua
l
agents, an agent
i
s genera
ll
y
d
ef
i
ne
d

as an autonomous, co
ll
a
b
orat
i
ve, an
d
a
d
apt
i
ve computat

i
ona
l
ent
i
ty w
i
t
h
react
i
ve
an
d
proact
i
ve
b
e
h
av
i
ors. Many ear
l
y researc
h
es on agent arc
hi
tecture com
bi

ne t
h
e
p
s
y
cholo
g
ical and behavioral studies of humans, and describe a
g
ent models to
e
xhibit co
g
nitive behaviors [14, 15]. In this view, an a
g
ent has three basic parts:
s
ensor
y
part, communication part, and dec
i
s
ion
p
art, whose actions are com
p
atible
with the basic action–perception cycle of cognitive brain functions shown in
Fig. 9.8. The sensors perceive information from the environment, the effectors

affect t
h
e env
i
ronment t
h
ro
u
gh
act
i
v
i
t
i
es, an
d
t
h
e par
t

o
f centra
l
process
i
ng ma
k
es

d
ec
i
s
i
ons of w
h
at act
i
ons w
ill

b
e ta
k
en
b
y t
h
e effectors accor
di
ng to t
h
e acqu
i
re
d

i
nformat

i
on t
h
roug
h
sensors.
T
his a
g
ent architecture is based on the AI perspective, which describes a
g
ents
as entities with knowled
g
e fo
r

r
easonin
g
in a human-li
k
e wa
y
. A
g
ent-oriente
d

software en

g
ineerin
g
is centered on the desi
g
n of autonomous, active, and inter-
F
ig
. 9.7.
S
tructure of T
S
AF
F
ig
. 9.8
.
Bas
i
c act
i
on–percept
i
on c
y
c
l
e
Ag
ent

Env
i
ronment
A
g
ent architecture
Ag
ent pro
g
rammin
g
framework
A
g
ent develo
p
m
en
t
p
latfor
m
Reactive Tuple space
TSA
C
entra
l
process
i
n

g
S
ensors E
ff
ector
s
acting agents. It mainly cares about how to design flexible and interactive entities
H
.
F
.
Li
e
t al
.
213
with clear definitions of a
g
ent’s behaviors and their interaction protocols. In
multiagent-based applicati
o
n
s, the uncertainty of the dynamic environment, the
complexity of coordination among aut
o
nomous agents, and the multiple roles
p
layed by each agent further necessitate the agent architecture to simplify the
p
rocess of

d
eve
l
opment. In TSAF, we a
i
m at t
h
ese requ
i
rements of a software
e
ng
i
neer
i
ng process to prov
id
e
di
fferent agent arc
hi
tecture. T
h
e fo
ll
ow
i
ng sect
i
on

el
a
b
orates t
hi
s arc
hi
tecture
i
n
d
eta
il
.
As an a
g
ent-pro
g
rammin
g

model, the primary goal of
TSAF is to provide a
f
means for buildin
g
a
g
ent applications to facilitate anal
y

sis, desi
g
n, and implemen
-
t
ation of software a
g
ents in a relativel
y

r
apid and eas
y
wa
y
. The a
g
ent architecture
of TSAF is shown in Fig. 9.9. Based on the basic agent model of action–
p
erception cycle, the communication part and central processing part are still
i
nc
l
u
d
e
d

i

n t
h
e arc
hi
tecture;
h
owever, t
h
ey are
d
e
lib
erate
d

i
n
di
fferent ways fro
m
th
e tra
di
t
i
ona
l

l
ayere

d
arc
hi
tecture
f
or ease of
b
u
ildi
n
g
a so
f
tware agent.
The sensory part includes agent sensory
behaviors that periodically sense the
y
chan
g
in
g
environment where the a
g
ent lives. The adaptabilit
y
of a
g
ents enables
t
hem to read

j
ust themselves to ada
p
t to the environment. In this case, we assume
t
hat an a
g
ent often kn
o
ws
q
uite a bit about its en
v
i
r
o
nm
e
nt an
d
kn
ows
h
ow
t
o
ada
p
t to its environment. For exam
p

le, a mobile informa
t
i
on agent in an
e
-commerce application may need to sense
i
ts operating environment to decide
whether to move away from some sites. Meanwhile, it also kee
p
s sensing the
Fig
. 9.9
.
A
g
ent architecture of TSAF
status of local data resource. If it knows that the accessed data sources are
p
rob
-
lematic, it may stop the searching activity immediately and move to other places.
Sensory pa
r
t
Coup
li
ng par
t
S

hare
d
Pr
o
a
c
ti
ve
r
ole behavior 1
bh
bh
R
eact
i
ve
re
a
c
ti
ve

be
ha
v
i
o
r1
…
External

n
ob
j
ect
T.
S
.
…
…
m
ain r
o
l
e

be
ha
v
i
o
r
as
y
nchronousl
y
notif
y
s
ync
h

ronous
l
y
/

asynchronously

cou
p
l
e
ro
l
e

be
ha
v
i
o
r 2
bh
bh
r
o
l
e

be
ha

v
i
o
r
3
ro
l
e
b
e
h
av
i
o
r
n
r
eactive behavior2
r
e
a
c
ti
ve

be
ha
v
i
o

r
r
External
n
o
b
j
ect
T
.
S
.
9
Multia
g
ent Communication for e-Business Usin
g
Tuple Space
s
2
14
T
he reactive part includes reactive behaviors that can be re
g
arded as stimulus–
response pattern. The stimulus may be from the external objects sensed by the
s
ensory part or from the other age
n
ts’ notifications through t

h
e
coupling part.
T
herefore, the reactive behaviors are divided into two different types. One type
i
nc
l
u
d
es s
i
mp
l
e
b
e
h
av
i
ors t
h
at are tr
i
ggere
d

b
y ot
h

er
b
e
h
av
i
ors of t
h
e agent. Fo
r

e
xamp
l
e, t
h
ey may
b
e tr
i
ggere
d

b
y t
h
e se
n
sory
b

e
h
av
i
or to react to t
h
e externa
l

e
nv
i
ronment or
b
y t
h
e proact
i
ve
b
e
h
av
i
ors to react to some
i
nterna
l
resu
l

ts. T
h
e
other t
y
pe is as as
y
nchronous listeners to other a
g
ents to perform collaborations
with other a
g
ents. The latter can be realized throu
g
h reactive tuples.
A reactive behavior is a
p
recise and deter
m
inistic action without lon
g
-term pro
-
active
p
rotocols neede
d

t
o interact with other agents.

I
t may be a simple activity
s
tarting at once, like stopping some action
s
, sending alarm signals or just trigger
-
i
ng an agent’s p
r
o
act
i
ve
b
e
h
av
i
or.
F
or examp
l
e,
i
n e-mar
k
et app
li
cat

i
on, a se
ll
e
r

agent as an auct
i
oneer may
h
ave t
h
ree react
i
ve
b
e
h
av
i
ors. One may
b
e tr
i
ggere
d

b
y an a
b

ort event of a
b
uyer agent to stop a
ll
transact
i
ons w
i
t
h
t
h
e
b
uyer agent.
T
he second ma
y
be tri
gg
ered b
y
a chan
g
e of a price level of a product in the mar
-
ket to read
j
ust its sellin
g

price for this product. The third ma
y
be tri
gg
ered b
y
a
new biddin
g
request from a bu
y
er a
g
e
nt t
o
a
c
ti
v
at
e
an a
uc
ti
o
n
be
ha
v

i
o
r
.

Proactive part includes the agent’s proactive behaviors. Such behaviors are tas
k

i
nitiative behaviors that do not merely act in response to their environment but are
able to exhibit goal-directed behaviors to
p
erform some intended tasks. Collabora-
t
i
ons w
i
t
h
ot
h
er agents to perform suc
h
tas
k
s are often nee
d
e
d
. An agent may

h
ave
to p
l
ay mu
l
t
i
p
l
e ro
l
es. As a
r
esu
l
t
,
eac
h
ro
l
e-
b
ase
d

b
e
h

av
i
or can
b
e
d
ef
i
ne
d
to per
-
f
orm a spec
i
f
i
c tas
k
. T
h
e “ma
i
n ro
l
e
b
e
h
av

i
or”
i
s a proact
i
ve
b
e
h
av
i
or t
h
at runs
p
er
i
o
di
ca
lly
as a
di
spatc
h
er of ot
h
er ro
l
e-

b
a
s
ed

b
e
h
av
i
ors. In t
h
e e-mar
k
et a
ppli
ca
-
t
i
on, for examp
l
e, a se
ll
er a
g
ent can
b
e
d

ef
in
ed
to
h
ave t
h
e ca
p
a
bili
t
i
es of a
d
vert
i
s-
i
n
g
pro
d
uct pr
i
ces, as we
ll
as auct
i
on

i
n
g
an
d
ne
g
ot
i
at
i
n
g
w
i
t
h

b
u
y
ers. T
h
us,
a buyer agent may have three role-based behaviors: searching for information,
b
idding for products, an
d

n

egotiating with seller agents.
In contrast to the traditional agent
a
rchitectures, our TSAF
h
as the following
t
h
ree
b
enef
i
ts
l
a
b
e
l
e
d
a
,

b,
an
d
c:
(
a) Separate Sensor
y

Part from the Couplin
g
Part
Th
ere are two wa
y
s for an a
g
ent to
l
earn a
b
out
i
ts outs
id
e env
i
ronment. One
i
s to
s
ense t
h
e
dy
nam
i
c env
i

ronment t
h
rou
gh
t
h
e sensor
y
part. T
h
e ot
h
er
i
s to
i
nteract
w
i
t
h
ot
h
er a
g
ents for a part
i
cu
l
ar tas

k
t
h
rou
gh
t
h
e coup
li
n
g
part. Some a
g
ent arc
hi-
tecture put the two parts to
g
ether in on
e

co
mm
u
ni
c
ati
o
n m
odu
l

e

bec
a
use

bo
th
of

them can be re
g
arded as the same t
h
i
n
g
of interactin
g
with
t
h
e

ou
t
s
i
de

wo
rl
d

o
f
a
g
ents. However, we separate the two
p
arts for the followin
g
reasons. First, the
y

ref
l
ect tota
ll
y
di
fferent
b
e
h
av
i
ors w
i
t

h

di
st
in
g
u
i
s
h
e
d

i
ssues, so
i
t
i
s muc
h
c
l
earer to
model them separately. The sensory part
performs the works of periodically perceiv-
t
i
ng t
h
e env

i
ronment for some spec
i
f
i
c
p
arameters an
d

k
eep
i
ng t
h
em
i
n t
h
e
i
nterna
l
sh
are
d

d
ata
b

ase for success
i
ve sta
g
es of
d
ec
i
s
i
on-ma
ki
n
g
or react
i
ons. On t
h
e ot
h
e
r

h
an
d
, an a
g
ent st
ill

faces one or more tas
k
s to
b
e so
l
ve
d
t
h
rou
gh
co
ll
a
b
orat
i
n
g
w
i
t
h

other agents. The coupling part
just performs this work
t
to prov
id

e un
i
f
i
e
d

i
nterfaces
H
.
F
.
Li
e
t al
.