an infrastructure for agent-based systems: an interagent approach

An Infrastructure for Agent-Based Systems:An Interagent ApproachFrancisco J. Martın,* Enric Plaza,† Juan A. Rodrıguez-Aguilar*´ ´IIIA ] Artificial Intelligence Research Institute, CSIC ] Spanish Council forScientific Research, Campus UAB, 08193 Bellaterra, Catalonia, Spain

We introduce an infrastructure for easing construction of agent-based systems. We arguethat such infrastructure constitutes a convenient solution for releasing agent developersfrom cumbersome interaction issues inherent to any agent-based system, and thereforefor helping them concentrate on the domain-dependent agents’ logics issues. Ourproposal relies upon two fundamental elements: con¨ersation protocols, coordinationpatterns that impose a set of rules on communicative acts uttered by agents participating

Ž .in a conversation what can be said, to whom, and when , and interagents, autonomoussoftware agents that mediate the interaction between each agent and the agent societywherein this is situated. Interagents employ conversation protocols for mediating conver-sations among agents. Thus management of conversation protocols is presented as raisond’etre of interagents. We also introduce JIM, our java-based implementation of aˆgeneral-purpose interagent. On one hand, we show how it handles conversation protocolsin practice, and on the other hand, how it has been endowed with the capability ofdealing with agent interaction at different levels by means of the SHIP protocol. Finally,we illustrate the use of interagents by explaining several roles that they play in Fishmar-ket, an agent-mediated electronic auction market. Q 2000 John Wiley & Sons, Inc.

I. INTRODUCTION

Agent-based systems provide a way of conceptualizing sophisticated soft-Žware applications that face problems involving multiple and logically and often

.spatially distributed sources of knowledge. In this way, they can be thought ofas computational systems composed of several agents that interact with oneanother to solve complex tasks beyond the capabilities of an individual agent.

*e-mail: martin,[email protected]†Author to whom correspondence should be addressed. e-mail: [email protected] grant sponsor: Spanish CICYT.Contract grant number: Project SMASH, TIC96-1038-C04001.Contract grant sponsor: DGR-CIRIT.Contract grant numbers: FI-PG196-8490, FI-DTr96-8472.

Ž .INTERNATIONAL JOURNAL OF INTELLIGENT SYSTEMS, VOL. 15, 217]240 2000Q 2000 John Wiley & Sons, Inc.

´ ´MARTIN, PLAZA, AND RODRIGUEZ-AGUILAR218

The development of agent-based systems can be regarded as a processcomposed of two well-defined, separate stages concerning, respectively:

v Žthe agents’ logics: from the agents’ inner behavior knowledge representation,.reasoning, learning, etc. to the agents’ social behavior responsible for high-level

Žcoordination tasks the selection, ordering, and communication of the results of1,2.the agent activities os that an agent works effectively in a group setting .

v the agents’ interactions taking place at several levels: content leël, concerned withthe information content communicated among agents; intentional leël, expressingthe intentions of agents’ utterances, usually as performatives of an agent commu-

Ž .nication language ACL , e.g., knowledge query and manipulation languageŽ . Ž .KQML , foundation for intelligent physical agents FIPA ACL, etc.; conërsa-tional leël, concerned with the conventions shared between agents when ex-changing utterances; transport leël, concerned with mechanisms for the transport

wof utterances; and connection leël, contemplating network protocols transmis-Ž .sion control protocolrinternet protocol TCPrIP , hypertext transfer protocol

Ž .HTTP , etc.

Notice that nowadays a large amount of time during the development ofagent-based systems is devoted to the management of the aforementionedtime-consuming, complex agents’ interactions. Since most of these appear to bedomain-independent, it would be desirable to devise general solutions at thisdevelopment stage that can be subsequently reused for the deployment of othermultiagent systems. In this manner, and very importantly, agent engineers couldexclusively concentrate on the domain-dependent agents’ logics issues. Addition-ally, for this purpose, they can largely benefit from their previous experiences inthe application of artificial intelligence techniques.

In this work we propose an infrastructure that eases the construction ofagent-based systems by taking charge of the cumbersome interaction issuesinherent to these types of systems. Such infrastructure relies upon two funda-ment al elements: conërsation protocols, coordination patterns that impose a setof rules on the communicative acts uttered by the agents participating in a

Ž .conversation what can be said, to whom, and when , and interagents, au-tonomous software agents that mediate the interaction between each agent andthe agent society wherein this is situated. Very importantly, interagents employconversation protocols for mediating conversations among agents, and so themanagement of conversation protocols is in fact their raison d’etre.ˆ

In our infrastructure, interagents constitute the unique means throughŽ .which agents interact within a multiagent scenario see Fig. 1 . Thus, as a rule,

agents’ external behavior is managed by interagents, while their individual logic,knowledge, reasoning, learning, etc. are internal to agents.

We have materialized the conceptualization of interagents through thedesign and development of JIM: a java-based implementation of a general-pur-pose interagent capable of managing conversation protocols and also capable ofdealing with agent interaction at different levels. JIM has been successfully

Ž .applied in the development of Fishmarket FM , our current implementation ofan agent-mediated electronic auction market.

INFRASTRUCTURE FOR AGENT-BASED SYSTEMS 219

Figure 1. Interagents conform the infrastructure of the agents composing a multiagentsystem. This figure shows the Fishmarket, an electronic auction house where interactions

Ž .among agents trading agents and market intermediaries take place through theircorresponding interagents.

The other sections of this article are organized as follows. Section IIprovides an overview of our infrastructure by explaining the basics of bothconversation protocols and interagents, and introduces an example of multia-gent conversation extracted from FM, which in turn is explained in depth inSection V. Next, Section III explains in-depth conversation protocols. We startintroducing their conceptual and formal models, followed by a further analysisconcerning the properties that they must exhibit to ensure sound conversations.Furthermore, the way of negotiating, instantiating, and employing conversationprotocols are also presented. Section IV sketches out JIM along with the

Ž .extensible and hierarchical interaction protocol SHIP protocol that it employsto handle agent interaction at different levels. Section V illustrates the valuableuse of interagents in the development of FM, an actual agent-based system.Finally, Section VI analyzes which features distinguish our approach fromrelated approaches, whereas Section VII presents some final remarks.

II. AN OVERVIEW OF INTERAGENTS

In this work, we view conversations as the means of representing theconventions adopted by agents when interacting through the exchange ofutterances3,4}utterance suggests human speech or some analog to speech, inwhich the message between sender and addressee conveys information aboutthe sender.’’5 More precisely, such conventions define the legal sequence ofutterances that can be exchanged among the agents engaged in conversation:what can be said, to whom, and when. Therefore, con¨ersation protocols arecoordination patterns that constrain the sequencing of utterances during aconversation.


