Formal Speciﬁcation of Matchmakers, Front-agents,

and Brokers in Agent Environments using FSP

Amelia B˘adic˘a

and Costin B˘adic˘a

University of Craiova, Business Information Systems Department

A. I. Cuza 13, Craiova, RO-200585, Romania

University of Craiova, Software Engineering Department

Bvd. Decebal 107, Craiova, RO-200440, Romania

Abstract. The aim of the paper is to precisely characterize types of middle-

agents – matchmakers, brokers and front-agents by formally modeling their inter-

actions with requesters and providers. Our approach is based on conceptualizing

these interactions by formal speciﬁcation using FSP process algebra. The main re-

sult is the development of formal speciﬁcation models of middle-agents that help

designers and developers by improving their understanding of available types of

middle-agents (including matchmakers, front-agents and brokers) and enable the

formal analysis of software agent systems that incorporate middle-agents.

1 Introduction

Development of agents that enable dynamic interaction between parties that request and

provide information, services or resources requires a careful analysis and understanding

of their capabilities. Our recent work in this area was focused on i) implementation of

middle-agents for connecting requesters with providers in e-commerce scenarios [2]

and ii) formal modeling of middle-agents with the goal to precisely characterize their

interactions with other agents in the system [3,4].

Connecting requesters with providers is a crucial problem in an agent environment

and its solution requires the use of middle-agents ([5]). Typical use of middle-agents

is encountered in e-commerce. The model agent-based e-commerce system discussed

in [2] uses middle-agents to connect user buyers on the purchasing side with shops on

the selling side in a distributed marketplace. Each user buyer is represented by a Client

agent and each shop is represented by a Shop agent. User buyer submits an order to

the system for purchasing a product via his or her Client agent. Client agent acts as a

Front-agent with respect to connecting the user buyer with an appropriate Shop agent

that provides the requested product. Moreover, Client agent uses a special agent called

Client Information Center – CIC that is responsible for providing information which

shop in the system sells which products. So, it can be easily noticed that CIC is in fact

a Matchmaker with respect to connecting Client agent with an appropriate Shop agent.

In this paper we consider formal models of domain independent interaction pat-

terns between agents involved in intermediation – i.e. we omit in our models i) domain

adic

a A. and B

adic

a C. (2008).

Formal Speciﬁcation of Matchmakers, Front-agents, and Brokers in Agent Environments using FSP.

In Proceedings of the 6th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages 9-18

DOI: 10.5220/0001729100090018

 SciTePress

dependent details of the environment and ii) details of the content languages used for

representing requests, responses, preferences, and capabilities. Thus we assume that

these interaction patterns are a deﬁning characteristic of each type of middle-agent. In

this work we employ our framework ﬁrstly proposed in [3]. This framework is utilizing

the ﬁnite state process algebra – FSP ([11]) modeling language.

We start in section 2 with an overview of middle-agents focusing on Matchmaker,

Front-agent, and Broker. In section 3 we introduce FSP and some guidelines of model-

ing agent interactions with FSP. Then we present detailed FSP models of Matchmaker,

Front-agent, and Broker middle-agents. We follow in section 4 with experimental eval-

uation of the models. The last part of the paper contains related work and conclusions.

2 Background on Middle-Agents

The starting point of our work is the classiﬁcation of middle-agents introduced in sem-

inal work [5]. Based on assumptions about what it is initially known by the requesters,

middle-agent, and providers about requester preferences and provider capabilities, au-

thors of [5] proposed 9 types of middle-agents: Broadcaster, Matchmaker, Front-agent,

Anonymizer, Broker, Recommender, Blackboard, Introducer, and Arbitrator. Based on

literature overview (see survey from [10]) we noticed that frequently utilized middle-

agents for connecting provider and requester agents are Matchmaker, Front-agent, and

Broker. Additionally, quoting [10], observe that “notions of middle-agents, matchmak-

ers, brokers [...] are used freely in the literature [...] without necessarily being clearly

deﬁned”. Therefore in this paper we focused on improving this state-of-affair by pre-

senting and discussing formal models of Matchmaker, Front-agent, and Broker middle-

agents with the goal of highlighting their similarities and differences. Matchmaker. A

