Intelligent & Mobile Agents

		MokaByte Numero 17 - Marzo 1998

		Agenti mobili in Java (II parte)
	di Ennio Grasso

1. Introduzione

Negli ultimi anni si è assistito ad una graduale ristrutturazione architetturale degli elementi software, e ciò a seguito della continua crescita di complessità e costo del software stesso. Parole chiave quali "client-server", "downsizing", "object-orientation" sono ormai diventate uso comune per identificare le caratteristiche necessarie che i nuovi elementi software devono soddisfare per inserirsi efficacemente all'interno di uno scenario di componenti razionalizzato. La tendenza predominante è quella di definire un modello computazionale che specifica sia concetti di strutturazione (building-block, oggetti, interfacce, contratti,...[OSCA93]), sia lo strato infrastrutturale, o middleware, che realizza le funzionalità di comunicazione rendendo trasparenti problematiche quali protocolli, distribuzione, locazione, ecc. L'assunzione fondamentale dei modelli computazionali client-server è di disporre di un'infrastruttura di comunicazione (tipicamente LAN) tra i vari nodi computazionali con le seguenti caratteristiche:

In pratica tali proprietà non sono sempre soddisfatte, soprattutto in uno scenario futuribile dove caratteristiche di mobilità degli utenti e flessibilità di localizzazione dei servizi in rete diventeranno requisito importante. Infatti, la recente convergenza dei mondi telecom e computing sta portando alla progressiva crescita di possibilità di servizi offerti in rete, dove i sistemi di comunicazione personale costituiscono elemento determinante. Le caratteristiche tipiche della rete in questi casi sono:

La nuova categoria di dispositivi mobili, Personal Communicators e Personal Digital Assistants (PDA), non sono adatti a supportare interazioni basate su RPC (Remote Procedural Call) e diventa necessario un meccanismo più flessibile e computazionalmente "leggero". Per affrontare efficacemente queste problematiche e permettere ai clienti di un servizio di poter facilmente configurare l'ambiente di comunicazione secondo le preferenze individuali, una nuova generazione di architetture basate sul concetto di Intelligent Agents (IA) sta nascendo.

Il modello degli Intelligent Agents rappresenta un'evoluzione dell'architettura client-server. Un agent può essere definito come un elemento software auto-contenuto responsabile per l'esecuzione di un determinato compito, contiene un certo livello di intelligenza e opera per conto di un utente. Secondo questo modello, è possibile "iniettare" un agent in rete per eseguire un certo compito indipendentemente dal fatto che la connessione con il client venga interrotta. L'agent si muove in rete, andando direttamente sui nodi dove sono localizzati i servizi, e la comunicazione client-server si traduce in un'interazione locale riducendo il traffico di rete e la conoscenza che l'utente deve avere sui servizi. Concettualmente gli agents implementano una metafora comune al modo tipico di operare nel mercato: visitare un posto, utilizzare un servizio (magari a seguito di una negoziazione), e quindi muoversi altrove. Dopo che l'agent ha raccolto i risultati desiderati, ritorna dall'utente.

Un esempio di applicazione del modello IA è un sistema di e-mail filtering & routing. In un modello client-server, il motore a regole risiede sul nodo client e i messaggi non vengono filtrati e processati a meno che il client non sia connesso in rete. In un modello basato sugli agents, le regole risiedono virtualmente in rete e operano anche quando il client non è connesso. Ad esempio, il motore a regole potrebbe inviare una notifica al client, tramite paging, per avvertirlo dell'arrivo di un messaggio urgente.

2. Radici storiche

Agli inizi degli anni '90 la tecnologia IA si è spinta in tre direzioni principali.

- System vendors, come Apple e Microsoft, hanno supportato il paradigma del component embedding, un concetto di strutturazione del software secondo il quale le applicazioni sono create come collezioni di componenti elementari (object-orientation). Tali componenti sono tipicamente definite dai vari vendors, mentre l'utente ha la possibilità di assemblarle (embedding) per creare applicazioni complesse utilizzando uno script language (es. Visual Basic) che amalgama e sfrutta i servizi delle componenti.

