O abordare teoretică și practică
a unui domeniu de mare actualitate în domeniul software.

Cuvîntul agent poate duce cu gîndul fie la angajații unei agenții de spionaj, fie la virușii informatici ai unei lumi supertehnologizate dintr-un viitor desprins din sfera SF-ului. Aceasta, firește, în cazul în care agent se rostește în mediile ce nu au prea mare tangență cu cel al calculatoarelor. Se pune atunci întrebarea: dar ce se înțelege prin agent în domeniul științei acesteia din urmă? Ei bine, problema este la fel de confuză, datorită varietății domeniului în care un agent se poate utiliza. Ramura numită Inteligența Artificială are o poziție diferită față de cea care tratează Rețelele de Calculatoare, care are la rîndul ei o altă poziție față de domeniul Bazelor de Date ș.a.m.d. Alte surse de confuzie mai sînt și 'sferele' unde cuvîntul agent este utilizat, adică mediul academic sau cel comercial. Cert este că o seamă de lucrări tratează tehnologia agent și fiecare din acestea propune o anumită vedere - mai mult sau mai puțin acceptată de comunitatea de specialiști - legată de acest subiect.

Acest articol își propune să prezinte cititorului mediul agent AWB, dezvoltat de către IBM Japan Laboratories. Mai întîi, trebuie, însă, introdusă noțiunea de agent mobil și aceasta în contextul mai larg al agenților software. Fiți, deci, pregătiți pentru o călătorie cu următorul itinerar: AWB, agent mobil, agent software. În ordine inversă însă, firește !

Agenții Software

Agenții software formează un subdomeniu de studiu din cadrul Inteligenței Artificiale Distribuite (DAI – Distributed Artificial Inteligence). Din punctul de vedere al direcțiilor de cercetare s-au evidențiat în timp două curente. Primul curent avea în vedere agenții inteligenți, concentrîndu-se în principal pe agenții deliberativi ce conțineau intern modele simbolice. Un agent deliberativ este „un agent care posedă un model explicit și simbolic al lumii și ale cărui decizii – legate, spre exemplu, de acțiunile pe care dorește să le execute – sînt făcute pe baza raționării simbolice (symbolic reasoning)“ [NWANA]. În plus, cercetarea era focalizată și asupra problemelor de interacțiune și comunicare dintre agenți, decompoziție și distribuție a sarcinilor (task-urilor), coordonare și cooperare, rezolvarea conflictelor prin negociere etc. Aceste studii au dus la realizarea unor sisteme de specialitate, cum ar fi : modelul actor (Hewitt, 1977), MACE (Gasser & Co., 1987), DVMT (Lesser & Corkill, 1981) etc. Al doilea curent de dezvoltare al sistemelor agent s-a evidențiat prin diversificarea tipologiei acestora. Consecința a fost identificarea, clasificarea și dezvoltarea a numeroase sisteme agent, ce prezentau particularități în cadrul modelelor lor conceptuale, însă toate avînd la bază scheletul și caracteristicile unui sistem agent clasic.

Tipologia agent

O tipologie semnifică studiul tipurilor unor entități. Următoarele rînduri vor prezenta o posibilă clasificare a agenților existenți, în diferite tipuri de clase agent. Clasificarea se va realiza pe baza identificării unei trăsături definitorii pentru un anumit tip de agent. Firește, faptul că un agent face parte dintr-o anumită clasă nu înseamnă că nu poate poseda și alte trăsături, definitorii altei clase. Astfel, avem următoarea clasificare, în funcție de: gradul de mobilitate, tipul de raționare și tipul de comportament.

Gradul de mobilitate. Mobilitatea semnifică abilitatea agenților de a se deplasa prin rețea. În funcție de gradul de mobilitate, putem evidenția două clase agent: clasa agenților mobili și clasa agenților statici.

Tipul de raționare. Raportat la tipul de raționare există două clase agent: clasa agenților deliberativi și clasa agenților reactivi. Agenții deliberativi posedă o stare internă descrisă simbolic, un model de raționare și se înscriu în planificare și negociere alături de alți agenți. Agenții reactivi, din contră, nu posedă stare internă sau modele simbolice ale mediului lor de existența, ci acționează pe baza comportamentului stimul - răspuns, prin răspuns imediat dat stării curente a mediului în care ei ființează.