Matchmaker middle-agent assumes that requester preferences are initially known only

to the requester, while provider capabilities are initially known to all interaction partici-

pants. This means that a provider will haveto advertise its capabilities with Matchmaker

and Matchmaker has responsibility to match a request with registered capabilities ad-

vertisements. However, the fact that provider capabilities are initially known also by

the requester means that the result of the matching (i.e set of matching providers) is re-

turned by Matchmaker to requester (so provider capabilities become thus known to the

requester), and the choice of the matching provider is the responsibility of the requester.

Consequently the transaction is not intermediated by Matchmaker, as would be the case

for example with a Broker or Front-agent.

Front-agent assumes that requester preferences are initially known only to the re-

quester, while provider capabilities are initially known both to provider and middle-

agent. This means that a provider will have to advertise its capabilities with Front-agent

and Front-agent is responsible to match a request with registered capabilities advertise-

ments. Additionally, as the provider capabilities are not initially known to the requester,

Front-agent also has the responsibility of intermediating the transaction between the re-

quester and the matching provider (this is why often this type of middle-agent is called

Broker rather than Front-agent; in our opinion a true Broker is different, see below).

Broker assumes that requester preferences are initially known only to the requester

and the middle-agent and provider capabilities are initially known only to the provider

and the middle-agent. The crucial point is that, however, requester preferences are not

initially knownto the provider and provider capabilities are not initially knownto the re-

quester. This means that a Broker will truly intermediate transactions between providers

and requesters in both directions: i) if a requester submits a request either it cannot be

matched and it is registered with the Broker or it is matched with a provider capa-

bility and then transaction is intermediated by the Broker, and ii) if a provider adver-

tises a capability then capability is registered with the Broker and also capability is

matched against registered requests; neither match is found and nothing more happens

or matches are found and corresponding transactions are intermediated by the Broker.

3 FSP Models

Overview of FSP. FSP is an algebraic speciﬁcation technique of concurrent and coop-

erating processes that allows a compact representation of a ﬁnite state labeled transition

system (LTS hereafter), rather than describing it as a list of states and transitions.

A FSP model consists of a ﬁnite set of sequential and/or composite process deﬁ-

nitions. Additionally, a sequential process deﬁnition consists of a sequence of one or

more deﬁnitions of local processes. A process deﬁnition consists of a process name

associated to a process term. FSP uses a rich set of constructs for process terms (see

[11] for details). For the purpose of this paper we are using the following constructs:

action preﬁx (a → P), nondeterministic choice (P|Q), and process alphabet extension

(P + {a

, . . . , a

}) for sequential process terms and parallel composition (P||Q) and re-

labeling (P/{new

/old

, . . . , new

/old

}) for composite process terms. The modeling

that we propose here follows the general guidelines outlined in [3]. Brieﬂy: i) agents

are modeled as FSP processes and a multi-agent system is modeled as a parallel com-

position of processes; ii) sets R of requesters and P of providers are assumed to be

initially given and agent requests and replies are indexed with requester and/or provider

identiﬁers; iii) matching operation is modeled as a relation M ⊆ R × P.

We assume that our system contains providers, requesters and a middle-agent. So

in our models we have Provider, Requester and middle-agent FSP processes. Addi-

tionally we assume that Provider offers are reproducible and Requester requests are

non-reproducible (see [3] for a more detailed discussion on this topic).

Matchmaker Middle-Agent in FSP. The block diagram and the FSP speciﬁcation of a

system with requesters, providers and a Matchmaker are shown in ﬁgure 1.

Provider agent registers its capability offer (action of fer) with the Matchmaker

and then enters a loop where it receives requests from Requester agents via action

receive

request and processes and replies accordingly via action send reply. Note that

a Provider can also withdraw a registered capability offer and while its capability is not

registered it always refuses to serve a request (action refuse request).

Requester agent submits a request to the Matchmaker (action send request) and

then waits for a reply. The Matchmaker replies with a set of matching providers (ac-

tion tell with argument M(r) ∩ P representing the set of matches; here P is the set of

registered providers and M(r) is the set of matching providers). Next Requester has the