- Il mondo di Internet e alcuni telecom carriers, come AT&T, hanno iniziato ad analizzare lo scenario applicativo di programmi che possono muoversi all'interno della rete (mobile agents). Di qui i linguaggi Safe-Tcl, Java, OREXX e Telescript per citare i più importanti.

- Infine, alcuni vendors di prodotti groupware hanno iniziato a esplorare la possibilità di utilizzare la tecnologia IA per automatizzare operazioni ripetitive e imparare le abitudini dell'utente, oppure agents che agiscono da intermediari per agevolare l'esecuzione dei tasks all'interno di un processo di workflow.

3. Domini applicativi degli Intelligent Agents

La tecnologia degli Intelligent Agent ammette uno spettro di applicabilità molto ampio. Di seguito sono riportati alcuni domini più interessanti.

I dispositivi mobili, laptops, notebooks, personal communicators, PDA, hanno tre caratteristiche per le quali la tecnologia IA risulta particolarmente utile:

. Connessione non è permanente. Il vantaggio degli agents è che questi possono operare per conto dell'utente anche quando non connesso;

. Bassa capacità di bandwidth della connessione. Una comunicazione RPC può richiedere molti flussi di dati tra client e server al fine di compiere anche una semplice operazione. Al contrario, un agent può essere "iniettato" in rete, raggiungere il server, instaurare una comunicazione locale, e ritornare i risultati rilevanti al client;

. Limitate capacità operative. Se da un lato i personal computers portatili accrescono sempre maggiormente le potenzialità tecniche, la categoria emergente dei personal communicators (es. Apple Newton, HP95) hanno limitate capacità di elaborazione e memoria. Il modello IA permette all'agent di operare nel server sfruttando le potenzialità di calcolo di quest'ultimo.

Nel mondo del mercato elettronico (Internet rappresenta il driver principale) il modello IA si rivela utile in due casi:

. come rappresentante inviato in rete dall'utente per localizzare le offerte di servizio più convenienti, negoziare tali offerte, e concludere transazioni;

. come front-end per l'accesso ad un particolare servizio. Quando definisce un nuovo servizio, il service provider deve preoccuparsi di come tale servizio può essere utilizzato dai potenziali utenti. L'utente deve installare sul proprio nodo un front-end (modulo client) specifico per l'interfacciamento al servizio, oppure disporre di un browser generico (es. Netscape, Mosaic), ma in questo caso il service provider non ha la possibilità di fornire valore aggiunto arricchendo e personalizzando l'offerta. Con il modello IA, il front-end di accesso al servizio viene definito dal service provider come un mobile agent che migra nel nodo client a seguito di richiesta del servizio e che contiene la logica necessaria per l'interazione con il servizio stesso (es. HotJava).

Le operazioni di information retrieval e data-mining possono essere eseguite in modo più efficace se la logica di interrogazione viene descritta in un agent che si muove nel nodo dove si trovano realmente i dati invece di spostare i dati nel nodo client per la loro elaborazione. Questo diventa ancora più rilevante se le sorgenti di informazioni sono molteplici e sparse in rete.

Il modello IA può essere sfruttato anche nell'area del management di sistemi telecom. Il modello tradizionale di management si basa su un'intelligenza centralizzata (manager) che controlla e gestisce le funzionalità di numerosi managed systems (network elements) tramite protocolli standard (SNMP, CMIP) e spesso sono richieste alte prestazioni della rete di controllo, che fisicamente può corrispondere alla stessa rete gestita, per garantire il real-time-management delle risorse.

L'interazione distribuita manager - managed system, dove il manager contiene la logica di gestione e il managed system agisce da intermediario sulle risorse, può essere sostituito con il modello dei mobile agents. In questo scenario il manager, dinamicamente e secondo le necessità, invia un mobile agent (es. uno script) contenente la logica di management al nodo dove si trovano le risorse da gestire. Una volta raggiunto il nodo, l'agent istruisce direttamente il managed system sulle operazioni di management da eseguire tramite una efficiente interazione locale.