Tipul de comportament. Următoarea clasificare așează agenții în funcție de idealurile și caracteristicile primare pe care aceștia ar trebui să le urmeze, adică: autonomie, învățare și cooperare (vezi figura „Tipuri de agenți în funcție de comportament“). Autonomia se referă la faptul că agenții autonomi pot opera fără nevoia de asistență umană. Astfel, acești agenți posedă stări și scopuri individuale și acționează în așa fel încît să îndeplinească sarcinile utilizatorului, pe a cărui încredere își desfășoară activitatea. O trăsătură cheie a autonomiei o reprezintă abilitatea de a lua inițiativa, în contrast cu simple răspunsuri la me-diu. Cooperarea se referă la capacitatea agenților de a aborda în comun aceleași „subiecte de interes“, în ideea ducerii la bun sfîrșit a ceea ce și-au propus. Pentru a coopera, agenții trebuie să posede abilități sociale, cum ar fi abilitatea de a interacționa cu alți agenți și/sau oameni, pe baza unui limbaj de comunicare. Învățarea este o caracteristică a agenților care își adaugă cunoștințe noi stărilor lor interne, pe baza reacțiilor proprii și/sau interacțiunii lor cu mediul exterior. Pe baza acestor trei tipuri de clase agent – să le zicem fundamentale – putem identifica alte clase agent, după cum arată și figura „Tipuri de agenți, în funcție de comportament“. Firește, disjunctivitatea zonelor existente în figura menționată anterior nu trebuie privită în sens strict geometric. Spre exemplu, pentru agenții colaborativi există și posibilitatea ca aceștia să posede facilități de învățare, însă într-o măsură mai mică decît acelea legate de cooperare și autonomie – altfel spus, nu trebuie dedus din figură faptul că agenții colaborativi nu învață niciodată.

În principiu, agenții există într-un adevărat spațiu multidimensional. Din cadrul acestui spațiu, am identificat o listă care se dorește suficient de cuprinzătoare pentru a conține cele mai utilizate clase agent. Există unele aplicații care combină agenții corespunzători mai multor categorii menționate anterior, sistemele în cauză numindu-se sisteme agent eterogene. Iată, deci, variata familie din care fac parte agenții mobili. Definiția unui agent mobil, trăsăturile definitorii acestuia și modul de funcționare sînt descrise în următoarea secțiune.

Agenții mobili

„Agenții mobili sînt procese software computaționale capabile să călătorească prin rețele WAN (ca de exemplu WWW), să interacționeze cu hosturi străine, în scopul obținerii unor informații pentru utilizatorul care i-a creat și apoi să se întoarcă acolo de unde au plecat și să prezinte rezultatul călătoriei lor“ [NWANA]. Pe lîngă abilitatea de a fi mobili, acești agenți mai prezintă cel puțin două trăsături : autonomie și cooperare. Cu aceste caracteristici, agenții mobili pot fi utilizați cu succes în rezolvarea problemelor de natură distribuită, cum ar fi, spre exemplu, rezervarea de locuri pentru o călătorie cu avionul sau întreținerea unei rețele de telecomunicații.

Spuneam că agenții pot fi clasificați în funcție de gradul de mobilitate în două categorii : agenți mobili și agenți statici. Se poate vorbi însă și de existența a mai multe grade de mobilitate pentru agenții mobili. Aceste grade oferă puterea agenților în a executa sarcini în mediul distribuit.

Să revenim la exemplul legat de rezervarea unui bilet de avion și să încercăm să îl dezvoltăm. Apoi vom evidenția avantajele ce decurg din realizarea acestui task de către un agent mobil, față de un sistem clasic de interogare.

Deci, un utilizator dorește să își facă o rezervare de loc pentru o călătorie cu avionul. Alături de această cerință, mai sunt o sumă de condiții pe care le pune călătorul: plecarea să nu fie mai tîrziu de ora X sau mai devreme de Y, compartimentul să fie pentru nefumători, să se sincronizeze cu zborul Z din aeroportul K ș.a.m.d. Toate aceste informații vor trebui încărcate în baza de date a unui agent mobil, care va avea ca itinerar hosturile pe care se găsesc bazele de date ale liniilor aeriene existente. Odată ajuns la un astfel de host, agentul ar putea extrage datele ce se conformează restricțiilor sale, după care ar merge pe următorul host și ar calcula noul orar în funcție de restricțiile inițiale și de datele obținute pînă în acel moment. În final, agentul s-ar reîntoarce la proprietarul său și ar prezenta un program de călătorie conținînd cele mai bune variante ce se supun condițiilor impuse. Alternativa acestei probleme soluționată cu ajutorul agenților mobili ar fi rezolvarea prin căile clasice, adică: se va interoga la distanță fiecare server de baze de date al liniilor aeriene dorite, iar după ce întregul set de date va ajunge pe hostul utilizatorului se va începe procesarea lor pentru a furniza calendarul final al posibilelor călătorii.