option to choose what provider from set P to contact for performing the service (ac-

Requester(r) Matchmaker

Provider(p)

request(r)

tell(r,P)

offer(p)

send_

req_to_provider

(

)

refuse_request(r,p)

withdraw(p)

receive_reply(r,p)

Provider = (o f fer → ProcessRequest |

receive

request → re fuse request → Provider),

ProcessRequest = (receive

request → send reply → ProcessRequest |

withdraw → Provider).

Requester = (send

request → WaitReply),

WaitReply = (tell(P ⊆ P) → if P , ∅ then ContactProvider(P) else Requester),

ContactProvider(P ⊆ P) = (while P , ∅ send

request to provider(p ∈ P) →

{receive

reply(p), refuse request(p)} → Requester).

Matchmaker = Matchmaker(∅),

Matchmaker(P ⊆ P) = (request(r ∈ R) → MatchReq(r, P) |

of fer(p ∈ P \ P) → Matchmaker(P ∪ {p}) |

withdraw(p ∈ P) → Matchmaker(P \ {p})),

MatchReq(r ∈ R, P ⊆ P) = (tell(r, M(r) ∩ P) → Matchmaker(P)) + {tell(r

′

∈ R, P

′

⊆ P)}.

Requester(r ∈ R) = Requester/{request(r)/send

request, tell(r, P ⊆ P)/tell(P),

send

request to provider(r, p ∈ P)/send request to provider(p),

receive

reply(r, p ∈ P)/receive reply(p), re fuse request(r, p ∈ P)/refuse request(p)}.

Provider(p ∈ P) = Provider/{o f fer(p)/o f fer,

send

request to provider(r ∈ R, p)/receive request,

receive

reply(r ∈ R, p)/send reply, refuse reply(r ∈ R, p)/re fuse reply}.

System = Matchmaker || (||

r∈R

Requester(r)) || (||

p∈P

Provider(p)).

Fig.1. System with Matchmaker middle-agent.

tion send

request to provider with argument p ∈ P representing the chosen provider).

Finally, Requester waits for a reply from the contacted provider (action receive reply).

Matchmaker agent registers and deregisters Provider offers and answers Requester

requests for matching offers. Matchmaker informs Requester about available registered

offers (action tell). Note that Requester is responsible to choose an appropriate match-

ing offer from the available matching offers (action send

request to pro- vider). This

complicates a bit Requester behavior as compared with Front-agent and Broker cases.

Special care is taken to accurately model agent communication using FSP synchro-

nization. Matchmaker model requires alphabet extension (construct {tell(r

′

∈ R, P

′

⊆

P)} in ﬁgure 1) to model correctly communicationbetween Matchmaker and Requester.

A critical situation may occur when a matching offer is found but the matching

Provider chooses to cancel its offer by deregistering it with the Matchmaker before

it is actually contacted by the Requester. This ability of the Provider is modeled with

action re fuse

request. Note that this situation cannot occur with the Front-agent and

Broker (remember that both Front-agent and Broker intermediate the request on behalf

of the Requester) so we did not have to model this ability of the Provider in those cases.

Requester(r) Front-agent

Provider(p)

request(r)

success(r)

offer(p)

fragent_req (p)

fragent

_reply(r,p)

fail(r)

withdraw(p)

Provider = (o f fer → ProcessRequest),

ProcessRequest = (receive

request → send reply → ProcessRequest |

withdraw → Provider).

Requester = (send

request → WaitReply),

WaitReply = ({sucess, fail} → Requester).

Frontagent = Frontagent(∅),

Frontagent(P) = (request(r ∈ R) → ResolveReq(r, P) |

of fer(p ∈ P \ P) → Frontagent(P ∪ {p}) |

withdraw(p ∈ P) → Frontagent(P \ {p})),

