Systemy wieloagentowe (MAS) struktura komunikacji między agentami. Autor: Zofia Kruczkiewicz

Transkrypt

1 Systemy wieloagentowe (MAS) struktura komunikacji między agentami Autor: Zofia Kruczkiewicz

2 Agenda 1. Wprowadzenie do zagadnień komunikacji między agentami 2. Specyfikacje FIPA 3. Komunikacja między agentami BUI 4. Wiadomości typu ACL 5. Semantyka wiadomości ACL 6. Protokoły interakcji 7. Przykład aplikacji realizujacej standardowy protokół Contact-Net Projekt MASE 8. Zastosowanie różnych mechanizmów JADE (2) zastosowanie szablonów protokołów

3 1. Wprowadzenie do zagadnień komunikacji między agentami

4 Wieloagentowy system informatyczny

5 Jakie są agenty? Autonomous - autonomiczne Interactive - interaktywne Adaptive przystosowujące się Sociable zdolne do zachowań społecznych Mobile - mobilne Proxy mogą wystąpić jako pełnomocnicy w różnych zadaniach Proactive zorientowane na cel Rational zdolne do racjonalnego działania Unpredictable - nieprzewidywalne Temporally continuous zdolne do ciągłej realizacji procesu Transparent and accountable - zrozumiałe i odpowiedzialne Coordinative skoordynowane planem, mechanizmami zarządzania Cooperative - współpracujące Competitive rywalizujące bez wyrządzania szkody innym agentom Rugged zdolne do zarządzania danymi obarczonymi błędami i danymi niepewnymi Trustworthy godne zaufania

6 Klasyfikacja paradygmatów agentów Autonomia dynamiczna (reaktywna, proaktywna) wynika z wewnętrznej struktury agenta nieprzewidywalna, przewidywalna wynika z zewnętrznych warunków Adaptacja Reakcja Wnioskowanie Uczenie Ewolucja Interakcja Komunikacja Koordynacja Kooperacja Współzawodnictwo

7 Interakcja - Dostępne, otwarte, niedeterministyczne, dynamiczne, ciągłe (wg J.Ferber)

8 2. SPECYFIKACJE FIPA Foundation for Intelligent Physical Agents normy- specyfikują zewnętrzne zachowania agenta i jego współpracę z innymi podsystemami ujętymi w specyfikacji FIPA informacje o aplikacjach określające sposób użycia technologii FIPA

9 Specyfikacje FIPA 2005 (97)

10 Część 1 - Agent Management Część 1 opisuje normy dotyczące: istnieniem agentów operacyjnością agentów zarządzaniem agentami Definicja platformy agenta, pojęcie białej i żółtej księgi, przysyłaniem wiadomości oraz zarządzaniem cyklami życia agenta, akty komunikacyjne agenta wyrażające jego inteligentne zachowanie oraz odpowiadająca ontologia oraz język zawartości wiadomości

11

12 Część 2 - Język komunikacji agenta The FIPA Agent Communication Language (ACL) jest oparty na teorii aktów mowy: wiadomości są aktami komunikacyjnymi. Specyfikacja składa się : ze zbioru typów wiadomości, które zawierają opis pragmatyki tych wiadomości wyrażające stosunek typu BUI agenta do innego agenta/agentów. Opis jest przedstawiony w formie narracyjnej i formalnej opartej na logice modalnej. Ze zbioru opisów protokołów komunikacji

13

14 Część 3 - Reprezentacja wiadomości i transportu wiadomości FIPA Agent Message Transport specifications deal with the transport and representation

15 Część 4 - Integracja Agent/Software Część 4 opisuje sposób integrowania oprogramowania nieagentowego z oprogramowaniem agentowym: Systemy baz danych Oprogramowanie sieciowe Oprogramowanie narzędziowe

16

17 Część 5 - Aplikacje (Osobisty Asystent Podróży) Turystyka obejmuje następujące komponenty: Zaopatrzeniowiec Pośrednik Usługi osobiste Role te pełni agent typu PTA - Personal Travel Agent