I sistemi di workflow management tradizionali prevedono un'architettura centralizzata dove un nodo server mantiene la conoscenza delle funzionalità di coordinamento e gestione delle attività del processo, mentre i nodi clients sono usati come interfacce per interagire con l'utente. Un'architettura centralizzata presenta diversi svantaggi:

. scalabiltà - è difficile prevedere come scalare un'architettura di workflow convenzionale per sistemi con diverse centinaia di processi concorrenti. Un'architettura centralizzata può essere penalizzante dal punto di vista prestazionale;

. vulnerabilità - se il nodo server dove risiede la logica di workflow fallisce, o la rete degrada, o la connessione si interrompe, l'intero sistema finisce per collassare;

. rigidità - l'architettura convenzionale prevede che i nodi utente siano permanentemente connessi al server per la durata del processo di workflow per essere coordinati nelle loro attività. Tuttavia, sono molteplici gli scenari in cui è richiesta la mobilità del client (rif. mobile computing), sia perchè il processo stesso può richiedere mobilità degli utenti (es. workforce management), e sia perchè la connettività permanente richiede il consumo delle risorse di rete con impatti economici e prestazionali.

In un modello di workflow basato su IAs, anzichè semplicemente segnalare le attività da eseguire, la descrizione del processo è contenuta in un agent che si sposta nei vari nodi coinvolgendo gli utenti interessati. Qualora il processo preveda l'esecuzione parallela di una serie di sotto-attività, l'agent "clona" un insieme di agents corrispondenti a tali sotto-attività che si spostano autonomamente nei nodi degli utenti interessati.

Nessuno dei domini applicativi sopra menzionati richiede necessariamente l'uso di tecniche IA e un approccio tradizionale RPC client-server permette di raggiungere gli risultati simili, ma al costo di aumentare il traffico di rete e il consumo delle risorse elaborative. Inoltre, l'approccio IA può anche servire come studio prototipale di un'applicazione tradizionale client-server. Un agent è un'entità flessibile e autocontenuta ed è in grado di interagire con software legacy senza grassi sforzi implemetativi e fornire suggerimenti e valutazioni per determinare se mantenere l'approccio agent o passare a una successiva ingegnerizzazione basata su RPC.

4. Caratterizzazione degli Intelligent Agents

Come visto sopra, il termine "Intelligent Agent" viene usato con uno spettro molto ampio di significati, da interfacce utente adattabili, a comunità di processi cooperanti per il raggiungimento di un obiettivo comune. Per questo motivo diventa difficile dare una definizione precisa ed esaustiva del termine. Al contrario, è più produttivo identificare le dimensioni caratterizzanti onde fornire una classificazione della tecnologia IA.

Di seguito viene descritto un framework sufficientemente generico e istanziabile a diversi modelli che caratterizza il modello IA. Il framework definisce due entità, agents e agencies, che possono interagire tra loro.

Agent. Le proprietà di un agent possono essere definite lungo quattro dimensioni:

- programmazione: indica il formalismo per definire la logica (intelligenza) degli agents. I metodi utilizzati prevedono linguaggi di scripting e/o rappresentazioni di conoscenza dichiarativa derivante da tecniche di intelligenza artificiale;

- capacità. Indica il livello di complessità delle azioni eseguite dall'agent. Un agent può svolgere operazioni più o meno complesse, dalla semplice esecuzione di un task, seguire inferenze, pianificazioni, learning, alla capacità di clonare altri agents, ecc.

- cooperazione: Un insieme di agents può essere in grado di cooperare per la risoluzione di problemi o il raggiungimento di obiettivi comuni. Questo può variare da un semplice stile di comunicazione client-server a tecniche sofisticate di negoziazione e cooperazione. Il tipo di interazione tra agents può corrispondere allo scambio di dati, informazioni (dati + meta dati), o altri agents.

- mobilità: per eseguire un certo compito gli agents possono spostarsi attraverso la rete in nodi remoti per eseguire il loro compito. Si possono distinguere due livelli di complessità:

. esecuzione remota: l'agent (programma + dati) viene spostato remotamente e lì eseguito (es. Java, Safe-Tcl, OREXX,...);