ResolveReq(r, P) = (if M(r) ∩ P = ∅ then fail(r) → Frontagent(P)

else ContactProvider(r, M(r) ∩ P, P)

ContactProvider(r, P

′

, P) = (while P

′

, ∅ fragent

req(p ∈ P

′

) → fragent reply(p) →

success(r) → Frontagent(P)).

Requester(r ∈ R) = Requester/{request(r)/send

request, fail(r)/ fail, success(r)/success}.

Provider(p ∈ P) = Provider/{o f fer(p)/o f fer, fragent

req(p)/receive request, fragent reply(p)/send reply,

withdraw(p)/withdraw}.

System = Frontagent || (||

r∈R

Requester(r)) || (||

p∈P

Provider(p)).

Fig.2. System with Front-agent middle-agent.

Front-agent Middle-Agent in FSP. The block diagram and the FSP speciﬁcation of a

system composed of requesters, providers and a Front-agent are shown in ﬁgure 2.

Provider agent is similar to Matchmaker case. Requester agent is simpler than

Matchmaker case: it submits a request to Front-agent (action send

request) and then

waits for Front-agent to either resolve that request (action success) or fail (action f ail).

Front-agent agent processes requests from Requester agents and registers offers

from Provider agents. Note that, differently from the Matchmaker, Front-agent has the

responsibility to choose an appropriate matching provider from the available match-

ing providers M(r) ∩ P (here P is the set of registered providers and M(r) is the set

of matching providers) using action fragent

request and to resolve the request (ac-

tion fragent request). Finally the result is passed to the Requester agent using action

success. In conclusion, the actual Provider that fulﬁls the request for the Requester on

behalf of the Front-agent is hidden from the Requester that issued the request.

Broker Middle-Agent in FSP. The block diagram and the FSP speciﬁcation of a system

composed of requesters, providers and a Front-agent are shown in ﬁgure 2. Provider

and Requester agents are similar to the Front-agent case.

Broker processes requests from Requesters and processes and registers offers from

Providers. If arequest can be served based on available matching offers then Broker

behaves similarly with Front-agent. Differently from Front-agent, if a request cannot be

Requester(r) Broker

Provider(p)

request(r)

success(r)

offer(p)

broker_req (p)

broker_reply(r,p)

fail(r)

withdraw(p)

Provider = (o f fer → ProcessRequest),

ProcessRequest = (receive

request → send reply → ProcessRequest |

withdraw → Provider).

Requester = (send

request → WaitReply),

WaitReply = ({sucess, f ail} → Requester).

Broker = Broker(∅, ∅),

Broker(P, R) = (request(r ∈ R \ R) → ResolveReq(r, R, P) |

of fer(p ∈ P \ P) → ResolveOf f (p, R, P) |

withdraw(p ∈ P) → Broker(R, P \ {p}) |

while R , ∅ fail(r ∈ R) → Broker(R \ {r}, P)),

ResolveReq(r, R, P) = (if M(r) ∩ P = ∅ then Broker(R ∪ {r}, P)

else ContactProviderReq(r, R, M(r) ∩ P, P)),

ContactProviderReq(r, R, P

′

, P) = (while P

′

, ∅ broker

req(p ∈ P

′

) → broker reply(p) → success(r) → Broker(R, P)),

ResolveOf f(p, R, P) = (if M

−1

(p) ∩ R = ∅ then Broker(R, P ∪ {p})

else ContactProviderO f f(p, M

−1

(p) ∩ R, R, P)),

ContactProviderO f f(p, R

′

, R, P) = (if R

′

, ∅ then broker

req(p) →

broker

reply(p) → success(r ∈ R

′

) → ContactProviderOf f(p, R

′

\ {r}, R \ {r}, P)

else Broker(R, P)).

Requester(r ∈ R) = Requester/{request(r)/send

request, fail(r)/ fail, success(r)/success}.

Provider(p ∈ P) = Provider/{o f fer(p)/o f fer, fragent

req(p)/receive request,

fragent

reply(p)/send reply, withdraw(p)/withdraw}.

System = Broker || (||

r∈R

Requester(r)) || (||

p∈P

Provider(p)).

Fig.3. System with Broker middle-agent.

served based on currently registered offers then, rather than reporting failure, the request

is recorded until: i) either a new matching offer is registered with the Broker or ii) the

request is deemed failed. Note that when a new offer is registered the Broker determines

the set of recorded (i.e. not yet served) matching requests – M

−1

(p) ∩ R (M

−1

(p) is the

set of matching requesters and R is the set of recorded requesters) and serves them using

the matching provider p – ContactProviderOf f sub-process in ﬁgure 3.

System Properties. A basic desirable property of systems with middle-agents is that

they are free of deadlocks. The result is formally stated as follows.