18 Część 5 - Aplikacje (Osobisty Asystent) Jest nim półautonomiczny agent typu PA (Personal Assistant) o następujących cechach: Realizuje usługi zaopatrzeniowe Informuje Zarządza podstawowymi danymi Organizuje rozrywkę Planuje czas przeznaczony na pracę i odpoczynek Organizuje spotkania Część 5 - Aplikacje (Przedsięwzięcia Audio/Video i transmisje) Wybór właściwych programów uwzględniając preferencje użytkownika Negocjowanie zmiany w programach

19 Część 5 - Aplikacje (Zarządzanie i zabezpieczanie sieci) Dostarczanie usług końcowym użytkownikom zgodnie z zasadą jakości usług i kosztu usług Idea VPN (Virtual Private Network) połączenia z wybranymi użytkownika na ich życzenie, dostarczanie usług audiowizualnych Zapewniają te usługi trzy typy agentów: The Personal Communications Agent (PCA) reprezentuje użytkownika The Service Provider Agent (SPA) - dostarcza usługi The Network Provider Agent (NPA) umożliwia dostęp do sieci

20

21 3. Komunikacja między agentami - BUI Cechy komunikacji : Komunikacja między agentami wynika ze spełnianych przez nich misji. Oparta jest ona na następujących mentalnych atrybutach agenta: Belief (wiara) oznacza zbiór propozycji, które agent akceptuje i zbiór propozycji, które agent nie akceptuje podczas negocjacji Uncertainty (niepewność) oznacza zbiór propozycji, które agent akceptuje lub nie akceptuje z pewnym poziomem niepewności, czy są prawdziwe lub fałszywe. Oznacza to, że agent przyjmuje model negocjacji, gdy przedmiotem jest niepewna informacja Intention (intencja) oznacza intencję, zamiar lub cel lub zbiór celów, które agent uważa za prawdziwe i te, w ktore agent nie wierzy. Intencje są przedstawiane w postaci planu akcji (np. za pomocą mapy stanów), prowadzących do zmiany stanów świata rzeczywistego, wybieranych przez agenta

22 Wnioski (1) Sprzeczności: dana jest propozycja p - wtedy stan wiary p, stan niewiary p, stan niepewności p i stan pewności p wykluczają się wzajemnie. W rozproszonych systemach agent jest jedynie zdolny do spełnienia swoich intencji za pomocą wpływu wywieranego na innych agentów do wykonania akcji. Wpływ wywierany na innych agentów osiąga się za pomocą specjalnej klasy akcji zwanych aktami komunikacyjnymi (communicative acts) czyli wysyłaniu wiadomości zawierających zakodowany akt komunikacyjny przez nadawcę do odbiorcy. Ważną rolę odgrywa typ wiadomości oraz posiadanie tej samej wiedzy opartej na koncepcji BUI. Np. Agent i wierzy, że lepiej jest czytać książki niż oglądać TV i uważa, że agent j będzie uważał podobnie. Agent i w ACL inform informuje j swojej o wierze. Agent j na podstawie semantyki inform wie, że agent i chce wpłynąć na jego intencje dotyczące wiary w wartość czytania książek, ale dla agenta j przyjęcie wiary agenta i może stanowić pewien problem.

23 Wnioski (2) transport wiadomości między agentami struktura wiadomości syntaktyka transportu wiadomości ACL w postaci strumienia bajtów katalog standardowych aktów komunikacyjnych zbiór i definicja podstawowych protokołów komunikacji zawierających zbiór wiadomości definicja modelu semantyki komunikacji.

24 4. Wiadomości typu ACL

25 Cechy wiadomości - FIPA ACL Typ wiadomości jest zgodny z typem zawartości wiadomości, którą powinna charakteryzować: kompletność prostota zwięzłość. Wiadomość reprezentuje akt komunikacyjny, jest jego synonimem Semantyka języka komunikacji jest oparta na precyzyjnym formalizmie, pozbawionym sprzeczności.