Interagents mediate the interaction between an agent and the agent societywherein this is situated. As explained in Section III, the main task of aninteragent is the management of conversation protocols. Here we differentiatetwo roles for the agents interacting with an interagent: customer, played by theagent exploiting and benefiting from the services offered by the interagent; andowner, played by the agent endowed with the capability of dynamically establish-ing the policies that determine the interagent’s behavior. Needless to say that anagent can possibly play both roles at the same time. Moreover, several owners

Ž .can even share their property collecti e ownership , whereas several customersŽ .can make use of the same interagent collecti e leasing .

In what follows we provide a detailed account of the full functionality ofinteragents}mostly from the point of view of customers}to illustrate how theyundertake conversation management. An interagent is responsible for postingutterances of its customer to the corresponding addressee and for collecting theutterances that other agents address to its customer. This utterance managementabstracts customers from the details concerning the agent communicationlanguage and the network protocol. Each interagent owns a collection of

Ž .relevant conversation protocols CP used for managing its customer conversa-tions. When its customer intends to start a new conversation with another agentthe interagent instantiates the corresponding conversation protocol. Once theconversation starts, the interagent becomes responsible for ensuring that theexchange of utterances conforms to the CP specification.

Before setting up any conversation the interagent must perform a CPnegotiation process with the interagent of the addressee agent. The goal of CPnegotiation is to reach an agreement with respect to the conversation protocol

Ž .to be used see III.F . Moreover, before starting a conversation, the interagentperforms a CP ¨erification process. This process checks whether the CP to be

Žused verifies the necessary conditions liveliness, termination, and deadlock, and.race condition free for guaranteeing the correct evolution of an interaction.

Finally, an interagent allows its customer to hold several conversations at thesame time. This capability for multiple con¨ersations is important because,although in the paper we consider only conversations with two participantsŽ .dialogues , conversations with any number of participants are built as a collec-tion of simultaneous CP instances. In other words, the agent views a conversa-tion as involving a participants while its interagent views such conversation as acollection of simultaneous dialogues represented as multiple CP instances.

Next we introduce an example of multiagent conversation extracted fromFM,6,7 an agent-mediated electronic market that serves to illustrate both the useand functionality of interagents. FM is an electronic auction house based on the

Ž .traditional fish market auctions in which trading buyer and seller heteroge-Ž .neous human and software agents can trade. The main activity within FM, the

auctioning of goods, is governed by the auctioneer who makes use of theŽ .so-called downward bidding protocol DBP . When the auctioneer opens a new

bidding round to auction a good among a group of agents, he starts quotingoffers downward from the chosen good’s starting price. For each price called,

Ž .three situations might arise during the open round: i several buyers submittheir bids at the current price. In this case, a collision comes about, the good is


not sold to any buyer, and the auctioneer restarts the round at a higher price;Ž .ii only one buyer submits a bid at the current price. The good is sold to thisbuyer whenever his credit can support his bid. Whenever there is an unsup-ported bid the round is restarted by the auctioneer at a higher price, theunsuccessful bidder is punished with a fine, and he is expelled out from

Ž .the auction room unless such fine is paid off; and iii no buyer submits a bid atthe current price. If the reserve price has not been reached yet, the auctioneerquotes a new price which is obtained by decreasing the current price accordingto the price step. If the reserve price is reached, the auctioneer declares thegood withdrawn and closes the round.

The conventions that buyer agents have to comply with when interactingwith the auctioneer during a bidding round are represented by means of aconversation protocol managed by the so-called trading interagents. These areowned by the institution, the auction house, but used by trading agents. Sec-tion V provides a more thorough discussion about the role played by interagentsin FM.

III. CONVERSATION PROTOCOLS

Ž .A conversation protocol CP defines a class of legal sequences of utter-ances that can be exchanged between two agents holding a conversation. We

Ž .model an implement a CP as a special type of pushdown transducer PDT ,Ž .which can be seen in turn as a combination of a finite-state transducer FST

Ž .and a pushdown automaton PDA :

v Ž .An FST is simply a finite-state automaton FSA that deals with two tapes. Tospecify an FST, it suffices to augment the FSA notation so that labels on arcs candenote pairs of symbols.8

v A PDA is composed of an input stream and a control mechanism}like an FSA}along with a stack on which data can be stored for later recall.9,10

Therefore, a PDT is essentially a pushdown automaton that deals with twotapes. A PDA can be associated to a PDT by considering the pairs of symbols onthe arcs as symbols of a PDA. The choice of PDTs as the mechanism formodeling CPs is motivated by several reasons. First, analogously to otherfinite-state devices a few fundamental theoretical bases make PDTs very flexi-ble, powerful, and efficient.8 They have been largely used in a variety of domainssuch as pattern matching, speech recognition, cryptographic techniques, datacompression techniques, operating system verification, etc. They offer a straight-forward mapping from specification to implementation. The use of pairs of

Ž . Žsymbols permits labeling arcs with prd pairs where p stands for a performa-.tive, and d stands for a predicate . This adds expressiveness to the representa-

tion of agent conversations. PDTs, unlike other finite-state devices, allow us tostore, and subsequently retrieve, the contextual information of ongoing conver-sations.

In this section we explain CPs in-depth, whose management is the raisond’etre of interagents. We start introducing a conceptual model of CPs. Next, theˆ


formalism underpinning our model is presented to provide the foundations for afurther analysis concerning the properties that CPs must exhibit. Finally, theway of negotiating, instantiating, and employing CPs is also explained.

A. Conceptual Model

Ž .Conceptually, we decompose a CP into the following elements see Fig. 3 :a finite-state control, an input list, a pushdown list, and a finite set of transitions.

First, the finite-state control contains the set of states representing thecommunication state of the interagent’s customer during an ongoing conversa-tion. We distinguish several states based on the communicative actions that theyallow: send, when only the utterance of performatives is permitted, recei e, whenthese can be only received, and mixed, when both the utterance and receptionare feasible.

The utterances heard by an interagent during each conversation are storedinto an input list. In fact, this input list is logically divided into two sublists: onefor keeping the utterances’ performatives, and another one for storing their

Ž .predicates. It is continuously traversed by the interagent in search of a prdpair which can produce a transition in the finite-state control. Notice that thecontinuous traversing the input list differs from the one employed by classic

ŽFSAs whose read only input tapes are traversed from left to right or the other.way around .

Let us consider a particular CP related to an ongoing conversation. We saythat an utterance is admitted when it is heard by the interagent and subse-quently stored into the input list. Admitted utterances become accepted whenthey can cause a state transition of the finite-state control. Then they areremoved from the input list to be forwarded to the corresponding addressee,and thereupon the corresponding transition in the finite-state control takesplace. Notice that all utterances are first admitted and further on they becomeeither accepted or not. Therefore, the input list of each CP keeps admittedutterances that have not been accepted for dispatching yet. From now on, thesecriteria will be taken as the message sending and receiving semantics used inSection III.E*.

