Commercio elettronico

PARTE II: AGENTI INTELLIGENTI PER IL COMMERCIO ELETTRONICO

Cap.VI: Gli Agenti Software

Richiamo
Si è già accennato, illustrando le tematiche riguardanti i nuovi rapporti tra venditori e compratori in rete, alla possibilità di utilizzare i servizi offerti dagli agenti software durante tutte le fasi del processo d'acquisto (per la scelta tra prodotti alternativi, la ricerca dell'offerta più conveniente, per avviare automaticamente delle contrattazioni sulle condizioni di vendita etc.). In questa sezione si vuole tentare di dare una definizione di agente, cercando di delinearne le caratteristiche peculiari.

Definizione E Proprietà Degli Degli Agenti- Gli Agenti Autonomi

La definizione di agente e l'individuazione delle sue caratteristiche hanno impegnato non poco i ricercatori del settore, dando corso ad un dibattito non ancora concluso.
La difficoltà di quest'operazione è legata alla necessità di riuscire ad individuare un insieme di proprietà comuni a tutti gli agenti, in modo tale da distinguere un agente da un programma o meglio riuscire ad individuare se un dato programma è o meno un agente (software). Definire il significato di agente partendo dall'analisi delle caratteristiche specifiche degli agenti fin qui sviluppati, ha solo portato ad una miriade di differenti definizioni di agente.
Partendo però da queste definizioni, è possibile individuare un insieme di caratteristiche essenziali dell'agente (caratteristiche che ogni agente deve possedere per essere definito tale), per poi passare ad individuare delle proprietà accessorie che caratterizzano varie sottocategorie di agenti (specializzazioni).
Questo tipo di lavoro è stato realizzato da Franklin e Graessen [1] portando così alla seguente definizione di agente: "Un agente autonomo è parte di un ambiente, capace di ottenere informazioni e di agire nel tempo su tale ambiente, percependone i cambiamenti ed operando di conseguenza per raggiungere i propri obiettivi."
Alcune precisazioni sull'enunciato:
- la prima caratteristica da sottolineare è quella della autonomia dell'agente; cioè la capacità di prendere decisioni (senza l'intervento di utenti o di altri agenti esterni) sulle azioni da intraprendere; questo significa che per esempio un agente sarà in grado di decidere se fornire o meno un servizio richiestogli.
Le decisioni sono dettate dagli obiettivi (o compiti) che l'agente deve raggiungere.
- la seconda caratteristica degli agenti è legata alla interazione tra l'agente e l'ambiente in cui si trova; l'agente è provvisto di "ingressi" atti a fornirgli una "conoscenza" di questo ambiente e di "uscite" per agire su di esso; in questo l'agente non è molto diverso da un programma per il quale siano definiti dei canali di input ed output.
La differenza è che l'azione dell'agente è spesso collegata a cambiamenti dell'ambiente in cui si trova (di cui sono causa o effetto); l'agente sarà comunque in grado di percepire tali cambiamenti ed agire conformemente ad essi.
In questo senso si parla di reattività e di proattività degli agenti: con il primo termine si indica la capacità degli agenti di agire in risposta ad eventi esterni; con il secondo la capacità di generare eventi nell'ambiente circostante, iniziare delle interazioni senza attendere eventi esterni, mostrando quindi capacità di iniziativa.
Ultima caratteristica degli agenti è la persistenza temporale: ciò significa che la durata di vita dell'agente è superiore alla durata dei compiti di base che esso esegue.
Un agente continua ad esistere con uno stato interno, in modo da poter eseguire interazioni successive, ed in generale continuerà a girare fino a che non deciderà di terminare.
Si esaminano, ora, due casi estremi che rientrano nella definizione di agente presentata: da una parte si considera la categoria di agenti più evoluta (le persone), con una serie di obiettivi da raggiungere, con più mezzi di percezione dell'ambiente, con una serie di possibili azioni, dotati di strutture complesse di controllo (autonomia).
All'opposto si può avere un termostato, anch'esso un agente con 1 o 2 ingressi, una sola azione possibile ed un elementare struttura di controllo.
Per fare un esempio della differenza tra agente (in questo caso software) e un programma un correttore ortografico abbinato ad un word processor non è necessariamente un agente se, per esempio, funziona in modalità batch: riceve in ingresso un file di testo e produce in uscita il file con il testo corretto.
L'uscita prodotta non ha alcuna influenza sulla percezione successiva dell'ambiente; inoltre anche la caratteristica di persistenza temporale non è soddisfatta perché il programma tipicamente si chiuderà a fine esecuzione e verrà riattivato solo a seguito di un comando utente.
Se invece lo stesso correttore ortografico è in grado di rilevare l'immissione di testo da tastiera e di effettuare le correzioni in tempo reale, allora è un agente software.
Anche un programma per il computo degli stipendi non è generalmente un agente, perché l'output prodotto non ha alcun effetto sull'ambiente tale da essere poi percepito dal programma; anche la caratteristica di persistenza temporale è assente come nel caso precedente.
Riassumendo un agente è quindi visto come un'entità caratterizzata da:
1. uno stato interno;
2. un insieme di possibili comportamenti;
3. una capacità di produrre modifiche nell'ambiente in cui si trova (che può essere anche un ambiente virtuale);
4. una sensibilità alle modifiche di tale ambiente.
Riporto quindi in una tabella quelle che sono le proprietà caratteristiche degli agenti:

*PROPRIETA’*	*NOME ALTERNATIVO*	*SIGNIFICATO*
*Reattività*	(percepire ed agire)	Risposta ai cambiamenti dell’ambiente
*Autonomia*		Controllo sulle proprie azioni
*Guidato da obiettivi*	(proattività)	Capacità di iniziativa
*Persistenza*		Processo sempre in esecuzione
*Socialità*	(Capacità di comunicare)	Capacità di comunicare con individui o altri agenti.
*Apprendimento*	Adattamento, intelligenza	Cambiare comportamenti in base alle esperienze precedenti
*Mobilità*		Capacità di spostarsi in ambienti diversi da quello di partenza.
*Flessibilità*	Vitalità	Capacità di improvvisazione davanti ad imprevisti e di risolvere anomalie
*Benevolenza*		L’agente perseguirà gli obiettivi postigli
*Veridicità*		L’agente non deve comunicare false informazioni