Proposition 1. The systems with Matchmaker, Front-agent and Broker shown in ﬁg-

ures 1, 2 and 3 are deadlock free.

Proof. We consider the Matchmaker system proof (other proofs follow the pattern).

Let us consider an arbitrary system state S. As the system is a parallel composition

of processes, state S is composed of sub-states corresponding to the Matchmaker and

to each of the Provider an Requester processes. Any progress from S will be caused

by an interaction between two processes: Matchmaker with a Provider, Matchmaker

with a Requester or a Requester with a Provider. Note that Matchmaker can be in one

of two states: i) Matchmaker(P) with P ⊆ P; ii) MatchReq(r, P) with r ∈ R and P ⊆ P.

In the ﬁrst case it means that Matchmaker ﬁnalized to process a request and it

is waiting for a new one. If a new request is available we are done. If a Provider is

available to register/deregister a capability offer, we are are again done. Otherwise it

means that all requesters submitted requests to providers and wait for service. In this

case we pick randomly a pair Requester(r) and Provider(p) with r ∈ R and p ∈ P and

system will proceed with interaction between Requester(r) and Provider(p).

In the second case progress will occur through interaction between Matchmaker

and Requester(r), as Requester(r) is deﬁnitely in state WaitReply.

4 Experimental Results

We conducted a series of experiments to check correctness of our models introduced in

section 3. As a side effect we have also recorded the size of the state model expressed as

number of states and transitions, depending on the number of requesters and providers.

Experimental Setup. Firstly we had to express the general models shown in ﬁgures 1,

2 and 3 using the FSP language supported by the LTSA tool [11]. The main difﬁculty

is encoding of processes indexed with sets in the language supported by LTSA.

Assuming that S is a set with n elements, mapping of processes indexed with sets

and/or set elements to the FSP notation supported by LTSA follows the guidelines: i)

an index s ∈ S is encoded as [s]; ii) an index S ⊆ S is encoded as [s

] . . . [s

] s.t.

= 1 if i ∈ S and s

= 0 if i < S . For example ResolveReq(2, {1}, {1, 3}) is mapped to

ResolveReq[2][1][0][1][0][1] and tell(1, {2, 3}) is mapped to

tell[1][0][1][1].

Note that a mapping can be deﬁned such that the size of resulting FSP speciﬁcation

is linear in the product of number of providers with number of requesters

. This is an

important desiderata to make the resulting FSP speciﬁcation of a practical value.

Proposition 2. Let m = |R| and n = |P|. The systems with Matchmaker, Front-agent

and Broker shown in ﬁgures 1, 2 and 3 can be mapped to the FSP language supported

by LTSA tool such that size of resulting speciﬁcation is O(m × n).

Proof. First note that mapping of set indexed names of processes and actions produces

new names of size linear with m and n..

Second, application of the following mapping rules produces parts of FSP speciﬁ-

cation that clearly have a size O(m × n).

If Proc(S ⊆ S) is a set indexed processes and |S| = n then the construct:

Proc(S ⊆ S) = (while S , ∅ action(s ∈ S) . . .)

is mapped to (here assuming n = 3):

Do not confuse size of FSP speciﬁcation (i.e. size of FSP code measured for example as the

number of nodes of its syntax tree) with size of LTS corresponding to this speciﬁcation.

Table 1. LTS size of the system with Matchmaker middle-agent.

# requesters # providers # states # transitions # states after minimization

2 3 608 2272 376

3 4 3392 14720 2064

4 5 166400 1010176 N/A

5 6 > 1000000 > 7000000 N/A

Proc[s1:0..1][s2:0..1][s3:0..1] = (

while s1 == 1 action[1] ... |

while s2 == 1 action[2] ... |

while s3 == 1 action[3] ...)

Note that the size of the resulted speciﬁcation is O(n).

If Proc

(S ⊆ S), i = 1, 2 are set indexed processes and |S| = n then the construct:

Proc

(S ⊆ S) = (while S , ∅ Proc

(S) . . .)

is mapped to (here assuming n = 3):

Proc1[s1:0..1][s2:0..1][s3:0..1] = (

if s1 == 1 || s2 == 1 || s3 == 1

then Proc2[s1:0..1][s2:0..1][s2:0..1] ...)