The context of each conversation can be stored and subsequently retrievedthanks to the use of a pushdown list. Such context refers to utterances previ-ously sent or heard, which later can help, for example, to ensure that a certainutterance is the proper response to a previous one. For instance, an utterance inthe input list}represented in a KQML-like syntax}will be processed only if itssender, receiver, and the value of the keyword :in-reply-to match, respectively,the receiver, sender, and value of the keyword :reply-with of the topmostmessage on the pushdown list.

Ž .Finally, each transition in the finite-set of transitions of a CP indicates: iwhat utterance can be either sent or received to produce a move in the

Ž . Ž .finite-state control; and ii whether it is necessary to store push or retrieveŽ .pop the context using the pushdown list.

Each arc of the finite-state control is labeled by one or more transitionspecifications. The structure of a transition specification is shown in Figure 2: a


transition from state i to state j occurs whenever an utterance with polarity x,performative p, and predicate d is found in the input list and the state of thepushdown list is Z. In such a case, the chain of stack operations indicated by opis processed. To fully specify a transition, the following definitions and criteriamust be observed:

v Ž .The polarity of an utterance u, denoted as polarity u , can take on one of twovalues: q, to express that the utterance is sent, or y, to indicate that theutterance is received. From this, for a given CP p we define its symmetric ¨iew pas the result of inverting the polarity of each transition.

v The special symbol pr* represents utterances formed by performative p and anypredicate, whereas the special symbol *rd stands for utterances formed by anyperformative and predicate d.

v < <When several transitions p rd ; Z op, . . . , p rd ; Z op label an arc, they can be1 1 n nŽ < < . <grouped into a compound transition as p rd ??? p rd ; Z op.1 1 n n

v Our model considers the following stack operations:Push pushes the utterance selected from the input list onto the stack;Pop pops the stack by removing the topmost utterance; andNop leaves the stack unchanged. Usually this operation is omitted in specifyingtransition.

v When the state of the pushdown list is not considered for a transition, it isomitted in the transition specification. In CPs, e-moves, i.e., moves that onlydepend on the current state of finite-state control and the state of the pushdownlist, are represented using the transition specification Z N op.

For instance, Figure 3 depicts the CP employed by a trading interagent toŽ .allow its customer buyer agent Akira to participate in a bidding round open by

the auctioneer agent as explained in Section II. Notice that the performatives ofthe utterances considered in the figure follow the syntax of Table I, and thepredicates within such utterances belong to the list of Table II. This simple

Ž .example illustrates the use of the pushdown list: i for saving the state of theŽ . Ž .bidding round round number, good in auction, list of buyers, etc. ; and ii for

ensuring that whenever a request for bidding is dispatched, the bid conveyed tothe auctioneer is built by recovering the last offer pushed by the tradinginteragent onto the pushdown list.

B. Formal Definition

Now it appears convenient to formally capture the conceptual modelintroduced above to be able to reason, later on, about the properties that wemust demand from CPs. Therefore, formally we define a conversation protocolas an 8-tuple,

² :CP s Q, S , S , G , d , q , Z , F1 2 0 0

Figure 2. Transition.


Figure 3. Partial view of the CP DBP used by trading interagents in the Fishmarket.

such that:

v Q is a finite set of state symbols that represent the states of the finite-statecontrol.

v S is a finite alphabet formed by the identifiers of all performatives that can be1uttered during the conversation.

v S is a finite input list alphabet composed of the identifiers of all predicates2recognized by the speakers.

v G is the finite pushdown list alphabet.v d is a mapping from Q = S = S = G* to the finite subsets of Q = G* which1 2

indicates all possible transitions that can take place during a conversation.v q g G is the initial state of a conversation.0v Z g G is the start symbol of the pushdown list.0v F : Q is the set of final states representing possible final states of a conversation.

11 ŽTable I. Types of performatives following Cohen and Levesque extracted5.from Parunak

ID Speech Act Description

Q QUESTION SOLICIT the addressee to INFORM the sender of some propositionR REQUEST SOLICIT the addressee to COMMIT to the sender concerning

some actionI INFORM ASSERTq attempt to get the addressee to believe the contentC COMMIT ASSERT that sender has adopted a persistent goal to achieve

something relative to the addressee’s desiresF REFUSE ASSERT that the sender has not adopted a persistent goal to

achieve something relative to the addressees desires


Table II. Trading interagent predicates

aMessage Predicate Parameters

1 admission buyerlogin password[ ]2 bid price

3 exit4 deny deny code]

<5 accept open closed auction number]6 open auction auction number] ]7 open round round number] ]8 good good id good type] ]

starting price resale price] ]{ }9 buyers buyerlogin *{10 goods good id good type] ]

}starting price resale price *] ]11 offer good id price]12 sold good id buyerlogin price]13 sanction buyerlogin fine14 expulsion buyerlogin15 collision price16 withdrawn good id price]17 end round round number] ]18 end auction auction number] ]

{ < } { }19 going single multiple q 1, 220 gone21 tie break buyerlogin]22 closed market]

CPs only contemplate a finite number of moves from each state that mustbelong to one of the following types:

Mo¨es using the input list these depend on the current state of the finite-statecontrol, the performative and predicate of a message in the input list, and thestate of the pushdown list. For instance, the move expressed by the followingtransition allows a trading interagent to convey to the auctioneer a request for

Ž .bidding received from its customer a buyer agent whenever an offer, receivedfrom the auctioneer, has been previously pushed upon the pushdown list

d q , qREQUEST, bid, offer Z s q , bid Z� 4Ž . Ž .s 9

E-mo¨es these depend exclusively on the current state of the finite-state control andthe state of the pushdown list. e-moves are specifically employed to model andimplement time-out conditions within CPs, so that interagents can handle expiredmessages and automatically recover from transmission errors

d q , e, e, bid Z s q , Z� 4Ž . Ž .9 8

It should be noted that at present we are only interested in deterministicŽ .CPs DCP : a CP is said to be deterministic when for each state q g Q, p g S ,1

< Ž . <d g S , and Z g G* there is at most one possible move, that is d q, p, d, Z F 1.2


C. Instantiation

CPs can be defined declaratively and stored into conversation protocolrepositories open to interagents. Each CP is identified by a unique nameanonymously set by the agent society. When an interagent is requested by itscustomer to start a conversation with another agent it must retrieve theappropriate CP from a conversation repository, and next proceed to instantiateit. In fact, the CP must be instantiated by each one of the interagents used bythe agents intending to talk.

We say that a CP becomes fully instantiated when the interagent creates aCP instance, i.e., after setting the values for the following attributes:

CP name. CP class to which the CP instance belongs;Speakers identifiers of the agents to engage in conversation. Notice that we shall

restrict a CP instance to consider exactly two speakers: the agent that proposes tostart a conversation, the originator, and his speaker, the helper. In spite of thislimitation, we are not prevented from defining multiagent conversation, sincethese can be created by means of multiple CP instances;

Con¨ersation identifier a unique identifier created by the originator;Polarity this property indicates how to instantiate the polarity of each transition of

the CP: if the instance polarity is positive, each transition is instantiated just as itis, whereas if it is negative each transition polarity is inverted. Notice that thehelper must instantiate the symmetric view of the originator’s CP to ensureprotocol compatibility as shown in Section III.E.