In base alla definizione posta ogni agente deve soddisfare le prime 4 proprietà della tabella.
Le altre proprietà servono a creare delle sottoclassi di agenti specializzati.
Passando in particolare agli agenti software li si può classificare utilizzando criteri differenti: si possono considerare le proprietà degli agenti, oppure i compiti per i quali vengono sviluppati, i sistemi utilizzati per immagazzinare la conoscenza dell'ambiente esterno o ancora i sistemi con i quali essi riescono a rispondere agli stimoli esterni.

Modelli Per Lo Sviluppo Di Agenti Software

Architettura Di Un Agente

L'architettura dell'agente software rappresenta il sistema con il quale si permette all'agente di raggiungere le 4 caratteristiche fondamentali che lo caratterizzano (persistenza, autonomia, reattività, proattività).
Tali architetture possono classificarsi in 3 categorie principali:
a. Sistemi Basati sulla Conoscenza. (Knowledge Based System, KBS). Un agente realizzato usando questo tipo di approccio deve avere almeno tre componenti:
1. Un modello simbolico dell'ambiente in cui operare;
2. Un elenco simbolico delle azioni possibili;
3. Un Algoritmo di pianificazione che prenda in ingresso la rappresentazione dell'ambiente, la rappresentazione dell'obiettivo e la lista delle azioni possibili e produca in uscita una sequenza di azioni che l'agente possa eseguire per arrivare al risultato.
Un agente, quindi, estrae un obiettivo, crea una lista di azioni da seguire, le esegue e raggiunge l'obiettivo, spesso valutando tra una serie di strategie che portano all'obiettivo quella che rende massimo un certo punteggio di prestazione.
b. Architetture reattive. Il principio ispiratore di queste architetture è quello che spesso non è necessaria una complessa forma di ragionamento (come quella supportata nei modelli KBS) per ottenere comportamenti che sembrano intelligenti risposte agli stimoli esterni. Inoltre spesso molti esseri viventi hanno una immediata reazione agli input ambientali che non può essere frutto di un ragionamento "ad alto livello" ma di quella che si chiama una "reazione istintiva".
Gli agenti basati su questa architettura sono provvisti di un insieme di regole cui sono associate delle azioni da compiere. Quando l'agente percepisce che la situazione esterna corrisponde ad una certa regola esegue l'azione ad essa associata.
c. Architetture ibride. Alcuni ricercatori pensano che la direzione giusta sia quella dell'integrazione dei due approcci sopra elencate. La più conosciuta architettura ibrida è dovuta a Georgeff ed è chiamata Procedural Reasoning System (PRS), tale architettura è un esempio di paradigma chiamato Belief-Desire-Intention (BDI).

I Sistemi Di Acquisizione Conoscenza
Un agente può accrescere la propria conoscenza per meglio assistere l'utente nel suo operato. I metodi per far acquisire le conoscenze all'agente possono essere classificati nel seguente modo [PM94]:
User looking: l'agente accresce la propria conoscenza osservando l'utente anche a sua insaputa, per un certo periodo, tiene traccia delle sue scelta e modifica il suo profilo utente;
User indirect feedback: l'agente propone dei risultati all'utente e prende nota quando, l'utente, trascura il suggerimento proposto compiendo azioni anche contrarie;
User direct feedback: L'agente impara chiedendo espliciti chiarimenti sulle scelte fatte dall'utente;
Learning by Example: l'utente può fornire all'agente un insieme di esempi sui quali basarsi.
Vi sono due possibili approcci: 1) gli esempi sono dei casi particolari molto spesso ipotetici, forniti all'agente in anticipo per il suo addestramento, in questo caso le sue conoscenze sono statiche; 2) gli esempi sono casi reali che l'utente indica all'agente man mano che accadono, in questo caso si avrà una crescita dinamica delle sue conoscenze;
Agent asking: l'agente quando non ha conoscenze specifiche su un argomento chiede ad altri agenti di fornirgli informazioni utili per risolvere il problema proposto.

Sistemi Multiagenti Su Reti Distribuite(Agenti Mobili)
Per applicazioni che coinvolgono più agenti (sistemi multiagenti) operanti su reti distribuite alle funzionalità di base di un agente bisogna aggiungere 2 caratteristiche ulteriori:
1 I meccanismi che permettono di localizzare la posizione dei servizi richiesti in rete;
2 I protocolli di comunicazione e i linguaggi indispensabili per poter condividere e scambiare conoscenza.
La comunicazione è uno dei requisiti fondamentali degli agenti intelligenti, gli studi su un linguaggio per la comunicazione fra agenti (ACL) quindi sono fondamentali nello sviluppo della ricerca sugli agenti intelligenti.
Per definire un linguaggio standard di comunicazione fra agenti (ACL, Agent Communication Language) occorre prima decidere quali sono i suoi requisiti fondamentali, inoltre occorre fornire gli agenti di una comune sintassi, semantica e pragmatica.
I più importanti requisiti di un linguaggio di comunicazione sono: forma, contenuto, semantica, implementazione, affidabilità, Networking. L'adempimento di questi requisiti sono fondamentali per realizzare uno standard di comunicazione tra agenti.
Si tenterà di descriverli in dettaglio [5]:

Forma. Un buon ACL dovrebbe essere sintatticamente semplice, facilmente leggibile dai programmatori, inoltre conciso, facile da analizzare e generare.

Contenuto. Il linguaggio dovrebbe possedere un ben definito insieme di primitive, estensibili, in modo tale da assicurare non solo l'uso del linguaggio ad una vasta gamma di sistemi, ma anche garantendo l'utilizzazione tra diverse applicazioni che chiedono o offrono servizi.

Semantica. La semantica deve poter definire l'effetto di ogni singola operazioni, espressa in termini di Pre-condizioni e Post-condizioni. Le operazioni, espresse in questi termini, devono essere non ambigue.