. migrazione: durante la propria esecuzione un agent è in grado di spostarsi di propria iniziativa in un altro nodo. Quindi l'agent è in grado di sospendere la propria esecuzione, migrare (programma + dati + stato di esecuzione) e riattivare la propria esecuzione al punto di sospensione. Durante il proprio tragitto, un agent può lanciare l'esecuzione di altri agents, clonare se stesso, e "incontrare" altri agents (es. Telescript).

Agency. Una agency rappresenta una macchina virtuale per l'esecuzione degli agents. Le agencies possono essere caratterizzate dalla loro capacità di supportare esecuzioni concorrenti di diversi agents, gestione della sicurezza, interazione con i servizi (es. databases), ecc. Le interazioni agent-agency possono essere organizzate secondo tre livelli crescenti di complessità e sofisticazione:

- Nel modello più semplice l'infrastruttura utilizza un broker come intermediario nella comunicazione. Il broker traduce il riferimento a un servizio (object reference) e permette all'agent di accedere al servizio stesso.

- Un modello più complesso prevede un facilitator che non si limita a interpretare riferimenti a servizi, ma aggiunge un servizio di trading permettendo di formulare richieste di un servizio come una serie di proprietà funzionali (es. il tipo di servizio) e non funzionali (es. il costo e la qualità del servizio) senza previa conoscenza dei possibili fornitori del servizio. Il facilitator localizza il servizio che in quel momento soddisfa maggiormente le specifiche del client e permette all'agent di accedere al servizio stesso.

- Infine, il modello più sofisticato prevede un mediator che identifica un fornitore di servizio non in base a una serie proprietà, ma tramite una caratterizzazione semantica della richiesta di servizio (routing semantico).

5. Modelli di Agents

Dopo aver introdotto queste dimensioni per caratterizzare la complessità di sistemi software che rientrano nella categoria IA, si possono identificare quattro aree di utilizzo differente della tecnologia IA.

Sono chiamati anche Personal Assistants (PAs) e il loro scopo è di collaborare con l'utente "imparando" abitudini e preferenze. Infatti, spesso i PAs realizzano interfacce grafiche personalizzate. Lo scopo principale di un PA è la collaborazione con l'utente e quindi l'enfasi viene posta sull'interazione utente-agent. Il tipo di compiti di un PA può essere molto vario, come il recupero di informazioni/dati locali tramite browsing intelligente, scheduling & filtering della posta elettronica, agenda elettronica, ecc. Esistono tre diversi livelli di complessità per la definizione di un PA:

- programmazione end-user: regole di produzione o script language dove l'utente specifica la logica per l'automazione di compiti ripetitivi;

- knowledge base: il PA nasce con una conoscenza estesa dell'ambiente e dell'utente. A run-time l'agent utilizza tale conoscenza per riconoscere i piani dell'utente e agire di conseguenza;

- machine learning: il PA è in grado di apprendere la conoscenza necessaria per assistere l'utente.

Pur essendo dei validi "valletti" per l'utente, i PAs non sono in grado di accedere a servizi in rete.

Si differenziano dai PAs per essere in grado di accedere a risorse e servizi remoti avendo conoscenza dell'infrastruttura di rete e dei servizi disponibili nell'ambiente distribuito. In pratica, un networked agent rappresenta uno smart-proxy tra l'utente e le risorse e servizi. Questo disaccoppiamento fa in modo che l'utente non debba conoscere come e dove accedere ad un servizio e analogamente un service provider non debba predefinire la logica di interazione (back-end) con gli utenti del servizio (es. IBM Intelligent Communication).

Questo tipo di agent viene anche chiamato softbot (software-robot) e permette di specificare richieste con linguaggi di alto livello (es. script, regole, formalismi grafici). L'agent utilizza queste specifiche per accedere ai servizi in rete, filtrare le informazioni rilevanti, e ritornare i risultati acquisiti. I networked agents sono particolarmente importanti nel dominio Internet dove la crescita esplosiva della WWW (World-Wide-Web) impone l'esistenza di agents (detti Web Crawlers) per navigare l'enorme quantità di informazioni disponibili. Non è azzardato prevedere che l'uso di agents come intermediari tra utenti e service providers renderà possibile la nascita di nuovi attori nel mercato i cui servizi forniranno il valore aggiunto per la scoperta, negoziazione e transazione di servizi offerti da terzi.

