Paweł Krajna Wrocław, 5.04.2007 Informatyka Systemów Autonomicznych Praca zaliczeniowa Temat: ACL - język komunikacji. Spis treści Wstęp...2 Dokumentacja...2 Przegląd komunikacji między agentami...3 Mechanizmy wysyłania wiadomości...3 Wiadomość w języku ACL...3 Struktura wiadomości...4 Parametry wiadomości...4 Zawartość wiadomości...4 Akty komunikacji (communicative acts)...5 Prymitywny akt komunikacji...5 Złożony akt komunikacji...6 Protokoły...7 Framework JADE...7 Przykład przygotowania i wysłania prostego komunikatu...7 Odbieranie komunikatu...8 Słowo zakończenia...8 Literatura...9 1
Wstęp ACL (ang. Agent Communication Language) jak wynika z rozwinięcia skrótu jest to język, który pozwala agentom komunikować się między sobą za pomącą wiadomości posiadających określoną strukturę. W mojej pracy postaram się opisać ten język, strukturę komunikatów oraz protokół komunikacji na tyle dobrze na ile robi to FIPA [1] w wydanych specyfikacjach. Pokaże również inny znacznie prostszy sposób programowania systemów wieloagentowych przy użyciu darmowego (dostępny na licencji GNU LGPL) frameworku JADE [4]. Pozwala on konstruować i administrować agentów zgodnych z FIPA. Jest to druga część mojej pracy. Wszystkie zawarte przykłady opierają się na zbieraniu informacji o pogodzie. Wiadomości zawierają treść w języku Prolog i/lub XML. Dokumentacja FIPA (ang. Foundation for Intelligent Physical Agents) -fundacja powstała, aby tworzyć standardy pozwalające budować systemy oparte na agentach. FIPA tworzy przede wszystkim standardy związane z komunikacją i współpracą agentów w systemach wieloagentowych. Stawia wymagania, które powodują że systemy rozwijane przez różne organizacje, mogą z sobą współpracować. definicje: Pierwszą ze specyfikacji wydanych przez fundacje jest FIPA 97 [2]. Zawiera ona Agent management [3]: normatywny framework, w ramach którego agent FIPA może istnieć, pracować i być sterowany; ACL: zbiór komunikatów i ich opis; Agent/Software integration: sugestia w jaki sposób agenci mogą się komunikować z otoczeniem (oprogramowaniem, systemami baz danych, sterownikami, itp.) Personal travel assistance; Personal assistant; Audio/video entertainment and broadcasting; Network mamagement and provisioning. Ostatnie cztery dokumenty przedstawiają implementacje i przykłady rozwiązań oparte 2
na wymaganiach opisanych w trzech pierwszych dokumentach. Przegląd komunikacji między agentami Specyfikacja FIPA ACL nie definiuje otwarcie czym jest agent albo w jaki sposób powinien być zaimplementowany, jednak zakłada szereg jego właściwości: agent posiada poglądy mentalne: wiara: zbiór własności, które agent uznaje za prawdziwe; tolerancja niepewności: zbiór własności, które agent akceptuje, ponieważ wydają się być bardziej prawdą niż fałszem; zamiary: zbiór własności, które agent chciałby uznać za prawdziwe ale nie wierzy, że są prawdziwe. Agent tworzy plan doprowadzenia świata do stanu, który pożąda. Agent podejmuje pewne akcje zwane aktem rozmowy polegające na wysyłaniu komunikatów. Sam język ACL dotyczy komunikacji między agentami poprzez przesyłanie wiadomości. Mechanizmy wysyłania wiadomości ACL zminimalizował wymagania dotyczące usługi dostarczania wiadomości na tyle, że agenci mogą używać różnorodnych protokołow komunikacji (TCP/IP, HTTP, SMTP, GSM,...); chodzi wyłącznie o to żeby przesłać tekstową wiadomość przez pojedynczy strumień bajtów. ACL nakłada następujące wymagania na protokół (Agent management): Protokół potrafi dostarczyć wiadomość jako sekwencję bajtów; Agent może zadecydować czy transmisja odbywa się asynchronicznie (może kontynuować prace w czasie, w którym musiałby oczekiwać na odpowiedz) czy synchronicznie; Parametry dostarczenia wiadomości (takie jak time out...) mogą być modyfikowane; Agent zostanie zwrotnie poinformowany o warunkach wystąpienia błędu (niedostarczalny, nieosiągalny, źle sformatowana wiadomość,...); Wiadomość w języku ACL Nie jest konieczne żeby agent implementował wszystkie typy wiadomości, jednak jest 3
postawione minimalne wymaganie dla zapewnienia zgodności z ACL: Agent jest zdolny do wysyłania i rozumienia wiadomości; Wiadomość ACL musi być poprawnie zaimplementowana zgodnie z definicją semantyczną; Nowy komunikat nie powinien oznaczać tego samego co inny zdefiniowany standardem; Agent musi być zdolny do generowania syntaktycznie poprawnych, zdefiniowanych wiadomości. Struktura wiadomości Główny element wiadomości ma następującą postać: (inform :sender pawel :receiver gawel :content weather(today, snowing) :in-reply-to g01 :reply-with p01 :language Prolog :ontology weather ) Jak widzimy pierwszy element wiadomości ACL (inform) to słowo identyfikujące akt komunikacji; reszta sekwencji to parametry wiadomości. Parametry wiadomości Parametry mogą występować w wiadomości w dowolnej kolejności. Jedyny wymagany parametr to :receiver aby wiadomość mogła być poprawnie dostarczona. Pełna lista zdefiniowanych parametrów zawiera parametry takie jak :sender i :receiver (nadawca i odbiorca wiadomości), :content i :language opisujące treść, :protocol identyfikujący protokół rozmowy, :reply-with określający wyrażenie użyte później w odpowiedzi przez odbiorce po to by nadawca wiedział do jakiej orginalnej wiadomości odnosi się odpowiedz, :in-reply-to z wyrażeniem przekazanym w prametrze :reply-with, :ontology określa kontekst wiadomości, :envelope (zawartość nie jest sprecyzowana w dokumentacji, może zawierać takie informacje jak czas wysłania, czas odbioru, routing, etc.) :repley-by, :conversation-id. Zawartość wiadomości Zawartość wiadomości odnosi się do tego co zgłasza akt komunikacji (jeżeli akt 4
komunikacji jest sentencją to zawartość komunikacji jest jej obiektem gramatycznym). Nie ma konkretnego języka zawartości. ACL narzuca jedynie warunek, że język zawartości potrafi wyrazić propozycje, obiekt i akcje: propozycja: oświadcza, że jakieś zdanie języka jest prawdą lub fałszem; obiekt: definiuje w języku niezdefiniowane rzeczy (przez nazwę); akcja: czynność jaka może być wykonana przez agenta. Agent musi być pewny, że język zawartości wiadomości jest pospolicie używanym językiem. Język ten może być uzgodniony na różne sposoby: przez przyjętą konwencję: oficjalny język, który każdy agent zrozumie (np. XML); negocjacje: agenci muszą wspólnie zadecydować jakiego języka będą używać; tłumaczenie: agent musi zaangażować usługę pośrednika w tłumaczeniu. Zazwyczaj agenci ustalają język na drodze negocjacji. Akty komunikacji (communicative acts) Akt komunikacji to proste bloki dialogu między dwoma agentami. Akt komunikacji jest niezależny od zawartości poszczególnych komunikatów i wykonuje się poprzez wysłanie wiadomości przez jednego agenta do drugiego. Istnieją dwie kategorie aktu komunikacji: prymitywny: złożony z co najwyżej jednego aktu komunikacji złożony: złożony z więcej niż jednego aktu (query-if act: Ja request ciebie: inform mnie pogoda jest pada snieg ), możliwy operator ; (a;b -akcja a poprzedza b); możliwy operator (a b -akcja a albo akcja b) Prymitywny akt komunikacji Przykład (potwierdzenie niepewnej propozycji z potwierdzeniem): (confirm :sender pawel :reciwer gawel :content weather(today,snowing) :language Prolog <!DOCTYPE request SYSTEM "request.dtd"> <request> <sender>pawel</sender> <receiver>gawel</receiver> <content> 5
) <action>weather</action> <args>today</args> <args>snowing</args> </content> <languange>prolog</languange> </request> Agent pawel jest zdolny potwierdzić własność w agentowi gawel tylko jeżeli pawel wierzy w w. Agent pawel musi wierzyć, że gaweł jest niepewny co do własności w. Nadawca życzy również gawlowi aby uwierzył we własność w. Plik request.dtd definiuje formalną strukturę dokumentu XML. Złożony akt komunikacji Przykład (agent nie ma żadnej wiedzy żeby wysłać propozycje: agent pawel pyta gawla o informacje o pogodzie we Wrocławiu na Dolnym Śląsku): (request :sender pawel :reciwer gawel :content (inform-if :sender pawel :reciwer gawel :content in(wroclaw, Dolny Slask ) :language Prolog ) :language sl ) <!DOCTYPE request SYSTEM "request.dtd"> <request> <sender>pawel</sender> <receiver>gawel</receiver> <content> <inform-if> <sender>pawel</sender> <receiver>gawel</receiver> <content> <action>in</action> <args>wroclaw</args> <args>dolny Slask</args> <content> <languange>prolog</languange> </inform-if> </content> <languange>prolog</languange> </request> Należy wyjaśnić nazwę inform akt: <pawel,inform-if(gawel,propozycja)> jest równoważne <pawel,inform(gawel,propozycja)> <pawel,inform(gawel,not(propozycja))> Na powyższych przykładach wyraźnie widać różnicę między prymitywnym i złożonym 6
aktem komunikacyjnym. Protokoły Trwająca rozmowę między agentami często przybiera postać typowego wzorca wiadomości zwany protokołem. Za prosty przykład protokołu może posłużyć FIPA-Request, który pozwala jednemu agentowi zapytać innego o wykonanie pewnej akcji, otrzymanie agenta do wykonania akcji lub odpowiedz, że nie jest w stanie jej wykonać. Graf 1. FIPA -Protokół Request. Framework JADE W ramach frameworku JADE [5], język komunikatów został zaimplementowany w postaci klasy jade.lang.acl.aclmessage. Klasa ta posiada szereg metod umożliwiających wygodne konstruowanie i przetwarzanie treści komunikatów: get / setperformative(); get / setsender(); add / getallreceiver(); get / setlanguage(); get / setontology(); get / setcontent(); Przykład przygotowania i wysłania prostego komunikatu ACLMessage msg = new ACLMessage( ACLMessage. INFORM); msg.addreceiver( new AID( pawel, AID.ISLOCALNAME)); msg.setlanguage( Prolog ); 7
msg.setontology( weather ); msg. setcontent( weather(today, snowing) ); send( msg); // myagent.send( msg ); Odbieranie komunikatu ACLMessage msg = receive(); // myagent.receive( msg ); if (msg!= null) { // Przetwarzanie komunikatu } else { block( ); /*block() -metoda klasy Behaviour powodująca przeniesienie danego zachowania z kolejki aktywnych zachowań w stan zablokowania */ } Po otrzymaniu dowolnego komunikatu (przez Agenta) wszystkie zablokowane zachowania są ponownie umieszczane w kolejce zachowań. Do selektywnego odczytywania komunikatów należy wykorzystywać obiekty klasy jade.lang.acl.messagetemplate: MessageTemplate tpl = MessageTemplate.MatchOntology( weather ); public void action() { ACLMessage msg = myagent.receive(tpl); if (msg!= null) { // Przetwarzanie komunikatu } Słowo zakończenia Jak widać język komunikacji agentów to proste zagadnienie i można by pokusić się o własną implementację. Jednak stosowanie ogólnie przyjętego standardu pozwalaja usystematyzować strukturę wysyłanych wiadomości i zapewnić komunikację między niezależnymi agentami lub agentem a systemem. Daje to szersze, wręcz nieograniczone możliwości. Sposobności te spowodowały, że programy implementujące agentów są dziś stosowane od początku procesu handlowego, czyli od marketingu i bezpośredniego kontaktu z klientem, poprzez rekomendowanie produktów, wyszukiwanie towarów i dostawców, negocjowanie cen, warunków dostawy, gwarancji, aż po reprezentowanie człowieka na aukcjach i rynkach elektronicznych. Przykładem jest agent SouthamptonTAC, który wykorzystuje logikę rozmytą do określania kategorii aukcji, w jakiej bierze aktualnie udział i na tej podstawie dobiera strategię i 8
decyduje, czy kupować towar, czy czekać [6]. Prowadzone są prace badawcze nad zastosowaniem tego typu agentów na giełdzie papierów wartościowych tak, aby wspomóc, a może nawet zastąpić, maklerów giełdowych. Możliwe że w przyszłości agenci w pełni zastąpią człowieka w procesie handlu elektronicznego. Literatura [1] Strona domowa FIPA: http://www.fipa.org/repository/fipa97.html [2] Strona zawierająca listę odnośników do użytych w pracy dokumentów: http://www.fipa.org/repository/fipa97.html [3] Specyfikacja Agent Communication Language (dokument: Part 2, FIPA 97): http://www.fipa.org/specs/fipa00003/oc00003.pdf [4] Strona domowa projektu JADE: http://jade.tilab.com/ [5] Pełna dokumentacja JADE: http://jade.tilab.com/doc/index.html [6] M. Brooke-Smith, Is it possible that human stockbrokers could, one day, be replaced with computer based agent traders?, 2nd Annual CM316 Conference on Multimedia Systems, Southampton University, UK 12th January 2002, http://mms.ecs.soton.ac.uk/mms2002/papers/29.pdf 9