Transport policies such as time-out or maximum time allowed in the input list. Thesecan be altered during the course of a conversation whereas the rest of attributesof a CP instance remain fixed. The use of transport policies require to extend theCP being instantiated with e moves that enable to roll back to previous conversa-tion states.Then, and considering the definition above, from the point of view of interagentsthe conversations requested to be held by its customer can progress throughseveral states:

Preinstantiated after retrieving the requested CP from the originator’s cnversationrepository;

Instantiated a CP becomes instantiated when the originator creates a CP instance,and subsequently asks the helper for starting a new conversation accepting the

Ž .terms attributes of the interaction expressed by the CP instance;Initiated this state is reached when both speakers agree on the value of the

attributes of a new conversation, as a result of the negotiation phase described inSection III.F;

Running state attained after the first utterance;Finished a conversation is over whenever either the final state of the CP is reached,

the helper refuses to start it, or an unexpected error comes about.

D. Instantaneous Description

An instantaneous description formally describes the state of a CP instanceat a particular time. An instantaneous description of a CP instance p is a 7-tuple:

² :o , h , p , t , q , l , asuch that:

o is the originator agent; h is the helper agent; p is the polarity of the CPinstance; t is the current setting of transport policies; q is the current state of


the finite-state control; i represents all utterances currently kept by the inputlist; and a is the current state of the pushdown list.

Figure 3 depicts the instantaneous description for an instance of the CPŽ .DBP employed by a trading interagent to allow its customer a buyer agent to

participate in a bidding round open by the auctioneer agent. We identify buyerAkira as the originator, the auctioneer as the helper, and the colored node q as8the state of the finite-state control.

A deterministic CP has at most}without taking into account possiblee-moves for dealing with expired utterances}one possible move from anyinstantaneous description. However, continuously traversing the input list insearch of an utterance that causes a transition can lead to race conditions. Forinstance, in the CP instance of Figure 3 the second and fourth utterances canoriginate a race condition since both utterances can cause a move in thefinite-state control. Thus, it is necessary to define criteria for deciding whichutterance must be accepted as we show in the next section.

E. Compatibility Semantics

To ensure the correct exchange of utterances during a conversation, thereare important, desirable properties such as termination, liveliness, deadlock, andrace condition free that CPs must verify. In what follows we concentrateexclusively lon the two last properties, since to guarantee both termination andliveliness it suffices to assume that every CP whose set of final states isnonempty does not remain forever in the same state.

First we formulate our notion of CP compatibility, following the notion ofprotocol compatibility proposed by Yellin and Strom, 12 whose work provides, infact, the foundations of our analysis.

CPs can be assigned two different semantics: asynchronous or synchronous.Although asynchronous semantics may facilitate implementation, it makes gen-erally harder reasoning about certain properties, such as deadlock which hasproven undecidable under these semantics.12 On the contrary, under syn-chronous semantics, reasoning about such properties is easier, though animplementation technique must map these semantics to a particular implemen-tation. For our purposes, we have decided for a synchronous semantic for CPsand, consequently, for devising the adequate mechanisms for implementation.Such a type of semantics requires assuming that a speaker can send an utteranceto the other speaker only if it is willing to receive the utterance. Therefore, wemust assume that the finite-state controls of both CP instances advance syn-chronously, and hence that sending and receiving an utterance are atomicactions. Upon this assumption, Yellin and Strom introduced the followingnotion of compatibility of protocols: ‘‘Protocols p and p are compatible when1 2they have no unspecified receptions, and are deadlock free.’’ On the one hand, interms of CPs, the absence of unspecified receptions implies that whenever thefinite-state control of a CP instance corresponding to one of the speakers is in astate where an utterance can be sent, the finite-state control of the CP instanceof the other speaker must be in a state where such an utterance can be received.


On the other hand, deadlock free implies that the finite-state control of both CPinstances are either in final states or in states that allow the conversation toprogress. Interestingly, the authors prove the existence of an algorithm forchecking protocol compatibility. By applying such an algorithm, it can be provedthat under synchronous semantics a CP instance p and its symmetric view p arealways compatible. From this follows that two CP instances are compatible ifboth belong to the same CP class, and both have the same speakers butdifferent polarity. In this way, the complete agreement on the order of theutterances exchanged between the speakers is guaranteed.

Concerning the implementation, observe that the atomicity of sending andreceiving utterances cannot be guaranteed. Nonetheless, when compatible CPinstances lack mixed states, the unspecified receptions and deadlock free prop-erties can still be guaranteed. However, the presence of mixed states can lead torace conditions that prevent both speakers from agreeing on the order of themessages, and therefore unexpected receptions and deadlocks might occur. Toavoid such situations, low-level synchronization mechanisms must be provided inaccordance with the interpretation given to message sending and receivingin Section III.A.

For this purpose, we consider that the speakers adopt different conflictroles}either leader or follower}when facing mixed states. The leader willdecide what to do, whereas the follower will respect the leader’s directions. Byextending CP instances with a new attribute}which can take on the valuesleader or follower}we include the role to be played by each speaker in front ofmixed states. Besides, we consider two special symbols}TRY and OK}thatalter the interpretation of message sending. Thus, on the one hand when amessage is sent under the TRY semantics, the receiver tries to directly acceptthe message without requiring previous admission. On the other hand, the OKsymbol confirms that the TRY was successful. Then given a CP² :Q, S , S , G, d , q , Z , F for each mixed state x g Q the CP instance corre-1 2 0 0sponding to the follower will be augmented in the following way:

Ž .;p g S , ;d g S , ;Z g G*, ;Z9 g G*, ;q g Q such that 'd x, qp, d, Z1 2�Ž .4 � 4s q, Z9 then a new state n f Q will be added Q s Q j n and the following

transitions will be added:

Ž Ž . . �Ž .41. d x, qTRY p , d, Z s n, ZŽ . �Ž .42. d n, yOK, e, Z s y, Z9

Y Ž . Ž .3. ;p9 g S , ;d9 g S , ;Z g G* then d x, yp9, d9, Z0 s d n, yp9, d9, Z01 2

Therefore, when the leader is in a mixed state and sends an utterance, thefollower admits it and subsequently accepts it. Conversely, when the follower isin a mixed state and sends an utterance, the leader, upon reception, determinesif it is admitted or not. Figure 4 illustrates how the CP instance on the leftshould be augmented to deal with the mixed state q .8

Notice that the conflict role played by each speaker must be fixed beforethe CP becomes completely instantiated. This and other properties of CPinstances need be negotiated by the speakers as explained in the next section.


Figure 4. Augmented CP instance.

F. Conversation Protocol Negotiation

In Section III.C we introduced the several attributes of a CP instance thathave to be fixed before the conversation between the speakers becomes fullyinstantiated, and subsequently started. The value of each one of these attributeshas to be mutually agreed to by the speakers to guarantee conversationsoundness. For this purpose, interagents have been provided with the capabilityof negotiating such values by means of the so-called Handshake phase, followingthe directions of their customers. During this process, the initial connectionbetween the originator and the helper is established, and next the originator