26 Wymagania transportu wiadomości ACL Usługę transportu wiadomości spełnia system zarządzania agentami Wymagania usług transportu wiadomości (niezbędne): przesyłanie zakodowanej wiadomości w postaci sekwencji bajtów usługi transportu powinny być niezawodne, dokładne, uporządkowane (kolejność) nie spełnienie tych własności powinno być sygnalizowane agent ma opcję wyboru sposobu odebrania wiadomości: uśpienie lub oczekiwania na wiadomość (tryb synchroniczny) lub wykonywanie innych czynności podczas oczekiwania na odpowiedź czas przeterminowania nie jest parametrem aktu komunikacyjnego, tylko systemu usług transportu wiadomości po wykryciu błędów, system może wysłać informację o tym fakcie do nadawcy w postaci wiadomości o błędzie system zapewnia wybór poprawnego mechanizmu transportu (TCP/IP, SMTP, HTTP, etc)

27 Wymagania dotyczące wiadomości ACL Wymaganie 1: Agenty mogą wysłać wiadomość not-understood, jeśli otrzymają wiadomość, której nie rozpoznają lub nie są w stanie odczytać zawartości wiadomości. Agenty muszą odebrać i obsłużyć taką wiadomość Wymaganie 2: Agent powinien posiadać predefiniowany zbiór typów wiadomości i protokołów, zgodnych z definicją semantyki aktów komunikacyjnych Wymaganie 3: Agent nie może zmieniać znaczenia istniejących predefiniowanych aktów komunikacyjnych Wymaganie 4: Agenty mogą wprowadzać nowe akty komunikacyjne zrozumiałe przez odbiorcę, jednak nie wolno im nadawać znaczenia istniejących aktów komunikacyjnych.

28 Wymaganie 5: Agent powinien poprawnie syntaktycznie formułować zawartość generowanej wiadomości oraz z taką samą poprawnością odczytywać wiadomości. Zawartość wiadomości Zawartość wiadomości odpowiada przeznaczeniu aktu komunikacyjnego. Wiadomość czyli akt komunikacyjny jest zdaniem, natomiast zawartość jest gramatycznym obiektem zdania. Zawartość jest zapisana w języku podanym w parametrze :language. Wymaganie 6: Ogólnie, język zawartości wiadomości musi wyrażać propozycje, obiekty i akcje. Język ten służy jedynie do wyrażania typów akcji: propozycji, informowania, żądania itp. Stany propozycji - true lub false Obiekty rzeczy abstrakcyjne lub konkretne Akcje agent staje sie aktywny (iota <variable> <term>) np. iota x(p x) oznacza, że x taki, że P [jest prawdziwe] dla x. Słowo iota jest konstruktorem dla termów.

29 Definicja 1: Język zawartości wiadomości FIPA jest oparty na gramatyce s-wyrażeń lub jej podgramatyce i umożliwia wyrażanie propozycji, obiektów i akcji odpowiadających cyklowi życia agenta. Wymaganie 7: Agent jest zobowiązany do wyrażania swoich możliwości wymieniając wiadomości napisane za pomocą języka zawartości wiadomości i stosując określoną ontologię.

30 Budowa wiadomości ACL

31 Parametry :performative :sender :receiver :reply-with :in-reply-to :envelope Znaczenie wiadomości typ wiadomości Nazwa agenta nadającego akt komunikacyjny (opcjonalna) Nazwa agenta, do którego wysłana jest wiadomość. Może to być pojedyncza nazwa lub zbiór nazw agentów - multicasting (opcjonalna) Atrybut zawiera wyrażenie, które identyfikuje oryginalną wiadomość. Może być używane w wątku konwersacji, jeśli jednocześnie prowadzi się kilka dialogów jednocześnie. Np. Agent i wysyła wiadomość do agenta j wiadomość, która zawiera :reply-with query1, agent j powinien odpowiedzieć :in-reply-to query1. Wiadomość wysłana jako odpowiedź zawiera w tym atrybucie wyrażenie, które jest również zawarte w parametrze reply-with w odebranej wiadomości, Wyrażenie użyteczne dla systemu usług transportowych i zawiera czas wysłania, czas odbioru, trasę itp. Struktura koperty jest listą par słów kluczowych, które oznaczają pewne aspekty usług wiadomości