Note that the size of the resulted speciﬁcation is O(n).

If |S

| = m and |S

| = n are sets, M ⊆ S

× S

is a relation then the construct:

Proc

(s ∈ S

, S ⊆ S

) = (if M(s) ∩ S = ∅ then . . . else Proc

(M)s) ∩ S). . .)

is mapped to (here assuming m = 2, n = 3 and M = {(1, 2), (1, 3), (2, 1), (2, 2)}):

Proc1[s:1..2][s1:0..1][s2:0..1][s3:0..1] = (

if s == 1 then

if s2 == 0 && s3 == 0 then ...

else Proc2[0][s2][s3] ...

else if s == 2 then ...

if s1 == 0 && s2 == 0 then ...

else Proc2[s1][s2][0] ...)

Note that the size of the resulted speciﬁcation is O(m × n).

Results and Discussion. In the experiments we considered 3 systems composed of: i) n

requesters and n + 1 providers, 2 ≤ n ≤ 5; ii) 1 middle-agent per system (Matchmaker,

Front-agent and respectively Broker), and iii) the matching relation M = {(i, i + 1)|1 ≤

i ≤ n} ∪ {(i, i + 2)|1 ≤ i ≤ n − 1} ∪ {n, 1)}

We utilized LTSA tool to analyze the resulting FSP models of systems with Match-

maker, Front-agent and Broker middle-agents. All the models are free of deadlocks

(thus conﬁrming theoretical results). Sizes in terms of number of states and transitions

of their corresponding labeled transition systems are presented in tables 1, 2 and 3.

FSP models used in experiments are available at http://software.ucv.ro/

badica_

costin/fsp/msvveis08_models.zip

Table 2. LTS size of the system with Front-agent middle-agent.

# requesters # providers # states # transitions # states after minimization

2 3 56 92 52

3 4 160 268 148

4 5 416 704 384

5 6 1024 1744 944

Table 3. LTS size of the system with Broker middle-agent.

# requesters # providers # states # transitions # states after minimization

2 3 293 464 281

3 4 1788 2997 1718

5 Related Work

Middle-agents were recently put forward in [7] in the context of applications of agents

in e-commerce. [7] covers in some detail Matchmaker, Broker, Broadcaster and Rec-

ommender with a focus on interaction protocols and languages for describing provider

capabilities. However, while Matchmaker description ﬁts within our model, note that

Broker described by [7] actually corresponds to our model of a Front-agent.

Our literature review indicates that while there is a growing interest in the subject

of ”middle-agents”, only a few papers address the problem of a concise deﬁnition of

middle-agents in terms of their interaction capabilities.

For example [1] suggests the use of LTSs for modeling agent types without provid-

ing deﬁnitions of middle-agents. [10] shows only models of matchmakers and brokers

using input/output automata (following initial proposal in [14]), while [9] informally

describes interactions of middle-agents with requesters and providers as sequences of

message exchanges presented in natural language. Rather, many references to middle-

agents focus in more or less detail on various applications and systems that use different

types of middle-agents, most often brokers and/or matchmakers (see overview in [10])

and highlighting implementation and/or performance issues.

Some recent works propose the use of process algebras for concisely modeling

middle-agent interactions. Paper [3] introduces a general framework for FSP modeling

of middle-agents and shows how this framework can be used to model a Recommender

agent. Using the same idea, paper [4] presents a model of an Arbitrator middle-agent

for coordination of participants in single-item English auctions. Our present work is an

extension of [3, 4] for modeling Matchmaker, Front-agent and Broker middle-agents,

including both theoretical and experimental results.

Our “agents-as-processes” modeling approach is not entirely new. Paper [6] pro-

poses the use of π-calculus ([12]) and shows models of a prototype agent system LO-

GOS for an unattended grounds operation-centerusing a fault resolution scenario. How-

ever, while this paper shows how to use a software tool for checking the proposed spec-

iﬁcations, it does not provide any experimental results – only general guidelines are

given. Paper [13] focuses also on the LOGOS agent system, but using a CSP [8]. While

this paper discusses some beneﬁts of the method (detecting race conditions, message

omissions, and better understanding of the system) it still does not provide any experi-