Ž .conveys its multiattribute proposal the set of attributes’ values to the helper.Then, we distinguish two models of negotiation based on the helper’s response:one-step and two-step negotiation.

In one-step negotiation the helper either automatically accepts or refusesthe originator’s proposal. The following sequence depicts a typical exchange forthis model of negotiation, where q values indicate the degree of preference overeach proposal.

originator: STARTCP/DBP; id=21; polarity=+; leader=me; q=0.7CP/DBP; id=21; polarity= ; leader=you; q=0.3

helper: OKCP/DBP; id=21; polarity=+; leader=me

In this example the helper accepts the second proposal from the originator.In two-step negotiation, instead of directly accepting or refusing the origi-

nator proposal, the helper can reply with a list of counterproposals rankedaccording to its own preferences. Then, the originator can either accept one ofthese proposals or cancel the process.

originator: STARTCP/DBP; id=22; polarity=+; leader=me;

timeout=500; q=0.7CP/DBP; id=22; polarity= ; leader=you;

timeout=1000; q=0.3helper: NOT

CP/DBP; id=22; polarity= ; leader=me;timeout=200; q=0.4


CP/DBP; id=22; polarity=+; leader=you;timeout=200; q=0.6

originator: OKCP/DBP; id=22; polarity=+; leader=you;

timeout=200

In this example the helper refuses the proposals of the originator, whofinally accepts the first helper’s counterproposal.

It should be noted here that the concrete conversation protocol to beinstantiated can be negotiated too. For this purpose, we have introduced the CP

Ž .type e.g. the CPrDBP for the downward bidding protocol , analogously toŽ . Žmultipurpose internet mail extensions MIME content types textrhtml, im-

.agergif, etc. . On the other hand, it is nonsense to negotiate certain attributesfor some CPs. For instance, the polarity of the CP to be employed by anauctioneer attempting to open a DBP round is unnegotiable since the auction-eer cannot play the role of a buyer and vice versa.

IV. JIM

In this section we introduce JIM, a general-purpose interagent enabled withthe capability of managing CPs which has proven its usefulness in several

Ž .applications see Section V . We precede the presentation of JIM by theintroduction of the SHIP protocol since this has profoundly shaped its architec-ture.

A. SHIP An Extensible and Hierarchical Interaction Protocol

Ž .The extensible and hierarchical interaction protocol SHIP offers a layeredŽapproach to support all levels of agent interaction a layer per level introduced

.in Section I . Each layer groups a set of protocols with similar functionalitytogether, and provides an abstract interface to higher layers that hides thedetails related to the particular protocol in use. For instance, two agents canexchange utterances without worrying about the underlying communicationmechanism}message passing, tuple-space, or remote procedure call. In addi-tion to this, the hierarchical structure of SHIP allows agents to choose theirinteraction level. This involves the use of the subhierarchy of SHIP representedby the chosen layer and the layers below, but not higher layers, e.g., an agent

Žmay decide to use the transport layer and the lower levels the connection layer.in this case but not the higher layers of SHIP. Lastly, SHIP is extensible, in the

Ž .sense that it permits the incorporation plug-in of new protocols into eachlayer.

SHIP is a request]response protocol which distinguishes two roles: clientand server. An interagent may play both roles at the same time, e.g., it can act asa server for its customer, and as a client for another interagent. In a typicalmessage flow a client sends a request to the server, and this sends a responseback to the client. All messages exchanged between a client and a server are


encapsulated as either requests or responses of the SHIP protocol as depictedby Figure 5. Observe that both requests and responses are represented as

Ž .13extensible markup language XML messages that nest the information corre-sponding to each level of interaction. On the sender side, messages to be sentare wrapped at each layer and passed down until getting to the communicationlayer responsible for the sending. Upon reception, on the receiver side, mes-sages are unwrapped at each layer and passed up to higher layers until themessage arrives at the layer chosen by the agent for interacting.

ŽSHIP has been built upon the following hierarchy of layers from top to.bottom : content, agent communication, conversation, transport, and connec-

tion. In what follows we describe the functionality of each one of these layerstaken as an example of the SHIP request in Figure 5 corresponding to a requestfor bidding of a buyer agent.

The content layer is concerned with the language for representing theinformation exchanged between agents. Such information refers to terms of a

Ž 14 .specific vocabulary of an application domain ontology . For example, a pieceŽ .of information at this level might be predicate bid codified in the FM

language using the ontology Fishmarket.

Figure 5. All messages between an interagent and its customer are encapsulated aseither requests or responses of the SHIP protocol.


The intentional layer codifies and decodifies performatives in a given ACL.For example, a performative requesting for bidding at this level wraps the

Ž .predicate bid received from the content layer with the illocution REQUEST ofŽ .the Basic ACL Basil whose performatives are shown in Table I.

The con¨ersational layer is in charge of providing the necessary mechanismsfor the negotiation, instantiation, and management of CPs as explained in-depthin Section III. Following the example above, the performative is wrapped with

Žthe information related to the context in which it is uttered conversation.protocol in use, sender, receiver, etc. .

The transport layer is concerned with the transport of utterances. For thisŽ .purpose, we have devised the interagent protocol IAP , an extensible applica-

Ž .tion-level protocol based on the hypertext transfer protocol HTTP . IAPconstrains the body of a message to be an utterance. Moreover, IAP overridesthe set of request methods provided by HTTP. For instance, on the one handthe POST method is used to indicate that the utterance enclosed in the messagebody must be addressed to the receiver specified in the context. On the otherhand, the GET method is used to retrieve the utterance accepted by aninteragent that matches the pattern of utterance enclosed in the message body.

Ž .Furthermore, a new addressing scheme has been introduced iap:rr and a newŽ .default port 2112 .

IAP allows messages to be tagged with different headers to specify theirlifetime:

v The delay header indicates how long an utterance queued in an interagent ispostponed before being processed. In this way, an agent can tell its interagent todeliver a given utterance after a certain period of time.

v The time-out header indicates the maximum period of time that an agentcommits to wait for receiving the response to a given utterance.

v The time-to-li e header indicates the lifetime of the utterance once admitted byan interagent}thus, when this time expires, the utterance is thrown away by the

Ž .receiving interagent and the sender receives back an error message.

We have introduced IAP due to the lack of an adequate transport protocolfor agents’ communicative acts. Currently, most ACLs such as FIPA ACL15 orKQML16 only define minimal message transport mechanisms}in FIPA ACLterms ‘‘a textual form delivered over a simple byte stream.’’15 As an alternativeto simple TCPrIP sockets, other transport protocols such as HTTP, simple mail

Ž .transfer protocol SMTP , or even global system for mobile communicationsŽ .GSM have been proposed. However, on the one hand these protocols offermany unnecessary features for this task, and on the other hand they lack manydesirable features. Hence the convenience of designing IAP as a specializedprotocol for the transport of utterances.