Care ar fi avantajele folosirii unui agent mobil în scenariul de mai sus? Iată doar cîteva:

Costurile de comunicație scăzute: doar datele cu adevărat utile ar ajunge la utilizator, celelalte fiind lăsate acolo unde nu s-au mai dovedit a fi folositoare. Prin aceste costuri, putem înțelege atît cele legate de timp, cît și de transfer de date.

Resurse hardware și software nepretențioase: aceste resurse ar putea fi suficient de puternice, încît să faciliteze manipularea agenților existenți și a datelor duse/aduse de aceștia.

Coordonare ușoară: s-a dovedit că este mai ușor să se coordoneze un număr de cereri independente și la distanță, decît ca acestea să fie coordonate local.

Calcul asincron: odată ce agentul ar pleca, utilizatorul și-ar putea consuma timpul concentrîndu-se asupra altei probleme – știind însă că rezultatul îi va veni la un moment dat. Utilizatorul s-ar putea chiar deconecta de la rețea, agentul așteptînd să se reconecteze pentru a se reîntoarce de unde a plecat.

Arhitectură distribuită foarte flexibilă: într-adevăr, agenții mobili furnizează o arhitectură foarte flexibilă în comparație cu arhitecturile distribuite clasice – cum este alternativa prezentată mai devreme.

Trăsăturile de mai sus ar putea convinge ușor un utilizator să apeleze la serviciile unui agent pentru a-i rezolva o problemă sau alta. Ei bine, lucrurile nu stau chiar așa. Următoarele rînduri ar face ca respectivul utilizator să mai cugete asupra deciziei de a utiliza agenți deoarece există o serie de probleme ce apar atunci cînd unui agent i se dă o sarcină spre a o îndeplini.

Problemele sînt următoarele:

Problema transportului: cum se transportă un agent dintr-un loc în altul; cum își modifică un agent structura în vederea acestui transport?

Problema autentificării: cum putem fi siguri că agentul care se prezintă este și agentul care spune că este? Problema secretului: cum putem fi siguri că agentul nostru ne poate proteja informațiile pe care i le furnizăm; cum putem fi siguri că altcineva nu încearcă să ne„deturneze“ agentul, pentru propriile lui scopuri; cum putem fi siguri că agentul nostru nu a fost „ucis“ iar codul său citit printr-un „dump“ al memoriei?

Problema securității: cum putem să ne ferim de agenți-viruși; cum putem să ne ferim de agenți malefici, cum ar fi acela care sosește pe un host și începe să bucleze la infinit, avînd ca scop reducerea capacității sistemului sau începe să se replice la nesfîrșit, dorind o cădere a sistemului din cauza memoriei insuficiente?

Ei bine, la toate aceste probleme se poate răspunde concret, în măsura în care se dezvoltă un mediu agent concret. Fiecare sistem agent are propria sa părere despre cum trebuie tratată, fie problema securității, fie cea a autentificării, fie o altă problemă. Și, în plus, acestea mai trebuie privite și din punctul de vedere al primitivelor de dezvoltare ale mediului agent, aceste primitive însemnînd atît echipamente hardware, cît și software, cum ar fi sistemul de operare deasupra căruia rulează mediul agent, limbajul de programare utilizat la scrierea mediului etc. Următoarea secțiune prezintă noțiunea de mediu agent sau sistem agent.

Sisteme Agent

Noua tehnologie ce reprezintă agentul a făcut ca numeroase firme, universități, laboratoare de cercetare sau, pur și simplu, persoane să dezvolte sisteme agent, fiecare avînd la bază o anumită înțelegere a fenomenului. Acest lucru s-a întîmplat și în cazul mediilor agenților mobili, și putem da ca exemplu: IBM (Aglets), General Magic (Odyssey), Darthmouth College (AgentTcl) și altele. Datorită acestei mari varietăți de medii agent, s-a ajuns, în mod normal, la apariția unei incompatibilități între agenții acestor medii. Această incompatibilitate se remarca la toate nivelele, adică un agent al unui mediu nu putea fi găzduit de un alt mediu sau nu putea accesa resursele gestionate de respectivul mediu sau nu putea comunica cu agenții locali ș.a.m.d.