Nel contesto di Distributed Artificial Intelligence (DAI), si introduce il concetto di coordinamento di un insieme di agents, e di come il comportamento collettivo venga gestito per la soluzione di un problema comune. Questo tipo di agent viene definito con tecniche di intelligenza artificiale (regole, ragionamento case-based o example-based). La comunicazione tra agents avviene tramite scambio di messaggi oppure tramite blackboard condivisa dove gli agents scrivono e leggono informazioni. Diverse proposte per l'interazione tra agents si basano sulla teoria degli atti linguistici per definire la semantica dei messaggi. KIF (Knowledge Interchange Format) è un linguaggio per la rappresentazione della conoscenza. Si basa sulla logica del primo ordine con alcune estensioni per permettere ragionamento non monotono. KIF può servire come forma intermedia per tradurre il linguaggio con cui è espresso il comportamento di un agent nel linguaggio di comportamento di un secondo agent. KQLM (Knowledge Query Manipulation Language) è un linguaggio per descrivere il protocollo di trasferimento di informazioni tra sistemi di conoscenza eterogenei e quindi per l'interazione tra agents. Con KQLM, un agent comunica il contenuto di un messaggio (definito in certo linguaggio, es. KIF) utilizzando delle performative, ossia primitive basate sulla teoria degli atti linguistici. Le performative possono essere asserzioni, interrogazioni, comandi, o qualunque altro atto linguistico concordato tra gli agents. Infatti, benchè esista un insieme di performative predefinite, tale insieme può essere esteso. Inoltre, un agent può decidere di "interpretare" solo alcune performative permettendo una grande flessibilità di modellizzazione.

I multi agents sono stati particolarmente investigati nel dominio di intelligenza artificiale ma poca enfasi è stata posta al concetto della mobilità.

Mentre i DAI-based multi-agents si focalizzano sulla risoluzione di problemi distribuiti in ambiente omogeneo, gli script-based multi-agents sono indirizzati nello scenario di sistemi distribuiti eterogenei e di grosse dimensioni per offrire una grande varietà di servizi sofisticati. Esempi sono sistemi avanzati di filtering e searching in rete di servizi, PDA network connection, fino a meccanismi di comunicazione intelligente e management della rete.

Gli agents di questa categoria sono descritti tramite script languages con la caratteristica di essere:

. interpretati, per rendere veloce la prototipazione, aumentare la sicurezza ed essere indipendenti dagli strati di basso livello;

I linguaggi più interessanti al momento sono Safe-Tcl, Sun Java, IBM Object REXX e Telescript.

Safe-Tcl nasce dalla volontà di definire sistemi di active-mail, ossia sistemi di posta elettronica attiva dove un messaggio può contenere del codice che viene automaticamente eseguito alla ricezione della mail oppure quando l'utente apre la mail per la lettura.

Safe-Tcl si basa su Tcl (Tool command language), un linguaggio che ha ormai raggiunto una discreta maturità ed è supportato sia in ambito accademico che commerciale. Tcl è uno script-language interpretato, ad alto livello, adatto per scrivere codice velocemente e con poco sforzo. Tuttavia Tcl non è adatto per un ambiente di posta attiva dove l'elemento "sicurezza" riveste un ruolo importante. Safe-Tcl è una restrizione di Tcl che elimina gli aspetti del linguaggio potenzialmente pericolosi (l'idea è che deve essere possibile eseguire un agent spedito dal tuo peggiore nemico senza che questi possa fare alcun danno al tuo sistema).

Tuttavia, l'eliminazione di molte funzionalità può limitare troppo il potere espressivo del linguaggio. Per ovviare a questo inconveniente, Safe-Tcl si basa sul concetto del doppio interprete (twin interpreter). In pratica, ogni nodo possiede due interpreti, trusted e untrusted. Il codice proveniente via e-mail viene eseguito dall'interprete untrusted. L'interprete trusted non eseguirà mai codice "insicuro", ma può essere usato per estendere l'interprete untrusted esportando alcune funzionalità, il tutto sotto il controllo dell'utente che può decidere il grado di fiducia che vuole garantire.