Implementazione. L'implementazione dovrebbe risultare efficiente sia in termini di velocità sia di utilizzazione. Si dovrebbe ben adattare alle tecnologie esistenti, possedere un'interfaccia facilmente utilizzabile, ed adattabile a qualsiasi tipo di linguaggio sia esso ad oggetti come C++, Smaltalk, Eiffel, Java, sia procedurale come C, Lisp (funzionale).

Networking. Un ACL dovrebbe adattarsi bene alle moderne tecnologie di rete. Il linguaggio dovrebbe supportare tutti i tipi di connessione di base come point to point, multicast, brodcast, sia in modo sincrono sia asincrono. Inoltre dovrebbe contenere un elevato numero di primitive utilizzabili sui vari linguaggi e protocolli.

Affidabilità. Un linguaggio di comunicazione deve garantire l'affidabilità della comunicazione tra agenti, fornendo vari servizi di sicurezza. Ad esempio garantire lo scambio privato tra due agenti, o possedere un metodo per essere sicuri dell'autenticità dell'agente con cui si sta comunicando. Infine il sistema dovrebbe essere in grado di funzionare anche in caso malfunzionamenti della rete, o altri guasti.

Stabiliti quali sono i requisiti fondamentali, per definire uno standard di linguaggio di comunicazione, si spiegherà sommariamente, alcuni linguaggi e strumenti già esistenti, come KQML, CORBA.
Il KQML (Knowledge Query and Manipolation Language) è definito come un nuovo linguaggio e protocollo, per lo scambio di informazioni e conoscenze tra agenti.
KQML è stato creato dalla ARPA nell'ambito del progetto Knowledge Sharing Effort (KSE) [5], un'iniziativa per sviluppare tecniche che supportano la condivisione di informazioni tra sistemi basati sulla conoscenza.
Uno degli obiettivi di progetto per KQML è di creare un linguaggio che possa supportare una grande varietà di architetture di agenti.
Per fare ciò, è stata introdotta una speciale classe di agenti chiamati communication facilitors, con lo specifico compito di facilitare la comunicazione per lo scambio di servizi fra agenti con diverse architetture [FFMM96].
La comunicazione tra agenti avviene tramite l'invio di un messaggi e la ricezione da parte di un altro agente.
Il messaggio incapsula differenti informazione di vario tipo:

l'indirizzo di chi si vuole contattare, oppure i servizi che si richiedono, o almeno una loro descrizione;

un modo per indicare, con chiarezza e senza ambiguità alcuna, il significato del messaggio.

In questo caso si parla di ontologia del messaggio [5].
Nella figura 1 è possibile distinguere un agente server, quindi capace di servire un servizio, e due agenti client che richiedono un servizio.
Ogni agente è fornito di un programma detto routers e insieme al facilitor permette di localizzare l'altro agente con cui comunicare.
Routers e facilitors si appoggiano ad una libreria detta KRIL, (KQML Router Interface Library)

KQML Routers. Ciascun agente che utilizza KQML possiede un personale router. Tutte i routers sono identici, vale a dire che sono una copia dello stesso programma. Gestisce tutti i messaggi d'ingresso o di uscita dell'agente ad esso associato, non alterando mai il contenuto.

Se i messaggi in uscita hanno un indirizzo, il router si preoccuperà di far pervenire il messaggio al ricevente, se invece il messaggio specifica un particolare servizio, il router cercherà un indirizzo Internet, che possa soddisfare la richiesta.

KQML Facilitors. Qualora il messaggio non contenga un indirizzo, o esso sia incompleto, il facilitor potrà ovviare a tale mancanza, per mezzo di un registro dove annota i server e i servizi che offrono. Questo registro può risultare utile quando l'agente non è a conoscenza dell'indirizzo del server. A differenza del router, il facilitor è unico per un locale gruppo di agenti.

KQML KRILs. Poiché il router è un separato processo rispetto alle applicazioni, è necessario avere un insieme di interfacce che gestiscono la comunicazione tra le applicazioni e il router.

Figura 1.1 Un esempio di architettura client-server che utilizza KQML
KQML si avvicina molto ai canoni che deve possedere un linguaggio di comunicazione tra agenti, ed ha buone possibilità di divenire il linguaggio per eccellenza, in altre parole lo standard tanto atteso.
CORBA (Common Object Request Broker Architecture) è il più importante ed ambizioso progetto prodotto dall'OMG (Object Management Group), il quale raggruppa più di 700 diverse compagnie.
Inizialmente CORBA era stato sviluppato per permettere a "componenti" intelligenti di scoprire ciascuno l'altro e comunicare su un particolare bus, detto bus degli oggetti.
Il bus degli oggetti chiamato ORB (Object Request Broker) ha il compito di prelevare le varie richieste (oggetti) da un Client, e trovare un Server che possa soddisfarle (cfr. Fig. 1.2). Al Client non interessa quale Server si occuperà della sua richiesta, ma semplicemente vuole una risposta.
Infatti si può verificare che per la stessa richiesta, l'ORB associ due Server diversi.

capVIq.png 565x245

Figura 1.2. Esempio di architettura client-server che utilizza CORBA.
Attualmente il progetto CORBA è stato esteso per comprendere la comunicazione fra applicazioni Client-Server programmate in diversi linguaggi di comunicazione e installate su diverse piattaforme con diversi sistemi operativi [6]. Usando CORBA è possibile dotare queste applicazioni di una interfaccia comune scritta in un linguaggio puramente dichiarativo chiamato IDL (Interface Definition Language).
Usando l'IDL è possibile interfacciare applicazioni in C++ con altre scritte in COBOL usando il bus ORB per fare viaggiare le informazioni.