Pentru a veni în sprijinul rezolvării acestei probleme, mai multe firme dezvoltatoare de sisteme agent (vezi [MAF]) au realizat o specificație, pe baza căreia să se poată dezvolta sisteme agent diverse, agenții acestora putînd însă interacționa. Astfel, s-au identificat părțile comune pe care le posedă mediile agent, adică acelea legate de interacțiune, transfer de agenți și securitate. Mai apoi s-au extras un set de trăsături în ideea standardizării acestora, pentru a promova atît interoperabilitatea agenților, cît și îmbunătățirea mediilor agent. Acest document, denumit Mobile Agent Facitity Specification (MAF), a fost propus spre standardizare comisiei OMG. În cadrul lui, se pot găsi atît definițiile noțiunilor de bază (agent, agent staționar, agent mobil, starea unui agent, numele unui agent, locul unui agent, sistem agent) cît și modalitățile de interacțiune a noului standard cu tehnologiile deja existente în acest moment, cum ar fi CORBA. Iată un extras a ceea ce au înțeles realizatorii MAF legat de tehnologia agent. [MAF]

Un agent este un program software ce rulează autonom, pe încrederea unei persoane sau organizații. Cei mai mulți agenți actuali sînt programați cu ajutorul limbajelor interpretate (de exemplu Tcl, Java), pentru a se asigura portabilitatea lor pe variatele sisteme existente. Fiecare agent are propriul său fir de execuție, astfel încît să poată să-și ducă la bun sfîrșit sarcinile, pe baza inițiativei proprii. Cînd un agent călătorește, el își transportă starea și codul program cu el. În acest context, starea agent poate fi definită fie ca starea sa la execuție, fie ca grupul valorilor variabilelor, pe baza cărora agentul poate deduce acțiunile următoare, în momentul în care a ajuns la destinație. Autentificarea unui agent se face pe baza identificării persoanei sau organizației în numele căreia agentul există. Localizarea unui agent este dată de către adresa de rețea a sistemului agent unde acesta stă, alături de calea locală pînă la fișierul propriu. Un sistem agent este o platformă ce poate crea, interpreta, executa, transfera și distruge un agent. Ca și agentul, un sistem agent se autentifică în numele unei persoane sau organizații, iar identificarea lui se face pe baza numelui și adresei acestuia. Un host poate conține mai multe sisteme agent. Comunicarea dintre sistemele agent se face prin modulul numit Infrastructura de Comunicare (CI – Communication Infrastructure). Un astfel de modul furnizează sistemului agent serviciile de apel de procedură la distanță (RPC – Remote Procedure Call), naming și securitate. Alături de aceste definiții, sînt date și alte noțiuni legate de agenți, cum ar fi serializarea / deserializarea unui agent, interacțiunea dintre agenți, transferul agenților, funcțiile unui sistem agent, securitatea unui agent și a unui mediu agent etc.

Securitatea mediului agent

În cadrul unui sistem agent, securitatea mediului este o problemă critică pentru buna desfășurare a task-urilor de către agenții existenți. Două scopuri sînt care dau importanță securității unui sistem agent. Pe de-o parte, agenții mobili, în cazul unui sistem de securitate flexibil, pot realiza lucruri valoroase din perspectiva proprietarului pe a cărui încredere se execută. Pe de altă parte, securitatea unui sistem agent trebuie să împiedice ca agenți malițioși să pericliteze stabilitatea sistemului și, odată cu el, a celorlalți agenți. Această problemă este prezentată la modul concret în ultima parte a articolului.

Din varietatea de sisteme agent amintite pînă acum, am ales spre prezentare un sistem agent care, în opinia mea, va fi unul din principalele platforme agent ce se vor găsi pe o mare parte a hosturilor conectate la Internet: IBM Aglets Workbench ( AWB).

IBM Aglets Workbench (AWB)

Aglets Workbench (AWB) este un mediu de agenți mobili, creat de către o echipă de cercetători de la IBM Japan Laboratories. Acești agenți mobili se numesc agleți și sînt programabili cu ajutorul limbajului Java. Un aglet este mobil, autonom, se execută asincron și paralel și interacționează cu alți agenți.