The connection layer occupies the lowest level of the SHIP protocol. It isresponsible for the creation of connections for SHIP requests. We consider aconnection as a virtual circuit established between two agents for the purpose ofcommunication. Different network protocols can be employed to establish suchconnections. Currently, JIM interagents support a wide variety of network


Ž .protocols: memory IrO streams, TCPrIP stream sockets, and secure socketŽ . Ž .layer SSL sockets; others like remote method invokation RMI and internet

Ž .inter-OLS protocol IIOP will be supported in the near future.As a final remark, notice that SHIP has required the introduction of several

Ž .MIME multipurpose internet mail extensions types for declaring the types ofŽ . Žconversation protocol e.g., CPrDBP , of ACL e.g., text/basil, text/

.kqml, text/fipaacl, etc. , etc.

B. Architecture

Ž .The architecture of JIM Fig. 6 shows a sketch of it is best explained interms of its components:

Ž .Interagent directory This component offers interagent naming services white pagesthat translate from unique identifiers of interagents into their logical addressesand vice versa. Each interagent can communicate with a subset of interagents ofthe agent society, named its acquaintances. A reflexive and symmetric, but nottransitive, relation acquaintance-of can be established among interagents. Aninteragent’s acquaintanceship is a set of unique identifiers and can vary dynami-cally, allowing a collection of agents to grow dynamically.

Director This component directs the behavior of the rest of components. It canreceive specific directives from both its owner and its customer. Each CP definesa set of constraints that the director takes into account to sort the utterancesstored in the different buffers.

CP repository This component stores all CP classes that can be instantiated by aninteragent. Such a repository can be updated in either statically or dynamically,e.g., in FM only the market intermediaries working for the institution, the auctionhouse, can define and store at run-time new CP classes into the CP repository ofeach interagent. Notice that the conversation protocol repository can either beowned by only one interagent or shared among several interagents.

ŽOngoing con¨ersation protocols This component stores all running CPs see Section.III.C . A CP instance is kept for each conversation in which the interagent’s

Figure 6. An overview of JIM’s architecture.


Ž .customer is involved. Once a CP is over reaches the finished state , is thrownŽ .away, or alternatively kept for tracing purposes .

Buffer for admitted utterances This component is responsible for storing all utter-ances coming from other interagents in the agent society. An utterance is storedhere until either it is accepted or it expires due to a time-out condition.

Buffer for accepted utterances This component stores utterances that have alreadybeen accepted by a CP but which have not been required by the customer yet.Once one of these utterances is required by the customer it is packaged up as aSHIP response and forwarded to it.

Buffer for outgoing utterances This component stores utterances that have beenforwarded from a customer agent, and received by its interagent but that have notbeen accepted yet. Notice that the input list of each CP instance can be seen as acomposition of the buffers for both incoming and ongoing utterances.

Buffer for delayed utterances This component stores the utterances that have beenŽsent by the customer specifying a lapse of time using the delay header of the IAP

.protocol before they are actually transmitted. When such a lapse of time expires,they are automatically transferred to the buffer for outgoing utterances.

Observe that the architecture of JIM presents up to four different facades:owner, customer, society, and web facades. Each facade represents a differententry for each type of agent requesting the services provided by JIM. Theservices provided through each facade differ. For instance, only the ownerfacade allows an agent to upgrade the CP repository. The web facade simply

Ž .provides access to World-Wide Web WWW resources. For instance, thisfacade allows a human agent to interact with the JIM’s customer through astandard WWW browser. Each facade is built on top of a different instance ofthe SHIP protocol. In JIM, a chain of responsibility is established through thedifferent protocol layers that conform the SHIP instance of each facade. That isto say, each layer is responsible for managing some of the services provided byJIM.

V. THE AGENT-BASED ELECTRONIC AUCTION MARKET FM

In this section, we introduce FM an example of a particular agent-basedsystem that serves to illustrate both the practical use and functionality ofinteragents. In fact, most of the features of interagents have emerged as ageneralization of the more ad hoc notion of remote control introduced at thefirst stages of the development of FM.17 In Refs. 17 and 18 we presented FM, anelectronic auction house based on the traditional fish market auctions. Furtheron, FM was extended to produce the multiagent test-bed for electronic auctionsintroduced in Ref. 7 and fully reported in Ref. 6. The current version of FM,FM0.9beta,19 is now available and can be downloaded from the Fishmarketproject web page.20

Ž 21.The actual fish market is an institution cf. North’s that establishes andenforces explicit conventions. From our view, it can be described and modeledas a place where several scenes run simultaneously, at different places, but withsome causal continuity.17,18 The principal scene is the auction itself, in whichbuyers bid for boxes of fish that are presented by an auctioneer who calls prices


in descending order}the downward bidding protocol. However, before thoseboxes of fish may be sold, fishermen have to deliver the fish to the fish market,at the sellers’ registration scene, and buyers need to register for the market, at thebuyer ’s registration scene. Likewise, once a box of fish is sold, the buyer shouldtake it away by passing through a buyers’ settlements scene, while sellers maycollect their payments at the sellers’ settlements scene once their lot has been

Žsold. Each scene is supervised by one of the market intermediaries auctioneer,.buyer admitter, buyer manager, seller admitter, seller manager, and boss which

represent and work for the institution.In a highly mimetic way, the workings of its electronic counterpart, FM,

also involve the concurrency of several scenes governed by the market interme-diaries identified in the fish market. Therefore, seller agents register their goods

Žwith a seller admitter agent, and can get their earnings from a seller manager.agent once the auctioneer agent has sold these goods in the auction room.

Buyer agents, on the other hand, register with a buyer admitter agent, and bidfor goods which they pay for through a credit line that is set up and updated bya buyer manager agent. Figure 7 shows the conceptual model of FM as amultiscene multiagent scenario.

Similarly to the actual fish market, FM can be regarded as an electronicinstitution in the sense proposed by Noriega18 and Sierra and Noriega.22 Thus,

Figure 7. FM multiscene structure.


buyer and seller agents can trade goods as long as they comply with theFishmarket institutional conventions. Those conventions that affect buyers andsellers have been coded into CPs handled by interagents that establish whatutterances can be said by whom and when. We differentiate two types ofinteragents in FM: trading interagents, owned by the institution but used bytrading agents, and institutional interagents, both owned and used by those agentsfunctioning as market intermediaries. Therefore, all interagents are owned bythe institution, but we identify two types of customers: the trading agents andthe institution itself.

Trading interagents constitute the sole and exclusive means through whichtrading agents interact with the market intermediaries representing the institu-tion. Within each scene, a trading interagent must employ a different CP toallow its customer to talk to the market intermediary in charge of it. Therefore,trading interagents are responsible for enforcing the protocols that guaranteethat every trading agent behaves according to the rules of the market. Forinstance, in the auction room a trading interagent uses the CPrDBP depicted in