Applicazioni Adatte All'uso Di Agenti Software
L'uso degli agenti software nasce dalla crescente necessità affrontare e risolvere problemi la cui soluzione , mediante l'uso di tecniche di programmazione tradizionali, si rivela piuttosto complicata o insoddisfacente.
Tra le nuove applicazioni disponibili si possono elencare:
1- Le situazioni ove si debbano risolvere problemi complessi : in questi casi risulta più agevole considerare tanti sottoproblemi più semplici e delegare la risoluzione di ogni sottoproblema ad un agente specializzato che coopera con tutti gli altri.
In questo caso l'utilizzo degli agenti ricorda il processo che ha portato alla creazione dei linguaggi orientati ad oggetti e rappresenta un utile strumento per passare con minore difficoltà dalla definizione del problema da risolvere, alla individuazione delle strategie di risoluzione fino all'implementazione.
2- I sistemi dall'architettura particolarmente complessa ed, in particolare, i sistemi distribuiti (o anche i sistemi aperti), caratterizzati da una forte dinamicità: la loro struttura spesso non è nota a priori, ed è caratterizzata da componenti eterogenei collegati tra loro. La rete Internet è l'esempio più noto di sistemi di questo tipo, una rete di calcolatori debolmente connessa, in rapida crescita..
In questo caso si vorrebbero strumenti per interagire con macchine sparse sui nodi della rete, senza il costante controllo da parte degli utenti, realizzando forme di cooperazione e di negoziazione tipiche di un sistema multiagente.
3- applicazioni di monitoraggio utente: gli agenti che provvedono a dare assistenza a utenti, mentre interagiscono con altri strumenti computazionali.
L'interface agent è attivato dall'utente al fine di coadiuvarlo nel raggiungimento dei suoi obiettivi. Esempi di sistemi che utilizzano l'interface agent sono sistemi di tutoring intelligenti, dove l'agente osserva l'utente senza intraprendere alcuna azione autonomamente. Su esplicita richiesta, da parte dell'utente, fornisce dei suggerimenti sul modo migliore di risolvere il problema.
4- Miglioramento di soluzioni preesistenti ottenuti mediante l'utilizzo degli agenti sono nel caso in cui le informazioni, le competenze coinvolte, le capacità e le risorse non sono centralizzate ma distribuite tra entità autonome.
Si consideri il caso in cui si voglia pianificare un viaggio: vari agenti specializzati dovranno cooperare per poter prenotare i voli per le varie destinazioni, per ricercare le sistemazioni alberghiere, affittare auto oppure organizzare visite guidate in ciascuna città e così via. È proprio un caso in cui la soluzione di un problema necessita di informazioni, competenze, risorse distribuite tra entità aventi ciascuna i propri obiettivi (corrispondenti agli interessi dei rispettivi proprietari).
Ogni agente possiede le sue specifiche conoscenze ed è preposto a risolvere uno specifico problema; i vari agenti, dunque, dovranno sia interagire tra loro sia cooperare con altri agenti (quelli di chi offre i vari servizi) per poter raggiungere il comune obiettivo (il viaggio).
5- Un'ultima area applicativa integrazione tra sistemi proprietari.
Tipicamente l'utilizzo dell'agente permette di richiedere a quest'ultimo dei servizi mascherando le caratteristiche dei sistemi sottostanti (agenti come interfaccia tra sistemi differenti).

Riferimenti e bibliografia
[1] Is it an Agent, or just a program? A taxonomy for autonomous Agents. Stan Franklin and Art Graesser. Istituto per i sistemi intelligenti- università di Menphis. www.msci.menphis.edu/~franklin/agentprog.htm.
[2] Applications of Intelligent Agents N. R. Jennings and M. Wooldridge Queen Mary & Westfield CollegeUniversity of London
[3] T. Finin, D. McKay, R. Fritzson, and R. McEntire. "KQML:An Information and Knowledge Exchange Protocol." K. Fuchi and T. Yokoi (ed.), Knowledge Building and Knowledge Sharing, Ohmsha and IOS Press, 1994.
[4] T. Finin, Y. Labrou, and J. Mayfield. "KQML as an Agent Communication Language." J. Bradshaw (ed.), SoftwareAgents, MIT Press, 1997.
[5] Yannis Labrou, Tim Finin: "A Semantics approach for KQML - a general purpose communication language for software agents"; URL: http://AI-www.AISI-NARA.AC.jp/~takeda/doc/html/icot-paper-vr/; 1996.
[6] Robert Orfali Dan Harkey Jari Edwards: "Instant CORBA", pp 3-19, 1997