Mobilitatea este caracteristica fundamentală a agleților. Prin aceasta, se înțelege posibilitatea acestora de a realiza un task la un moment dat pe un anumit host, după care se pot opri, se pot deplasa pe un alt host și pot continua task-ul întrerupt. Firește, există limitări de implementare, în ceea ce privește întreruperea și apoi continuarea unui task însă, în mare, cam așa stau lucrurile.

Concret, un aglet are o stare anumită la execuția lui pe un host oarecare. Înainte de plecarea pe un alt host, această stare este înghețată la nivelul heap-ului local și apoi serializată. La sosirea pe hostul destinație, agletul deserializează automat heap-ul serializat la plecare, prin această operație refăcîndu-și starea. Deci, dacă este vorba de întrerupere și revenire pentru un anumit task, atunci este vorba despre task-ul a cărui stare poate fi pusă în heap-ul local pentru a fi serializată, deserializată și apoi continuată. Ideal ar fi fost ca această stare să vizeze și stiva locală a agletului. Aceasta ar fi însemnat ca, de pildă, în cazul în care un aglet ar fi fost în execuția unei funcții și-ar fi dorit deplasarea pe un alt host, să înghețe stiva local㠖 adică valorile provenite din regiștrii microprocesorului – să o serializeze, să se deplaseze la hostul destinație, să deserializeze stiva și să continue execuția funcției întrerupte la hostul anterior. Acest scenariu nu s-a putut implementa datorită limitărilor de securitate ale sistemului, impuse de către limbajul și mediul Java. Din acest motiv, de fiecare dată cînd un aglet ajunge la un host oarecare, își începe execuția prin intrarea în funcția run() (vezi caseta cu exemplul MyAglet) și nu prin eventuala continuare a ei de la o instrucțiune interioară.

Autonomia unui aglet se referă la faptul că acesta poate conține suficient de multă informație pentru a decide ce task să execute, unde să îl execute și cînd să îl execute.

Execuția asincronă a unui aglet se referă la faptul că acesta este implementat cu ajutorul unui fir de execuție (thread). Acest thread se execută asincron față de celelalte thread-uri ce implementează alți agenți.

Paralelismul în execuție a unui aglet se referă la faptul că acesta rulează în paralel cu alți agenți existenți pe respectivul host.

Interacțiunea dintre agleți se realizează cu ajutorul mesajelor. Un aglet poate trimite un mesaj sincron sau asincron unui alt aglet, astfel făcîndu-se comunicarea între agleți.

Echipa de la IBM pune la dispoziția potențialilor proiectanți un pachet Java ce conține clasele cu metodele de bază pentru dezvoltarea de agleți. Aceste clase formează J-AAPI (Java Alget API) și reprezintă o propunere de standardizare pentru agleți și mediul unde aceștia ființează. Spre exemplu, amintim o parte din interfețele și clasele existente în pachet: Aglet, AgletIdentifier, AgletProxy, Itinerary, Message, AgletContext. Dar această interfață de programare a aplicațiilor (API) nu este totul. Tehnologia de realizare a agleților cuprinde și un protocol de transfer agent (ATP – Agent Transfer Protocol), necesar transferului agenților prin rețea. [ATP]

ATP este un protocol de rețea la nivel de aplicație, pentru sisteme distribuite bazate pe agenți. Avînd ca suport rețeaua Internet și folosind URL (Unified Resource Locator) ca adresă pentru hosturile unde se găsesc agenți, ATP oferă un protocol uniform și independent de platformă, pentru transferul agenților între calculatoarele din rețea. Prima versiune a protocolului ATP ( ATP / 0.1) este implementată și ea într-un pachet documentat și independent de AWB. Faptul că este scris în întregime în Java oferă avantajele portabilității și formării unui API standard pentru crearea demonilor ATP, conectarea la hosturi ATP și generarea de cereri și răspunsuri ATP specifice. Acestea fiind elementele de bază pentru dezvoltarea unui sistem agent și a agenților, echipa IBM a mai realizat și unele unelte care să ușureze programatorilor munca de dezvoltare a agleților. Aceste unelte sînt următoarele: pattern-uri de agleți, un server aglet și un lansator de agleți.