32 :content :language :encoding :ontology :reply-by :protocol :conversationid Atrybut zawiera dane wiadomości, czyli treść akcji Atrybut zawiera schemat kodowania zawartości wiadomości. Opis kodowania wyrażeń zawartych w wiadomości Oznacza ontologię, która jest używana do podania znaczenia symboli używanych w wyrażeniu zawartości wiadomości (często domyślna) Oznacza czas i/lub datę wyrażenia, która oznacza najdłuższy czas, po którym wysyłający agent oczekuje na odpowiedź Identyfikator oznacza protokół, który zastosował wysyłający agent. Protokół dodatkowo podaje kontekst wiadomości (opcjonalny). W domyślnej sytuacji każda wiadomość może być traktowana indywidualnie, bez stosowania protokołu. Nadaje się wtedy niezerowy conversation-id. Odpowiedzi mogą być identyfikowane za pomocą tego samego conversation-id. Czas przeterminowania w reply-by oznacza maksymalny czas oczekiwania na kolejną wiadomość wyznaczoną przez protokół Wyrażenie jest używane do identyfikacji sekwencji wychodzących wiadomości, które tworzą konwersację. Konwersacja może być użyta do zarządzania strategią komunikacji i aktywności agenta oraz do dodatkowej interpretacji znaczenia wiadomości

33 Wykaz standardowych wiadomości ACL

34 Typ wiadomości accept proposal agree cancel cfp confirm disconfirm failure inform inform if (macro act) inform ref (macro act) Interpretacja znaczenia wiadomości Nadawca akceptuje wykonanie zadania przez odbiorcę, które zostało wcześniej zaproponowane przez odbiorcę Nadawca zgadza się na wykonanie zleconego zadania przez odbiorcę w przyszłości po spełnieniu pewnych warunków Nadawca anuluje wykonania zadania przez odbiorcę Nadawca podaje propozycję wykonania zadania przez odbiorcę, podając definicję tego zadania Nadawca potwierdza odbiorcy, że ufa wysłanej wcześniej przez niego informacji (nadawca zazwyczaj nie ufa) Nadawca potwierdza odbiorcy, że nie ufa wysłanej wcześniej przez niego informacji (nadawca zazwyczaj ufa) Nadawca wykonuje zadanie, ale powiadamia odbiorcę, że nie może go skończyć Nadawca przesyła propozycję do odbiorcy Nadawca przesyła propozycję do odbiorcy, podając, czy jest prawdziwa Nadawca przesyła wiadomość do odbiorcy, zawierającą odwołanie do propozycję,

35 not understood propose query if query ref refuse reject proposal request request when request whenever subscribe Nadawca nie rozumie wiadomości otrzymanej wcześniej od odbiorcy i informuje go o tym Nadawca informuje odbiorcę, że przyjmuje jego propozycje wykonania zadania, podanego w wiadomości cfp Nadawca pyta odbiorcę, czy wysyłana propozycja jest prawdziwa Nadawca pyta odbiorcę, czy wskazana propozycja w wiadomości jest prawdziwa Nadawca odmawia odbiorcy wykonania zadania Nadawca nie przyjmuje propozycji od odbiorcy Nadawca żąda wykonania zadania przez odbiorcę Nadawca żąda wykonania zadania przez odbiorcę, kiedy zostaną spełnione podane propozycje Nadawca żąda wykonania zadania przez odbiorcę, w dowolnym momencie, kiedy zostaną spełnione podane propozycje w wiadomości Nadawca żąda, aby był przez odbiorcę powiadamiany o wskazanej informacji oraz o zmianach tej informacji

36 Zależności między wiadomościami ACL

37 Typ wiadomości Kategorie wiadomości Przesyłanie informacji Żądanie informacji Negocjacje Wykonanie akcji Osługa błędu accept-proposal + agree cancel + + cfp + confirm disconfirm + + failure + inform inform-if (macro act) inform-ref (macro act) not-understood + propose + query-if query-ref + + refuse + reject-proposal + request request-when request-whenever subscribe +

38 5. Semantyka wiadomości ACL

39 Semantyka języka ACL Język semantyki typu Semantic Language (SL) jest formalnym językiem używanych do definicji semantyki języka typu FIPA Agent Communication Language (FIPA ACL).

40 (I John (B Bob(temperature 10)))