mental results and neither discusses the practical problems encountered.

6 Conclusions and Future Work

In this paper we applied a formal framework based on FSP process algebra for mod-

eling a system that contains requesters, providers and middle-agents. We considered

three types of middle-agents: Matchmaker, Front-agent, and Broker. For each system

we checked the resulting model with the help of LTSA analysis tool.

We also identiﬁed some paths for continuing this research: i) modeling of more

complex systems containing more types of middle-agents; ii) introduction and analysis

of qualitative properties of agent systems.

References

1. Alagar, V., Holliday, J.: Agent types and their formal descriptions. Technical Report COEN-

2002-09-19A, Santa Clara University. Computer Engineering Department, (2002).

2. B˘adic˘a, C., Ganzha, M., Paprzycki, M.: Developing a Model Agent-based E-Commerce Sys-

tem. In: E-Service Intelligence: Methodologies, Technologies and Applications, Studies in

Computational Intelligence 37, Springer, (2007) 555–578.

3. B˘adic˘a, A., B˘adic˘a, C., Lit¸oiu, L.: Middle-Agents Interactions as Finite State Processes:

Overview and Example: In Proc.16

IEEE International Workshops on Enabling Technolo-

gies: Infrastructure for Collaborative Enterprises (WETICE 2007), (2007) 12–17.

4. B˘adic˘a, A., B˘adic˘a, C.: Formal modeling of agent-based english auctions using ﬁnite state

process algebra. In: N. Nguyen et al. (Eds.): Agent and Multi-Agent Systems: Technologies

and Applications. Proc. KES-AMSTA’2007, LNAI 4496, Springer (2007) 248–257.

5. Decker, K., Sycara, K. P., and Williamson, M.: Middle-agents for the internet. In: Proceed-

ings of the 15

Int.Joint Conf.on Artif.Intel. IJCAI’97, vol.1, Morgan Kaufmann, (1997)

578–583.

6. Esterline, A., Rorie, T., and Homaifar, A.: A Process-Algebraic Agent Abstraction. In: Rouff,

C.A. et al. (Eds.): Agent Technology from a Formal Perspective, NASA Monographs in Sys-

tems and Software Engineering, Springer (2006) 88–137.

7. Fasli, M.: Agent Technology For E-Commerce. Wiley, (2007).

8. Hoare, C.A.R.: Communicating Sequential Processes. Prentice Hall International Series in

Computer Science, Hemel Hempstead. (1985).

9. Hristozova, M., Lister, K., and Sterling, L.: Middle-agents – towards theoretical standardiza-

tion. In: I. J. Timm, M. Berger, S. Poslad, and S. Kirn (Eds.): Proc. of the Int. Workshop on

Multi-Agent Interoperability – MAI’02. 25

German Conference on Artif.Intel. (KI’2002),

http://www.informatik.uni-bremen.de/agki/www/astap02/mai02-ws.pdf, (2002) 65–80.

10. Klusch. M., Sycara, K.P.: Brokering and matchmaking for coordination of agent societies: A

survey. In Omicini, A., Zambonelli, F., Klusch, M., and Tolksdorf, R. (Eds.): Coordination

of Internet Agents. Models, Technologies, and Applications, Springer (2001) 197–224.

11. Magee, J., Kramer, J.: Concurrency. State Models and Java Programs (2

ed.). John Wiley

& Sons (2006).

12. Milner, R. Communicating and Mobile Systems: The π-calculus, Cambridge University

Press, Cambridge. (1999).

13. Rouff, C., Rash, J., Hinchey, M., and Truszkowski, W.: Formal Methods at NASA Goddard

Space Flight Center. In: Rouff, C.A. et al. (Eds.): Agent Technology from a Formal Perspec-

tive, NASA Monographs in Systems and Software Engineering, Springer (2006) 287–309.

14. Wong, H.C., Sycara, K.: A taxonomy of middle-agents for the internet. In Proceedings of the

International Conference on MultiAgent Systems (ICMAS-2000), Washington, DC, USA,

IEEE Computer Society. (2000) 465–466. An extended version of the paper is available at

http://www.cs.cmu.edu/

softagents/papers/ExtMiddleAgentsICMAS.pdf.