Safe-Tcl è stato proposto come estensione a MIME (Multipurpose Internet Mail Exchange) per applicazioni di enabled-mail. Le primitive Safe-Tcl per MIME sono particolarmente adatte a offrire servizi interattivi multimediali e a risolvere problematiche di lavoro cooperativo (CSCW).

Java è un linguaggio semi-interpretato con sintassi simile a C++ e semantica semplificata. Il compilatore Java esegue l'analisi sintattica e traduce il programma in una forma intermedia (detta byte-code). A run-time, l'interprete Java traduce la forma intermedia ed esegue la logica del programma. Questo approccio permette la migrazione della forma intermedia sui vari nodi e essere eseguita localmente disponendo dell'interprete Java. Ad esempio, il browser HotJava permette applicazioni WWW-enabled dove, a differenza di browser tradizionali come Netscape e Mosaic, l'attivazione di un link da parte dell'utente può corrispondere al downloading in locale di un programma Java eseguito localmente (rif. electronic commerce).

Come visto in precedenza, le potenzialità di questo modello sono notevoli. Un service provider che definisce un nuovo servizio avrà la possibilità non solo di offrire il servizio, ma anche un front-end (agent) da migrare nei nodi clients con un duplice scopo:

- permettere di sfruttare le capacità computazionali del nodo client per eseguire localmente operazioni elementari senza richiedere l'accesso al server remoto (es. l'interazione con l'utente per preparare una query);

- interfacciare l'utente con il servizio senza richiedere che l'utente abbia previa conoscenza delle modalità di interazione con il servizio stesso.

REXX è uno script-language affermato nel mondo IBM (MVS, OS/2) per il rapid-prototyping di applicazioni. La recente evoluzione del linguaggio, Object REXX, rappresenta il modello cui IBM affida le proprie speranze per coprire l'area IAs. L'aspetto più interessante di OREXX è la sua integrazione con SOM (System Object Model), l'implementazione IBM delle specifiche CORBA (Common Object Request Broker Architecture), e OpenDoc, l'architettura Apple/IBM per il document-management definita al di sopra si SOM. Con OREXX è possibile "agglomerare" oggetti SOM per creare building-blocks complessi (rif. embedding di componenti).

Mentre Safe-Tcl, Java e OREXX permettono l'esecuzione remota di agents, Telescript permette la migrazione di agents mentre sono attivi. Telescript è alla base di PersonalLink, una rete di servizi definita da AT&T, la cui visione è il "mercato elettronico" dove una vasta quantità di servizi viene offerta a un insieme di utenti. Telescript si basa sul paradigma della programmazione remota dove gli agents migrano e si spostano in rete al fine di scoprire servizi e di comunicare tra loro (meeting). I concetti base di Telescript sono: places, agents, meetings e connections. I places definiscono la struttura statica della rete (intesa come mercato elettronico) e rappresentano i punti di incontro degli agents. Gli agents rappresentano i potenziali consumatori e fornitori di servizi. Consumatori e fornitori possono scoprire l'esistenza gli uni degli altri "viaggiando" in rete (una particolare istruzione di Telescript è appunto go). Agents nello stesso place possono interagire tra loro. Per iniziale l'interazione gli agents devono prima "incontrarsi" (istruzione meet) a seguito della quale possono iniziare una comunicazione peer-to-peer.

Ennio Grasso appartiene alla linea di Tecnologie Softeware di CSELT. Occupandosi di object-oriented distributed computing da quando è entrato in CSELT nel 1992, ha maturato una certa esperienza sia progettuale che implementativa. È rappresentante CSELT in OMG e segue lo standard CORBA sin dalle prime fasi. Autore del modello transazionale dell'architettura TINA, ha studiato l'applicazione di concetti transazionali rilassati per sistemi distribuiti dove il concetto di "transazionalità" deve essere adattato al dominio applicativo. Ultimamente la sua area di competenza si è concentrata sugli aspetti architetturali di Java, in particolare per gli aspetti di distrubuted computing, migrazione di codice e mobile agents.