Gli Agenti Mobili Di Mitsubishi Eletric.
Molti sono gli esempi di applicazioni distribuite che tutti i giorni abbiamo modo di utilizzare, magari a nostra insaputa. Il World Wide Web è un esempio, forse il più utilizzato, di applicazione distribuita in cui si utilizza il paradigma Client/Server.Il Client/Server è un esempio di applicazione distribuita, in cui è richiesta la collaborazione di più programmi in esecuzione su computer diversi.
Possono essere spediti dati fra i vari computer, ma può essere spedito anche del codice da eseguire.
Internet può quindi essere considerato il più grande sistema distribuito mai costruito.
Per evidenziare ancora di più il senso di globalità si parla anche di Computazione Globale (Global Computation).
Oltre all'esempio dell'ipertesto globale del World-Wide-Web, vale la pena ricordare che il protocollo Ftp ci mette a disposizione un file system globale, nel senso che possiamo accedere a tutti gli hard disk di tutti i computer collegati ad Internet (ai quali abbiamo l'accesso, ovviamente), e col protocollo Telnet possiamo utilizzare computer sparsi per il mondo come se fossero a casa nostra.
Ovviamente non si sono considerati i problemi di connessione e, quindi, il tempo necessario per portare a termine operazioni che fanno uso della rete.
Diventa quindi inutile avere computer potenti, quando si usano connessioni di rete poco veloci: nelle applicazioni distribuite i fattori da prendere in considerazione sono la latenza e la bandwidth, e non tanto la velocità del processore e la quantità di memoria (purché questi non raggiungano valori talmente bassi da diventare a loro volta fattori importanti).
Prendiamo in esame alcuni dei più famosi paradigmi per il codice mobile.
Client - Server: si tratta di una filosofia di programmazione molto diffusa, che viene utilizzata anche in assenza di connessioni di rete: il client richiede dei servizi messi a disposizione da un server.
Il server ha a disposizione tutte le risorse e tutti i mezzi per adempiere alla richiesta del client e fornirgli i risultati.
Questo almeno è quello che appare al client: il server a sua volta per portare a termine il suo compito, può richiedere alcuni servizi ad un altro server, agendo così anche come client.
Ovviamente non è necessario che client e server risiedano su computer diversi.
Come si è detto, si tratta di un'astrazione per distribuire i vari compiti tra vari componenti, che possono essere threads di esecuzione diversi su una stessa macchina, oppure programmi che risiedono su macchine diverse, che si trovano geograficamente lontane.
Se si ha davvero l'indipendenza dalla locazione fisica, la distribuzione diventa completamente trasparente per il client e per il server.
Il sistema X-Windows adotta il paradigma Client-Server: il server gestisce un display fisico ed i vari client (le varie applicazioni) non accedono direttamente al display, ma vi accedono tramite la richiesta di servizi al server; una piacevole conseguenza di questo sistema è che il client può risiedere su una macchina diversa ed ottenere comunque i servizi grafici messi a disposizione di un server remoto.
Una normale sessione del server può essere così schematizzata:
Intercetta la query proveniente dal client locale o da un server remoto
Verifica che la query sia soddisfatta sul database locale
Se la query non ha avuto successo, inviala ai vari server collegati
Remote Evaluation: un programma X per portare a termine un certo compito può avere bisogno di risorse che non sono presenti nella macchina in cui si trova.Può appoggiarsi allora ad un altro calcolatore dotato di tali risorse.
E' compito del programma X fornire le istruzioni necessarie per utilizzare tali risorse.
Sul computer remoto sarà presente un altro programma Y che è in ascolto di richieste in arrivo. Tale programma mette a disposizione le risorse della propria macchina (come del resto faceva il server nel paradigma Client-Server), purché il programma X gli fornisca del codice da eseguire; questo codice sarà mandato in esecuzione sul computer dove è in esecuzione Y.
Questo paradigma è, in effetti, più flessibile del precedente: il precedente mette a disposizione solo un numero limitato di servizi che il client può richiedere.
In questo paradigma invece l'esecutore (il programma Y) offre un servizio programmabile, poiché esegue codice fornito da altri programmi.
Non c'è bisogno di riprogrammare il server per ottenere nuovi servizi.
Code on Demand: questo è il caso esattamente simmetrico al precedente: il programma X ha le risorse, ma non sa come utilizzarle, richiede quindi delle istruzioni (codice) ad un altro programma Y, che risiederà su un altro computer.
Una volta ottenute le istruzioni, sarà il programma X ad eseguirle sul proprio computer e sulle proprie risorse.
Il browser ha a disposizione tutte le risorse (monitor, primitive grafiche), ma è il server web a cui viene spedita la richiesta che spedisce il documento: codice HTML, quindi codice, da essere eseguito (interpretato) per mostrare all'utente le informazioni richieste.
Come si è visto nel paradigma Client - Server non viene trasmesso codice, ma solo dati che descrivono la richiesta di un particolare servizio.
Gli altri due paradigmi sono molto più potenti del primo: viene spedito codice eseguibile, e questo rende indipendenti i programmi che comunicano, in quanto non è necessario modificare l'esecutore, se vogliamo che esegua operazioni nuove: basta modificare il programma che spedisce il codice, anzi, basta modificare solo il codice spedito.
Agenti Mobili: è il paradigma che estremizza il concetto di codice mobile.
Un programma X invece di spedire il codice ad un altro programma che si trova su un computer remoto, si trasferisce su tale computer, insieme ai suoi dati, e continua la sua esecuzione lì.
Questa esigenza può nascere nel caso in cui il programma X abbia dei dati e delle operazioni da eseguire su questi dati, però non ha alcune risorse che sono su un altro computer, ma che comunque non possono essere trasferite tramite la rete.
Ad esempio può essere necessaria una notevole potenza di calcolo, e questa (purtroppo) non può essere trasferita in rete, ed allora, per sfruttarla, X dovrà trasferirsi su questo potente computer, effettuare lì le operazioni sui propri dati, e ritornare sul computer da cui era partito per riportare i risultati all'utente che aveva lanciato il programma.
Col paradigma degli agenti mobili si cerca di ridurre l'utilizzo della rete per la comunicazione fra più applicazioni: col Client - Server, per ogni richiesta di servizio si ha la spedizione di un pacchetto in rete, e si è già detto che l'utilizzo della rete è il collo di bottiglia delle applicazioni distribuite.
Se quindi il client ha bisogno di effettuare una certa operazione tramite la chiamata dei servizi del server, si avranno tante comunicazioni in rete quante richieste di servizi sono necessarie per portare a termine tale operazione.
L'idea degli agenti mobili è invece quella di svolgere tale operazione direttamente spostandosi (spostando il proprio codice e i dati) sul computer del server, ed interagire col server in locale.
I risultati delle operazioni saranno poi riportati al sito di origine.
E' chiaro che in questo caso solo due comunicazioni in rete sono necessarie: una per la spedizione dell'agente e l'altra per il ritorno a casa dell'agente (o comunque per la spedizione del risultato).
Un Agente è un programma che va in esecuzione su un server, indipendentemente dall'utente che lo ha lanciato e dal fatto che sia contemporaneamente collegato o meno alla rete.
Gli agenti mobili possono viaggiare su molteplici macchine, eseguire una qualche applicazione e portare indietro, sulla macchina che lo ha lanciato, i risultati.
L'obbiettivo più frequente dell'Agente Mobile è quello di interrogare alcuni database, estrarre informazioni su determinati prodotti e stabilire quale offerta sul mercato si avvicina maggiormente ai requisiti dell'utente.
Per questo tipo di soluzione e' necessario progettare i seguenti tre diversi elementi software:
Client: intercetta le richieste dell'utente, genera l'agente appropriato e lo spedisce al server a cui e' collegato
Agente mobile: e' il programma vero e proprio che viene fatto migrare da client a server o da server a server
Server o contesto di esecuzione: ha il compito di intercettare l'agente ed eseguirlo in un ambiente protetto
Un computer con un sistema operativo costituisce una piattaforma su cui gli sviluppatori possono costruire applicazioni; il paradigma comunicazione degli agenti mobili vuole rendere la rete una piattaforma per sviluppare applicazioni.

I Vantaggi degli Agenti Mobili

Uno dei vantaggi degli agenti è che questi possono operare per conto dell'utente anche quando non è connesso.
Inoltre una comunicazione Client/Server può richiedere molti flussi di dati tra client e server al fine di compiere anche una semplice operazione.
Al contrario, un agente può essere iniettato in rete, raggiungere il server, instaurare una comunicazione locale, e riportare i risultati rilevati al client, utilizzando quindi solo due comunicazioni in rete.
Con la soluzione che prevede l'utilizzo degli agenti mobili tutte le funzionalità aggiuntive possono essere sviluppate ed aggiunte secondo la logica degli agenti: per ogni funzione aggiuntiva è infatti necessario progettare e realizzare solo l'agente che si occupa di detto scopo senza modificare le caratteristiche del server.
Il robot aggiuntivo viene eseguito sul server solo nel momento in cui serve e normalmente non occupa risorse del sistema quando non viene utilizzato.
Inoltre gli agenti mobili consentono:
di sfruttare le potenzialità di calcolo del server ;
una alta affidabilità di trasmissione ;
l'uso di dispositivi personali e a basso costo;
un buon livello di sicurezza su una rete pubblica.

I Vantaggi di Java

Vediamo adesso cosa offre Java per le applicazioni distribuite ed in particolare come, se possibile, sfruttare le features di questo linguaggio per implementare i suddetti paradigmi di comunicazione.
Senz'altro l'utilizzo delle sockets rende possibile l'implementazione di programmi che comunicano tramite il paradigma Client / Server.
I sockets non sono di certo una novità, tuttavia l'implementazione che Java fornisce a livello di classi utilizzabili dall'utente, rende la scrittura di un'applicazione Server e di una Client molto semplice. Lo stesso non si può dire delle API sockets che si trovano nelle librerie di altri linguaggi (vedi C fra tutti). Da una parte il server creerà un oggetto di classe ServerSocket specificando semplicemente il numero della porta su cui si metterà in ascolto col metodo accept (sempre della suddetta classe).
Questo metodo, appena sarà ricevuta una richiesta di connessione, restituirà un oggetto della classe Socket. Usando i due stream (di input e di output) messi a disposizione da tale oggetto sarà possibile iniziare la comunicazione.
Dall'altra parte il client dovrà creare un oggetto della classe Socket specificando nel costruttore l'indirizzo dell'host e il numero di porta; se la connessione viene stabilita anche il client userà i due stream per la comunicazione col server.
Ovviamente tali stream di input e output derivano rispettivamente dalle classi basi astratte InputStream e OutputStream, quindi qualsiasi classe che usi degli stream ai quali si riferisce tramite variabili (riferimenti) di tipo InputStream e OutputStream, potrà comunicare in rete in modo completamente trasparente.
Nella release 1.1 del jdk è inoltre presente un nuovo framework, Remote Method Invocation , abbreviato spesso con RMI, che permette ad oggetti che si trovano anche su computer diversi di comunicare tramite normali invocazioni di metodi.
In questo modo si può ottenere un riferimento ad un oggetto remoto, e chiamarne i metodi, come se fosse un oggetto locale. Questo non è altro che il meccanismo delle Remote Procedure Calls (RPC).
In questo modo il client non dovrà richiedere dei servizi al server, ma, una volta ottenuto un riferimento ad un oggetto server, ne chiamerà direttamente i metodi.
In Java le classi vengono caricate a run-time solo quando sono necessarie, tramite un ClassLoader. Il ClassLoader può recuperare i dati delle varie classi non solo dal file system locale, ma anche dalla rete.
Del resto, quando apriamo una pagina web in cui è presente un'applet Java, è il class loader che si preoccupa di trasferire dalla rete tutti i dati necessari per le classi usate dall'applet; anzi solo delle classi che effettivamente vengono usate dall'applet.
Non basterà la dichiarazione di una variabile di tipo X perché il ClassLoader cerchi di scaricare dalla rete i dati del file X.class, ma sarà necessaria un'istruzione del tipo new X(...). Quindi i dati della classe saranno scaricati solo quando viene creato un oggetto di tale classe . Ovviamente questo meccanismo viene utilizzato anche in locale, ma forse in quel caso non viene notata una grossa differenza.
I motivi di tale ottimizzazione risiedono, ovviamente, nel cercare di ridurre il più possibile le comunicazioni in rete. Il downloading dinamico delle classi di un'applet non è altro che un esempio di Code On Demand.
Un'altra feature molto importante introdotta nel jdk 1.1 è la Serializzazione .
Tramite questa è possibile scrivere in uno stream (ObjectOutputStream e ObjectInputStream) un qualsiasi oggetto; quest'ultimo deve appartenere ad una classe che implementi l'interfaccia java.io.Serializable.
Si noti che basta dichiarare che una classe implementa tale interfaccia, senza dover definire metodi particolari: tutti i dettagli di tale serializzazione sono risparmiati al programmatore, e questo non è poco! Ovviamente le classi più usate implementano tale interfaccia.
Siccome si è visto che le comunicazioni tramite le socket avvengono usando gli stream, si capisce subito che tramite la serializzazione si possono spedire interi oggetti in rete. In particolare anche i threads possono essere spediti in rete tramite la serializzazione (la classe Thread non implementa l'interfaccia richiesta, ma basta derivare da Thread ed implementare tale interfaccia nella classe derivata), quindi se sul computer destinatario è in ascolto un programma per ricevere threads dalla rete e mandarli in esecuzione, si ha un esempio di Remote Evaluation!
A questo punto il passaggio agli agenti mobili sembra scontato: dovrebbe bastare modificare tale programma sul computer di destinazione, in modo che invece di mandare in esecuzione il thread letto dalla rete, lo faccia semplicemente continuare ad eseguire dal punto in cui era stato interrotto.
Purtroppo questo non è possibile: la Java Virtual Machine non permette di modificare direttamente il Program Counter (ovviamente per motivi di sicurezza tra le altre cose), e comunque lo stato di esecuzione di un thread non viene serializzato.
Un'implementazione corretta degli agenti mobili, richiede invece che sia possibile proprio questa caratteristica; se si vuole, questa è una di quelle caratteristiche che differenzia il paradigma degli agenti mobili da quello della Remote Evaluation.
Se con mobilità di codice, si intende la possibilità di permettere ad un processo, o ad un thread, di spostare il proprio codice ed il proprio stato di esecuzione, su un altro computer, e lì proseguire ad eseguire, allora NON possiamo dire che Java permette la mobilità di codice: permette piuttosto ad un thread su un certo computer di collegarsi (il termine inglese è linked oppure bounded) dinamicamente con del codice proveniente da un altro computer.
Java sarebbe un linguaggio che permette la mobilità debole (weak mobility), che è contrapposta al primo tipo di mobilità: la mobilità forte (strong mobility).
Comunque a Java manca molto poco per fregiarsi di tale qualità: il punto debole è proprio quello di non permettere il salvataggio ed il ripristino dello stato di esecuzione, ma, tramite piccoli stratagemmi e regole a cui il programmatore che vuole usare gli agenti mobili in Java deve sottostare (quelle adottate negli Aglets), si può dire che gli agenti mobili sono implementabili in Java.
Del resto non dimentichiamo che programmazione distribuita implica programmazione concorrente, che, a sua volta, implica necessità di sincronizzare processi e risorse ed in questo non possiamo avere niente da ridire su quello che Java mette a disposizione: sincronizzazione a livello di linguaggio, quindi a livello di sintassi, e non di libreria! Questo vuole dire poter scrivere sezioni critiche in modo pulito, direttamente con istruzioni specifiche: l'istruzione synchronized permette l'accesso ad un thread alla volta al blocco di codice che racchiude, o ad alcuni metodi di una classe.
Ovviamente è sempre compito del programmatore sincronizzare in modo opportuno risorse e threads, ma in questo modo si ha la possibilità di farlo in modo semplice ed elegante (e spesso questo ha come piacevole conseguenza la leggibilità di codice!).
Inoltre un problema legato alla programmazione distribuita è la forte dipendenza dall'architettura del computer sul quale sarà eseguito il codice.
Il paradigma Client / Server non risente molto di questo problema, perché non viene spostato del codice, ma solo dei dati (tutt'al più si avranno da risolvere i problemi delle rappresentazioni dei dati nelle varie piattaforme).
E' anche vero, però, che i paradigmi più interessanti e flessibili sono proprio quelli che basano la propria forza sulla spedizione di codice in rete.
Già sarebbe tanto richiedere che codice compilato per un sistema operativo su una macchina Intel venga eseguito correttamente e senza problemi su un computer sempre Intel, ma con un diverso sistema operativo, figuriamoci quando , oltre al sistema operativo, cambia anche il tipo di processore! Java, per l'ormai suo famoso byte code, non presenta, o quasi, questo problema

Concordia: Java Mobile Agent Technology
Un Concordia System è costituito di:
Java VirtualMachine;
Concordia Server;
Almeno un Agente;
Il Concordia Server è un programma Java che si esegue in ogni nodo in cui l'agente si installa.
L'Agente è un altro programma Java che il Concordia Server gestisce attraverso la rete.
E' stabilito un Itinerario (tipo di macchina e metodo associato) tramite il quale il Concordia Server conosce quale metodo deve essere spedito e dove. Una volta trasferito, l'Agente e' incodato al nodo per essere eseguito.
L'Agente può essere anche un demone remoto.
In tutti i modi gli Agenti Concordia sono autonomi e autodeterminanti.
Il lavoro di trasporto dell'Agente è trasparente all'utente e lo stato delle variabili persiste durante tutti i trasferimenti dell'Agente. Il Concordia utilizza un modello push-pull per muovere i bytecodes.
Il pull model funziona in modo simile al downloading del bytecode di un'applet; ogni agente porta un URL che punta alla locazione del suo codebase sulla sua home machine.
Se il Server Concordia si accorge che il codice non è presente sul File System locale, lo richiama dalla host machine.
Il push model fa viaggiare la classe richiesta una sola volta, insieme all'Agente, sulla rete. Per questo bisogna specificare le classi che viaggeranno con l'Agente. Se una classe servirà ad ogni salto sulla rete si userà il push model. Se una classe può non servire si propenderà per l'altro modello.
L'Itinerario dell'agente definisce dove esso viaggerà sulla rete, tramite la coppia tipo di macchina - tipo di lavoro .
Tipicamente un sistema Concordia è formato da più macchine collegate in rete Lan opp. Wan, ognuna delle quali esegue il suo Concordia Server entro il quale operano gli agenti mobili. Il Concordia Server presiede la gestione dei servizi Concordia, provvede alla creazione/distruzione degli agenti e costituisce l'ambiente in cui essi operano.

Componenti Del Sistema Concordia

caVIsa.gif 323x254

Il Concordia Server è il sistema completo installato ed operante su ciascuna macchina della rete Concordia. Esso è formato da dei componenti funzionali adibiti allo svolgimento di differenti compiti:
- L'Agent Manager si occupa della gestione delle comunicazioni sulla rete. Rappresenta un livello di astrazione per il programmatore rispetto alla complessità della rete.
- Il Security Manager assicura l'integrità delle risorse disponibili, degli agenti e dei dati che essi trasportano.
- Il Persistence Manager memorizza lo stato dell'agente nella fase di trasferimento verso un altro nodo della rete; esso permette di riavviare gli agenti in occasione del ripristino di un server della rete che abbia subito un precedente blocco.
- L'Inter-Agent Communication Manager gestisce lo scambio di messaggi tra gli agenti. È possibile quindi inviare un messaggio di notifica al verificarsi di un certo evento ad un gruppo di agenti, non necessariamente presenti sullo stesso nodo della rete. Inoltre l'Inter-Agent Communication Manager permette la cooperazione tra gli agenti (sincronizzazione e scambio di dati).
- Il Queue Manager si occupa dello scheduling degli agenti presenti sul server e garantisce la trasmissione "affidabile" degli agenti su di una rete "inaffidabile".
- Il Directory Manager permette a ciascun agente di localizzare un servizio disponibile sulla rete.
- L'Administration Manager rappresenta lo strumento di gestione dell'intero sistema Concordia.
- L'Agent Tool Library è l'insieme degli strumenti di sviluppo degli agenti Concordia(Administration APIs, Lightweight Agent Transport APIs, Service Bridge API, etc.).

Caratteristiche Principali Di Concordia

Concordia utilizza i servizi di comunicazione offerti da TCP/IP.
In questo modo utilizza protocolli di comunicazione ampiamente standardizzati.
Le funzioni di gestione avanzata del sistema permettono di manipolare migliaia di agenti in esecuzione su ciascun server. L'amministratore del sistema può avviare, sospendere, fermare l'attività dei server, e gestire i permessi di accesso degli agenti. Inoltre in ogni momento può monitorare le prestazioni del sistema.
La Collaborazione tra gli agenti può essere utilizzata per scopi differenti; l'esempio più ovvio consiste nella possibilità di svolgere attività in parallelo sui vari nodi della rete. Un altro esempio è costituito dalla semplicità con la quale si può scindere un problema complesso in una serie di sotto-task da svolgere e affidare ciascuno di essi ad un agente. Infine i risultati ottenuti durante l'esecuzione dell'agente possono determinare le successive azioni che dovrà svolgere e i nodi da raggiungere.
Il Service Bridge consente di estendere i servizi del Concordia Server permettendo la comunicazioni con servizi esterni alla JVM .
Persistence and Queuing sono i sistemi che affrontano i problemi legati ai cattivi funzionamenti del sistema e/o della rete. Tali servizi sono pensati anche per garantire il corretto bilanciamento del sistema, qualora le macchine sulla rete offrano prestazioni differenti.
Il Service Naming, in un ambiente caratterizzato dall'estrema mobilità dei servizi e delle informazioni (internet), permette di definire una lista che renda possibile di localizzare un servizio.
La Struttura di Sicurezza prevede una serie di diritti di accesso ai servizi, legati ai proprietari degli agenti.
Lightweight Agent Transporter API: queste API permettono allo sviluppatore di ricevere, eseguire e lanciare agenti Concordia all'interno di una applicazione client (tipicamente un'applet Java), senza dover installare un Concordia Server sulla macchina client. Questo oggetto l'Agent Transporter, sebbene non fornisca i servizi di amministrazione e di robustezza e affidabilità del Concordia Server, tuttavia fornisce la struttura minima di comunicazione e sicurezza necessaria per eseguire e inviare gli agenti Concordia.
Servizi di Crittografia: non sono integrati nel Security Manager, in quanto è prevista la possibilità di inserire il proprio meccanismo di sicurezza preferito.

Benefici Derivanti Nello Sviluppo Di Software Basato Su Agenti Concordia

Gli agenti Concordia possono essere utilizzati per sviluppare nuove applicazioni, oppure per aggiungere nuove funzioni a quelle già esistenti.
Tali agenti sono stati pensati per permettere l'elaborazione off-line, sviluppare applicazioni per reti distribuite con una opportuna astrazione dalle problematiche di comunicazione, garantendo servizi di affidabilità e sicurezza.
Ecco, dunque, quali sono le possibili applicazioni di questo sistema:
- Applicazioni che accedano a dati distribuiti in una rete caratterizzata da veloci cambiamenti (per esempio la posizione dei servizi e dei dati cambia frequentemente).
- Permettere l'accesso ad applicazioni proprietarie da parte di personale operante all'esterno dell'azienda (rappresentanti, venditori, etc); estendere così il ciclo di vita delle applicazioni preesistenti aggiungendo nuovi servizi (i.e. accesso Internet/Intranet Access, Mobile Computing Features, Disconnected Computing Capabilities, etc.)
- Utilizzare oggetti distribuiti mediante CORBA (i.e. providing Business-Business interfaces for Electronic Commerce)
- Permettere applicazioni che non necessitino una connessione persistente per essere portate a termine (avvio di una elaborazione batch su un server remoto).
- Integrazione tra strumenti di comunicazione differenti (laptops, PDAs, smartphones, windows, Macs, Email, Voicemail, Pager, or FAX)
- Sviluppo di applicazioni di monitoraggio dei nodi di una rete (i.e. Network Monitoring Applications).
- Sviluppare rapidamente nuovi applicativi che in precedenza si sarebbero basati su architettura Client/Server

Riferimenti

1 Home Page CONCORDIA:
http://www.meitca.com/HSL/Projects/Concordia/.
2 Concordia at glance
3 Mobile agents white paperobile Agents : are they a good idea? Colin G. Harrison David M. Chess IBM Research Division Yorktown Heights NY 010598
4Concordia: An Infrastructure for Collaborating Mobile Agents David Wong, Noemi Paciorek, Tom Walsh, Joe DiCelie, Mike Young, Bill Peet
Mitsubishi Electric ITA Horizon Systems Laboratory 1432 Main Street
Waltham, MA 02154, USAemail: {wong,noemi,walsh,dicelie,young,billp}@meitca.com
5 Mobile agent computing : a white paper from Mitsubishi Electric ITA
6 Security and Reliability in Concordia TM Tom Walsh, Noemi Paciorek, David Wong

PARTE II: AGENTI INTELLIGENTI PER IL COMMERCIO ELETTRONICO Cap.VI: Gli Agenti Software

Definizione E Proprietà Degli Degli Agenti- Gli Agenti Autonomi

Modelli Per Lo Sviluppo Di Agenti Software

PARTE II: AGENTI INTELLIGENTI PER IL COMMERCIO ELETTRONICO

Cap.VI: Gli Agenti Software