41 Przykłady Definicja aktu komunikacyjnego <i, act (j, C)> Równoważna definicja aktu komunikacyjnego (act :sender i :receiver j :content C) FP: φ1 RE: φ2 gdzie i jest inicjatorem akcji, j jest uczestnikiem, act jest nazwą aktu, C reprezentuje semantyczny kontekst φ1 and φ2 są propozycjami, FP jest możliwym skutkiem działania act, RE jest racjonalnym efektem działania act.

42 Przykład (1) ogólny model request Model aktu komunikacyjnego typu request (FIPA00037, 2000): <i, request (j, a)> FP: φ1 RE: φ2 Równoważny zapis (request :sender i :receiver j :content a) FP: FP(a) [i\j] Bi Agent (j, a) Bi Ij Done (a) RE: Done (a)

43 Przykład (1) zastosowanie request Agent x żąda od agenta y, aby ten zarezerwował mu bilet. (request :sender (agent-identifier :name x) :receiver (set (agent-identifier :name y)) :content "((action (agent-identifier :name y) (reserve-ticket LHR MUC 27-sept-97) ))" :protocol fipa-request :language fipa-sl :reply-with order567)

44 Przykład (1) ogólny model agree Jeśli agent i może wykonać polecenie, wysyła wiadomość typu agree do agenta j <i, agree (j, <i, request>, φ))> <i, inform (j, Ii Done (<i, act>, φ))> FP: Bi α Bi (Bifj α Uifj α) RE: Bj α gdzie: α = Ii Done(<i, act>, φ)

45 Przykład (1) - zastosowanie agree Agent y odpowiada agentowi x, że zgadza się, ale pod warunkiem, że na koncie agenta x znajduje się wystarczająca ilość pieniędzy. (agree :sender (agent-identifier :name y) :receiver (set (agent-identifier :name x)) :content "( (action (agent-identifier :name y) (reserve-ticket LHR MUC 27-sept-97)) (sufficient- funds ac12345))" :in-reply-to order567 :protocol fipa-request :language fipa-sl)

46 Przykład (1) - ogólny model refuse Jeśli agent i odmawia agentowi j wykonania polecenia wysłanego w wiadomości typu request, wysyła do niego wiadomość typu refuse <i, refuse (j,<i, act>,φ)> <i, disconfirm (j, Feasible(<i, act>))>; <i, inform (j, φ Done (<i, act>) Ii Done (<i, act>))> FP: Bi Feasible (<i, act>) Bi (Bj Feasible (<i, act>) Uj Feasible (<i, act>)) Bi α Bi (Bifj α Uifj α) RE: Bj Feasible (<i, act>) Bj α gdzie: α = φ Done (<i, act>) Ii Done (<i, act>)

47 Przykład (1) zastosowanie refuse Agent y odpowiada, że odmawia rezerwacji biletu agentowi y, ponieważ brakuje pieniędzy na koncie (refuse :sender (agent-identifier :name y) :receiver (set (agent-identifier :name x)) :content "((action (agent-identifier :name y) (reserve-ticket LHR MUC 27-sept-97)) (insufficient- funds ac12345))" :in-reply-to order567 :protocol fipa-request :language fipa-sl)

48 Przykład (2) call for proposal Agent j składa propozycję agentowi i sprzedania mu 50 skrzynek śliwek (cfp :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content "((action (agent-identifier :name i) (sell plum 50)))" :ontology fruit-market :reply-with proposal2 )

49 Przykład (2) refuse Agent i odmawia agentowi j zakupu śliwek, gdy j nie ma wystarczającej kwoty na koncie: (refuse :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name i) (sell plum 50)) (insufficient-funds ac12345))" :language fipa-sl)

50 Przykład (2) - propose Agent i informuje j, że sprzeda 50 skrzynek ze śliwkami w cenie $200: ( propose :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action i (sell plum 50))(cost 200))" :ontology fruit-market :language fipa-sl :in-reply-to proposal3)

51 Przykład (2) reject-proposal Agent i informuje j, że odrzuca ofertę kupna śliwek od j, ponieważ cena jest za wysoka (reject-proposal :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (sell plum 50)) (cost 200) (price-too-high 50))" :in-reply-to proposal3)