Ž .Figure 3 for allowing its customer a buyer agent to participate in a biddinground. In general, we refer to the conversations supported by trading intera-gents as intrascene con¨ersations because they are dialogues held within eachscene between the market intermediary responsible for the scene and eachtrading agent situated in the scene.

As to market intermediaries, they must hold several conversations at thesame time with the agents in the scene that they govern. For this purpose, theinstitutional interagents that they employ must exploit their capability forsupporting multiple conversations, as explained in Section II, by building collec-

Ž .tions of simultaneous CP instances one per trading agent . Thus, for example,the auctioneer’s interagent maintains an instance of the CPrDBP for eachbuyer agent in the auction room. Moreover, not only are institutional intera-gents used to support conversations with trading agents, but also to allow thoseagents working as market intermediaries to coordinate their activities. We willrefer to the conversations held between market intermediaries as interscenecon¨ersations.

Both types of interagents have been endowed with further capabilities. Onthe one hand, they are in charge of conveying monitoring information to the

Ž .auditing agent also called monitoring agent , so that market sessions can bemonitored, and analyzed step-by-step. On the other hand, interagents providesupport for agent failure handling. For example, when a trading agent eithergoes down or simply fails to consume the utterances conveyed by its interagentŽsay that the trading agent lapses into an extremely demanding deliberative

.process for elaborating its strategies , this interagent proactively unplugs itscustomer from the market and leaves the market on its behalf.

Finally, by applying the results derived from our analysis in Section III.E,Ž .the interagents in FM can dynamically at run-time reconfigure retrieved CPs

to guarantee the verification of liveliness, termination, and deadlock and racecondition free.


Summarizing, the successful incorporation of interagents into FM hasŽ .proven their usefulness by coping with several tasks: i to handle the interplayŽ .between trading agents and the market institution intrascene conversations ;

Ž . Žii to handle the coordination between market intermediaries’ tasks interscene. Ž .conversations ; iii to provide support for the monitoring of market sessions;

Ž . Ž .iv to handle agents’ failures; v to reconfigure CPs so as to ensure protocolcompatibility.

VI. RELATED WORK

So far, much effort in agent research concerning agent interaction hasfocused on the semantic and pragmatic foundations of different agent communi-

Ž . 11,23,24cation languages ACLs based on speech act theory. Researchers in theŽ .advanced research program agency ARPA knowledge sharing effort have

Ž .proposed agent communication languages ACLs as the means to allow theexchange of knowledge among software agents to make their interoperationeasier.25 Generally, an ACL is composed of three main elements: an open-endedvocabulary appropriate to a common application area,26 an inner languageŽ 27 .KIF]knowledge interchange format to encode the information content com-

Žmunicated among agents, and an outer language KQML]knowledge query and28 .manipulation language to express the intentions of agents. Apart from KQML,

there are other ACLs in use such as FIPA ACL,15 KQML Lite,29 etc. Howeverthis research is currently broadening from the specification of individual utter-ances to include the characterization of goal-directed conversations for whichagents use ACLs. Thus new works in speech act research, exemplified by efforts

Ž . 30 5such as knowledgeable agent-oriented system KAoS , Dooley graphs, coordi-Ž . 4 31nation language FSM is finite state machines COOL , and MAGMA, at-

tempt at representing and reasoning about the relationships within and amongconversations, or groups of utterances. A number of formalisms have beenproposed for the modeling of conversations. FSMs,4,32 Dooley graphs,5 Petrinets,33 etc. Our approach proposes a new model based on PDTs that allowsstoring the context of ongoing conversations, and, in contrast with other ap-proaches, that provides a mapping from specification to implementation. More-over, as a distinctive feature from other approaches, we provide our model witha detailed analysis that studies the properties that conversation protocols mustexhibit to ensure protocol compatibility, and therefore the soundness of agentconversations.

Although there is a large number of software tools for developing agents,34

not many of them happen to provide support for the specification of conversa-tion protocols. AgentTalk,35 COOL,4 JAFMAS,32 Agentis,36 Jackal,37 and InfoS-leuth,38 do offer conversation constructs. Java-based agent framework for multi-

Ž .agent systems JAFMAS , for instance, provides a generic methodology fordeveloping speech-act based multiagent systems using coordination constructssimilar to COOL. In addition to this, as far as our knowledge goes, none of themoffers dynamically and incrementally specifiable conversation protocols except


for InfoSleuth.38 We attempt to make headway in this matter with respect toother agent building tools by introducing interagents, autonomous softwareagents that permit both the dynamic and incremental definition of conversationprotocols by both the agent engineer and the owner.

We have chosen the conceptualization of interagents as autonomous soft-ware agents instead of an agent’s built-in conversation layer as proposed inother agent architectures because of the need to separate the agents’ logics fromthe agents’ interactions}such separation has proven to be valuable in thedevelopment of a particular type of agent-based systems, namely, electronicinstitutions such as FM. Interagents}like KQML facilitators39 }are inspired bythe efficient secretary metaphor already introduced in the Actors model ofconcurrent computation.40 Nonetheless, interagents}unlike KQML facilitators}offer the conversational level required by agents to cooperate in nontrivialways.

VII. CONCLUSIONS

We introduced conversation protocols CPs as the methodological way toconceptualize, model, and implement conversations in agent-based systems. CPsallow imposing a set of constraints on the communicative acts uttered by theagents holding a conversation. We also introduced interagents as autonomoussoftware agents that mediate the interaction between each agent and the agentsociety wherein this is situated. Based on CPs and interagents we proposed aninfrastructure for easing the development of agent-based systems that takescharge of the complex, time-consuming interaction issues inherent to theconstruction of these types of systems. In this way, the overhead related to themanagement of the interaction tasks needed by an agent is shifted to itsinteragent. Interagents employ CPs for mediating conversations among agents,and so the management of CPs is identified as their main task. Two majorbenefits are achieved by deploying our infrastructure from the point of view ofthe agent developer: on the one hand, their agents can reason about communi-cation at higher levels of abstraction, and on the other hand they are releasedfrom dealing with interaction issues, and so they can concentrate on the designof the agents’ logics. We have also introduced JIM, a general-purpose intera-gent. JIM is currently being used to coordinate the activities of the marketintermediaries composing the Fishmarket system7,20 and the interaction between

Ž .the market as a whole and the participating buyers and sellers see Fig. 1 .Additionally, JIM is being successfully employed by other ongoing research

Ž . 41projects: the system of multiagents for services in hospitals SMASH project,that addresses the construction of prototype multiagent systems with learningcapabilities that cooperate in the solution of complex problems in hospitalenvironments; and in the multiagent learning framework Plural42 which tacklesthe problem of sharing knowledge and experience among cognitive agents thatcooperate within a distributed case-based reasoning framework.


References

1. Lesser VR. Reflections on the nature of multi-agent coordination and its implica-tions for an agent architecture. Autonomous Agents Multiagent Syst 1998;1:89]111.