Pattern-urile de agleți pun la dispoziția implementatorului clase și metode, pentru a crea agenți specializați pe anumite task-uri. Exemple de pattern-uri ar fi perechile mesager - receptor (Messenger - Receiver) sau stăpîn - sclav (Master - Slave). În cadrul primei perechi, avem de-a face cu un aglet mesager care se deplasează la hostul unde este creată perechea lui receptoare și îi furnizează un mesaj. A doua pereche tratează următorul scenariu: un aglet stăpîn creează unul sau mai mulți agleți sclavi, ce au sarcina să se deplaseze la unul sau mai multe hosturi din rețea și să execute niște task-uri specifice. Odată ce un aglet sclav își termină lucrarea, se întoarce la agletul stăpîn și îi raportează ceea ce a realizat.

Serverul aglet realizează monitorizarea agleților de pe hostul de unde este lansat. Astfel, cu ajutorul lui, utilizatorul poate să creeze, să trimită, să recheme sau să distrugă un aglet. În plus, serverul Tahiti – căci așa se numește – realizează și funcțiile de management de securitate a mediului de agleți, ca și management de execuție a thread-urilor și logare. Tahiti se dorește a fi o unealtă pentru agleți, în același mod în care browser-ul Web a devenit o unealtă fundamentală pentru utilizatorii WWW-ului.

Lansatorul de agleți (Aglet Launcher ) permite virtualului utilizator să lanseze și să recheme un aglet, prin intermediul unui applet dintr-o pagină de Web. Acest lansator se numește Fiji.

Securitatea AWB-ului

Securitatea AWB-ului a fost proiectată pe mai multe nivele.

Primul nivel este chiar cel suportat de limbajul Java. Acesta se referă la faptul că posibilele importuri de fragmente de cod în agenți sînt supuse unor stricte serii de verificări, începînd cu teste care să asigure formatul corect al codului și terminînd cu o serie de verificări de consistență, făcute de către verificatorul de cod Java.

Pe următorul nivel, se află managerul de securitate al agleților. Acesta permite utilizatorilor AWB-ului să își implementeze propriul lor mecanism de securitate. Spre exemplu, agletul server Tahiti implementează un manager de securitate configurabil, care furnizează un anumit grad de siguranță, atît pentru sistemul agent al hostului respectiv, cît și pentru agenții utilizatorului. Trebuie spus faptul că sistemul implicit de securitate al agenților este foarte restrictiv atît pentru cei ce sînt catalogați ca „de încredere“ (trusted), cît și cei luați drept „lipsiți de încredere“ (untrusted).

Al treilea și ultimul nivel de securitate este cel denumit „Java Security API“, ce semnifică un cadru pentru ca proiectanții de agleți să includă funcționalități de securitate în codul lor. Aceste facilități sînt următoarele: semnătură digitală, criptare și autentificare.

Concluzie

Acest articol a prezentat ceea ce semnifică cuvîntul agent si cum se pot clasifica agenții în clase agent, pentru o mai bună înțelegere a fenomenului. S-a abordat apoi subdomeniul specializat pe tratarea agenților mobili și li s-au prezentat acestora trăsăturile definitorii. S-a vorbit despre ceea ce înseamnă un mediu agent, luîndu-se în discuție un recent document ce prezintă o propunere spre standardizare a specificațiilor legate de interoperabilitatea agenților mobili. În final, s-a trecut în revistă mediul agent Aglets Workbench, creat de către IBM Japan Laboratories, pentru realizarea de agenți programabili cu ajutorul limbajului Java.

Bibliografie
[ NWANA] Hyacinth S. Nwana - Software Agents : An Overview. - Cambridge University Press, 1986
[ MAF] Crystaliz, Inc., General Magic, Inc., GMD FOKUS, IBM - Mobile Agent Facility Specification - OMG TC Document cf/xx-x-xx June 2, 1997
[J-AAPI] Danny B. Lange, Mitsuru Oshima - Programming Mobile Agents in Java With the Java Aglet API - www.trl.ibm.co.jp/aglets/agletbook/elements.html
[CHANG] Daniel T. Chang, Danny B. Lange - Mobile Agents : A New Paradigm for Distributed Object Computing on the WWW - www.trl.ibm.co.jp/aglets/whitepaper.html
[ATP] Danny B. Lange, Yariv Aridor - Agent Transfer Protocol – ATP / 0.1 - www.trl.ibm.co.jp/aglets/atp/atp.html