52 Przykład (2) - inform (inform :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (sell plum 50)) (cost 200))" :language sl)

53 Przykład (2) - failure (failure :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (sell plum 50)) (error-message "No plum")) :language sl)

54

55

56 6. Protokoły interakcji Używane wiadomości w różnych konwersacjach mogą tworzyć pewien szablon, co prowadzi do definicji nowego typu protokołu interakcji Wymaganie 8: Agent nie musi implementować standardowych protokołów, jednak jeśli przyjęto nazwę standardowego protokołu, musi ona odpowiadać podanej w specyfikacji FIPA. Agent może brać udział w kilku konwersacjach jednocześnie prowadząc dialog z wieloma agentami. Konwersacje te mogą należeć do różnych protokołów. Należy zapewnić rozróżnialność poszczególnych wiadomości należących do różnych protokołów i konwersacji.

57 Przykład Specyfikacja protokołu, jeśli jest operacją (request :sender i :receiver j :content some-act :protocol fipa-request )

58 Notacja standardowego opisu protokołu prostokaty z podwójnymi krawędziami reprezentują akt komunikacyjny Biały prostokąt reprezentuje akcje podejmowane przez nadawcę Szare prostokaty reprezentują akcje podejmowane przez pozostałych uczestników protokołu Tekst napisany italikiem reprezentuje komnetarz

59 Protokół FIPA-request

60

61 Protokół FIPA-request-when

62

63 FIPA-query Protocol

64

65 Protokół FIPA-contract-net

66

67 FIPA-Iterated-Contract-Net Protocol

68

69

70 7. Przykład aplikacji realizujacej standardowy protokół Contact- Net Projekt MASE

71

72

73

74

75

76

77

78 receive(inform) receive(failure) send(cfp) send(reject-proposal) receive(propose) Deadline for proposals send(accept -proposal)

79 send(failure) send(inform) receive(cfp) receive(reject -proposal) refuse send(propose) receive (acceptproposal)

80

81

82 8. Zastosowanie różnych mechanizmów JADE (2) zastosowanie szablonów protokołów

83

84

85

86

87 Zachowania Jade

88 Inicjator protokołu import jade.core.*; import jade.lang.acl.aclmessage; import jade.proto.contractnetinitiator; import jade.domain.fipanames; import java.awt.event.*; import java.util.*; import javax.swing.*; // deficja agenta typu inicjator protokołu typu FIPA-Contract-Net public class ContractNetInitiatorAgent1 extends Agent { int inicjowanierandom; //dane do realizacji losowych zadań int liczbaodbiorcow; //liczba agentów usługodawców String odbiorcy = ""; //łańcuch zawierający nazwy agentów usługodawców //wiadomość typu cfp protokolu ContarctNet ACLMessage wiadomosc = new ACLMessage(ACLMessage.CFP); //definicja komponentów interfejsu graficznego agenta typu inicjator //metoda Ramka tworząca interfejs graficzny użytkownika i przygotowująca wiadomość typu cfp void Ramka(Agent a) { final Agent ag = a; ramka = new JFrame("Agent inicjator"); ramka.setsize(300, 420); ramka.setdefaultcloseoperation(jframe.dispose_on_close);

89 //obsługa zdarzeń GUI agenta usługobiorcy zatwierdz.addactionlistener(new ActionListener() public void actionperformed(actionevent evt) { // kod źródłowy metody, która przygotowuje wiadomość typu cfp // i wstawia zachowanie typu NowyContractNetInitiator //które po uruchomieniu wysyła wiadomość typu cfp } }); //wstawianie komponentów GUI do obiektu ramka typu // wywołanie metody setup agenta inicjujące działania agenta protected void setup() { Ramka(this); }} //definicja klasy typu Behaviour do obsługi protokołu typu FIPA-Contract-Net po stronie agenta inicjatora class NowyContractNetInitiator extends ContractNetInitiator { int liczbaodbiorcow; int inicjowanierandom; JTextArea komentarz; //kontakt z GUI agenta inicjatora NowyContractNetInitiator(Agent agent, ACLMessage wiadomosc, int liczbaodbiorcow_, int inicjowanierandom_, JTextArea kom) { // kod źródłowy konstruktora }

