tuPInJADE-Tutorial
Description
TutorialontuPrologagentsinDCaseLPToshowhowtuPrologagentscaneasilybeprogrammedandexecutedinDCaseLP,wewillgothrough,stepbystep,thecreationandimplementationofasmallMAS1prototypewhosecomponentsarebothJavaandtuPrologagents.The MAS we are about to create will represent a simple distributed market place where there are agents willing to buy fruit and agents wishing to sell it. Tosimplify our example, we will suppose that the fruit sold in the market is onlyoranges, apples and kiwi; moreover, there are only 3 shops and only 2 peoplebuying. The shops where people buy and the people themselves can all be rep resented by agents. We will call buyer1 and buyer2 the agents representing thepeople,whilewewilladdresswithseller, seller1and seller2theagentsrepresent ing the shops. Thus, our MAS consists of 5 agents. These agents could be Java,tuProlog or Jess agents. We will programme the behaviour of 4 of these agentsusing tuProlog, while we will use Java for the remaining one, for example theagent seller.Whatisthenextstep?The next step we will carry out is to determine what kind of interactions cantake place among our agents. All the interactions among the agents will implysending/receivingmessagesthroughtheJADEplatformsinwhichtheagentsaredeployed. So, what type of messages do we want to consider? Well, given thatour example is simple, we can probably expect the agents that sell fruit to mainlyreceive2differenttypesof requestsfromthebuyers:• ...
Informations
| Publié par | Sawyung |
| Nombre de lectures | 17 |
| Langue | English |
Extrait
Tutorial on tuProlog agents in DCaseLP
To show how tuProlog agents can easily be programmed and executed in DCaseLP, we will go through, step by step, the creation and implementation of a small MAS prototype whose components are both Java and tuProlog agents. 1 The MAS we are about to create will represent a simple distributed market-place where there are agents willing to buy fruit and agents wishing to sell it. To simplify our example, we will suppose that the fruit sold in the market is only oranges, apples and kiwi ; moreover, there are only 3 shops and only 2 people buying . The shops where people buy and the people themselves can all be rep-resented by agents. We will call buyer1 and buyer2 the agents representing the people, while we will address with seller , seller1 and seller2 the agents represent-ing the shops. Thus, our MAS consists of 5 agents . These agents could be Java, tuProlog or Jess agents. We will programme the behaviour of 4 of these agents using tuProlog , while we will use Java for the remaining one, for example the agent seller .
What is the next step? The next step we will carry out is to determine what kind of interactions can take place among our agents. All the interactions among the agents will imply sending/receiving messages through the JADE platforms in which the agents are deployed. So, what type of messages do we want to consider? Well, given that our example is simple, we can probably expect the agents that sell fruit to mainly receive 2 different types of requests from the buyers: • the price at which the fruit is sold; • an amount of fruit to buy . For the purpose of simplicity, we will assume that the buyers always buy the same amount of fruit: that amount can vary according to the type of fruit. Obvi-ously, the sellers will have to keep track of the amount of fruit that they have in stock in order to be able to respond to the requests made by the buyers: if they 1 The reader can find more details about the tuProlog agents in DCaseLP, this example and its execution, in the Master Thesis of Ivana Gungui (in English) that can be downloaded using this link: http://www.disi.unige.it/person/MascardiV/Download/Gungui.pdf.gz .
1
have enough fruit they will sell it, otherwise they will have to inform the buyer that the quantity of fruit they have in stock is not enough. When a sale of fruit can be carried out, the seller will send a message to the buyer to inform it of the successful transaction. On the other hand, the buyer will need to keep track of the amount of money that it has available . The messages that the agents exchange can then be summarised as follows:
INTERACTIONS in our MAS
Message buyers sellers
REQUEST price send receive
INFORM price receive send
REQUEST buy send receive
INFORM bought receive send
INFORM no more receive send
Now that we have established the possible interactions that can take place in our MAS, we must decide what should be the initial situation of the MAS. What would happen in a market? The people intending to buy fruit would go round having a look at the prices of the different shops and then would decide to buy where the fruit is cheaper. Therefore, it seems a good idea if, at the beginning, the buyers request the price of each fruit to all the sellers : obviously the order with which these questions are carried out cannot be decided before executing the MAS and will have to be random. Once one buyer knows the prices of the fruit, independently of what the other buyer is doing, it will send requests for buying the cheapest fruit. In our MAS, a
2
buyer will carry on trying to buy fruit while it has money that allows it to do so, while a seller will carry on selling until it has enough fruit to sell. For what we have said until now, it can be gathered that the 2 tuProlog agents buying fruit , buyer1 and buyer2 , behave in the same way and differ only in the quantity of fruit that they wish to buy for each fruit and in the quantity of money that they own. Thus, we can write the theory file for one of them, let’s say buyer1 , and then copy it for buyer2 modifying it accordingly. Similarly, the 2 tuProlog agents selling fruit , namely seller1 and seller2 , will have the same theory file, with different facts regarding the quantity of fruit in stock and the prices at which the fruit are sold. We will see the Java agent selling fruit, that is seller , at the end.
The buyer agent We will first detail what the knowledge base of the agent will contain, and after-wards we will show the definition of the main predicate. The user must though remember that the clauses defining the main predicate will have to appear at the beginning of the theory file . First of all, we decide the quantity that this agent will buy for each fruit so, in the text file containing the tuProlog theory for the agent buyer1 , we add the following lines: buys(goods(oranges),quantity( 2 )) :- true. buys(goods(apples),quantity( 3 )) :- true. buys(goods(kiwi),quantity( 12 )) :- true. The term goods( term ) represents a type of fruit, while quantity( term ) is used to express how many kilograms of the relative fruit the agent buys. We will write in blue the data that will probably be different in the theory file of the agent buyer2 . The buyer also needs to know how much money it owns, so we add this fact: money( 200 ) :- true. To be able to decide which seller sells a fruit at the cheapest price, the buyer will have to keep track of the prices applied by each seller. We can thus add: price(seller,oranges,na) :- true. price(seller1,oranges,na) :- true. price(seller2,oranges,na) :- true. price(seller,apples,na) : true. -
3
price(seller1,apples,na) :- true. price(seller2,apples,na) :- true. price(seller,kiwi,na) :- true. price(seller1,kiwi,na) :- true. price(seller2,kiwi,na) :- true. We have used the constant na ( n ot a vailable) to indicate the situation when the price applied by the seller is not yet known to the buyer. At the beginning, the buyers are not aware of the prices and, for simplicity, we suppose that they do know the names of the sellers. Previously we have decided that the first task of the buyers will be to find out the prices of the fruit, but there is a situation that we must take into account: what happens in case the answer of a seller is lost or does not arrive before the buyer agent starts its cycle again; the buyer would repeat the request because it does not know the price yet. To avoid a buyer agent sending more than one request to the same seller, we use this auxiliary predicate: asked( fruit , seller , yes/no ). that will allow the agent to know if it has already sent a request for a price. Thus, we add the facts shown below: asked(oranges,seller,no) :- true. asked(apples,seller,no) :- true. asked(kiwi,seller,no) :- true. asked(oranges,seller1,no) :- true. asked(apples,seller1,no) :- true. asked(kiwi,seller1,no) :- true. asked(oranges,seller2,no) :- true. asked(apples,seller2,no) :- true. asked(kiwi,seller2,no) :- true.
The constant no indicates that the agent has not yet asked the price of the fruit to the corresponding seller agent. In case the agent needs to know how much of a fruit it has bought, we can add the following: goods possessed(oranges,0) :- true. goods possessed(apples,0) :- true. goods possessed(kiwi,0) :- true.
Finally, in order to refer to the seller agents by using the constants seller , seller1
4
and seller2 , instead of the strings representing their JADE addresses (GUIDs), we add: address name("seller@ai:1099/JADE ,seller):- true. " address name("seller1@ai:1099/JADE",seller1):- true. address name("seller2@ai:1099/JADE",seller2):- true. The first argument of the predicate is the JADE GUID of the seller agent: in our example, the seller agents are all running in a JADE platform running on a computer named ai . We could programme the agent to ask the Directory Facilitator agent (avail-able in JADE) for the addresses of the seller agents and then store them in the knowledge base, but for simplicity we prefer to assume that the buyers already know the addresses of the sellers. Finally, we add two more facts to the theory: goods list([oranges,apples,kiwi]) :- true. sellers addresses(["seller@ai:1099/JADE", "seller1@ai:1099/JADE", "seller2@ai:1099/JADE"]) :- true. The first fact is used to know the list of fruit available in the market, while the sec-ond one tto know the list of the JADE addresses corresponding to the seller agents. The main activities carried out by the buyer agent are, in order: handling in-coming messages , asking the price of the fruit to sellers (performed until it knows the price at which each fruit is sold by every agent) and buying fruit . The simple way of programming the behaviour of the agent is, therefore, to separate these tasks and deal with them separately by calling auxiliary predicates that will perform them. So, at the beginning of the theory file (where the defini-tion of the main predicate must be!) we write the following rule: main :- handle msgs,ask prices,buy goods. Now we will go through each auxiliary predicate in detail.
handle msgs This activity mainly consists on receiving a message and processing it in the ap-
5
propriate manner. The first action will therefore be the call to the receive pred-icate that we have defined in the TuJadeLibrary . We will make use of another predicate to examine the message received (if there is one) and decide how to proceed. We can define the handle msgs predicate as follows: handle msgs :- receive(Performative,Message,Sender), select(Performative,Message,Sender). The receive predicate is successful both if the agent has received a message and if it has not. If the agent has at least received a message then the Performative , Message and Sender variables are bound to information regarding the message received, otherwise they remain unbound. The select predicate has a multiple definition: one deals with the messages that are sent by the seller agents while the other one assures that the predicate never fails, avoiding the failure of the main predicate which would cause an error. select(Performative,Message,Sender) :-bound(Performative),bound(Message), address name(Sender,Name),unpack(Message,TermMsg), handle(Performative,TermMsg,Sender). select( , , ) :- true. If the bound predicate fails it means that no message has been received, so the agent will continue by evaluating the next predicate in the main goal, that is ask prices . In case a message has been received, we must check if it has been sent by a seller agent, so we call the address name goal: if it fails then the sender is not one of the seller agents, so the message is discarded; on the other hand, if it does not fail, we must handle its content. Before examining the content, we call the unpack predicate, also defined in the TuJadeLibrary , in order to create the TermMsg term corresponding to the tuProlog term that the seller agent intended to send but was converted into a string to be inserted as the content of the message. At the beginning we have pointed out what are the interactions that take place among our agents, so we know that a buyer agent will receive only three different types of messages from the seller agents. Since the action that the buyer agent needs to carry out depends on the predicate that appears in the term that has been sent by the seller agent, we define the handle predicate as shown below: handle("INFORM",price(Goods,Price),Sender) :-bound(Goods),bound(Price),address name(Sender,S), retract(price(S,Goods, )), 6
7
ttuifratruyebuhegolikhcuhtfosmarsowe(Q))howmknowsd,)G(ooitytuqnagohebual(gysdsooaeW.eoslulavtetayownedbytheagentahatomnuttehomendamsitnetnocesohewagssmehegtinagmfnasooeupprtsehsehaclauhirdThetnidr.ylgtnegoccabyedeathostpssseteehrfiuacundptays,andwesuallybutia,feurnircdnotttheementityquanehtybsnwfotnuomaseyunemothuyobdtehubeyarerotedrcementthemoneyitotiurehT.usernitlctgansioketaytnbtsowoughuitbhefrbttymeneedrccenakntoer-dorinP)s,tfo)P(ecirpehtwoluatetheuseweeva(e,SoGdooglarpcitihaostpfrofttuiihtnalcsssesI.seG,S(sdoop,)Secirt(acnemo),,Ptrredo)sa,ddobnu(doG(Sender,ressname(thguob,"MROFNI":-r)deen,Ss)odGooosdS(G,irectrp(dle(.hance)),Priessaedsestorgprillinehrpectlsuylveoiyebuheytanocstriitcaylnobnekatnoreceivedinthismenasdoterhtpeirecesrrndpogfinitrui,ecynaftfo,ocehsiem.shTetmrtoowatetediccepreprihtseilppatahtmreatngniaintcoesagurtiT.ehsrleslfathesendeeatwhichehttcirpreyuuobamsorebthagssnfeiniottnesbehtmrofattheruynsraetthotnoacet.mhTteressagismebeenehas,tuotahtt,siubehrhyeboashtugefthcaitnoahbseesncucessfullycarriedsehe.Tesaticedpretsni,esualcdnocgtheusine,byssagestrdnsacaaterrttahalippatismterpthgiderhtseuobeesthemesad,handlcenoettnaseghwsolendIN("RMFOno",(desdooG)N,sah.)er):-bound(GoodsomerG(oosd,)eSdn),,Serndt(actrreserdda,)eS(emansert(,asse(S,pric(e,Srpci,s))oGdodessooG(psdoessoactrgot(M)y(re),q,autnti(soGdo)suys(goodds,X)),bessa,P--MsiMN,an\=,P+QsXNi),Q)y(sssesdopg(ooestr),as(NM)oneyrt(mwtliclnoitunbeeyvaluatingthenextlaoghtniiameenonam,nybelgouys.odsrcthTfiedefiealsuthehningepreandlsietacidhtenoehtswaldeat-seshmitnished))Goods,fi,,:)t-urh.nald(ee,orcainThe.eferertnviechtesegaeatitgethessaesamni,geptctoxeawnsissdeiagssmeisthnegaehtdnadedrac
owns is less than the quantity that this buyer usually buys. The only action taken by the buyer is to cancel the previously stored sell-ing price, if any, of the corresponding fruit and substitute it with the constant finished , thus the agent knows if it can no longer buy that fruit from the cor-responding seller agent. If the received message does not have the expected performative ( INFORM ), then it is discarded and the agent evaluates the next goal in the main one; this is possible because the last clause assures that the handle predicate never fails. ask prices This activity consists in asking the fruit prices to the seller agents by sending them a message with the performative REQUEST . The main ask prices predicate is defined below: ask prices :- sellers addresses(Sell), goods list(GList), ask prices(Sell,GList). First of all, we retrieve the list of the JADE addresses of the seller agents; then, we retrieve the list of fruit sold in the market and, finally, we send to each seller a message (one for each fruit sold in the market) asking the price at which it sells the fruit. To do so, we use the auxiliary ask prices predicate that takes two arguments: ask prices([Seller|Others],GoodsList) :-ask prices to seller(Seller,GoodsList), ask prices(Others,GoodsList). ask prices([], ) :- true. ask prices to seller(Seller,[Goods|Others]) :-address name(Seller,S),asked(Goods,S,no), pack(price(Goods),Str), send("REQUEST",Str,Seller), retract(asked(Goods,S,no)), assert(asked(Goods,S,yes)), ask prices to seller(Seller,Others). ask prices to seller(Seller,[Goods|Others]) :-address name(Seller,S),price(S,Goods,X),X \ = na, ask prices to seller(Seller,Others).
8
ask prices to seller(Seller,[Goods|Others]) :-address name(Seller,S),asked(Goods,S,yes), ask prices to seller(Seller,Others). ask prices to seller( ,[]) :- true. The auxiliary ask prices to seller predicate is the one that actually sends a message. One of the first actions carried out by this predicate is to call the asked goal in order to know if the agent has already sent, or not, a message asking the price of the fruit. Before calling the send predicate we have to call the pack predicate (both predicates are defined in the TuJadeLibrary ) on the term we want to send and on the string into which the term will be converted, so we can insert that string as content of the message. Afterwards, we substitute the asked fact whose third argument was the no constant, with a new one whose third argument is the yes constant, in order to know in future that the agent has already sent a request for the price of the fruit (specified in the fact) to the seller (also specified in the fact). The second clause defining ask prices to seller checks whether the price of the given fruit is available or not. If the agent already knows the price then the next fruit in the list of the fruit sold in the market is examined. On the other hand, if the price is still not present, but it has been requested, the agent cannot do anything regarding that fruit so, while waiting for the agent seller to reply, it checks if it knows the price of the other fruit: this is done by the third clause. The final clause defining ask prices to seller is used to know if the agent has asked the price of all the fruit sold by a seller agent.
buy goods This activity consists in buying fruit: buy goods :- sellers addresses(SList), goods list(GList),buy goods(SList,GList). First of all, we retrieve the list of the JADE addresses of the seller agents; then, we retrieve the list of fruit that the buyer intends to buy and, finally, we send for each
9
fruit, a message asking to buy it to the seller that sells that fruit at the cheapest price. To do so, we use the auxiliary buy goods predicate that takes two argu-ments: buy goods(SList,[Goods|Others]) :- money(M),M > 0, buys(goods(Goods),quantity(Q)), find min price(SList,Goods,30000,nobody, HonestSeller),HonestSeller \ = nobody, buy from seller(HonestSeller,Goods,Q), buy goods(SList,Others). buy goods( , ) :- true. At first, of course, we check if the agent has money, otherwise it does nothing and starts again the evaluation of the main goal. If the agent has money to spend, though, we consider each fruit that it wishes to buy and decide which seller charges the cheapest price for such fruit by calling the find min price goal. The auxiliary find min price predicate is defined as follows: find min price([Seller|Others],Goods,Min, , HonestSeller) :- address name(Seller,S), price(S,Goods,Price),Price \ = na, Price \ = finished,Price < Min, find min price(Others,Goods,Price,Seller, HonestSeller). find min price([Seller|Others],Goods,Min,Sel, HonestSeller) :- address name(Seller,S), price(S,Goods,Price),Price \ = na, Price \ = finished,Price >= Min, find min price(Others,Goods,Min,Sel, HonestSeller). find min price([Seller|Others],Goods,Min,Sel, HonestSeller) :- address name(Seller,S), price(S,Goods,na), find min price(Others,Goods,Min,Sel,HonestSeller). find min price([Seller|Others],Goods,Min,Sel, HonestSeller) :- address name(Seller,S), price(S,Goods,finished),
10
find min price(Others,Goods,Min,Sel,HonestSeller). find min price([], , ,Seller,Seller) :- true. The first clause defining the find min price checks if the buyer already knows the price at which the given fruit is sold by the seller considered. This check is easily performed by solving the price goal. This call also allows the buyer to know if the seller still has the quantity of fruit that it wants to buy. If the buyer can buy the fruit from the seller, then the price at which the fruit is sold is compared to the minimum price that the buyer has found for that fruit (stated by the third argument of the find min price goal). Obviously, at the beginning of the search for the cheapest price, we will need to have a very high minimum, this is why in the buy goods goal we call the predicate with the minimum set to 30000 : we will make sure that at least one seller will sell the fruit at a price that is lower than this chosen amount. Thus, if the price is lower than the current minimum, the buyer continues its search by calling the same goal but substituting the minimum price found until now with the price just considered, and substituting the fourth argument (that indicates the cheapest seller found until now) with the current seller. If, on the other hand, the price charged by the seller that is currently considered is higher or equal to the current minimum price, then this situation is dealt by the second clause that will make the buyer totally ignore this seller and continue the search by considering the next seller. The third clause deals with the case in which the buyer does not yet know the price that the current seller charges for the fruit: the buyer totally ignores this seller and continues the search. If the current seller does not have the quantity of fruit that the buyer needs, then this seller is ignored and the search carries on. Finally, the last clause is the one that terminates the search since all the sellers have been considered; the last argument of the goal is bound to the cheapest seller found until now, so if it is the nobody constant it means that the buyer is not going to buy the fruit (in fact, the first buy goods clause fails). After having considered a fruit, the buyer considers the next fruit in the list, until it has considered all the fruit it is interested in. The auxiliary buy from seller predicate is the one that sends a request to buy a fruit to a seller agent and is defined below: buy from seller(Seller,Goods,Quantity) :-address name(Seller,S),price(S,Goods,Price), money(M),M > 0,NM is M - Price,NM >= 0, pack(buy(Goods,Quantity),Str),
11
© 2010-2024 YouScribe