2. Jennings NR. Commitments and conventions: The foundation of coordination inŽ .multiagent systems. Knowledge Eng Rev 1995;8 3 :223]250.

3. Winograd T, Flores F. Understanding computers and cognition. Reading, MA:Addison-Wesley; 1988.

4. Barbuceanu M, Fox MS. Cool: A language for describing coordination in multiagentsystems. In: Proceedings of the First International Conference on Multi-AgentSystems. 1995.

5. Van Dyke Parunak H. Visualizing agent conversations: Using enhanced Dooleygraph for agent design and analysis. In: Proceedings of the Second InternationalConference on Multi-Agent Systems. 1996.

6. Rodrıguez-Aguilar JA, Martın FJ, Noriega P, Garcia P, Sierra C. Towards a test-bed´ ´Ž .for trading agents in electronic auction markets. AI Com 1998;11 1 :5]19.

7. Rodrıguez-Aguilar JA, Martin FJ, Noriega P, Garcia P, Sierra C. Competitive´scenarios for heterogeneous trading agents. In: Second International Conference onAutonomous Agents. 1998.

8. Roche E, Schabes Y. Finite state language processing. Cambridge, MA: MIT Press;1997.

9. Aho AV, Ullman JD. The theory of parsing, translation, and compiling, Vol.I]Parsing. Series in automatic computation. Englewood Cliffs: Prentice Hall; 1972.

10. Brookshear JG. Theory of computation, formal languages, automata, and complexity.Redwood City, CA: Benjamin-Cummings; 1989.

11. Cohen PR, Levesque HJ Communicative actions for artificial agents. In: ProceedingsŽ .of the First International Conference on Multi-Agent Systems ICMAS-95 . Menlo

Park, CA: AAAI Press; June 1995. pp 65]72.12. Yellin DM, Strom RE. Protocol specifications and component adaptors. ACM Trans

Ž .Programming Languages Syst 1997;19 2 :292]333.13. Connolly D. XML, principles, tools and techniques. O’Reilly; 1997.14. Gruber TR. Toward principles for the design of ontologies used for knowledge

sharing. In: Guarino N, Poli R. editors. Software agents. DordrechtrNorwell, MA:Kluwer Academic; 1993.

15. FIPA 97. Specification part 2: Agent communication language. Technical Report,FIPA-Foundation for Intelligent Physical Agents. 1997.

16. Mayfield J, Labrou Y, Finin T. Evaluation of KQML as an agent communicationlanguage. In: Woolridge M, Muller J, editors. Intelligent Agents II. BerlinrNew¨York: Springer-Verlag; 1996. pp 347]360.

17. Rodrıguez-Aguilar JA, Noriega P, Sierra C, Padget J. Fm96.5 a java-based electronic´auction house. In: Second International Conference on The Practical Application of

Ž .Intelligent Agents and Multi-Agent Technology PAAM’97 . 1997.18. Noriega P. Agent-mediated auctions: The Fishmarket metaphor. Ph.D. thesis. Uni-

versitat Autonoma de Barcelona. 1997. Also to appear in IIIA Monography Series.19. Rodrıguez-Aguilar JA, Martın FJ, Gimenez FJ, Gutierrez D. Fm0.9 beta users guide.´ ´ ´

Technical Report, Institut d’Investigacio en Intel?ligencia Artificial. Technical Re-´ `port IIIA-RR98-32. 1998.

20. The Fishmarket Team. The Fishmarket project. In: www.iiia.csic.esrProjectsrfish-market.

21. North D. Institutions, institutional change and economics performance. Cambridge,UK: Cambridge Univ. Press; 1990.

22. Sierra C, Noriega P. Institucions electroniques. In: Proceedings of the Primer`Congres Catala d’Intel.ligencia Artificial. 1998.` ` `

23. Austin JL. How to do things with words. London: Oxford Univ Press; 1962.24. Searle J. Speech acts. Cambridge, UK: Cambridge Univ Press; 1969.


25. Genesereth M, Ketchpel P. Software agents. Comm ACM Special Issue on Intelli-Ž .gent Agents. July 1994;37 7 :48]53.

26. Gruber T. A translation approach to portable ontology specifications. TechnicalReport KSL-92-71. Knowledge Systems Laboratory, Computer Science Department,Stanford University; April 1993.

27. Ginsberg ML. Knowledge Interchange Format: The KIF of death. AI MagŽ .1992;12 3 :57]63.

28. Finin T, Labrou Y, Mayfield J. Kqml as an agent communication language. In:Bradshaw J, editor. Software Agents. Cambridge, MA: MIT Press; 1995., Invitedchapter.

29. MacEntire R, McKay D. KQML Lite specification. Technical Report, LockheedMartin Mission Systems, Technical Report ALP-TRr03. 1998.

30. Bradshaw JM. An open agent architecture supporting reuse, interoperability, andextensibility. In: Tenth Knowledge Acquisition Workshop for Knowledge basedSystems. 1996.

31. Demazeau Y. From interactions to collective behaviour in agent-based systems. In:Proceedings of European Conference on Cognitive Sciences. 1995.

32. Chauhan D. JAFMAS: A java-based agent framework for multiagent systems devel-opment and implementation. Ph.D. Thesis, ECECS Department, University ofCincinnati, 1997.

33. Koning J-L, Francois G, Demazeau Y. Formalization and pre-validation for interac-tion protocols in multiagent systems. In: Thirteenth European Conference on Artifi-cial Intelligence. 1998.

34. AAAI-98 Workshop on Software Tools for Developing Agents. 1998.35. Agenttalk: Describing multi-agent coordination protocols. http:rrwww.

cslab.tas.ntt.jpratr.36. d’Inverno M, Kinny D, Luck M. Interaction protocols in agents. In: Third Interna-

tional Conference on Multi-Agent Systems. 1998.37. Cost RS, Finin T, Labrou Y, Luan X, Peng Y, Soboroff I. Jackal: a java-based tool

for agent development. In: AAAI-98 Workshop on Software Tools for DevelopingAgents. 1998.

38. Nodine M, Perry B, Unruh A. Experience with the InfoSleuth agent architecture. In:AAAI-98 Workshop on Software Tools for Developing Agents. 1998.

39. Patil RS, Fikes RE, Patel-Schneider PF, McKay D, Finin, T, Gruber TR, Neches R.The darpa knowledge sharing effort: Progress report. In: Proceedings of the ThirdInternational Conference on Principles of Knowledge Representation and Reason-ing. 1992.

40. Aghal G. Actors, a model of concurrent computation on distributed systems. Cam-bridge, MA: MIT Press; 1986.

41. The SMASH project. http:rrwww.iiia.csic.esrProjectsrsmashr.42. Martin FJ, Plaza E, Arcos JL. Knowledge and experience reuse through communica-

Ž .tion among competent peer agents. Int J Software Eng Knowledge Eng, Vol. 9, No.Ž .3, 1999 319]341.

an infrastructure for agent-based systems: an interagent approach

Documents