90 @Override //obsługa odbioru wiadomości typu refuse protected void handlerefuse(aclmessage refuse) { // kod źródłowy metody // obsługa odbioru wiadomości typu propose protected void handlepropose(aclmessage propozycja, Vector v) { // kod źródłowy metody } //obsługa odbioru wiadomości typu propose oraz przygotowanie się do wysłania wiadomości typu //reject-proposal lub protected void handleallresponses(vector odbiorcy, Vector wybrani) { //reakcja na przekroczenie czasu oczekiwania na propozycje // kod źródłowy metody // obsługa odbioru wiadomości typu failure protected void handlefailure(aclmessage failure) { // kod źródłowy metody //obsługa wiadomości typu inform protected void handleinform(aclmessage inform) { // kod źródłowy metody } //pomocnicza metoda do obsługi zlecania zadań public byte[] wypelnij(int n, int m, int offset, int zakres) { // kod źródłowy metody return tablica1; } }

91 Odbiorca import jade.core.agent; import jade.lang.acl.*; import jade.domain.*; import jade.domain.fipaagentmanagement.*; import jade.proto.contractnetresponder; import javax.swing.*; // klasa agenta typu odbiorca public class ContractNetResponderAgent1 extends Agent { // definicja komponentów GUI agenta odbiorcy //metoda Ramka służy do budowy GUI agenta odbiorcy void Ramka() { // kod źródłowy metody tworzacej GUI } // metoda inicjująca agenta typu odbiorca - tworzy GUI użytkownika // i wstawia zachowanie agenta typu NowyContractNetResponder // do obsługi nadawania i odbioru wiadomości po stronie odbiorczej protected void setup() { // kod źródłowy metody }

92 // definicja klasy NowyContractNetResponder do obsługi // nadawania i odbioru wiadomości po stronie odbiorczej // protokołu FIPA-Contract-Net class NowyContractNetResponder extends ContractNetResponder { JTextArea komentarz; // elementy łączące z GUI agenta //odbiorcy JFrame ramka; //definicja konstruktora klasy NowyContractNetResponder NowyContractNetResponder(Agent agent, MessageTemplate szablon, JTextArea komentarz_, JFrame ramka_) { //kod źródłowy konstruktora }

93 // metoda do obsługi wysłania wiadomości propose lub wysłania wiadomości protected ACLMessage prepareresponse( ACLMessage wezwanie_do_propozycji) throws NotUnderstoodException, RefuseException{ // kod źródłowy metody } // metody do obsługi odbioru wiadomości typu protected void handlerejectproposal(aclmessage wezwanie_do_propozycji, ACLMessage propozycja, ACLMessage akceptacja) { // kod źródłowy metody } // metoda do obsługi wysłania wiadomości propose lub wysłania wiadomości refuse oraz // wysłania wiadomości typu inform w przypadku zaakceptowania propozycji zawartej // w wiadomości propose wykonania zadania lub failure w przypadku niepowodzenia // podczas realizacji protected ACLMessage prepareresultnotification( ACLMessage wezwanie_do_propozycji, ACLMessage propozycja, ACLMessage akceptacja) throws FailureException { // kod źródłowy metody } //koniec metody } //koniec definicji klasy NowyContractNetResponder

94 Start systemu agenta inicjator przygotowuje dane zlecanego zadania, agenci odbiorcy r1 i r2 oczekują na wiadomość typu cfp

95 Przygotowanie danych do wysłania wiadomości typu propose przez agentów typu odbiorcy

96 Reakcje agenta inicjatora na spóźnione nadesłanie wiadomości typu propose ze strony agentów usługodawców wysłanie wiadomości reject-proposal

97 Przypadek odebrania propozycji wysłanych przez agentów usługodawców agentowi wysłanie accept-proposal oraz reject-proposal

98 Przypadek akceptacji przez agenta usługobiorcę propozycji w wiadomości propose wysłanej przez agenta usługodawcę r1 i następnie wysłanie przez agenta r1 informacji o wykonanym zadaniu wysłanie inform

99

100

101

102

103