Tesi - Un modello di qualità per la scelta di servizi Web in ambito Biomedico (il ruolo dei modelli

Un modello di qualità

per la scelta di servizi Web in ambito Biomedico

(il ruolo dei modelli di coordinazione)

Barbara Re

A me, alla mia testardaggine e al mio impegno

e a tutti coloro che, anche volendo, non

possono raggiungere questo obiettivo.

ii

Ringraziamenti

Prima di tutto vorrei ringraziare i miei genitori per avermi sostenuto ed aver sempre creduto

in me. Mamma grazie per tutti gli insegnamenti che mi hai dato, spero di essere nel corso

della mia vita tanto forte almeno quanto te!

Un grazie alla mia sorellina. Milly spero che per ora possa essere stata per te una brava

maestra ed amica, nonchè un esempio da seguire.

Un grazie lo devo anche a Chiara insostituibile compagna di studi e di avventure Camerti.

Per il suo sostegno ed i suoi consigli, per tutte le volte che mi ha permesso di sfogarmi e mi

è stata vicino incondizionalmente. Spero di cuore amica mia che questa società fondata nel

1997 non si sciolga così facilmente!!

Inoltre, vorrrei ringraziare la Dott. Emanuela Merelli che mi ha seguito in questi mesi di

lavoro per i continui stimoli, per avermi accolto come solo una madre sa fare e per avermi

sostenuto e dedicato un bel pò del suo tempo, nonostante i molteplici impegni. Grazie Prof

per l'amore che dedica alla ricerca e alla sua professione, perchè possa essere per me un

esempio per tutta la vita.

Vorrei ringraziare, inoltre, Paolo Romano per la disponibilità, la coordialità e l'interesse

verso questo lavoro.

Un ringraziamento particolarare va a Diego per i suoi consigli e per tutte le volte che

chiedendogli aiuto non ha detto �non posso�.

Ed in�ne grazie amore mio!!

Indice

Indice ix

1 INTRODUZIONE

Un modello di qualità per il recupero di informazioni in Internet 1

1.1 Il dominio Biomedico . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 L'obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 I principali approcci . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 La struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . 8

I PARTE TEORICA 11

2 Modello di coordinazione 13

2.1 Cosa si intende per coordinazione . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Processi di coordinazione di base . . . . . . . . . . . . . . . . 18

2.1.2 Modelli e metafore in Biologia . . . . . . . . . . . . . . . . . . 20

2.2 Agenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Tipologie di Agenti . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2 Multi agent system (MAS) . . . . . . . . . . . . . . . . . . . 26

v

INDICE

2.3 Modelli di coordinazione per applicazioni basate su agenti . . . . . . 27

2.3.1 Coordinazione Diretta . . . . . . . . . . . . . . . . . . . . . . 28

2.3.2 Coordinazione Meeting-Oriented . . . . . . . . . . . . . . . . 29

2.3.3 Coordinazione Blackboard-based . . . . . . . . . . . . . . . . 31

2.3.4 Coordinazione Linda-like . . . . . . . . . . . . . . . . . . . . . 32

2.4 Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5 Aggiungere reattività al modello di coordinazione . . . . . . . . . . . 36

2.6 Tucson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6.1 Il modello di coordinazione TuCSoN . . . . . . . . . . . . . . 38

2.6.2 Tuple Centre . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6.3 Reazioni TuCSoN . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Due modelli di coordinazione: brokering e matchmaking 43

3.1 Processo di localizzazione di un servizio:

una veduta d'insieme . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2 Cosa sono i Middle-agent . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1 Servizio di mediazione . . . . . . . . . . . . . . . . . . . . . . 47

3.2.2 Coordinazione del servizio di mediazione . . . . . . . . . . . . 50

3.2.3 A�dabilità della mediazione . . . . . . . . . . . . . . . . . . . 52

3.3 Tipi di Middle-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.3.1 Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3.2 Brokers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3.3 Matchmaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.4 Come avviene la coordinazione del

broker e matchmaker . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

vi vi

INDICE

3.4.1 Il matchmaking . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4.2 Il brokering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5 Matchmaking e brokering performance a confronto . . . . . . . . . . 62

3.5.1 Sistemi Sperimentali . . . . . . . . . . . . . . . . . . . . . . . 62

3.5.2 Un primo esperimento sul tempo di risposta . . . . . . . . . . 63

3.5.3 Un secondo esperimento sul fallimento del sistema e il suo

ripristino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.6 Un linguaggio comune per descrivere le capacità degli agenti . . . . . 67

II PARTE APPLICATIVA 69

4 Strumento di lavoro: JADE 71

4.1 Che cos'è JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.1.1 Containers e Piattaforme . . . . . . . . . . . . . . . . . . . . 73

4.1.2 Le componenti fondamentali: AMS, DF e ACC . . . . . . . . 74

4.2 Behaviour degli agenti . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3 Comunicazione tra agenti . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3.1 Struttura di un messaggio ACL . . . . . . . . . . . . . . . . . 80

4.3.2 Supporti alla comunicazione . . . . . . . . . . . . . . . . . . . 82

4.3.3 Contenuto dei messaggi ACL . . . . . . . . . . . . . . . . . . 83

4.3.4 Invio e ricezione dei messaggi . . . . . . . . . . . . . . . . . . 83

4.3.5 Spedire messaggi ad agenti remoti . . . . . . . . . . . . . . . 84

4.4 Ontologie in Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.5 Mobilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.6 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

vii vii

INDICE

5 BioMOBY 93

5.1 MOBY: una veduta d'insieme . . . . . . . . . . . . . . . . . . . . . . 94

5.2 Componenti di MOBY . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2.1 MOBY-Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2.2 MOBY-Central . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.3 Comparazione con myGrid . . . . . . . . . . . . . . . . . . . . . . . . 105

5.4 Il nostro MOBY-Central locale . . . . . . . . . . . . . . . . . . . . . 105

5.4.1 Istallazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.4.2 DataBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.5 Servizi preseti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6 Caso di Studio 125

6.1 Architettura e modello di coordinazione . . . . . . . . . . . . . . . . 126

6.2 Protocollo di comunicazione:

MOBYOntology e MOBYVocabulary . . . . . . . . . . . . . . . . . . 131

6.3 Agenti e Behaviours . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.3.1 BioMobyServiceAgent . . . . . . . . . . . . . . . . . . . . . . 140

6.3.2 BioMobyDiscoverServiceAgent . . . . . . . . . . . . . . . . . 143

6.3.3 BioMobyApplicationAgent . . . . . . . . . . . . . . . . . . . . 148

6.3.4 QualityServiceAgent . . . . . . . . . . . . . . . . . . . . . . . 152

6.4 La qualità in Internet . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.4.1 Tre livelli di matching . . . . . . . . . . . . . . . . . . . . . . 156

6.4.2 Criteri generali di valutazione della qualità . . . . . . . . . . 157

6.4.3 Algoritmo di matching . . . . . . . . . . . . . . . . . . . . . . 162

Conclusioni 171

viii viii

INDICE

Appendice 175

A Lista degli acronimi e dei relativi signi�cati 177

B AUML 183

ix ix

Capitolo 1

INTRODUZIONE

Un modello di qualità per il

recupero di informazioni in

Internet

Internet rappresenta un'opportunità senza precedenti. Il suo impiego può fornire agli

operatori sanitari (e più in generale alla popolazione) un'informazione sanitaria di

qualità e di facile accesso. Tuttavia, l'informazione disponibile nella rete può anche

risultare di qualità scadente, quando non dannosa. Tutte le indagini che �nora

hanno valutato la qualità delle informazioni sanitarie su Internet hanno mostrato

in tutti i settori esaminati la presenza, nella maggioranza dei casi, di informazioni

non accurate o incomplete. C'è quindi un bisogno impellente di fare qualcosa nei

confronti dei cittadini, dei medici e dei ricercatori nel settore della medicina per

1

INTRODUZIONE

impedire il veri�carsi di una epidemia di disinformazione medico-scienti�ca.

Il problema quindi non sta più nel trovare le informazioni, ma sta nel valutare la

credibilità di chi le o�re così come l'attinenza e l'esattezza di un servizio ricercato

nella rete.

Emerge la necessità di possedere un modello con cui poter misurare la qualità delle

informazioni recuperate. In questo scenario la tecnologia on-line stà contribuendo a

sostanziali cambiamenti.

Per i cittadini si ha:

• accesso diretto agli specialisti che lavorano nei centri maggiori; la telemedicina

eliminerà la necessità di viaggi lunghi, sconvenienti e potenzialmente pericolosi

per i pazienti;

• riduzione dei tempi d'attesa, meno ansie per prenotazioni di ricoveri, consegne

di risultati di esami e disponibilità di farmaci;

• miglioramento dell'informazione pubblica.

Per i medici si ha:

• condivisione delle informazioni sui pazienti;

• accesso immediato, dalle loro postazioni, su base geogra�ca o dal letto del

paziente, a:

� informazioni cliniche integrate;

� recenti ricerche e pratiche cliniche;

� risorse per l'aggiornamento continuo;

� migliore informazione sulle priorità e gli approcci per migliorare la sanità

e l'assistenza;

2

INTRODUZIONE

• aumento delle opportunità e maggiore semplicità di comunicazione.

Mentre per i ricercatori si ha:

• accesso immediato al servizio;

• alta varietà dell'o�erta;

• convenienza;

• personalizzazione del servizio;

• annullamento delle distanze;

• velocità;

• servizi fruibili 24 ore su 24 e sette girni su sette.

Quindi la medicina on-line mette insieme più settori: siti scienti�ci, siti dedicati al

paziente, cartelle sanitarie, portali sanitari, aziende farmaceutiche, siti istituzionali,

pagine personali, ... rimane di�cile identi�care un unico standard di qualità data

la diversità di ognuno. Per questo motivo il dominio applicativo verrà ristretto alla

biomedicina.

Nel primo paragrafo tratteremo del dominio applicativo su cui svilupperemo la

nostra architettura, nel secondo si discuterà dell'obiettivo che miriamo a raggiungere,

nel terzo si fa una breve panoramica sugli standard che la rete ci mette attualmente

a disposizione. In�ne, nel quarto viene presentata la struttura della tesi.

1.1 Il dominio Biomedico

Alla luce di quanto detto, l'ambiente in cui andremo a lavorare è quello biomedico.

3

INTRODUZIONE

Bioinformatics, la Bioinformatica, come de�nito nel glossario di Telemedicina

della Commissione Europea [Beo03], può essere considerata come l'attività a cav-

allo tra la biologia molecolare e quella computazionale. Bio-medical Informatics,

l'Informatica Biomedica, introduce in questa attività multidisciplinare una parti-

colare attenzione a prevenire, diagnosticare e trattare le malattie. In altre parole

la Bio-medical Informatics rappresenta l'applicazione clinica e organizzativa della

Bioinformatica nella Human Health area.

In particolare, la Bioinformatica si occupa di sviluppo e manutenzione di database

(di DNA, di sequenze, di proteine ecc.), di sviluppo di nuovi strumenti computa-

zionali per la predizione delle funzioni di proteine e delle strutture tridimensionali

e della scoperta di nuovi vaccini candidati antigeni coinvolgendo i geni di malattie

genetiche.

1.2 L'obiettivo della tesi

L'obiettivo della tesi è stato quello di realizzare un prototipo a supporto delle ricerche

cliniche e biomediche, basato su di un modello di qualità studiato per la scoperta

di servizi idonei a soddisfare le esigenze di un ipotetico utente. Per de�nire tale

modello ci si è ispirati al matchmaker proposto in [PSNS], e sono state sfruttate

le informazioni che caratterizzano BioMOBY [WGFS03], un repository di servizi

biologici.

La presente tesi ha approfondito l'aspetto di coordinazione un concetto certo non

banale. Durante l'evolversi del lavoro si è sentita questa esigenza perchè parlare di

qualità non preclude il concetto di organizzazione, coordinazione e cooperazione.

Per coordinare risulta fondamentale capire quali sono le parti in gioco, quali ruoli

4

INTRODUZIONE

essi giocano e quali informazioni sono maggiormente discriminanti, solo in questo

modo possiamo speci�care l'importanza e l'e�ettivo valore dei parametri del modello

di qualità.

L'importanza dell'organizzazione è fondamentale anche perchè un ambiente in cui è

presente una buona organizzazione delle parti porta ad una maggiore comprensione

e chiarezza.

In�ne, la coordinazione è alla base di ogni società e tanto più forte sarà in una società

in cui l'informatica mette in ballo le sue potenzialità.

1.3 I principali approcci

Nel panorama internazionale esistono molti strumenti di valutazione delle infor-

mazioni mediche in Internet ma: �nessuno� è valido, molti sono incompleti, di pochi

esistono dati sul loro utilizzo.

Diversi sono i tipi di approcci utilizzati e di seguito ne descriviamo alcuni.

I codici etici o�rono una serie di criteri che i gestori dei siti possono impegnarsi

a rispettare. I costi di approccio di questo tipo sono in genere piuttosto ridotti,

visto che è richiesto solo un investimento iniziale per le riunioni di preparazione del

codice. D'altra parte anche i bene�ci di tali codici possono essere limitati visto che

non esistono meccanismi e�caci di controllo dell'applicazione. Tra questi abbiamo

trovato:

• Ehealth code of ethics/Internet Health Coalition 1;

• Hon code 2.1http://www.ehealthcoalition.org2http://www.hon.ch

5

INTRODUZIONE

Il primo, che è stato adottato nel maggio 2000 dalla Internet Health Coalition, è

forse quello più conosciuto nel suo genere. Il fondamento �loso�co di questo codice

è il principio di rispetto per le persone; cioè l'obbligo etico di trattare ciascun utente

sulla base della propria dignità e morale. Il principio di rispetto richiede che gli indi-

vidui siano trattati come persone che decidono in maniera indipendente e che fanno

scelte basate su propri valori. Il codice sottolinea il fatto che chiunque usi Internet

per motivi correlati con la salute si veda garantiti i seguenti principi informativi:

sincerità, onestà, qualità, privacy, professionalità, responsabilità e aggiornamento.

Il secondo è stato realizzato dalla Health On the Net Foundation (HON), fondata nel

1995, che è un'organizzazione internazionale svizzera senza scopo di lucro, che si oc-

cupa di assistere i profani, i non specialisti e i medici a trovare informazioni mediche

e sanitarie utili e a�dabili sulla Rete. I principali promotori della HON sono lo

Stato di Ginevra, la clinica universitaria di Ginevra, l'Istituto elvetico di bioinfor-

matica e la Sun Microsystems. La HON prevede una serie di otto criteri di qualità

(autorità, complementarietà, riservatezza, attribuzione, giusti�cazione, certezza del-

l'autore, certezza della garanzia e certezza della pubblicità & delle policy) e viene

attualmente utilizzato in più di 3000 siti Internet in tutto il mondo. Un fornitore di

un sito che desideri utilizzare il marchio della HON deve presentare formale richiesta

e impegnarsi a osservare rigidamente tutti i principi contenuti nel codice stesso. I

siti conformi si riconoscono grazie al marchio sotto forma di link �attivo� del codice

HON, che �gura in posizione di primo piano.

Un altro tipo di approccio sono le griglie di valutazione per gli utenti �nali:

• DISCERN 3;

3http://discern.org.uk

6

INTRODUZIONE

• QUICK 4.

Il progetto DISCERN è stato avviato nel 1996-97 dalla British Library e dal pro-

gramma di ricerca e sviluppo esecutivi dell'NHS. Lo strumento DISCERN è un ques-

tionario che può essere utilizzato per valutare l'a�dabilità di una pubblicazione quale

fonte di informazioni sulle scelte terapeutiche. Le domande sono organizzate in tre

sezioni come segue: dalla 1 alla 8 richiamano l'a�dabilità della pubblicazione e aiu-

tano l'utente a valutare se può �darsi della fonte stessa, dalla 9 alla 15 mettono a

fuoco i particolari speci�ci delle informazioni relativamente alle scelte di trattamento

e la 16 riguarda la valutazione di qualità generale dello strumento.

QUICK è inteso come strumento didattico in ambienti come le scuole, le biblioteche,

i centri di documentazione, i doposcuola o i club informatici. Può essere utilizzato

come parte integrante del programma scolastico, nell'ambito delle competenze in-

formatiche e dell'apprendimento dello spirito critico. È sostenuto dalla UK Health

Development Agency e dal UK Centre for Health Information Quality.

Un'altro approccio è quello di realizzare siti web che mettono a disposizione

risorse selezionate sulla base di un insieme di criteri:

• OMNI 5;

• CISMeF 6.

L'OMNI (Organising Medical Networked Information) è un gateway per l'accesso a

risorse Internet di qualità valutata in campo medico e sanitario, destinato a studenti,

ricercatori, accademici e professionisti nel settore delle scienze mediche e sanitarie.4http://www.quick.org.uk5http://www.biome.ac.uk6http://www.cismef.org

7

INTRODUZIONE

Questo gateway è stato creato da un nucleo di specialisti della University of Nottin-

ghasm Green�eld Medical Library, in collaborazione con importanti organizzazioni

in tutto il Regno Unito e oltre. L'OMNI è uno dei gateway del servizio BIOME ed

è �nanziato dal Joint Information Systems Committee attraverso la Resource Disco-

very Network (RDN).

CISMeF è un Gateway tematico di qualità-controllata la cui realizzazione è stata

intrapresa dall'ospedale dell'università de Rouen (RUH). CISMeF è diventato fun-

zionante nel mese di febbraio del 1995. Esso utilizza due tools standard per l'orga-

nizzazione delle informazioni: il lessico bibliogra�co della maglia della base di dati

di Medline e un metadata. Le risorse incluse in CISMeF sono descritte da quanto

segue: titolo, autore o creatore, oggetto e parole chiavi, descrizione, editore, data,

tipo delle risorse, disposizione, contrassegno e lingua.

1.4 La struttura della tesi

La tesi è stata svolta a completamento del lavoro di stage, svolto in collaborazione

con Ercoli Chiara, durante il quale si è sviluppato un componente a supporto del

discovery dei servizi Biomedici.

Per comprendere meglio l'opera si è ritenuto opportuno suddividerla in due

sezioni. La prima è di natura teorica mentre la seconda riguarda l'applicazione

sviluppata durante il periodo di stage.

La prima parte è costituita da due capitoli.

Il primo capitolo riguarda una panoramica sui modelli di coordinazione.

Il secondo capitolo riguarda brokering e matchmaking due modelli di coordinazione

che hanno ispirato il lavoro.

8

INTRODUZIONE

La seconda parte è composta da tre capitoli.

Il terzo capitolo descrive la piattaforma ad agenti JADE che abbiamo utilizzato per

sviluppare il nostro prototipo.

Il quarto capitolo descrive il progetto BioMOBY dal quale abbiamo tratto le infor-

mazioni biomediche.

Il quinto capitolo descrive in modo dettagliato il nostro prototipo che sfrutta le in-

formazioni fornite da BioMoby, una tecnologia ad agenti e il livello semantico che le

ontologie sono capaci di fornire.

Per completezza dell'opera, nelle appendici si è inserito una lista degli acronimi

e dei relativi signi�cati e una breve trattazione sull'AUML.

9

Parte I

PARTE TEORICA

11

Capitolo 2

Modello di coordinazione

Negli ultimi anni i sistemi si sono evoluti in sistemi complessi per cui c'è stata una

crescita d'interesse in merito a come questi possano essere coordinati. Diversi lavori

sono stati prodotti in merito, in alcuni casi, focalizzano sulla coordinazione di sistemi

di elaborazione distribuiti e paralleli, in altri, sulla coordinazione di sistemi umani

ed a volte anche, su compessi sistemi che includono persone e computer.

In questo capitolo usiamo il termine teoria della coordinazione, per riferirci al

modello teorico che riguarda come la coordinazione si realizza in diverse tipologie di

sistemi.

Introduciamo ora un quesito che la teoria della coordinazione può aiutarci a

rispondere:

Come l'uso dell' Information Technology può cambiare il modo di lavorare in-

sieme delle persone?

La domanda che ci siamo posti non è l'unico fulcro possibile in materia, ma è

13

CAPITOLO 2. MODELLO DI COORDINAZIONE

particolarmente opportuna per due ragioni:

1. Negli anni recenti, un numero elevato di persone hanno acquisito accesso diretto

al computer, che spesso è connesso in rete con altri computer, primariamente

per compiti individuali come l'analisi dei fogli di calcolo e l'elaborazione di

un testo, ma anche per interagire con gli altri. Da quanto detto si evince

che un numero elevato di persone può usare il calcolatore e le sue capacità di

comunicazione al �ne di essere aiutati nella coordinazione del proprio lavoro.

2. A lungo termine, il costo e le capacità di Information Technologies cambieranno

e si veri�cheranno vincoli su certi tipi di comunicazione e coordinazione. In

una società in cui le interdipendenze globali stanno divenendo più critiche, e il

ritmo con cui il cambiamento si realizza sta accelerando, si sente la necessità

di creare organizzazioni più �essibili e adattabili che ci conducano presto oltre

una soglia dove modi completamente nuovi di organizzare le attività umane

saranno desiderabili.

Al �ne di realizzare il modello di qualità, ci è sembrato opportuno avere un

quadro completo fondato su consistenti principi teorici di come e perchè gli elementi

del prototipo possono coordinarsi.

L'obiettivo che vorremmo raggiungere con questo capitolo è quello di fornire al

lettore una panoramica piuttosto completa sul concetto di coordinazione, di agente

e sui modelli di coordinazione per applicazioni Internet basate su agenti mobili.

Nei successivi paragra� daremo una de�nizione del termine coordinazione, de-

scriveremo brevemente i processi coinvolti nella coordinazione e le loro dipendenze e

forniremo un esempio di coordinazione in Biologia. Sarà poi introdotto il concetto di

agente per poi descrivere i modelli di coordinazione di applicazioni basate su di essi

14


(Direct, Meeting-oriented, Blackboard-based e Linda-like). Per concludere forniremo

con una panoramica su Linda e TuCSoN.

2.1 Cosa si intende per coordinazione

Noi tutti abbiamo un'intuizione del signi�cato della parola �coordinazione�. Quando

partecipiamo ad una conferenza ben organizzata, quando vediamo una squadra di

calcio vincente o quando vediamo che una riunione funziona agevolmente, noi possia-

mo notare quanto bene le azioni di un gruppo di persone possono essere coordinate.

Tuttavia, una buona coordinazione è quasi invisibile, ed è più facile notare se essa è

mancante. Ad esempio, quando passiamo ore aspettando in una sala d'attesa di un

aeroporto perché la linea aerea non può trovare una pista per il nostro aereo, quando

l'hotel dove noi pensavamo di aver riservato una stanza è pieno, o quando il nostro

programma di elaborazione di testi non funziona in una versione nuova del sistema

operativo, è facile divenire consapevoli dell'e�etto di un modello di coordinazione

poco sviluppato.

Per molti scopi, questo signi�cato intuitivo è su�ciente. Comunque, nel provare

a caratterizzare un'area interdisciplinare nuova, è utile farsi un'idea precisa di ciò

che si intende con il termine �coordinazione� e quindi di seguito riporto una lista di

de�nizioni date a questo termine.

The operation of complex systems made up of components [Fou91].

L'autore di questa de�nizione voleva sottolineare il ruolo dei sistemi complessi e la

loro composizione.

2.1 Cosa si intende per coordinazione 15


The emergent behavior of collections of individuals whose actions are based on

complex decision processes [Fou91].

In questa de�nizione si sottolinea il ruolo dei comportamenti degli individui che ra-

gionano e in base alla loro conoscenza prendono delle decisioni.

Information processing within a system of communicating entities with distinct

information states [Fou89].

Questa de�nizione si di�erenzia dalle precendenti perchè si introduce il concetto di

processare le informativi all'interno di sistemi di comunicazioni in cui le entità che

vi appartengono giocano di�erenti ruoli in quanto sono in possesso di di�erenti in-

formazioni.

The joint e�orts of independent communicating actors towards mutually de�ned

goals [Fou91].

L'autore in questo caso vuole sottolineare il fatto che le parti cooperano per raggiun-

gere un obiettivo comune.

Networks of human action and commitments that are enabled by computer and

communications technologies [Fou91].

Come abbiamo detto l'Information Technology gioca un ruolo fondamentale per lo

sviluppo della coordinazione del lavoro delle persone.

Activities required to maintain consistency within a work product or to manage

dependencies within the work�ow [Cur89].

L'autore evidenzia l'importanza di mettere in sequenza le attività generando un'or-

16 2.1 Cosa si intende per coordinazione


ganizzazione complessa.

The integration and harmonious adjustment of individual work e�orts towards

the accomplishment of a larger goal [Sin92]

L'autore sottolinea il ruolo dell'integrazione di lavori individuali.

The additional information processing performed when multiple, connected actors

pursue goals that a single actor pursuing the same goals would not perform [Mal88]

Si sottolinea in questo caso che lavorare permette di raggiungere obiettivi che nel

caso possero perseguiti da un singolo non potrebbero essere raggiunti.

The act of working together [MC88a]

Il [MC88a] a�erma che gli attori lavorano, cooperano, recitano insieme.

La diversità di queste de�nizione illustra sia la di�coltà di de�nire il termine �co-

ordinazione� che la varietà di possibili punti di partenza per studiare questo concetto.

Ritengo che per i nostri scopi sia preferibile prendere in considerazione, almeno ini-

zialmente, la seguente de�nizione sicuramente di più semplice comprensione rispetto

alle altre:

La coordinazione è la gestione delle dipendenze tra le attività. [MC94]

Essa è consistente sia con l'intuizione che, se non ci sono interdipendenze, non

c'è nulla da coordinare, sia con la storia della teoria dell'organizzazione che enfatizza

sull'importanza dell'interdipendenza.



Come ci suggerisce [MC94], crediamo sia utile usare la parola �coordinazione� in

un senso abbastanza inclusivo. Per esempio, è chiaro che attori che compiono attività

interdipendenti possono avere con�itti d'interesse che devono essere in grado di ge-

stirle. Similmente, anche se parole come cooperazione, collaborazione e competizione

hanno una propria connotazione, una parte importante di ciascuna di esse coinvolge

la gestione delle dipendenze tra le atività. 1

A questo punto dovrebbe essere chiaro che la coordinazione può essere alla base

di diverse tipologie di sistemi come quelli umani, computazionali e biologici tra loro

molto simili anche se di natura diversa.

Descriviamo ora i processi di coordinazione di base e forniamo alcuni esempi di

coordinazione tratti dal dominio biologico.

2.1.1 Processi di coordinazione di base

Un primo veicolo per facilitare il transferimento dei modelli di coordinazione tra

di�erenti discipline mensionate nel paragrafo precedente è identi�care e studiare i

processi base coinvolti nella coordinazione. Per far ciò è opportuno porsi diversi in-

terrogativi, come quelli di seguito riportati .

Ci sono fondamentali processi di coordinazione che si realizzano in tutti i sistemi

coordinati? Se sì, come si possono rappresentare e analizzare? E' possibile caratte-

1Questi termini hanno naturalmente un più largo signi�cato. Per esempio, cooperazione di solito

implica obbiettivi comuni tra di�erenti attori, competizione implica che i guadagni di un'attore sono

le perdite di un'altro, e collaborazione spesso connota che le parti lavorano insieme applicando uno

sforzo intellettuale comune. Comunque, qualche volta è utile considerare tutti questi termini come

descrizione di di�erenti approcci per gestire dipendenze tra attività che sono forme di�erenti di

coordinazione.



rizzare situazioni in un modo che aiuti a generare e a scegliere appropriati meccanismi

di coordinazione per questi processi?

Uno dei vantaggi della de�nizione tratta da [MC94] è che ci aiuta a dare una

risposta a questi quesiti in quanto se la coordinazione è de�nita come la gestione

delle dipendenze, allora i vari progressi dovrebbero essere caratterizzati da generi

diversi di esse. La Tabella 2.1 tratta da [MC88a] mostra come ogni dipendenza è

gestita da diversi processi di coordinazione.

DIPENDENZE ESEMPI DI PROCESSI DI COORDINAZIONE

PER GESTIRE LE DIPENDENZE

Condivisione delle risorse FIFO, ordine di priorità, decisioni manageriali

Assegnazione dei compiti (come condivisione delle risorse)

Vincoli di prerequisiti noti�cazione, ordinamento in sequenza, localizzazione

Trasferimento just in time, economic order quantity

Task/ subtask selezione dell'obiettivo, decomposizione dei compiti

Tabella 2.1: Di�erenti processi di coordinazione per gestire le dipendenze

Per esempio, nel caso in cui si debba accedere allo stesso insieme limitato di

risorse si possono applicare diversi processi di coordinazione (FIFO, ordine di priorità,

decisioni manageriali).

Volendo introdurre un esempio pratico, se tre commessi di un negozio hanno bisogno

di usare la stessa macchina, essi potrebbero usare un semplice meccanismo First

In First Out. Alternativamente, essi potrebbero negoziare l'automobile in base alla

priorità dei compiti che vanno a svolgere o in base a quanto il lavoratore è disposto

a pagare per utilizzarla.



La lista di dipendenze e processi di coordinazione mostrati nella Tabella 2.1 non

sono certo esaustivi, ma è importante notare che alcuni processi speci�ci che sorgono

in particolari tipi di sistemi possono essere visti come un'istanza di un processo

generico. Infatti, nel [MC94] si a�erma che una delle più intriganti possibilità per la

teoria di coordinazione è identi�care e sistematicamente analizzare una larga varità

di dipendenze e di processi di coordinazione associati.

Passiamo ora ad analizzare come la coordinazione si realizza in un campo tanto

complesso come quello biologico.

2.1.2 Modelli e metafore in Biologia

La gran parte degli studi biologici riguarda come gli esseri viventi interagiscono tra

loro. Per esempio, la �siologia umana può essere vista come uno studio delle attività

di di�erenti parti del corpo che sono coordinate al �ne di tenere una persona in vita.

Altre parti della biologia coinvolgono lo studio di come esseri viventi di�erenti in-

teragiscono con gli altri. Per esempio, l'ecologia può essere vista come lo studio

dell'attività di coordinazione di piante ed animali di�erenti per mantenere in vita

l'ambiente.

Alcuni dei più interessanti studi sulla coordinazione biologica coinvolge di�erenti

animali in un gruppo. Per esempio, [MC88b] discute sulla taglia ottimale della preda

di caccia di un leone, che trae bene�cio nel catturare qualcosa che comunque dovrà

condividere con gli altri.

Altri esempi impressionanti del comportamento di un gruppo possono essere

trovati nelle società di insetti, come api e formiche. Il loro comportamento è estre-

mamente complesso, nonostante la semplicità degli individui. Usando una varietà

di semplici regole, questi insetti assegnano a lavoratori indipendenti una varietà di



compiti al �ne di ottenere un risultato che raggiunga livelli economicamente e�cienti.

Tra queste attività è possibile individuare la ricerca di nuove sorgenti di cibo utiliz-

zando la via più breve e agevole per tornare a casa così da svolgere il loro compito

nel modo più veloce.

Ecosistema delle api

Nel mondo delle api, l'interazione di due semplici regole, di seguito riportate, con-

trolla l'allocazione globale delle api alle varie sorgenti di cibo.

La prima regola a�erma che il nettare scaricato dalle api nell'alveare al loro ritorno

è proporzionale alla ricchezza del nettare. La seconda regola a�erma che, se le api

scaricano velocemente, allora recluteranno altre api per la loro sorgente di cibo. Met-

tendo insieme queste due regole otteniamo che più api collezionano cibo attingendo

alla sorgente migliore.

Ecosistema delle formiche

Uno dei più a�ascinanti fenomeni di organizzazione osservabili in natura è una colonia

di formiche: sono dappertutto, se c'è un panino incustodito lo trovano in poco tempo,

in ancora meno tempo lo hanno ricoperto e a �ne pic-nic non ce n'è più traccia.

Per quanto piccole siano, le formiche trovano sempre la via più breve e più agevole

per tornare a casa (anche senza un corso di Ricerca Operativa sanno bene cos'è

la soluzione di costo minimo). L'algoritmo che formalizza il comportamento delle

formiche prende il nome di ANT COLONY OPTIMIZATION (ACO) [DGMS02] ed

è stato introdotto nel 1992 da Marco Dorigo del Politecnico di Milano.

L'euristica ACO è applicata a problemi di ottimizzazione discreta. Per descrivere

brevemente questa società organizzata bisogna prima di tutto de�nire l'ambiente in



cui le formiche operano: esse si muovono su un grafo con un numero �nito di nodi.

Per capire dove le formiche si trovano in un dato istante useremo il concetto di

stato, mentre per valutare globalmente cosa fanno de�niremo cos'è una soluzione

ammissibile.

Intuitivamente il funzionamento della colonia si può descrivere nel seguente modo:

le formiche esplorano un grafo muovendosi asincronamente. La scelta del percorso

viene fatta in base ai risultati di un processo stocastico, che è de�nito tramite infor-

mazioni locali ad ogni nodo contenute nella tabella di routing delle formiche. Pur es-

sendo le formiche su�cientemente complesse da trovare singolarmente una soluzione,

si ottiene una buona soluzione solo grazie ai risultati collettivi di tutte le formiche.

Ogni formica fa uso solo di informazioni private (la sua memoria) e di informazioni

locali (ant routine table). Per comunicare fra di loro, le formiche leggono e scrivono

scie di feromoni. Quando una formica trova una soluzione, la valuta e deposita la

sua valutazione nella scia sul percorso che ha seguito. Questa valutazione verrà poi

ripresa dalle formiche.

L'euristica prevede inoltre due fenomeni interferenti esterni: l'evaporazione delle

scie e l'azione dei folletti. La prima va sempre implementata nell'algoritmo, viceversa

la seconda è usata solo in categorie speci�che di problemi.

L'evaporazione delle scie è un processo che fa decrescere l'intensità delle scie con il

passare del tempo. Questa interferenza permette di evitare che l'algoritmo converga

troppo rapidamente verso una ragione sub-ottima e favorisce l'esplorazione di nuove

regioni.

L'azione dei folletti è un processo che permette di implementare algoritmi di

ottimizzazione locale all'interno dell'algoritmo ACO. I folletti agiscono depositando

o rimuovendo feromoni in maniera da condizionare la ricerca delle formiche.



Una volta compreso il concetto di coordinazione riteniamo ora opportuno in-

trodurre il concetto di agenti, che se vogliamo fare un parallelismo con gli esempi

biologici appena presentati rappresentano per un certo verso le formiche del sistema

che abbiamo sviluppato.

2.2 Agenti

Il concetto d'intelligenza arti�ciale, ovvero l'idea di riprodurre il comportamento

umano all'interno di entità software, interessa da molti anni un grande numero di

ricercatori. Gli studi a�rontati hanno permesso l'evoluzione del concetto di agenti.

Quando si parla di agenti, la prima cosa da chiarire è che non esiste una de�nizione

univoca ed accettata universalmente ed il problema di de�nire precisamente che �cos'è

un agente� è un tema caldo di discussione che ha provocato non poche controversie.

Comunque, senza dilungarci nell'elencare tutte le de�nizioni presenti in letteratu-

ra, possiamo sfruttare la de�nizione data nel [WJ95b] che de�nisce un agente come

un sistema hardware o software che soddisfa le seguenti proprietà:

autonomia: un agente lavora senza il continuo intervento umano ed ha il controllo

sul suo stato interno e sulle sue azioni;

abilità di comunicazione: un agente comunica con altri agenti tramite un certo

modello di comunicazione;

reazione: un agente percepisce l'ambiente in cui è immerso e risponde ad eventi che

avvengono in esso;

iniziativa: un agente non risponde solo all'ambiente ma è capace di prendere delle

iniziative.

2.2 Agenti 23


Strettamente correlato alla teoria degli agenti è il concetto di Multi agent system,

descritto nel paragrafo 2.2.2. Tale sistema è considerati un approccio interessante

per costruire sistemi distribuiti intelligenti. L'interesse notevole in questo campo è

motivato dai vantaggi che in genere comporta l'adozione della tecnologia ad agenti:

tra le principali ricordiamo la fault tolerance, la �essibilità e l'alto parallelismo.

Nei successivi sottoparagra� saranno presentate prima le principali tipologie di

agenti per poi dare una breve descrizione dei Multi Agent System.

2.2.1 Tipologie di Agenti

Un documento interessante per comprendere lo stato dell'arte per quanto riguarda le

ricerche nel campo degli agenti è [H.S96]. Esso de�nisce diverse tipologie di agenti e

analizza nel dettaglio ipotesi, motivazioni, obiettivi e problemi che li caratterizzano.

Le sette tipologie esaminate in [H.S96] sono le seguenti:

Agenti collaborativi (collaborative agents): sono agenti autonomi che han-

no la capacità di cooperare con altri agenti e possono possedere capacità di

apprendimento oppure no.

Agenti d'interfaccia (Interface agents): agenti che hanno il compito di gestire

il dialogo con l'utente. Sono autonomi ed hanno capacità di apprendimento,

ma in genere non comunicano con altri agenti. Spesso sono chiamati personal

assistants.

Agenti mobili (Mobile agents): agenti in grado di spostarsi (migrare) da un

computer all'altro (attraverso una rete) durante la loro stessa esecuzione. Gli

agenti mobili costituiscono un argomento di ricerca interessante, ma che rap-

presenta una percentuale piuttosto bassa sull'intera comunità di agenti.

24 2.2 Agenti


Information/Internet agents: agenti per la gestione di informazioni provenienti

da varie fonti, che possono essere numerose ed eterogenee, spesso prelevate da

Internet interagendo con motori di ricerca.

Agenti reattivi (Reactive agents): agenti dotati soltanto di reattività e non di

proattività. Non possiedono una rappresentazione interna simbolica dell'am-

biente esterno, ma agiscono solo secondo il principio richiesta-risposta.

Agenti ibridi (Hybrid agents): agenti che combinano due o più delle tipologie

sopra indicate.

Agenti intelligenti (Smart agents): agenti dotati di autonomia, capacità di col-

laborazione e di apprendimento.

La de�nizione precisa del termine intelligente dipende dal contesto in cui ci si

trova ad operare: solitamente indica che l'agente persegue i propri obiettivi ed

esegue i propri compiti in modo da ottimizzare una data misura di prestazione.

Il fatto che gli agenti siano intelligenti non signi�ca che essi non commettono

errori, indica piuttosto che operano in maniera �essibile e razionale in un certo

numero di circostanze ambientali, date le informazioni possedute ed una cer-

ta capacità percettiva ed attuativa [WJ95a] (è ovvio che non esistono agenti

intelligenti in assoluto).

Tutti questi di�erenti tipi di agenti, inoltre, dovrebbero essere capaci in qualche

modo di (i) comunicare (interagire) con gli altri allo scopo di scambiarsi informazioni

e (ii) collaborare con gli altri agenti.

In particolare, un agente dovrebbe essere capace di realizzare quanto possibile com-

plesse comunicazioni con altri agenti per scambiare informazioni o chiedere il loro

aiuto nell'interpretazione di un obiettivo. Questo conduce naturalmente alla nozione

2.2 Agenti 25


di un numero di agenti cooperativi con gli altri al �ne di completare un obiettivo

comune. La necessità di comunicare e cooperare conduce alla necessità di coordinare

le attività degli agenti in ordine di sempli�care il processo di costruzione di un Multi

agent system, e fornire l'abilità di riusare la descrizione dei meccanismi e dei modelli

di coordinazione.

2.2.2 Multi agent system (MAS)

Possiamo dire che un Multi agent system (MAS) è una comunità sociale di membri

interdipendenti che agiscono individualmente ma una de�nizione più precisa è data

da [WN99] e riportata quì di seguito.

�Un MAS è un sistema in cui alcuni agenti intelligenti interagiscono per sod-

disfare un certo insieme di obiettivi, allo scopo di portare a termine un insieme di

compiti.�

Gli agenti esistono ed operano in qualche ambiente che tipicamente è tanto com-

putazionale quanto �sico. Tale ambiente può essere aperto o chiuso e può contenere

altri agenti. Anche se in certe situazioni essi possono operare singolarmente, (gene-

ralmente interagiscono con gli altri è quindi più conveniente trattarli collettivamente,

cioè come società di agenti.

L'infrastruttura computazionale per l'interazione fra gli agenti fornito dall'am-

biente; comprende i protocolli per la comunicazione e per l'interazione. I primi per-

mettono agli agenti di scambiare e comprendere messaggi, mentre gli altri rendono

gli agenti in grado di avere conversazioni strutturate.

In�ne, le caratteristiche principali di un MAS sono le seguenti: forniscono una

infrastruttura che speci�ca i protocolli di comunicazione e interazione, sono aperti,

contengono agenti autonomi che possono perseguire i propri interessi oppure essere

26 2.2 Agenti


cooperativi, ciascun agente ha informazioni e capacità limitate, il sistema di controllo

è distribuito, i dati sono decentralizzati, la computazione è asincrona.

2.3 Modelli di coordinazione per applicazioni basate su

agenti

Vogliamo ora discutere sui modelli di cordinazioni per applicazioni basate su agenti.

Per analizzare l'impatto che essi hanno sulle applicazioni, ci riferiamo a quanto detto

nel [CLZ] che propone una nuova tassonomia costruita su due caratteristiche che sono

di particolare importanza quando si parla di agenti. Queste caratteristiche sono il

grado di accoppiamento spaziale (spatial coupling) e temporale (temporal coupling)

introdotti da un modello di coordinazione. In particolare:

• si ha accoppiamento spaziale se per comunicare, le entità coinvolte nella coor-

dinazione devono necessariamente conoscere la reciproca collocazione, al con-

trario, modelli spazialmente non accoppiati ra�orzano interazioni anonime;

• si ha accoppiamento temporale se le comunicazioni sono sincrone, ossia se

mittente e rivevitore esistono al momento della comunicazione, al contrario,

modelli temporalmente non accoppiati realizzano interazioni asincrone.

Dalla combinazione delle caratteristiche appena mensionate possono derivare

quattro principali categorie di modelli di coordinazione, come mostrato in Figura

2.1 : Direct, Meeting-oriented, Blackboard-based e Linda-like che tratteremo nei

successivi sottoparagra�.

2.3 Modelli di coordinazione per applicazioni basate su agenti 27


Figura 2.1: Modelli di coordinazione per applicazioni ad agenti

2.3.1 Coordinazione Diretta

Nel modello di coordinazione diretta, gli agenti iniziano a comunicare chiamando

esplicitamente le parti coinvolte con il loro nome (accoppiamento spaziale). Nel caso

della coordinazione reciproca tra agenti, due agenti sono d'accordo sul protocollo di

comunicazione da usare, tipicamente peer-to-pear. L'accesso alle risorse locali gene-

ralmente usa una coordinazione client-server, dove le risorse sono o�erte da diversi

server locali appartenenti allo stesso dominio. In�ne, la coordinazione diretta implica

solitamente la sincronizzazione delle entità coinvolte (accoppiamento temporale).

La maggior parte dei sistemi ad agenti basati su Java come Aglets [LO98] adot-

tano modelli di coordinazione diretta. Ad alto livello, essi possono sfruttare il modello

di coordinazione client e server, tipico del paradigma object-oriented, anche tra agenti

remoti attraverso Java RMI [SFKH03]. A basso livello, essi possono sfruttare diret-

tamente TCP/IP il quale è estremamente �essibile, ma richiede la precisa de�nizione

di un protocollo di scambio di messaggi

28 2.3 Modelli di coordinazione per applicazioni basate su agenti


Nell'applicazioni Internet adottare il modello di coordinazione diretto non è con-

sigliabile dato che, se due agenti comunicano direttamete su larga scala, essi neces-

sitano di essere localizzati per motivi legati ai protocolli di routing. Inoltre, connes-

sioni ripetute richiedono una stabile connessione di rete dato che la comunicazione

dipende dall'a�dabilità della rete e che carichi eccessivi possono provocare il falli-

mento della consegna o un ritardo non prevedibile. In�ne, la maggior parte delle

applicazioni basate su agenti sono intrinsecamente dinamiche, perchè gli agenti sono

creati dinamicamente. E' quindi di�cile adottare un modello accoppiato spazial-

mente che richiede l'identi�cazione dei partner coinvolti nella comunicazione, come

quello diretto.

La coordinazione diretta è supportata da sistemi middleware [TS03], come COR-

BA e DCOM [Sho02], per risolvere problemi relativi alla locazione degli agenti e al

naming. Comunque, i sistemi middleware sono per la maggior parte orientati per

permettere l'interoperabilità tra componenti software eterogenei piuttosto che per

de�nire un ambiente di computazione distribuito globalmente che ancora conta su

comunicazioni dirette (RPCbased) per i loro servizi.

Perciò, i sistemi middleware mentre facilitano l'uso dello sviluppo di componenti

indipendenti, provocano problemi di latenza e di a�dabilità.

In presenza di agenti, modelli di coordinazione diretta possono essere e�ettiva-

mente sfruttati solo per interazioni in ambienti locali.

2.3.2 Coordinazione Meeting-Oriented

Il modello di coordinazione Meeting-Oriented [PS97] ha lo scopo di de�nire modelli

disaccoppiati spazialmente, dove gli agenti possono interagire nel contesto dell'incon-

tro senza necessità di speci�care il nome dei partner coinvolti. In questo contesto



l'agente prima si lega, esplicitamente o implicitamente a punti d'incontro noti, poì

può sicronizzarsi e comunicare con gli altri agenti che partecipano a meeting. Il fatto

che ci siano punti di riunione aperti non implica che un agente non ne possa creare

di nuovi nel momento in cui ne senta la necessità anche se spesso essi sono costret-

ti localmente. Infatti, per evitare problemi legati alla comunicazione remota, come

ritardi ed ina�dabilità, un incontro si realizza in un dato ambiente di esecuzione e

solo gli agenti che vi appartengono possono parteciparvi.

Il sistema di agenti mobili Ara implementa un tipico esempio di coordinazione

Meeting-Oriented. Come pure il concetto di comunicazione e sincronizzazione basata

su eventi de�nito dall'OMG, e implementato nel sistema ad agenti mobili MOLE

[BHR97], può essere considerato una so�sticata forma di coordinazione Meeting-

Oriented.

Speci�catamente l'oggetto sincronizzato, al quale l'agente condivide la referenza,

assume il ruolo di punto d'incontro e il veri�carsi dell'evento di accesso ad uno degli

oggetti di sincronizzazione implica che gli agenti devono convogliare implicitamente

alla riunione.

Il modello di coordinazione Meeting-Oriented risolve parzialmente il problema

di identi�care esattamente il partner coinvolto, in quanto essi non possono realiz-

zare una completa scissione spaziale, ma devono condividere la conoscenza del nome

del luogo d'incontro. Lo svantaggio maggiore, comunque, consiste nell'usuale raf-

forzamento della sincronizzazione tra agenti che interagiscono tra loro e �nchè lo

scheduling e la posizione dell'agente non può essere predicibile, il rischio di perdere

l'interazione è molto alto.

In aggiunta, se il punto di incontro non è localmente vincolato, gli agenti devono es-

sere perfezionati dal passaggio di messaggi, così che da ereditare problemi di e�cienza

30 2.3 Modelli di coordinazione per applicazioni basate su agenti


e d'a�dabilità del modello di coordinazione diretta.

La soluzione Meeting-Oriented produce meno tra�co di rete della coordinazione

diretta ed in più è pienamente distribuita, nonostante cio, la soluzione costringe un

agente a rimanere su di ogni luogo visitato per lungo tempo, provocando diversi

inconvenienti tra i quali quello provocato da un agente maligno che può sfruttare il

tempo trascorso in un determinato luogo per spedire informazioni private all'esterno.

2.3.3 Coordinazione Blackboard-based

Nel modello di coordinazione Blackboard-based (basato su lavagna condivisa), gli

agenti interagiscono attraverso spazi di dati condivisi, usando un repository comune

per memorizzare e recuperare i dati. In questo senso, le interazioni sono temporal-

mente divise ma, siccome gli agenti per comunicare e scambiarsi i dati attraverso la

lavagna devono essere d'accordo su di un comune identi�catore del messaggio, essi

sono spazialmente accoppiati. Per ciascun insieme di risorse omogenee può essere

assegnata una lavagna locale al �ne di superare problemi di scalabilità, in quanto

la presenza di un'unica lavagna in cui coivogliano tutte le informazioni degli agenti,

crerebbero confusione e sarebbe estremamente pesanti per il sistema.

Molti sistemi propongono e implementano un modello di coordinazione Blackboard-

based per applicazioni ad agenti. In Ambit [CG98], gli agenti possono attaccare un

messaggio �rmati ad una lavagna in un dato luogo e un altro agente può recuperare

e leggere questo messaggio nel momento in cui arriva nello stesso luogo.

Come già abbiamo detto la coordinazione Blackboard-based realizza un scissione

temporale in quanto il messaggio può essere appeso dalla lavagna e non ci sono

problemi riguardanti dove sono i mittenti o quando leggeranno la comunicazione.

Questo suggerisce uno scenario mobile dove la posizione e lo scheduling degli agenti



non può essere facilmente monitorato. In aggiunta, siccome tutte le interazioni tra

agenti sono costrette per essere compiute attraverso la lavagna, l'ambiente host può

essere facilmente monitorato e controllato realizzando un modello di esecuzione più

sicuro.

2.3.4 Coordinazione Linda-like

Il modello di coordinazione Linda-like usa uno spazio di tuple o tuple space (TS)

locale come contenitore di messaggi. Uno spazio di tuple è simile ad una lavagna, in

cui gli accessi sono basati su meccanismi associativi [GC92]. L'informazione è orga-

nizzata in tuple e recuperata utilizzando un meccanismo pattern-matching. Questo

modello non realizza né l'accoppiamento spaziale né tantomeno quello tempoorale.

Il concetto di una lavagna associativa è adottato nella'architettura di coordina-

zione per applicazioni Web interattive chiamate PageSpace [CKR+98]. In cui una

molteplicità di spazi di tuple distribuiti basati su oggetti possono essere usati sia da

agenti mobili che da agenti �ssi per memorizzare e recuperare referenze ad oggetti.

Altri sistemi come TuCSON [OZ99a] e MARS [CLZ00], adottano un modello di

coordinazione Linda-like de�nendo ulteriormente la reattività dello spazio di tuple

come descritto nel paragrafo 2.5.

Passiamo ora, dopo aver fatto una panoramica sui possibili modelli di coordina-

zione ad analizzarne alcuni come Linda e TuCSoN.

2.4 Linda

Linda è stato proposto all'inizio del 1990 [Gel85] come nuovo linguaggio di program-

mazione distribuito tra processi concorrenti, fondato su un meccanismo di comuni-

32 2.4 Linda


cazione asincrona ed associativa, basato su un ambiente globale e condiviso dalle

varie applicazione, chiamato spazio di tuple.

Uno spazio di tuple è una collezione o un insieme di tuple. Una tupla a sua volta

è una sequenza di campi attuali (espressioni, variabili costanti o variabili istanziate),

e campi formali (variabili non istanziate).

Per individuare una tupla all'interno di uno spazio di tuple viene utilizzato un

meccanismo di pattern matching in cui le tuple soddisfano il matching se:

1. hanno lo stesso numero di campi;

2. i campi contengono valori o variabili che soddisfano il matching, in particolare:

• due campi attuali soddisfano il matching se sono identici;

• un campo formale soddisfa il matching con qualsiasi campo dello stesso

tipo.

I maggiori bene�ci portati da questo modello sono la separazione tra computazione

e coordinazione [GC92] e l'accesso associato allo spazio di interazione. Il tutto per-

mette la scrittura di architetture ad agenti chiare, separando per bene quello che è

la computazione dalla coordinazione.

Linda de�nisce oltre a questo ambiente di esecuzione anche delle semplici primi-

tive per manipolare le tuple, tra cui due operazioni non bloccanti out(t) e eval(t)

per aggiungere delle tuple ad uno spazio di tuple e due operazioni bloccanti in(t) e

read(t) per accedere alle tuple di uno spazio di tuple.

In particolare:

out(t) aggiunge la tupla, ottenuta valutando t, allo spazio di tuple.

2.4 Linda 33


eval(t) di�erisce da out(t) in quanto la tupla viene prima aggiunta allo spazio delle

tuple, ed un nuovo processo concorrente viene mandato in esecuzione per va-

lutare la tupla; questa non sarà disponibile per e�ettuare il matching, �no a

quando la valutazione non sarà completata.

in(t) valuta t e cerca nello spazio di tuple una tupla t' che soddis� il matching con

t; se t' viene trovata, viene tolta dallo spazio di tuple ed i valori di t' sono

assegnati ai corrispettivi campi formali di t. Se non viene trovata una tale

tupla, l'operazione è sospesa �nchè non ce ne sarà una disponibile.

read(t) di�erisce da in(t) semplicemente per il fatto che la tupla selezionata t' non

viene tolta dallo spazio di tuple.

In queste operazione è inerente il non determinismo, in quanto quando le opera-

zioni di in e di read sono sospese in attesa di una stessa tupla, e quando quest'ultima

diviene disponibile, solo una delle operazioni sospese potrà proseguire nell'esecuzione.

Allo stesso modo se per una stessa operazione di in o di read esiste più di una tupla

che soddisfa il matching, allora ne viene scelta una a caso.

Il modello di comunicazione asincrono di Linda, permette di controllare esplicita-

mente le interazioni fra i processi tramite dati condivisi e di usare le stesse primitive

sia per manipolare i dati che per sincronizzare i processi rendendo esplicite tutte le

interazioni di un programma col suo ambiente.

Si tratta quindi di un modello InterProcess Communication basato su di una

memoria condivisa (in questo caso lo spazio di tuple): in particolare se un processo

P vuole mandare un messaggio al processo Q, come mostrato in Figura 2.2, dovrà

mettere tale messaggio nello spazio delle tuple di Q, tramite ad esempio un'operazione

34 2.4 Linda


out(message). Ovviamente, Q dovrà essere in ascolto di messaggi tramite ad esempio

un'operazione in(message).

Figura 2.2: Scambio di messaggi tra processi

Concludendo, Linda si dimostra adeguato per scrivere applicazioni concorrenti,

ma non altrettanto adatto per scrivere applicazioni distribuite. Infatti, la protezione

dei dati (privacy) e la sicurezza, che sono fondamentali per le applicazioni mobili,

non sono a�atto garantite da Linda.

Fondamentalmente il problema è dovuto al fatto che tutte le tuple sono contenute in

un unico spazio di tuple. Da questo punto di vista avere spazi delle tuple multipli

può aiutare a raggiungere alcuni obiettivi, ma senz'altro non permette la gestione

esplicita delle località. Inoltre, Linda con le sue primitive, non supporta la mobilità

di codice, che invece è fondamentale per le applicazioni distribuite e quindi non può

essere de�nito come un Mobile Code Language.

2.4 Linda 35


2.5 Aggiungere reattività al modello di coordinazione

I modelli di cordinazioni per applicazioni basate su agenti descritti nel paragrafo 2.3

possono essere arrichiti con la reattività, che è la capacità di reagire a determinati

eventi nel mondo esterno, dalla quale scaturisce la capacità di incarnare capacità

computazionali all'interno del mezzo di coordinazione per lasciare problemi speci�ci

di reazione programmabile che possono in�uenzare il comportamento dell'interazione

degli agenti.

Di�erenti proposte in di�erenti contesti puntano all'integrazione del grado di

reattività nel modello di coordinazione. Nell'area delle reti e dei messaggi attivi

[TSS+97], la possibiltà per i messaggi di incarnare il codice necessario per gestirli

può essere in qualche modo categorizzato come uno sforzo verso modelli di coordina-

zione dinamici e direttamente programmabili. Nel modello di coordinazione Meeting-

Oriented [BHR97], l'oggetto sincronizzato può incarnare speci�che politiche per in-

�uenzare l'interazione tra gli agenti coinvolti nell'incontro. Per esempio, l'ogget-

to sincronizzato può essere programmato per noti�care asincronamente un evento

all'agente, realizzando così una parziale forma di scissione temporale.

In un modello tuple space reattivo, lo spazio di tuple non è più un semplice

repository di tuple in cui trovare un meccanismo associativo anonimo. Invece, uno

spazio di tuple può avere un proprio stato e può reagire con azioni speci�che agli

accessi compiuti da agenti mobili. La reazione può accedere allo spazio di tuple,

cambiando il loro contenuto ed in�uenzando la semantica dell'accesso degli agenti.

In questo contesto, il modello TuCSoN, che sarà analizzato nel successivo para-

grafo, de�nisce uno spazio di tuple logico e programmabile per la coordinazione della

conoscenza di agenti mobili. Le reazioni sono programmabili come tuple del primo

36 2.5 Aggiungere reattività al modello di coordinazione


ordine logico.

La reattività dello spazio di tuple può fornire molti vantaggi in un'applicazione

ad agenti mobili. Essa può essere usata per implementare speci�che politiche locali

per l'interazione tra gli agenti e l'ambiente di host, per realizzare il miglior controllo

e de�nire l'integrità dell'ambiente da agenti maligni. Più in generale, la capacità

di adattamento del comportamento di uno spazio di tuple ad uno speci�co accesso

aggiunge intelligenza distribuita all'intero sistema. Come intelligenza e comporta-

mento adattabile sono riconosciute estesamente come caratteristiche fondamentali

per gli agenti, il [CLZ] a�erma che le stesse proprietà possono arricchire i modelli di

coordinazione.

2.6 Tucson

Una volta introdotto il concetto di reattività passiamo ad annalizzare TuCSoN (Tuple

Centre Spread over Network) che è un modello e un'infrastruttura per la coordina-

zione degli agenti mobili Internet che sfrutta la nozione di spazio di interazione locale

basato su tupla (tuple centre).

Considerando l'apertura e la vastità di Internet, possiamo pensare a tale scenario

come una molteplicità di ambienti indipendenti e progettare le applicazioni in termini

di agenti che accedono in modo esplicito alle risorse della rete. Il supporto di TuCSoN

per tale approccio alla progettazione dell'applicazione è basato su una molteplicità

di spazi di interazione indipendenti, chiamati tuple centre. Un tuple centre è come lo

spazio di tuple di Linda, arricchito della capacità di de�nire il suo comportamento

in risposta agli eventi di comunicazione, in accordo con le speci�che necessità di

coordinazione.

2.6 Tucson 37


Nei successivi sottoparagra� saranno brevemente descritti il modello di coordi-

nazione di TuCSoN, il tuple centre e le reazioni di TuCSoN.

2.6.1 Il modello di coordinazione TuCSoN

Il modello di coordinazione di TuCSoN [OZ99a] è mirato a supportare la proget-

tazione e lo sviluppo di applicazioni orientate all'informazione basate su agenti mo-

bili. L'approccio è fondamentalmente orientato ai dati, e sfrutta una particolare

nozione di spazio di dati condiviso di tipo Linda. Per far fronte alla mobilità, un nodo

di una rete, che vuole ospitare agenti mobili, deve de�nire il suo proprio spazio locale

di comunicazione, che viene poi utilizzato dagli agenti per interagire tra loro. Ogni

spazio d'interazione locale consiste in una molteplicità di astrazioni di comunicazione

globali chiamate tuple centre.

Gli agenti mobili possono accedere al tuple centre attraverso un'interfaccia di

comunicazione Linda-like e le primitive di comunicazione bloccanti o no hanno la

stessa semantica di quelle di Linda descritte nel paragrafo 2.4. Inoltre, ogni ope-

razione deve essere e�ettuata rispetto ad uno speci�co spazio di tuple indicando

esplicitamente il suo nome. Se t è il nome di un tuple centre e T è il nome della

tupla, ad esempio, un'operazione out(T)@t e�ettuata da un agente esprime l'inten-

zione di inserire una tupla T all'interno del tuple centre denotato da t nello spazio

di comunicazione locale dove l'agente è attualmente in esecuzione. Questo permet-

te una forma di comunicazione espressiva, poichè in tal modo vengono forniti una

molteplicità di canali di comunicazione, che possono essere programmati e a cui si

può accedere individualmente e indipendentemente.

Il modello TuCSoN supporta direttamente l'integrazione tra sorgenti di infor-

mazione eterogenee. Il suo modello di coordinazione su tupla sposta le interazioni

38 2.6 Tucson


disaccoppiate grazie alla comunicazione generativa, che fornisce la scissione dell'a-

gente, sia dal punto di vista dello spazio che dal punto di vista del tempo; in questo

modo gli agenti possono interagire senza conoscere reciprocamente nè chi sono nè

dove sono, indipendentemente dalla loro contemporanea esistenza.

2.6.2 Tuple Centre

TuCSoN va oltre Linda, fornendo �essibilità e controllo attraverso astrazioni di co-

municazione programmabili, chiamate tuple centre. Diversamente dallo spazio di

tuple di Linda il comportamento di un tuple centre [OZ99b], come canale di comuni-

cazione, può essere de�nito a seconda delle necessità applicative: il comportamento

di un'astrazione di comunicazione, come uno spazio di dati condiviso, viene semplice-

mente de�nito come una transizione di stato osservabile che segue un certo evento

di comunicazione. Quindi de�nire nuovi comportamenti per un tuple centre signi�ca

speci�care un nuovo stato di transizione in risposta ad un evento di comunicazione

standard.

I tuple centre sono mezzi di interazione pienamente distribuiti, e possono essere

considerati come delle astrazioni sociali che consentono di vincolare esplicitamente

le interazioni degli agenti, e ra�orzare le attività di coordinazione e cooperazione che

de�niscono l'aggregazione di agenti come società. I protocolli di interazione possono

essere proiettati e distribuiti tra agenti e mezzi a seconda dello speci�co obiettivo

applicativo.

Un primo vantaggio è l'aumento dell'autonomia dell'agente, in quanto può essere

progettato concentrandosi solo sui propri obiettivi e compiti, senza tener conto delle

dipendenze dagli altri agenti e senza tener traccia dell'evoluzione dell'ambiente.

Attraverso i tuple centre viene anche aumentata la decentralizzazione, poichè

2.6 Tucson 39


sono di�usi sulla rete e si trovano �sicamente nei nodi visitati dagli agenti mobili.

In�ne, la natura topologica degli spazi di interazione globali di TuCSoN rende

possibile trattare con aspetti tipici dei sistemi distribuiti, in particolare per ra�orzare

le politiche di sicurezza, di allocazione del carico di lavoro e fault tolerance.

Quindi in sintesi, ciò che caratterizza il tuple centre è un concetto di speci�ca di

comportamento attraverso il quale si può de�nire come un tuple centre reagisce ad

un evento di comunicazione entrante o uscente.

Dal punto di vista dell'agente un tuple centre assomiglia ad un tuple space per-

chè vi si accede attraverso una stessa interfaccia. Diversamente dal tuple space,

il comportamento del tuple center, in risposta agli eventi di comunicazione, può

essere de�nito da leggi di coordinazione che si trovano all'interno del mezzo di

comunicazione e non in ogni singolo agente.

2.6.3 Reazioni TuCSoN

Ogni primitiva di comunicazione TuCSoN può essere associata ad una speci�ca at-

tività computazionale, chiamata reazione [OZ98]. Una reazione viene de�nita come

un insieme di operazioni non sospensive, con una semantica transazionale di tipo

successo o fallimento.

Inoltre, tutte le reazioni eseguite come una conseguenza di un singolo evento di co-

municazione vengono caricate in una singola transazione dello stato del tuple centre,

prima che ogni altro evento di comunicazione reattivo venga processato. Come con-

seguenza, dal punto di vista dell'agente, il risultato dell'invocazione di una primitiva

di comunicazione e la somma degli e�etti della primitiva stessa e di tutte le reazioni

che esso avvia, percepite tutte insieme come una transizione di stato singola di tuple

centre.

40 2.6 Tucson


La programmazione delle reazioni richiede la de�nizione di un appropriato lin-

guaggio, in grado di fornire l'acesso a tutte le informazioni reative agli eventi di

comunicazione e fare in modo che le reazioni abbiano libero accesso alla modi�ca

delle informazioni nei tuple centre. Il modello TuCSoN per la coordinazione degli

agenti mobili prescinde dal linguaggio adottato per la speci�ca delle reazioni, dal

tipo di tupla usata per la comunicazione e dai criteri di tuple matching.

TuCSoN supporta una forma di coordinazione disaccoppiata e di coordinazione

oggettiva, dove le regole di coordinazione sono incorporate nei tuple centre e sono al

di fuori delle entità interagenti, cosicché essi possono e�ettivamente governare le loro

interazioni in modo predicibile. Le regole di interazione di TuCSoN possono essere

espresse come programmi nel linguaggio di speci�ca ReSpecT [OZ98] e incorporate

all'interno dei tuple centre. ReSpecT può essere considerato una sorta di linguaggio

assembly per le interazioni, con forti basi formali, generale e potente a su�cienza

per supportare lo sviluppo di linguaggi di speci�ca a più alto livello.

In�ne, le leggi di coordinazione speci�cate nei tuple centre sono dinamicamente

ispezionabili.

Dopo aver studiato i concetti relativi alla coordinazione di sistemi complessi

prendenso in esame due modelli di coordinazione brokering e matchmaking.

2.6 Tucson 41

Capitolo 3

Due modelli di coordinazione:

brokering e matchmaking

Dopo aver introdotto, nel Capitolo precedente, il concetto di coordinazione, riteniamo

opportuno dedicare questo capitolo alla trattazione di due modelli di coordinazione

che hanno ispirato il nostro lavoro: il brokering e il matchmaking proposti in [PSNS].

Al �ne di comprendere questo nuovo elemento introduciamo il concetto di inter-

mediario. Il dizionario Garzanti della lingua italiana de�nisce l'intermediario come:

� colui il quale facilita la conclusione di un a�are tra due contraenti, interponen-

dosi fra di loro data la sua conoscenza del dominio, la �ducia che gli altri ripongono

in lui e la visibilità che ha sul mercato.�

Intrinseco a questa de�nizione è il concetto di economia che, come tutti sanno,

è stato rivisto con lo sviluppo della rete. Gli intermediari entrano nella rete occu-

pandosi della ricerca, del recupero e dell'aggregazione dei servizi facendo si che la

43

CAPITOLO 3. DUE MODELLI DI COORDINAZIONE:BROKERING E MATCHMAKING

realizzazione dell'operazione on-line ne riduca i costi.

Quando parliamo di intermediari, sia nell'economia �sica che in quella digitale,

non facciamo riferimento solamente a persone �siche, ma anche a sistemi software

ad esempio i middle-agent. Questi agenti che possono essere considerati elettronici

mediatori nell'economia digitale [BWY00] svolgono il compito di coordinare princi-

palmete le attività fra agenti fornitori e richiedenti dei servizi (informazioni, beni o

competenze) in Internet [DSW] localizzando e connettendo le parti in un ambiente

aperto appropriato a risolvere determinati problemi di connessione.

Nel seguente Capitolo, dopo aver presentato il processo di localizzazione del

servizio, daremo prima una caratterizzazione base dei middle-agent per poi sof-

fermarci sulle loro caratteristiche. Saranno, inoltre, presentati mediator, broker e

matchmaker tre tipi di middle-agent e alcuni modelli di coordinazione particolari di

una società di agenti: il brokering e il matchmaking. Il Capitolo si concluderà de-

scrivendo le caratteristiche base di un linguaggio che può essere usato per descrivere

le capacità degli agenti.

3.1 Processo di localizzazione di un servizio:

una veduta d'insieme

Il processo di mediazione viene realizzato attraverso l'uso di tre categorie di agenti

[KS01]: service providers (P-agents), service requester (R-agents) e middle-agent.

Il P-agent fornisce alcuni tipologie di servizi che permettono di trovare le informazioni

o risolvere alcuni particolari problemi relativi al dominio speci�co. Gli R-agent sono

coloro i quali necessitano degli P-agent per sviluppare alcuni compiti ed in�ne i

middle-agent sono coloro i quali aiutano a localizzare gli altri.

44 3.1 Processo di localizzazione di un servizio:una veduta d'insieme


Il processo base che mostra la capacità di mediazione di un middle-agent ha la

seguente forma:

1. un P-agents pubblicizza le sue capacità al middle-agent ;

2. il middle-agent memorizza queste informazioni;

3. un R-agent richiede ad un qualsiasi middle-agent di localizzare e conneterlo

ad un P-agent che ha determinate capacità tra cui quella di completare la

transazione portandogli un valore aggiunto;

4. il rispettivo middle-agent tratta questa richiesta confrontandola con la sua

conoscenza relativo alle capacità degli P-agent registrati ottenendo così un

risultato che può essere o un sottoinsieme delle informazioni memorizzate con

il nome del rispettivo P-agent da contattare o il risultato di una completa

transazione per il servizio più appropriato.

Mentre a prima vista questo processo può sembrare estremamente semplice, esso

in realtà è molto complesso soprattutto per il fatto che Internet è una società aperta

ricca di informazioni attraversata da continui cambiamenti che riguardano, ad esem-

pio, la locazione, l'eterogeneità e il contenuto delle risorse disponibili. La complessità

del processo può essere portata anche dal fatto che si ha a che fare con di�erenti co-

munità di utenti e MAS ciascuna delle quali stà perseguendo il proprio obiettivo che

può essere in con�itto con l'obiettivo di un altro. In aggiunta, il numero elevato di

agenti e MAS che sono stati sviluppati da di�erenti gruppi e organizzazioni rendendo

massimo il problema della connessione. Così, le capacità essenziali di alcuni tipi di

middle-agent sono quelle di facilitare l'interoperabilità di appropriati servizi, agenti

e sistemi, a costruire un certo livello di �ducia, con�denza e sicurezza in un modo

3.1 Processo di localizzazione di un servizio:una veduta d'insieme

45


�essibile confermando una regolare e legale framework quando disponibile. Questo

dipende dalle richieste implicite ad un'applicazione, alle informazioni o all'ambiente

di sistema.

Dato che tipi di middle-agent diversi realizzano di�erenti performance quale tipo

di middle-agent è più appropriato dipende dalle applicazione. La s�da complessiva

di una soluzione basata su middle-agent è trovare quale situazione è la più e�cace,

e�ciente e a�dabile. Inoltre, il fatto che non vengano usate solo informazioni locali,

ma tutte quelle che sono disponibili in Internet fa nascere il problema di capirsi l'un

l'altro aumentando la necessità di un linguaggio comune, come LARKS [SWKL02],

per descrivere capacità e richieste dell'agente in un modo conveniente. Inoltre, si ha

l'esigenza di determinare un meccanismo per realizzare uno strutturato e semantico

incontro attraverso l'uso di ontologie 1.

Descriviamo ora cosa sono i middle-agent e quali sono le loro caratteristiche base.

3.2 Cosa sono i Middle-agent

La nozione di middle-agent, matchmakers, brokers, facilitators e mediators sono usa-

te comunemente in letteratura senza che siano chiaramente de�nite. Con la nostra

trattazione vorremmo risolvere questo problema terminologico.

In generale, come già abbiamo detto i middle-agent sono agenti che aiutano agli altri

a localizzare e connettere gli agenti che forniscono il servizio [DSW]. Inoltre, cias-

cun middle-agent può essere caratterizzato dalle seguenti abilità base che in seguito

saranno trattate in dettaglio:1Il concetto di ontologia non è banale e diverse sono le de�nizioni trovate in letteratura. Guarino

la de�nisce come un particolare sistema di categorie che o�re una determinata visione del mondo.

Mentre Grouber come una speci�cazione esplicita di una concettualizzazione.

46 3.2 Cosa sono i Middle-agent


1. o�rire servizio di mediazione di base;

2. coordinare questi servizi in accordo con determinati protocolli, convenzioni e

policy;

3. assicurare una mediazione di servizi a�dabili in termini di livelli di qualità e

di una gestione basata sulla �ducia all'interno e attraverso i limiti del sistema

multiagente.

3.2.1 Servizio di mediazione

In un sistema informativo aperto come Internet un middle-agent deve fornire un

servizio di mediazione di base per:

• trattare la capacità dell'agente e la descrizione del servizio;

• realizzare una semantica interazione tra agenti e sistemi;

• gestire i dati e la conoscenza;

• distribuite interrogazioni di lavorazione ed operazioni.

Ora brevemente discutiamo ciascuno di questi tipi di servizi e successivamente nel

paragrafo 3.3 proponiamo una rispettiva classi�cazione service-oriented dei middle-

agent.

Per quanto riguarda la trattazione della capacità dell'agente e la descrizione del

servizio, il requisito base per capire e automaticamente processare le richieste è in

accordo con l'uso di un comune linguaggio di descrizione come LARKS [SWKL02],

Capability Description Language (CDL) o un framework per la descrizione di un

servizio basato su XML come Resource Description Framework (RDF).

In generale, il middle-agent deve in tempo reale analizzare, convalidare, capire e

3.2 Cosa sono i Middle-agent 47


rispettivamente processare le capacità e la descrizione del servizio che riceve per poi

determinare quale dei servizi reclamizzati è il più adatto per la richiesta di un agente.

La scelta di un appropriato meccanismo di matching tra le richieste e i servizi

disponibili certamente dipende dalla struttura e dalla semantica della descrizione del

servizio che meglio soddisfa le richieste tanto quanto il tipo e la qualità dell'output

del processo di matching. Il meccanismo di matching può contare, per esempio, sul

semplice match basato su chiave-valore che usa strutture dati e tipi di deduzioni,

o un piuttosto complesso meccanismo di inferenza. Nel caso in cui vogliamo real-

izzare accoppiamenti semanticamente signi�cativi si costringe il servizio ad essere

fortemente legato con la classe di servizi che permettono interoperazione semantica

tra gli agenti.

Per ciò che riguarda la semantica interazione tra agenti e sistemi uno dei prin-

cipali ostacoli è la semantica e la sintattica eterogeneità dei dati e della conoscenza

dei middle-agent che ricevono e accedono informazioni da una molteplicità di agenti

eterogenei, sistemi informativi e sorgenti.

La capacità funzionale di un middle-agent di risolvere tale eterogeneità semantica e

strutturale fa riferimento al processo basato sulla conoscenza di brokering semantico

[SKL99] e può utilizzare ontologie o integrazione di informazioni.

Infatti, la maggior parte dei metodi per risolvere problemi di eterogeneità contano

sull'uso di parziali o globali ontologie di conoscenza le quali possono essere condivise

tra gli agenti. Questo richiede che un middle-agent fornisca alcuni tipi di servizi

ontologici per la creazione, il caricamento, la gestione e l'uso appropriato di un do-

minio ontologico speci�co o più brevemente di un'ontologia [BvHH+]. Sullo stesso

livello si richiede al middle-agent la conoscenza di relazioni inter-ontologia quando

sono processate le richieste e i dati tra di�erenti agenti.



L'utilizzo una rappresentazione di conoscenza unica supporta il middle-agent (i) nel

capire la semantica delle capacità delle richieste e delle pubblicità o della descrizione

dei servizi che esso riceve da agenti eterogenei e (ii) nel riconciliare le eterogeneità se-

mantiche dei match. Il tipo di applicazione e mediazione di un middle-agent richiede

anche di determinare quali tipi di ontologie e servizi sono i più appropriati. Un'a-

nalisi comprensiva dei metodi e delle tecniche per la risoluzione di di�erenti tipi di

eterogeneità può essere trovata per esempio nel [K+93].

Per la gestione dei dati e della conoscenza, i servizi di base interni ad un middle-

agent riguardano l'e�cienza dell'elaborazione e della memorizzazione dei dati e della

conoscenza relativamente a se stesso e gli altri. Tali informazioni sono, ad esempio,

l'insieme delle capacità di un P-agent registrato, vecchie e attuali richieste di un dato

R-agent, la conoscenza di un'ontologia condivisa e altri dati ausiliari per lo sviluppo

di processi interni. Il corrispondente database, repository e base di conoscenza di un

middle-agent, che contiene tutte le informazioni in suo possesso, può essere ispezion-

ato da un altri agenti e usato per di�erenti scopi come, ad esempio, la speci�cazione

di appropriate richieste nel dominio o il monitoraggio delle attività in accordo con

valide restrizioni di accesso e policy di sicurezza.

In�ne, per quanto riguarda interrogazioni distribuite di lavorazione ed operazioni,

il middle-agent deve permettere consultazioni dirette a multipli database esterni o

altre sorgenti per ottenere informazioni riguardanti il nome di colui il quale ha fatto

richiesta. In questo caso il middle-agent deve, inoltre, realizzare interrogazioni pro-

grammate e distribuite ed eseguire delle transizioni in collaborazione con il rispettivo

sistema multi agente.



3.2.2 Coordinazione del servizio di mediazione

La coordinazione di un servizio di mediazione di un middle-agent richiede in par-

ticolare l'abilità di comunicazione dell'agente, del sistema e del'utente coinvolti nel

processo di mediazione di cui abbiamo parlato nel paragrafo 3.1, in accordo con un

dato protocollo, delle convenzioni e delle policy. Informazioni aggiuntive quali il

nome e la registrazione di un agente sono necessarie per permettere al middle-agent

di localizzare e identi�care fornitori e clienti nei diversi MAS.

Di seguito indichiamo i sottoprocessi che coinvolgono la coordinazione del servizio di

mediazione.

Registrazione degli agenti

La localizzazione degli agenti attraverso middle-agent presume che i P-agent siano

registrati e possano essere richiamati in ogni momento, al �ne di utilizzare i loro

servizi base.

In riguardo alla scalabilità il middle-agent può essere capace di individuare di-

namicamente le capacità degli agenti anche se appartenenti a diverse società di agenti

così come può mantenere la massima accessibilità per coinvolgere società di agenti

con ogni capacità. Ad esempio, un R-agent all'interno di una società può bene�ciare

di alcuni servizi forniti da diversi P-agent, senza essere consapevole del fatto che

ognuno di loro appartiene ad un Multi Agent System diverso. Questo può essere

realizzato dal middle-agent il quale è inizialmente contattato dall'R-agent che vuole

sfruttare la sua interpretazione semantica di servizio e che vuole, inoltre, realizzare

appropriate collaborazioni con il middle-agent.



Interazioni tra agenti

Ciascuna interazione coordinata tra il middle-agent, i registrati R-/P- agent e altri

middle-agent è realizzata grazie all'accordo di usare uno o più linguaggi di comu-

nicazione ad agenti come l'ACL [LFP99]. Infatti, nel comunicare informazioni fra

agenti diversi è essenziale preservare la semantica desiderata delle espressioni dato

che sia il formato di un messaggio che il suo contenuto devono essere compresi cor-

rettamente dal middle-agent e dai sui clienti al �ne di sviluppare e supportare il

rispettivo servizio di mediazione richiesto.

Accesso alle sorgenti di dati e alle informazioni

In alcuni casi il middle-agent ha accesso al database di sistema o ad altre sorgenti di

informazione attraverso API standard. Altri di�erenti approcci sono forniti per far si

di recuperare i dati necessari al completamento dei compiti spettanti almiddle-agent :

tra questi possiamo individuare quello in cui si instaura una interazione con i wrapper

agent a cui si indirizzano appropriate interrogazioni. Ciascun wrapper trasforma

le richieste ricevute e interroga nel linguaggio proprietario il sistema ottenendo un

risultato nel formato desiderato dal middle-agent il quale unisce tutti questi risultati

parziali ottenuti da diversi wrapper per realizzare ulteriori processi.

Interfaccia con l'utente

Oltre al requisito di un middle-agent di saper comunicare in modo appropriato con

i suoi R-agent o con altri sistemi, esso può fornire agli utenti l'interfaccia al servizio

permettendo loro di relazionarsi con le informazioni disponibili di loro interesse.

Questi insiemi di informazioni sono descrizioni di servizio attuali o fornitori di servizi

registrati a cui si può accedere solo se si è in possesso di determitate policy.



Protocolli e policy di mediazione

Ciascuna attività relativa alla mediazione di un servizio all'interno di una società di

agenti può essere organizzata e coordinata in accordo con determinati protocolli e

convenzioni di interazione. Il middle-agent per de�nizione gioca un ruolo centrale di

inizializzazione e coordinazione delle interazioni tra agenti appartenenti ad insiemi

collaborativi e competitivi.

La maggior parte dei protocolli di interazione, descritti nel paragrafo 3.4, include

matchmaking, brokering e arbitraggio nella negoziazione tra P- e R-agents, apparte-

nenti per esempio, a mercati virtuali o aste.

3.2.3 A�dabilità della mediazione

Ciascun cliente richiede al middle-agent contattato di essere a�dabile in termini di

�ducia e qualità del servizio. Questo signi�ca che il middle-agent dovrebe sviluppare

il suo servizio di mediazione in ogni momento in una maniera �data e in accordo con

una dato livello di sicurezza e di qualità �ssata da ciascun agente individualmente o

dalla società di agenti. In altre parole si richiede che il middle-agent a�ronti il suo

lavoro tenendo in considerazione di�erenti tipi di polize in una maniera coerente e

consistente.

Un middle-agent deve, inoltre, assicurarsi che i dati che memorizza, processa

e fornisce agli altri agenti, siano conformi ai requisiti di qualità e agli standard

prede�niti. In questo contesto una policy racchiude le intenzioni e le volontà di

un agente in riguardo a problemi che hanno a che fare con la qualità di prodotti e

servizi che esso riceverà dal middle-agent o dal P-agent. La speci�cazione, la gestione

e la valutazione della qualità dei dati e dei servizi mediati implica di seguire degli

standard. Una precisa trattazione è data nel [JJQ+00].



In riguardo all'uso dei servizi e dei dati i requisiti di qualità sono l'accessibi-

lità e l'usabilità degli agenti in termini di sicura disponibilità e interpretabilità in

ordine a determinare i cambiamenti e di ragionare su di essi. Altri fattori di quali-

tà includono la correttezza, la completezza, la consistenza e la ridondanza dei dati

tanto bene quanto la funzionalità, l'e�cienza e la portabilità dell'implementazione

del servizio di mediazione. Ulteriori fattori riguardano la qualità di mediazione del

servizio fornito dal middle-agent stesso. Per esempio, la mediazione fornita dovrebbe

essere accurata, fault-tollerance rispetto a potenziali fallimenti del servizio, adatta-

bile, e�cente rispetto al tempo e alle risorse e stabile. Esso, inoltre, richiede che

il middle-agent garantisca contro la perdita di dati permettendo di incrementare il

livello di �ducia nel suo servizio di mediazione.

Oltre alla domanda dell'utente di fornire un servizio di qualità ci sono anche

altri essenziali requisiti che devono essere garantiti dal middle-agent come quelli di

privacy, anonimità e veri�cazione delle capacità che l'utente stà reclamizzando. In

questo caso il middle-agent agisce come un �dato intermediario tra gli agenti.

Considerando il concetto di sicurezza da un lato sia i dati interni, che la conoscen-

za esterna che i processi di computazione di una mediazione eseguita da un middle-

agent dovrebbero essere tanto robusti da evitare attacchi e manipolazioni da parte

di sistemi, agenti o utenti maligni. Dall'altra lato, il cliente di un middle-agent non

dovrebbe essere incentivato a fare un cattivo uso di alcuna delle informazioni di rile-

vante importanza ottenute durante la mediazione. In questo senso la maggior parte

delle azioni sono accompagnate da autorizzazioni e veri�che di credenzialità di tutte

le parti che sono coinvolte nella mediazione. Tuttavia alla base dei processi che ven-

gono realizzati ci devono essere relazioni di �ducia fra le parti appartenenti ad una

o più società di agenti connesse tra loro.



Riassumendo, nasce la necessità per tutti gli agenti di applicare nel processo di

mediazione un appropriato modello di �ducia per analizzare e stimare il rischio di

un metodo e per prevenire e contrattaccare attacchi contro i dati e la conoscenza.

Passiamo ora ad analizzare alcune tipologie di�erenti di middle-agent.

3.3 Tipi di Middle-agent

Decker nel [DSW] discute su di�erenti ruoli dei middle-agent nello spazio delle

soluzioni del problema di connessione dal punto di vista della privacy. L'autore

esamina particolarmente la conoscenza circa le preferenze del R-agent e le capacità

del P-agent. Da questo punto di vista speci�che richieste e risposte o azioni di un

servizio sono interpretate rispettivamente come istanze delle preferenze degli R-agent

e le capacità degli P-agent.

Sia le preferenze che le capacità, possono essere tenute inizialmene private al R-agent,

per poi essere rivelate ad alcuni middle-agent o essere fatte conoscere al P-agent.

Questo porta alla categorizzazione di alcuni ruoli come mostrato nella Tabelle 3.1

tratta dal [DSW].

PREFERENZE CAPACITA' INIZIALMENTE CONOSCIUTE DA

INIZIALMENTE solo P-agent P-agent + middle-agent

CONOSCIUTE DA P-agent + middle-agent + R-agent

solo P-agent (Broadcaster) Front-agent matchmaker

P-agent + middle-agent Anonymizer broker Reccommender

P-agent + middle-agent + R-agent Blackboard Introducer Arbitrator

Tabella 3.1: Categorizzazione dei ruoli del middle-agent

54 3.3 Tipi di Middle-agent


Per esempio, in una transazione mediata dal broker, esso dopo aver compreso

inizialmente le informazioni relative alle capacità di privacy e alle preferenze sia del

P-agent che dell R-agent le può tenere nascoste, e in questo caso né il P-agent né

l'R-agent si conoscono direttamente. Nel caso in cui la transizione sia mediata dal

matchmaker ogni R-agent può interrogarlo circa le informazioni di capacità di un

registrato P-agent ottenendo una risposta. Le informazioni, in questo caso sono,

infatti, rivelate inizialmente sia al richiedente che al fornitore. Comunque, questa

categorizzazione del ruolo del middle-agent non permette una temporizzazione degli

eventi.

In aggiunta a questa prospettiva sul middle-agent ristretto a elementi di privacy

il [KS01] propone una più generale classi�cazione dei middle-agent che tiene in con-

siderazione le capacità base. Questa classi�cazione è implicita dall'estensione che un

middle-agent sta o�rendo servizi di mediazione come quelli descritti.

Figura 3.1: Classi�cazione dei middle-agent

La Figura 3.1 riassume queste classi di servizi per un middle-agent in generale

3.3 Tipi di Middle-agent 55


e per alcuni comuni tipi di middle-agent in particolare, chiamati mediator, broker e

matchmaker. La matrice di classi�cazione corrispondente basata sulle di�erenze in

servizi è data nella Figura 3.2.

Figura 3.2: Classi�cazione dei middle-agent basata sui servizi

In seguito discuteremo brevemente in merito al mediator, al broker e al match-

maker.

3.3.1 Mediators

Un mediator agent nella sua originale de�nizione data da Wiederhold nel 1992

[Wie92] è dinamicamente e attivamente l'interfaccia per l'utente (R-agent) relati-

vamente ai dati e alla conoscenza in suo possesso. In questo contesto il termine me-

diazione include il processo necessario per interfacciarsi, alle strutture di conoscenza

che guidano le trasformazioni necessarie dei dati in informazioni e per attingere da

ciascun deposito le informazioni intermedie del quale si può aver bisogno.



In generale, un mediatore focalizza sulla previsione di un servizio dedicato al

brokering delle informazioni semantiche. Questo include il servizio per una :

1. dinamica determinazione delle informazioni del servizio prodotto;

2. negoziazione tra agenti consumatori e fornitori;

3. dinamica creazione e comparazione delle informazioni concludendo o assem-

blando componenti e servizi di vari fornitori.

Come menzionato sopra, lo scenario più comune di un mediator in un sistema di

informazione intelligente è che esso agisca come una unità collaborativa centrale con

un insieme di P-agent ciascuno dei quali fornisce l'accesso ai dati di alcune sorgenti

di informazioni comuni ad un modello di dati.

Un mediator nella sua attività crea e gestisce un modello di informazioni sia globale

che parziale sull'ambiente di un altro agente attraverso un'interazione basata sulla

conoscenza di ricevere informazioni da di�erenti sorgenti o�rendo un valore aggiunto

al servizio.

Esso prende le richieste di un R-agent e risponde loro o usando il suo modello di

informazione globale o inviando appropriate richieste al wrapper agent opportuno per

trattare interrogazioni distribuite. In questo senso le informazioni sono raggruppate

seguendo un meccanismo generato su domanda dal mediator.

In contrasto con il broker il mediator non colleziona semplicemente le informazioni

di di�erenti fornitori di dati, ma integra esse in un modello globale di informazioni al

�ne di risolvere inconsistenze e con�itti. Questo modello è tipicamente nascosto nella

de�nizione di mediatore ed è generato staticamente o dinamicamente. In aggiunta,

un broker non è capace di trattare interrogazioni distribuite per cui si avvale dei

wrapper.

3.3 Tipi di Middle-agent 57


3.3.2 Brokers

Un broker, a volte chiamato anche facilitator, può attivamente interfacciare R-agent

e P-agent facando da intermediario alle richieste di transazioni di servizi. Tutte le

comunicazioni tra coppie di P- e R-agent devono superare il broker. Esso tipicamente

contatta i più importanti P-agent negoziando per l'esecuzione e il controllo delle

transazioni più appropriate ritornando il risultato del servizio all' R-agent.

Questo è in contrasto con le funzionalità dell'agente matchmaker, ma è intrinseco

a quella del mediator. Diversamente mediators e broker tipicamente non forniscono

un modello di informazioni globale, semanticamente integarato e consistente per i

loro clienti, ma memorizzano le informazioni collegate con informazioni ontologiche

secondo alcuni standard dati in un repository appropriato come un data warehouse.

In aggiunta, un broker tipicamente non ha un estensivo insieme di servizi di media-

zione tanto quando lo ha un mediator; rispetto a questo un broker può contare su

di�erenti tipi di agenti orientati ai compiti che sono capaci di collaborare e negoziare

con esso. Un broker può sfruttare se necessario il lavoro di certi P-agent.

Diversamente da un mediator, l'interazione di un broker con un altro agente non

è né ristretta ad un wraper o ad un mediator né connessa con una pre�ssato numero

di agenti. Questa capacità è particolarmente utile �nchè i broker sono attivi in un

ambiente dinamico nel quale le risorse e gli agenti possono continuamente entrare e

uscire. In tali ambienti risulta essere improprio mantenere uno statico e pre-integrato

modello globale il quale è valido per una società di agenti e sistemi piuttosto chiusa.

Comunque, dobbiamo notare che la semantica del termine matchmaker bro-

ker tanto bene come mediator e broker sono spesso usati intercambiabilmente in

letteratura.



3.3.3 Matchmaker

Il compito di un matchmaker è quello di accoppiare solamente l'R-agent con il P-

agent, nel senso che il match è realizzato tra una data richiesta dell'R-agent e una

pubblicità di un servizio del registrato P-agent che poi gestiranno automamente

l'interazione. In contrasto con le funzionalità sia del broker che del mediator il

matchmaker restituisce all'agente richiedente una lista ordinata di P-agent. Come

conseguenza l'R-agent deve contattare e negoziare direttamente con il P-agent per

ottenere il servizio che desidera.

Questa diretta intermediazione tra l'R-agent e il P-agent selezionato è sviluppata

indipendentemente dal matchmaker evitando così un collo di bottigia sulla trasmis-

sione dei dati o su di un'improvvisa sospensione dell'attività del matchmaker, ma

alla stesso tempo incrementa la comunicazione diretta tra R- e P-agent.

Si potrebbe quindi considerare il matchmaking come sottoinsieme del brokering,

ma allo stesso tempo lo estende dando a posteriori all'R-agent la piena scelta di

selezionare un P-agent indipendentemente dal matching risultante.

3.4 Come avviene la coordinazione del

broker e matchmaker

La coordinazione di un'attività di mediazione all'interno e attraverso una società di

agenti può esere sviluppata da un middle-agent, per esempio, attraverso il processo

di brokering e di matchmaking. Entrambi i tipi di mediazione implicano di�erenti

requisiti e protocolli per l'intereazioni tra gli agenti coinvolti in questi processi. In

accordo con le caratteristiche base di classi�cazione di un middle-agent, come descrit-

to nel paragrafo 3.2, ciascun metodo e tecnica di discovery del servizio con capacità

3.4 Come avviene la coordinazione delbroker e matchmaker

59


o può essere implementato utilizzando tanto il brokering quanto il matchmaking. In

aggiunta, le ontologie di servizio sono tipicamente usate per sviluppare un signi�ca-

tivo ragionamento automatico sulle capacità e le descrizioni dei servizi speci�cati in

un dato linguaggio.

Descriveremo ora brevemente i modelli di interazione di alto livello sia per il

matchmaking che per il brokering.

3.4.1 Il matchmaking

Per quanto riguarda ilmatchmaking quando un agente che o�re un servizio registra

se stesso nel middle-agent insieme ad una descrizione delle sue capacità speci�cate in

accordo con il linguaggio di comunicazione esso è memorizzato come una pubblicità

nel database del middle-agent. Così, quando un agente richiede un servizio, il middle-

agent ricerca nel suo database di pubblicità un P-agent che può soddisfare tale

richiesta. Le richieste sono soddisfatte solo quando la pubblicità è �su�cientemente

simile� alla decrizione del servizio richiesto (service matching). Come mensionato nel

paragrafo 3.3.1 l'agente richiedente interagisce direttamente con il giusto fornitore

per ottenere il servizio e i dati che desidera (service gathering).

La Figura 3.3 da una veduta d'insieme delle interazioni delle parti coinvolte nel

processo di matching.

3.4.2 Il brokering

Per quanto riguarda il brokering, mostrato nella Figura 3.4 esso è basato sulle

capacità funzionali del broker informalmente descritto nel paragrafo 3.3.2.

Da sottolineare, inoltre, è l'esistenza di esempi di implementazione di sistemi

multiagenti e piattaforme le quali sono coordinate attraverso middle-agent attraverso

60 3.4 Come avviene la coordinazione delbroker e matchmaker


Figura 3.3: Modello di interazione: matchmaking

Figura 3.4: Modello di interazione: brokering

3.4 Come avviene la coordinazione delbroker e matchmaker

61


modelli di coordinazione come il brokering e il matchmaking. Questi esempi sono

IMPACT [BS91], RETSINA/LARK [SZ96] e InfoSleuth [NFK+00].

3.5 Matchmaking e brokering performance a confronto

Nel [DWS96] è stata discussa la decisione di usare matchmaking o brokering per

risolvere problemi di connessione. Noi ora riportiamo le parti salienti della trattazione

che evidenziano l'esistenza di un elevato numero di possibili punti di controllo tra cui

il livello al quale i servizi richiesti sono generati, il numero dei P-agent nel sistema, il

tempo necessario per ciascun P-agent per soddisfare la richiesta, il grado di fallimento

dell'agente.

3.5.1 Sistemi Sperimentali

Nel [DWS96] sono considerano due sistemi alternativi. Ciascuno dei quali è composto

da un certo numero di P- ed R-agent.

Nel sistemi presi in esame ci sono un certo numero di parametri che possono

variare tra cui il numero dei P-agent (N), il tempo richiesto da ciascun servizio per

soddisfare una richiesta (T) e il livello medio nel quale le richieste sono generate

(P). L'attuale tempo di servizio per ciascuna richiesta e il periodo tra una richiesta e

l'altra sono generate randomicamente; il tempo di servizio è distribuito normalmente

intorno a T e il periodo di generazione delle richieste è distribuito esponenzialmente

intorno a P. Nel [DWS96] è predisposta, inoltre, una situazione reale, quindi, alcuni

parametri sono fuori controllo, tra essi la latenza sulla comunicazione tra agenti,

il bisogno computazionale del broker o del matchmaker e l'ammontare del tempo

62 3.5 Matchmaking e brokering performance a confronto


trascorso da un P- e un R-agent sul progettare, schedulare e sull'eseguire operazioni

interne.

Nel [DWS96] sono inoltre fatte assunzioni circa il range di valori che i parametri

del sistema assumerà. Prima, si assume che il tempo di servizio è relativamente

lungo se confrontato con la massima computazione del matchmaker, broker e P-

agent stessi. In secondo luogo, si assume che il numero di P-agent è relativamente

basso (massimo 20 P-agent).

Di seguito sono presentati due esperimenti fatti nel sistema appena descritto.

3.5.2 Un primo esperimento sul tempo di risposta

Nel primo esperimento, il [DWS96] valida il modello teoretico ed empiricamente com-

para il broker e il matchmaker. Per un dato tempo di servizio un certo numero di

P-agent, viene variato il periodo di generazione delle richieste. Per ciascun periodo,

si sono generate 100 richieste e misurato la media e la deviazione standard del tempo

passato alla loro soddisfazione. La Figura 3.5 mostra i risultati relativi alla soddis-

fazione della richiesta quando il periodo di generazione della stessa varia tra cinque

e quindici secondi, nel sistema ci sono tre P-agent e il tempo di servizio è di quindici

secondi.

Da notare che, nonostante l'acerbità del modello, esso da una buona indicazione

sull' tempo di risposta aspettato, specialmente per richieste che hanno un largo

periodo di generazione. Per periodi brevi quando il sistema è saturo le misurazioni

fatte coincidono con la previsione teoretica. Inoltre, le prime richieste sperimentano

un tempo di attesa più basso provocando la diminuzione del livello di disallineamento.

In ogni caso, è chiaro che il carico di bilanciamento del brokering conferisce un

vantaggio sul tempo di risposta del matchmaking.

3.5 Matchmaking e brokering performance a confronto 63


Figura 3.5: Tempo medio per 100 richieste di servizi in funzione del periodo di

generazione della richiesta

3.5.3 Un secondo esperimento sul fallimento del sistema e il suo

ripristino

Nel secondo esperimento mostrato, si investiga sul e�etto del fallimento del sistema

e il ripristiono in entrambi i modelli. Si inizia con tre P-agent e si �ssa il tempo

di servizio e il periodo di generazione delle richieste rispettivamente a quindici e

dieci secondi. Dopo cinque minuti si uccide uno dei P-agent e dopo altri cinque se

ne uccide un'altro ancora. Cinque minuti dopo questo, uno dei due agenti uccisi

ritornano nel sistema, e dopo altri cinque minuti anche l'ultimo ritorna. In questo

sistema, quando un P-agent muore invia un messaggio di interruzione di servizio

all'R-agent che deve essere riallocato ad un altro P-agent.

Le Figure 3.6 e 3.7 mostrano i risultati dell esperimento. Ciascun punto rappre-

senta il completamento di una richiesta di servizio. La linea rappresenta il numero di



Figura 3.6: E�etti del fallimeto e del ripristiono nel matchmaking

Figura 3.7: E�etti del fallimeto e del ripristiono nel brokering

3.5 Matchmaking e brokering performance a confronto 65


P-agent attivi in ogni momento. La superiorità del tempo di risposta del brokering

è veramente drammatica. In esso di individua la di�erenza di comportamento dei

due modelli quando il P-agent ritorna attivo. Quando c'è un solo P-agent il siste-

ma è saturo così che il P-agent inizia ad accumulare un gran numero di richieste

arretrate. Quando il secondo e il terzo P-agent ritornando disponibile l'R-agent del

matchmaking continua ad allocare una metà o un terzo delle loro richieste al P-agent

sovraccaricato, così che il lavoro arretrato persiste per molto tempo. Nel brokering,

invece, tutte le nuove richieste sono allocate al nuovo P-agent permettendo il lavoro

arretrato di essere velocemente smistato.

Concludendo, il matchmaker può essere utilizzato principalmente in sistemi de-

centralizzati. Esso o�re risposte più �essibili ad agenti che entrano ed escono dal

sistema e ciascun agente tiene un controllo sulle sue decisioni. Comunque il match-

maker presentano un singolo punto debole dato dal fatto che ciascun agente necessita

di essere abbastanza intelligente per costruire un'interrogazione e valutare le scelte

tra P-agent alternativi. Usando il matchmaker l'ammontare del costo è livemente più

alto a causa delle interrogazioni aggiuntive e di una mancata traduzione ontologica

centralizzata.

Il brokering può, invece, essere utilizzato in sistemi centralizzati. Esso può, inol-

tre, maneggiare la dinamica entrata e uscita dell'agente, fornire un facile modo di

caricare il bilanciamento e realizzare una traduzione ontologica centralizzata o delle

semplici caratteristiche di integrazione. Comunque, essi so�rono la necessità degli

agenti che hanno una conoscenza statica del broker generando un collo di bottiglia

sulla comunicazione.

Considerando quando detto per le sue caratteristiche il matchmaker è il modello

che abbiamo seguito per l'implementazione del nostro prototipo.



Concludendo il capitolo riferendoci alle caratteristiche di un linguaggio comune

di descrizione delle capacità degli agenti di cui abbiamo più volte mensionato.

3.6 Un linguaggio comune per descrivere le capacità degli

agenti

Come abbiamo accennato precedentemente c'è un ovvia necessità di descrivere le

capacità che un agente in un comune linguaggio prima di ogni richiesta, fornitura

o matching si realizzi tra gli agenti che si trovano in un determinato ruolo. Infatti,

la formale descrizione delle capacità è uno dei maggiori problemi nell'ingegneria del

software e dell'Intelligenza Arti�ciale (IA). Alcune delle principali caratteristiche che

tali linguaggi di descrizione delle capacità degli agenti proposte da [SWKL02] sono

elencati di seguito.

Espressività Il linguaggio deve essere abbastanza espressivo per rappresentare non

solo i dati e la conoscenza, ma anche per descrivere il signi�cato del codice

del programma. Le capacità degli agenti sono descritte in un livello astratto

piuttosto che in uno implementativo.

Inferenza L'inferenza su descrizioni scritte in questo linguaggio sono supportate.

Un utente può leggere ogni asserzione nel linguaggio e gli agenti software saran-

no capaci di processare e specialmente confrontare ogni coppia di asserzioni

automaticamene.

Facilità d'uso Ogni descrizione non dovrebbe essere solo facile da leggere e capire,

ma anche facile da scrivere per l'utente. Il linguaggio dovrebbe supportare l'uso

d'un dominio o un'ontologia comune per speci�care le capacità dell'agente.

3.6 Un linguaggio comune per descrivere le capacità degli agenti 67


Applicabile al Web Uno dei principali domini applicativi per il linguaggio è la

speci�cazione della pubblicità e delle richieste per gli agenti. Il linguaggio

permette di realizzare scambi automatici delle informazioni tra questi agenti e

il loro il trattamento.

Inoltre, il processo di matching su di un dato insieme di capacità descrittive e

richieste, entrambe descritte in un Agent Capability Description Language (ACDL)

dovrebbe essere e�ciente, accurato e pienamente automatico.

68 3.6 Un linguaggio comune per descrivere le capacità degli agenti

Parte II

PARTE APPLICATIVA

69

Capitolo 4

Strumento di lavoro: JADE

In questo capitolo verrà descritta la piattaforma ad agenti JADE (Java Agent DEve-

lopment Framework) [jad] che abbiamo utilizzato per sviluppare il prototipo descritto

nell'introduzione.

Ci sembra quindi opportuno dedicare una breve trattazione degli aspetti speci�ci

dello strumento e dei concetti necessari per una migliore comprensione del tutto.

Analizzeremo cos'è JADE, la sua architettura e le sue principali funzionalità. Quello

che si vuole fare non è dunque un analisi approfondita, ma una navigazione veloce e

al contempo su�ciente degli argomenti che saranno toccati all'interno del lavoro.

4.1 Che cos'è JADE

JADE è un middleware sviluppato interamente in linguaggio Java da TILAB (Tele-

com Italian Labs) per la realizzazione di applicazioni basate sugli agenti conformi allo

standard FIPA. Esso tratta di tutti gli aspetti che non sono peculiari per un agente

e che sono indipendenti dall'applicazione così come dal protocollo di trasporto, dal-

71

CAPITOLO 4. STRUMENTO DI LAVORO: JADE

la codi�ca e dal parsing. Il suo obiettivo è sempli�care lo sviluppo degli agenti

assicurando l'aderenza allo standard.

Prima di continuare la nostra trattazione su JADE riteniamo opportuno intro-

durre FIPA.

FIPA [�p] (Fondation for Intelligence Physical Agents) è un organizzazione no-pro�t

nata a Ginevra nel 1996 che mira alla creazione di standard da seguire durante la

fase di progettazione di un MAS (Multi Agent System) per poter garantire l'inter-

operabilità di agenti e sistemi software agent-based eterogenei, poiché sviluppati da

compagnie e organizzazioni diverse. L'obiettivo di FIPA è indicato nella dichiarazione

di missione:

�The promotion of technologies and interoperability speci�cations that facilitate

the end-to-end interworking of intelligent agent system in modern commercial and

industrial settings�.

Ritornando a JADE, elenchiamo di seguito i principi fondamentali su cui esso si

basa.

interoperabilità - JADE, come già detto, è conforme alle speci�che dello standard

FIPA, di conseguenza, un agente può interagire con altri agenti purchè conformi

allo stesso standard;

uniformità e portabilità - JADE fornisce un omogeneo insieme di API che sono

indipendenti dallo strato di rete e dalla versione della Java Virtual Machine. In

particolare, l'ambiente run-time fornisce le stesse API sia per l'ambiente J2EE,

per J2SE e J2ME.

semplicità d'uso - La complessità del middelware viene nascosta al programmatore

fornendo semplici e intuitive API.

72 4.1 Che cos'è JADE


�loso�a pay-as-you-go - Il programmatore non necessità di usare tutte le fun-

zionalità o�erte da JADE e queste, se non usate, non aggiungono overhead

computazionale.

Il middleware è estremamente versatile adattandosi non solo ad ambienti con

risorse limitate come terminali mobili, ma anche ad architetture complesse come

.NET.

4.1.1 Containers e Piattaforme

JADE include sia le librerie di classi Java per la realizzazione degli agenti sia l'am-

biente run-time che fornisce i servizi di base e che deve essere attivo su un device

�nchè sia possibile eseguire uno o più agenti. Ogni istanza del run-time di JADE è

chiamata container (�contenitore� di agenti) e l'insieme di tutti i container è detto

piattaforma e fornisce un omogeneo livello che nasconde completamente agli agenti

la complessità e l'eterogeneità degli strati sottostanti (hardware, sistemi operativi,

tipi di reti e JVM). Un singolo speciale Main container deve sempre essere attivo in

una piattaforma e tutti gli altri container sono attivati con questo non appena essa

si avvia. Segue che il Main container deve essere mandato in esecuzione prima di

ogni altro normal container.

Se un altro Main container si avvia in un altro luogo nella rete, esso costituisce una

di�erente piattaforma dove nuovi container possono registrarsi. La Figura 4.1 illustra

il concetto sopra espresso attraverso un semplice scenario mostrando due piattaforme

JADE composte rispettivamente da tre e un container. Gli agenti JADE sono iden-

ti�cati da un unico nome e, purché conoscano i nomi degli altri agenti, essi possono

comunicare in maniera trasparente malgrado la loro attuale locazione: stesso con-

4.1 Che cos'è JADE 73


tainer (es. agenti A2 e A3), di�erenti container nella stessa piattaforma (es. agenti

A1 e A2) o di�erenti piattaforme (es. agenti A4 e A5).

Figura 4.1: Container e Piattaforme

4.1.2 Le componenti fondamentali: AMS, DF e ACC

Le entità fondamentali per il corretto funzionamento della piattaforma sono:

AMS Agent Management System;

ACC Agent Communication Channel;

DF Directory Facilitator.



L'AMS è un agente che esercita il compito di supervisore, controllando l'acces-

so e l'uso della piattaforma. Esso è indispensabile ed unico in una piattaforma ad

agenti ed è responsabile di tutte le operazioni di gestione che la riguardano, come la

creazione o la cancellazione di agenti ed il controllo della migrazione degli stessi.

L'AMS o�re servizi di �pagine bianche� agli agenti, mette cioè a loro disposizione

una serie di funzioni basilari. Per far questo l'AMS mantiene una directory di AID

(Agent Identi�er) che contiene gli indirizzi di trasporto degli agenti registrati sulla

piattaforma, informazioni sul loro stato e servizi appropriati per la gestione del loro

ciclo di vita.

Ogni agente, quando viene creato, deve registrarsi presso l'AMS per ottenere il pro-

prio valido AID. La registrazione comporta l'autorizzazione, previa fase di autenti�-

cazione, ad accedere al MTP (Message Transport Protocol) per svolgere la mansione

di invio e ricezione di messaggi.

L'ACC è un agente che rappresenta l'unica porta implementata in JADE abilita-

ta alla comunicazione con l'ambiente esterno alla piattaforma. E' quì che tutte le co-

municazioni devono passare, incluse quelle da o verso agenti residenti in piattaforme

diverse da JADE. L'utilizzo di questo unico elemento come porta di comunicazione

permette di raggiungere lo scopo di tenere nascosto a tutti gli agenti il metodo di

trasmissione delle informazioni utilizzato. In questo modo non si deve gestire il tipo

di canale usato.

Il suo comportamento fondametale consiste nel restare in un ciclo di wait nell'attesa

di un messaggio in arrivo verso la piattaforma. Quando questo evento si veri�ca è

compito dell'agente ACC smistare correttamente il messaggio.

Tuttavia sempre più spesso le comunicazioni dovranno avvenire tra piattaforme non

omogenee, implicando all'ACC di essere in grado di interpretare messaggi provenienti

4.1 Che cos'è JADE 75


da piattaforme non JADE. Questo è possibile grazie all'opportunità di utilizzare un

sistema di codi�ca e decodi�ca da stringa ad oggetto ACLMessage.

In�ne, il DF è un agente che fornisce un servizio di �pagine gialle� alla piatta-

forma, cioè permette agli agenti di pubblicare uno o più servizi forniti da loro così

che altri agenti possono trovarli e successivamente sfruttarli come descritto in Figu-

ra 4.2. Questo servizio viene creato automaticamente nel Main container, ma può

essere rimosso senza problemi. Il DF, infatti, non è una struttura indispensabile per

la vita degli agenti, ma un comodo sistema di ricerca.

All'atto della sua creazione, o in qualunque istante del suo ciclo di vita, un agente

JADE può scegliere se registrarsi presso il DF, dato che il servizio è quello di pub-

blicizzare la presenza di un dato agente nella piattaforma.

Essendo il DF un agente è possibile interagire con esso con l'usuale scambio di mes-

saggi ACL usando un proprio linguaggio (SL0) e una propria ontologia (FIPA-agent-

management) in accordo con le speci�che FIPA. Inoltre, per sempli�care questa

interazione, JADE fornisce la classe jade.domain.DFService la quale permette di

pubblicare e ricercare servizi attraverso chiamate di metodi.

Un agente che desidera uno o più servizi deve fornire al DF la descrizione includendo

la sua AID, possibilmente la lista delle ontologie che gli altri agenti necessitano per

interagire con esso e la lista dei servizi cercati. Per ogni servizio pubblicato la de-

scrizione fornita include il tipo di servizio, il nome, i linguaggi e le ontologie richieste

per sfruttare il servizio e le sue proprietà.

Invece, un agente che desidera ricercare un servizio deve fornire al DF una descrizione

di template. Il risultato della ricerca è una lista di tutte le descrizioni che incontrano

la template fornita. Una descrizione incontra una template se tutti i campi speci�-

cati nella template sono presenti nella descrizione con lo stesso valore.



Da considerare il fatto che JADE introduce il concetto di federazione di DF e di DF

federato permettendo di ottenere una ricerca che prende in considerazione tutti i DF

federati con quello di partenza.

Figura 4.2: Servizio di �pagine gialle�

4.2 Behaviour degli agenti

Un agente deve essere capace di portare avanti più attività (behaviours) contem-

poraneamente in risposta a degli eventi esterni. Per renderne più e�ciente la ges-

tione, ogni agente in JADE è composto da un singolo thread di esecuzione, mentre

tutte le sue attività sono modellate e implementate come oggetti Behaviour aggiun-

ti dinamicamente. Possono essere implementati anche agenti multi-threaded, ma

JADE non fornisce alcun supporto speci�co per essi, ad eccezione del meccanismo di

sincronizzazione costituito dalla coda dei messaggi ricevuti.

Gli sviluppatori che vogliono implementare un'attività speci�ca per un agente

devono de�nire una o più sottoclassi di Behaviour, instanziarle e aggiungere gli

4.2 Behaviour degli agenti 77


oggetti appena creati alla lista delle attività da schedulare. In realtà JADE fornisce

già alcune sottoclassi prede�nite, cioè SimpleBehaviour e CompositeBehaviour.

La classe astratta SimpleBehaviour rappresenta un'attività atomica e modella

behaviours che sono costituiti da un'attività monolitica e unica e che non può essere

mai interrotta. Da essa derivano alcuni sotto-behaviours, tra cui quelli rappresen-

tati dalle seguenti classi: OneShotBehaviour, CyclicBehaviour, WakerBehaviour e

TickerBehaviour.

La classe astratta CompositeBehaviourmodella un'attività complessa, cioè un'at-

tività che è a sua volta composto da altre attività, che costituiscono i suoi �gli. Quindi

le operazioni reali che questo behaviour dovrà svolgere non sono da lui de�nite, ma

dai behaviours che lo compongono. Infatti, il CompositeBehaviour deve preoccupar-

si solamente di realizzare lo scheduling di questi ultimi in base a una certa politica.

Quindi ogni volta che viene schedulato il metodo action() di CompositeBehaviour,

viene immediatamente chiamato il metodo action() di uno dei suoi behaviours �gli.

Le classi che estendono CompositeBehaviour fornite da JADE sono:

SequentialBehaviour, ParallelBehaviour e FSMBehaviour (Finite State Machine

Behaviour).

La lista delle attività da schedulare può essere gestita da un qualsiasi agente per

mezzo dei due metodi addBehaviour() e removeBehaviour(). Naturalmente, ogni

behaviour può essere aggiunto alla lista in qualsiasi momento e non solo in fase di

setup. JADE fornisce uno scheduler, utilizzato dalla classe Agent e nascosto al pro-

grammatore che seleziona un behaviour fra tutti quelli disponibili nella lista delle

attività pronti e lo manda in esecuzione. Il behaviour rimarrà in esecuzione �no a

quando il suo metodo action() non avrà terminato e nessuno altro behaviour di

quell'agente potrà essere eseguito. Dato che tutti i behaviours di un agente coope-

78 4.2 Behaviour degli agenti


rano e sono sottoposti a scheduling contemporaneamente, il metodo action() non

deve assolutamente entrare in un loop in�nito, non deve essere troppo lungo, ma

deve rilasciare le risorse il prima possibile in modo da preservare una certa prontezza

da parte del sistema. Più in dettaglio, lo scheduler esegue il metodo action() di

ciascun behaviour presente nella lista delle attività pronte e quando termina l'ese-

cuzione, il behaviour chiama il metodo done() per controllare se ha terminato il suo

compito. In caso a�ermativo il behaviour viene de�nitivamente cancellato dalla coda

delle attività pronte, altrimenti, viene mantenuta nella coda per essere rischedulata

all'occasione successiva. Abbiamo visto che i behaviours si comportano come threads

che cooperano; però bisogna aggiungere che, a di�erenza di questi, non esiste per i

behaviours uno stack in cui salvare i dati durante il context switch. Perciò, lo stato

dell'intera computazione deve essere mantenuto sulle variabili delle varie istanze di

Behaviour o del relativo Agent. Per evitare che i behaviours sprechino del prezioso

tempo di CPU viene data loro la possibilità di bloccare la propria esecuzione. Con

il metodo block(), non appena il metodo action() termina, vengono posti in una

coda di behaviours bloccati o in attesa. Quindi l'e�etto bloccante non è ottenu-

to nel momento in cui viene chiamato block(). Infatti, non essendoci uno stack

che conservi il contesto parziale delle operazioni, il metodo action() è ogni volta

eseguito dall'inizio: non c'è insomma un modo di interrompere il behaviour nel bel

mezzo della sua esecuzione, cedere la CPU agli altri behaviours e poi ripartire dallo

stesso punto in cui era stato precedentemente interrotto. I behaviours bloccati sono

sottoposti nuovamente a scheduling non appena si veri�ca l'evento atteso.

4.2 Behaviour degli agenti 79


4.3 Comunicazione tra agenti

La piattaforma JADE utilizza come struttura fondamentale per la comunicazione: i

messaggi ACL (Agent Comunication Language).

Un agente che desidera inviare un messaggio deve creare un oggetto ACLMessage,

impostare gli attributi con valori appropriati e poi chiamare il metodo send() della

classe Agent.

Nei successivi paragra� viene descritta la struttura, il contenuto, l'invio e la ricezione

di un messaggio ACL e il supporto alla comunicazione.

4.3.1 Struttura di un messaggio ACL

La struttura generalizzata di un messaggio, come descritto in �gura 4.3, viene divisa

in:

Figura 4.3: Struttura generale di un messaggio ACL

• Dati del messaggio vero e proprio, incluso il corpo del testo (rettangolo bianco);

80 4.3 Comunicazione tra agenti


• Payload del messaggio inclusi i dati prestabiliti da FIPA (rettangolo grigio)

Nella tabella 4.1 viene presentato un elenco completo delle variabili de�nite dagli

standard.

PARAMETRO CATEGORIA

performative tipo di comunicazione

sender attore della comunicazione

receiver attore della comunicazione

reply to attore della comunicazione

content contenuto del messagggio

language descrizione del contenuto

encoding descrizione del contenuto

ontology descrizione del contenuto

protocol controllo di conversazione

conversation id controllo di conversazione

reply with controllo di conversazione

in reply to controllo di conversazione

reply by controllo di conversazione

Tabella 4.1: Messaggio ACL

Nessun campo di un messaggio ACL è obbligatorio ad eccezione del campo perfor-

mative, che indica il tipo di comunicazione. Ogni messaggio, infatti, deve dichiarare

che tipo di informazione intende comunicare.

Per l'accesso e l'impostazione degli attributi del messaggio, la classe ACLMessage

mette a disposizione una serie di metodi. Bisogna aggiungere che alcuni di questi

4.3 Comunicazione tra agenti 81


attributi possono essere costituiti da un insieme di valori, e non da uno solo. Di

conseguenza esistono diversi metodi a seconda del numero degli elementi che costi-

tuiscono l'attributo. Quelli che ne hanno uno solo aggiungono semplicemente un

nuovo valore all'insieme, mentre gli altri restituiscono un oggetto di tipo Iterator,

cioè una struttura dati che contiene tutti i valori dell'insieme e che fornisce metodi per

l'accesso ad alcuni di essi. C'è poi il metodo reset() che consente la cancellazione

dei valori di tutti gli attributi del messaggio.

4.3.2 Supporti alla comunicazione

JADE facilita il lavoro del programmatore per mezzo di alcuni metodi. Uno di

questi è senza dubbio createReply() che ritorna un nuovo oggetto ACLMessage, con

alcuni attributi correttamente impostati per poter rispondere in modo adeguato ad

un messaggio precedentemente ricevuto.

Inoltre, JADE mette a disposizione dell'utente un codec (StringACLCodec), uti-

lizzato nelle comunicazioni inter-piattaforma, che converte l'intero messaggio ACL

in una stringa, e viceversa. Per questo �ne, JADE fornisce un'interfaccia ACLCodec

(implementata da StringACLCodec), il cui compito è quello di convertire oggetti Java

in una grezza sequenza di byte che sia in accordo con le possibili forme di rappresen-

tazione dei messaggi ACL indicate da FIPA. In JADE, tutti i messaggi ACL sono

codi�cati di default nel formato stringa, così come viene de�nito in FIPA. In nor-

mali condizioni, gli agenti non necessitano di chiamare esplicitamente questo codec,

poiché la chiamata viene e�ettuata automaticamente dalla piattaforma.



4.3.3 Contenuto dei messaggi ACL

Particolare attenzione merita la trattazione dell'attributo content del messaggio

ACL. JADE fornisce i metodi setByteSequenceContent() e

getByteSequenceContent(), rispettivamente per impostare e per ottenere il con-

tenuto del messaggio come sequenza di byte, e i metodi setContent() e getContent(),

rispettivamente per impostare e ottenere il contenuto del messaggio come stringa.

La classe ACLMessage aiuta il programmatore consentendogli l'uso della codi�ca

Base64 per mezzo di altri due metodi: setContentObject() e getContentObject().

Questi metodi non sono conformi a FIPA e poiché la codi�ca Base64 non è ricono-

sciuta automaticamente da tutte le piattaforme, essi devono essere adeguatamente

utilizzati dai programmatori i quali devono presupporre che i metodi siano conosciuti

a priori da tutti gli agenti interessati nella comunicazione.

4.3.4 Invio e ricezione dei messaggi

La classe Agent fornisce un insieme di metodi per e�ettuare la comunicazione con

altri agenti tramite lo scambio asincrono di messaggi, istanze della classe ACLMessage.

Inoltre, JADE fornisce sotto forma di behaviours, pronti all'uso e da sottoporre a

schedulazione insieme alle altre attività, alcuni dei protocolli di interazione de�niti

da FIPA.

La piattaforma associa a ciascun agente una coda privata in cui ripone i messaggi in

arrivo e, inoltre, mette a disposizione alcune modalità per consentire l'accesso alla

coda.

Dato che il modello di JADE basato sui behaviours consente ad un agente di

eseguire alcune attività in parallelo, e quindi anche di portare avanti molte conver-

sazioni simultaneamente, e dato che la coda dei messaggi in arrivo è unica per tutti



i behaviours dell'agente, viene fornita una versione dei due metodi di ricezione che

permette di poter scegliere quali tipi di messaggi ricevere, semplicemente utilizzando

un parametro di tipo MessageTemplate che descrive le caratteristiche volute, cioè

con quali attributi e con quali valori degli attributi si vuole ricevere il messaggio.

Per quanto riguarda i behaviours che implementano le operazioni di spedizione e

ricezione dei messaggi, è necessario dire che SenderBehaviour estende OneShotBehaviour

e incapsula un'unità atomica che realizza l'azione di spedire un messaggio, mentre

ReceiverBehaviour estende direttamente la classe Behaviour e incapsula un opera-

zione atomica che realizza l'azione di ricevere un messaggio e che termina a ricezione

e�ettuata. Il messaggio è ricevuto tramite il metodo getMessage().

4.3.5 Spedire messaggi ad agenti remoti

Parlando a proposito dell'agente, nel paragrafo 4.1.2, abbiamo detto che esso è iden-

ti�cato da un AID, una struttura con più slots, uno dei quali contiene la lista di tutti

gli indirizzi di trasporto con cui può essere contattata la piattaforma che contiene

l'agente stesso. E' logico pensare che questo slot deve contenere almeno un indirizzo

di un MTP (Message Transport Protocol) per poter supportare le comunicazioni tra

piattaforme diverse.

JADE ha una struttura che consente di utilizzare più MTPs in un modo �essibile;

infatti, ciascun contenitore può avere più MTPs attivi, così che l'amministratore della

piattaforma può scegliere ogni volta il tipo di trasporto più adeguato. JADE esegue

il routing sia dei messaggi in entrata che di quelli in uscita. Quando viene attivato

un nuovo MTP su un contenitore, la piattaforma ottiene un nuovo indirizzo che è

aggiunto alla lista di tutti quelli disponibili, quest'ultima mantenuta nel pro�lo della

piattaforma, cioè APDescription, la cui struttura è de�nita da FIPA e che è a sua



volta mantenuta dall'AMS. Per di più, il nuovo indirizzo è aggiunto in tutti gli oggetti

AMSAgentDescription, descrizioni degli agenti registrati presso l'AMS.

Un indirizzo di trasporto viene mantenuto �no a che il suo contenitore è atti-

vo, poiché quando quest'ultimo viene chiuso, tutti i suoi MTPs sono disattivati e le

relative informazioni mantenute sull'AMS vengono aggiornate di conseguenza. Ri-

capitolando quanto appena detto, una piattaforma, e quindi i suoi agenti, durante

la loro esistenza possono avere più indirizzi, che possono essere attivati e disattivati

durante l'esecuzione del sistema.

JADE si occupa di mantenere una certa consistenza nella piattaforma e negli ind-

irizzi sul suo pro�lo, nelle conoscenze di base dell'AMS, e nei valori degli identi�catori

ritornati col metodo getAID() della classe Agent. Per particolari situazioni dipen-

denti dal contesto di applicazione, un agente è in grado di scegliere esplicitamente

un sottoinsieme di tutti gli indirizzi disponibili con cui esso deve essere contattato

dal resto dell'universo degli agenti. In alcuni casi, un agente può persino decidere

di attivare protocolli speci�ci di una applicazione, che non appartengono all'intera

piattaforma ma solo a se stesso. Così gli indirizzi preferiti di un agente non sono

necessariamente gli stessi messi a disposizione dalla piattaforma. Per poter support-

are ciò, l'agente deve essere in grado di gestire la sua copia dell'AID e impostare con

esso il campo mittente del suo messaggio ACL piuttosto che con l'AID ritornato dal

metodo getAID().

Per poter de�nire un nuovo MTP da usare in JADE, tutto ciò che serve è imple-

mentare l'interfaccia MTP che modella un canale bidirezionale, che può sia spedire

che ricevere messaggi ACL, e che estende ulteriori due interfacce, OutChannel e

InChannel, che rappresentano canali a senso unico.

Poi esiste l'interfaccia TransportAddress (implementata oltre che dall'indirizzo IIOP



anche dall'indirizzo RMI), una semplice rappresentazione dell'URL che consente di

leggere distintamente il protocollo, l'host, la porta e il �le.

In�ne, JADE fornisce la classe MessageTransportProtocol che implementa l'in-

terfaccia MTP e che si occupa dell'interpretazione dell'envelope del messaggio di

trasporto.

4.4 Ontologie in Jade

Gli agenti che intendono comunicare in un modo semanticamente consistente devono

condividere lo stesso linguaggio, vocabolario e protocollo.

L'ontologia è la descrizione degli oggetti, dei concetti e delle relazioni in una certa

area di interesse. Una de�nizione precisa è data da [ont]:

�Un insieme di simboli associati ad un'interpretazione che può essere condiviso

da una comunità di agenti. Un'ontologia include un vocabolario di simboli che si

riferiscono ad oggetti in un dato dominio, insieme ad altri simboli associati alle

relazioni che caratterizzano tale dominio.�

I concetti possono essere rappresentati nella logica del primo ordine come predi-

cati monadici, mentre predicati più complessi rappresentano le relazioni. Ogni agente

deve rappresentare la propria conoscenza nel vocabolario di una speci�ca ontologia;

in questo modo gli agenti che condividono la stessa ontologia per la rappresentazione

della conoscenza comprendono le �parole� del linguaggio di comunicazione utilizzato.

Seguendo lo standard FIPA, JADE già supporta l'utilizzo di un'ontologia base;

questo è evidente nell'uso di comunicazioni FIPA e della classe Coder/Decoder per

il linguaggio SL (Semantic Language) il quale determina la forma dei messaggi

scambiati tra agenti.

86 4.4 Ontologie in Jade


Nello sviluppo di un MAS è necessario de�nire un'ontologia del dominio applica-

tivo per de�nire la struttura e il contenuto dei messaggi scambiati tra gli agenti.

JADE fornisce tre modi per implementare la comunicazione tra agenti.

1. Il primo e il più comune modo consiste nell'uso di stringhe che rappresentano

il contenuto del messaggio. Questo è conveniente quando il contenuto del

messaggio è un dato atomico, ma non nel caso in cui è un concetto astratto,

oggetto o struttura dati.

2. Il secondo modo sfrutta la tecnologia Java per trasmettere Serialized oggetti

Java direttamente come contenuto del messaggio. Questo è spesso un modo

conveniente per una applicazione locale dove tutti gli agenti sono implementati

in Java. Lo svantaggio è che questi messaggi non sono in linguaggio naturale

e non rispettano lo standard FIPA.

3. Il terzo metodo coinvolge la de�nizione dell'oggetto che deve essere trasferito

come estensione di una classe prede�nita così che JADE possa codi�care e

decodi�care messaggi in formato standard permettendo l'interoperabilità con

altri sistemi ad agenti.

Di�erenti metodi saranno usati per impostare e recuperare il contenuto dei mes-

saggi in base al tipo. La tabella 4.2 indica la corrispondenza.

Di seguito verrà descritto come de�nire una ontologia speci�ca del dominio ap-

plicativa.

De�nire una ontologia speci�ca

Una ontologia speci�ca descrive gli elementi che possono essere usati come contenuti

di un messaggio di un agente. Un'ontologia è composta di due parti, un vocabolario

4.4 Ontologie in Jade 87


CONTENT TYPE GETTING CONTENT SETTING CONTENT

Strings getContent() setContent()

Java Objects getContentObject() setContentObject()

Ontology Objects extractContent() �llContent()

Tabella 4.2: Tabella delle corrispondenze

che descrive la terminologia dei concetti usati dagli agenti nel loro spazio di comuni-

cazione, e la nomenclatura delle relazioni che intercorrono tra questi concetti e che

descrivono la loro semantica e struttura.

Quando si implementa una ontologia speci�ca per una applicazione, si estende la

classe Ontology prede�nita in JADE e si aggiunge un insieme di schemi elementari

che descrivono la struttura dei concetti, azioni e predicati che verranno utilizzati per

descrivere il contenuto del messaggio.

Generalmente, quando de�niamo un'ontologia utiliziamo tre interfacce: Concept,

Agent Action e Predicate che fanno riferimento alle tre principali classi ConceptSchema,

AgentActionSchema e PredicateSchema.

Esaminando la gerarchia di queste classi, come mostrato in Figura 4.4 si può

notare che la classe AgentActionSchema eredita dalla classe ConceptSchema la quale

a sua volta è sottoclasse della classe TermSchema.

Mentre la classe PredicateSchema eredita dalla classe ContentElementSchema. Ma

alla base entrambe hanno una comune superclasse la quale è la classe ObjectSchema.

Ciò che ora a�ronteremo è un importante problema, bisogna capire quando usare

uno di questi oggetti ontologici.

1. L'agente A richiede all'agente B di sviluppare uno speci�co compito. In accordo

88 4.4 Ontologie in Jade


Figura 4.4: Gerarchia delle classi

con FIPA, il contenuto del messaggio che A spedisce a B deve essere �action�,

ad esempio una tupla il cui slot contiene l'identi�catore dell'agente a cui è

richiesto di sviluppare l'azione (qui l'agente B) e un descrittore che rappresenta

come richiesta il compito da sviluppare. In JADE, il compito sarà de�nito

da un oggetto Java che implementa l'interfaccia Agent Action e l'azione sarà

un'istanza della classe Action alla quale saranno passati come argomenti l'AID

dell'agente B e l'oggetto che descrive il compito da sviluppare.

2. L'agente A chiede all'agente B se una data proposizione è vera. In accordo

con FIPA il contenuto del messaggio deve essere deve essere un oggetto che

rappresenta la proposizione da controllare. In JADE una proposizione può

essere de�nita da un oggetto Java che implementa l'intarfaccia Predicate.

3. Prendiamo in esempio due agenti che implemenano il ruolo di client e server

4.4 Ontologie in Jade 89


per una banca che gestisce depositi bancari e supponiamo che il client richiede

al server di sviluppare un'azione consistente nel fare un deposito in un dato

conto. Per fare questo viene de�nita una classe MakeOperation che descrive

l'azione da svolgere. Siccome si tratta di un'azione, essa implementa l'interfac-

cia Agent Action. Il server per prima cosa processa le informazioni dopo di che

risponde inviando un oggetto Result, un oggetto Account, che rappresenta il

risultato dell'operazione processata, o un oggetto Problem se l'azione fallisce.

Tanto l'oggetto Account quanto l'oggetto Problem non sono Agent Action ne

Predicate, ma vengono semplicemente de�nite come concetti che implementano

l'interfaccia Concept.

Queste tre interfacce permettono di de�nire oggetti astratti in un'ontologia.

JADE, inotre, fornisce il supporto per de�nire elementi atomici che costituiscono

generalmente gli slot dei concetti astratti, tali come String, Integer, Float e molto

altro. Il supporto per questi tipi atomici di oggetti è fornito attraverso la classe

PrimitiveSchema ed è maneggiato dalla classe BasicOntoloty.

4.5 Mobilità

La mobilità è la capacità di un agente di migrare o clonarsi su host multipli remoti.

Per il momento JADE consente solamente la mobilità all'interno della stessa piatta-

forma, quindi un agente mobile in JADE può navigare solamente tra i contenitori di

una stessa piattaforma. La migrazione e la clonazione sono transizioni che sono state

considerate nel ciclo di vita dell'agente e, come tutte le altre transizioni del ciclo,

possono essere avviate sia dall'agente stesso che dall'AMS. Infatti, l'agente possiede

un'interfaccia che consente di richiedere all'AMS, tramite messaggi ACL, le opera-

90 4.5 Mobilità


zioni con cui esso consente la migrazione e la clonazione.

Un requisito fondamentale che gli agenti mobili devono avere è sicuramente la con-

sapevolezza del luogo in cui si trovano in ogni istante. JADE fornisce un'ontologia

che mantiene i necessari concetti e azioni. L'ontologia è rappresentata dalla classe

MobilityOntology, che costituisce un altro esempio di de�nizione di una nuova

ontologia speci�ca di un dominio di applicazione.

Più speci�catamente, la classe Agente del package jade.core sono dedicati per ge-

stire la mobilità di un agente, attraverso i metodi doMove(), beforeMove(), afterMove(),

doClone(), beforeClone() e afterClone(). I primi tre maneggiano il processo di

muovere un agente, mentre gli altri tre quello di clonarli.

Daremo ora una breve descrizione del processo di migrazione e clonazione degli

agenti.

Per muovere un agente si necessita di chiamare il metodo doMove() fornito dalla

classe Agent passando come parametro l'oggetto Location dove Location rappre-

senta il container cioè la destinazione dell'agente che migra. In pratica, ciascuna

Location rappresenta un contenitore di agenti ed è una struttura composta da un

identi�catore di contenitore, da un nome locale, dal protocollo utilizzato per raggiun-

gere il contenitore, e, in�ne, da un indirizzo di trasporto del contenitore associato al

protocollo utilizzato.

Equivalentemente, per clonare un agente si necessita di chiamare il metodo doClone()

fornito anche in questo caso dalla classe Agent. Anche qui il parametro passato è

l'oggetto Location.

4.5 Mobilità 91


4.6 Sicurezza

JADE include alcune caratteristiche a supporto della sicurezza, come l'autenticazione

dell'agente o del suo possessore, l'autorizzazione e la comunicazione sicura all'interno

della stessa piattaforma, che forniscono la tecnologia di base per i programmatori im-

pegnati a livello concreto nello sviluppo di applicazioni basate sugli agenti [TPR01].

I sistemi distribuiti richiedono un livello di sicurezza piuttosto alto sia per quan-

to riguarda le infrastrutture che le applicazioni; i sistemi multi-agente distribuiti,

che per loro natura aspirano ad assicurare l'autonomia e la mobilità degli agenti,

richiedono un'attenzione maggiore agli aspetti della sicurezza. I sistemi multi-agente

che non forniscono una componente di sicurezza non sono in grado nemmeno di

fornire servizi di certi�cazione o altre applicazioni che usino Internet. Un agente

malizioso, ad esempio, potrebbe uccidere un agente certi�catore, e prendere il suo

posto vendendo informazioni non reali, agendo con una identità contra�atta. Oppure

potrebbe esistere il caso in cui qualsiasi entità riesca a connettere un container remo-

to ad una piattaforma e muovere sul Main container di questa un agente malizioso

che riesca a leggere o a cancellare tutti i �les della macchina su cui è posta. JADE

rende la piattaforma un ambiente multi-utente controllato, in cui tutte le componen-

ti sono possedute da utenti autenticati, i quali sono autorizzati dall'amministratore

della piattaforma ad eseguire solamente alcune azioni.

92 4.6 Sicurezza

Capitolo 5

BioMOBY

Per non rimanere ad un alto livello d'astrazione, si è sentita l'esigenza di individuare

un dominio speci�co di sperimentazione. Abbiamo quindi deciso di specializzare il

nostro lavoro nel dominio biomedico.

Questa scelta è conseguenza del fatto che la crescente quantità e distribuzione di

risorse bioinformatiche porta a confrontarsi con una realtà ricca di una conoscenza

distribuita, eterogenea e autonoma. Nasce così il problema della sua organizzazione

per realizzare un utile obiettivo.

Noi vogliamo formalmente catturare una piccola parte di questa conoscenza al-

l'interno di un middleware che assista una larga serie di biologi e portarli ad utilizzare

il nostro sistema, rimanendo consapevoli del fatto che di�erenti attività richiedono

di�erenti rappresentazioni di conoscenza.

Dopo un'ampia ricerca si è deciso di utilizzare BioMOBY che è un progetto

di ricerca Open Source il cui obiettivo è quello di generare un'architettura per il

discovery di dati biologici attraverso Web Service.

In questo capitolo daremo nel primo paragrafo una panoramica generale su BioMO-

93

CAPITOLO 5. BIOMOBY

BY e nel secondo analizzeremo le sue principali componenti. Nel terzo paragrafo fare-

mo una breve comparazione con myGrid, nel quarto descriveremo come siamo arrivati

ad avere localmente un MOBY-Central ed in�ne, nell'ultimo paragrafo elenchiamo i

servizi che BioMOBY ci mette a disposizione.

In questo capitolo vedremo cos'è un sistema distribuito e le sue principali carat-

teristiche, come la trasparenza, la scalabilità, ecc.

Passeremo poi ad analizzare la parte software, individuando tre tipi di sistemi: i

Distributed Operating System (DOS), i Network Operating System (NOS) e i mid-

dleware.

Nella parte �nale ci so�ermeremo sul sistema middleware, evidenziando i modelli

di distribuzione e di comunicazione, i servizi, la sua posizione nel modello OSI e i

possibili strumenti per implementarlo.

5.1 MOBY: una veduta d'insieme

Il progetto BioMOBY è nato dall'esigenza di indirizzare il problema di scoperta e

recupero di dati biologici da host multipli e servizi, tentando di generare una query

standardizzata e un'interfaccia di ricerca che usa un modello ad oggetti.

Di seguito vengono elencati i principi sui quali esso si basa.

• Il tutto deve essere completamente Open Source [os].

• Standard esistenti dovrebbero essere usati in modo appropriato per garantire

l'interoperabilità.

• Il sistema dovrebbe trattare in modo identico il recupero e l'analisi dei servizi.

• Le applicazioni dovrebbero utilizzare delle semplici API.

94 5.1 MOBY: una veduta d'insieme

CAPITOLO 5. BIOMOBY

• Dati biologici centralizzati dovrebbero essere disponibili.

• Le query de�nite dall'utente dovrebbero essere sempli�cate il più possibile.

• Le preferenze dovrebbero essere date per sempli�care e alleggerire i dati, per

minimizzare il tra�co di rete non necessario e per sempli�care la creazione di

client e server.

• L'�investimento� fatto per implementare BioMOBY dovrebbe essere minimo in

modo da incoraggiare un gran numero di partecipanti ad aderire rapidamente

al progetto.

Il progetto BioMOBY condivide alcune similarità con altri progetti integrati, ma

aggiunge alcuni nuovi aspetti come quello di ordinare gerarchicamente i tipi di servizi

presenti, ri�ettendo il modo in cui i biologi esplorano e manipulano i loro dati.

In campo scienti�co i ricercatori hanno solitamente in mano dati sui quali de-

siderano investigare in profondità. BioMOBY facilita questo compito fornendo un

sistema di discovery dell'informazione che identi�ca e recupera basi di dati che hanno

l'appropiata conoscenza. Inoltre, esso fa si che gli interessati non siano costretti ad

interagire con molti complessi sistemi di recupero dei dati distribuiti su diversi host,

ma da loro la possibilità di interfacciarsi attraverso un unico comune formato in una

maniera leggibile all'uomo.

Il progetto BioMOBY ha uno scopo limitato che è quello di focalizzarsi sulla

descrizione e la scoperta dei servizi, nonché sulle operazioni di de�nizione degli input

e output.

I servizi potrebbero essere tanto semplici come il recupero di una sequenza basata

su di un ID, o tanti complessi come la determinazione di, o l'allineamento tra, un

dominio di funzionale interesse tra molte centinaia di sequenze di geni.

5.1 MOBY: una veduta d'insieme 95

CAPITOLO 5. BIOMOBY

Implementazioni individuali di BioMOBY possono aggiungere a queste funzionalità

di base ulteriori caratteristiche come quella di discovery di qualità da noi sviluppata

e descritta nel Capitolo 6 relativo al Caso Studio.

Gli utenti che interagiscono con il sistema possono essere classi�cati in tre cate-

gorie: bioinformatici, biologi e programmatori.

I principali utenti sono i bioinformatici, che hanno conoscenze nel dominio biologico

e abilità di programmazione. MOBY si aspetta inoltre di aiutare i bioinformatici a

sviluppare applicazioni per i biologi che si limitano ad utilizzare gli strumenti messi

a disposizione.

Viene introdotta anche la categoria dei programmatori perchè si ritiene che, nonos-

tante MOBY sia stato implementato nel dominio biomedico, la sua architettura è

indipendente da esso e potrebbe essere sfruttata per lo sviluppo di tool in altri domini.

I requisiti operazionali di MOBY sono i seguenti:

Hardware MOBY non richiede particolare hardware né sul lato server né sul lato

client oltre a quelli largamente usati dalle industrie per la connessione client-

server.

Software MOBY è implementato in Perl 5.0 e in Java 2. Il disegno del sistema

evita comunque di prendere decisioni architetturali che precludono l'imple-

mentazione in altri linguaggi.

Operating Systems MOBY richiede un sistema operativo che supporti Perl 5.0 o

Java 2.

Connettività Si richiede che il client e il server abbiano l'accesso al Web attraverso

HTTP.

Passiamo ora a descrivere i componenti chiave dell'architettura di MOBY.

96 5.1 MOBY: una veduta d'insieme

CAPITOLO 5. BIOMOBY

5.2 Componenti di MOBY

MOBY è un sistema attraverso il quale un client sarà capace di interagire con sorgenti

multiple di dati biologici nonostante lo schema della loro con�gurazione di base.

Il sistema, inoltre, permette l'identi�cazione dinamica di nuove relazioni tra dati

di di�erenti sorgenti. Nella Figura 5.1 vengono mostrate le parti coinvolte in una

dinamica transazione di MOBY.

Figura 5.1: Architettura di una dinamica transazione di MOBY

Come si può osservare, tre categorie di computer sono coinvolte: MOBY-Central,

descritto nel paragrafo 5.2.2 , MOBY-Server e MOBY-Client. Per prima cosa i

MOBY Servers registrano i loro servizi con MOBY-Central. La transazione continua

con l'arrivo della richiesta da parte del MOBY-Client che possiede una certa quantità

5.2 Componenti di MOBY 97

CAPITOLO 5. BIOMOBY

di dati e chiede a MOBY-Central quali sono i servizi capaci di usare i dati in suo

possesso come input. MOBY-Central ritorna uno o più WSDL Service Description

dei servizi trovati. Tra questi il MOBY-Client ne sceglierà uno e gli spedirà i suoi

dati. Quello che ritornerà sarà il risultato del servizio chiamato.

I dati sono passati nella forma MOBY-Object che spiegheremo nel paragrafo 5.2.1.

Descriviamo ora brevemente il ruolo di MOBY-Server e il ruolo di MOBY-Client.

GeneralmenteMOBY-Servers per diventare parte dell'ambiente di MOBY necessi-

ta solamente di implementare uno o più servizi. Esso si registra con il MOBY-Central

in quanto fornitore del servizio X che usa un o più input Y e genera uno o più out-

put Z.

Il MOBY-Client, invece, rappresenta il computer dal lato dell'utente. Esso è re-

sponsabile prima di identi�care a che tipo di dati è interessato e poi di generare una

query al MOBY-Central dalla quale ritornerà una lista di potenziali servizi. Spetterà

al MOBY-Client sceglierne uno con cui interagire direttamente.

5.2.1 MOBY-Objects

BioMOBY cerca di superare il problema di standardizzazione dei diversi tipi di

dati provenienti dai vari MOBY-Services, focalizzandosi sull'integrazione degli stessi.

Questa integrazione BioMOBY la sviluppa in maniera minimalista attraverso l'uti-

lizzo di una tripla espressa in un XML leggero che successivamente spiegheremo in

dettaglio, e che è in grado di identi�care univocamente tutti i servizi messi a dispo-

sizione.

Alla tripla, inoltre, possono essere aggiunte informazioni addizionali dette �payloads�

native dal sistema MOBY o da altri sistemi esterni.

Passeremo ora ad analizzare i principali elementi che caratterizzano MOBY-

98 5.2 Componenti di MOBY

CAPITOLO 5. BIOMOBY

Object.

MOBY Class Ontology

I tipi di dati (Class) ontology consistono in nodi, che rappresentano varie classi di

dati, e vertici, che rappresentano uno dei tre tipi di relazioni identi�cate con ISA,

HASA e HAS, come mostrato in Figura 5.2. Queste sono memorizzate in un database

relazionale, ma potrebbero anche essere rappresentate come un documento RDF.

Figura 5.2: La Class Ontology

La relazione ISA indica che, nell'asserzione soggetto-predicato-oggetto, la classe

soggetto eredita dalla classe oggetto (DNA Sequence ISA Nucleotide Sequence); tutti

gli attributi del secondo sono così presenti nel primo.

Le relazioni HASA e HAS indicano un'associazione di tipo contenitore tra soggetto


CAPITOLO 5. BIOMOBY

e oggetto: HASA indica una cardinalità di uno, mentre HAS indica una cardinalità

di uno o più.

Le ultime due relazioni introducono complessità addizionale permettendo la deriva-

zione di una nuova classe, mentre la relazione ISA, da sola, non altera la struttura.

In BioMOBY l'entità di dati sono castate in una classe o un'altra in base a che

sottoinsieme di entità è legata in quel dato momento. Come mostrato in Figura 5.2,

tutti gli oggetti hanno la stessa root che è la classe Object a cui sono legati da una

relazione ISA. Questa classe ha una struttura XML molto semplice. Essa consiste in

un singolo elemento il cui nome è in accordo con la classe e i tre attributi dei quali

solo due sono obbligatori: �namespace� e �ID�.

<Object namespace = `` '' id = `` ''/>

Il terzo opzionale attributo è chiamato �articleName� ed è usato quando un

servizio richiede il nome dell'input e/o identi�ca diferenti subcomportamenti di una

classe complessa.

BioMOBY Triple

Il MOBY-Objects è la più piccola struttura dati che viene passata tra Client e Server,

come già detto, rappresentata dalla tripla Class, Namespace ed ID. Quest'ultima ci

permette di indicare:

• La classe nella quale il dato può essere rappesentato (o castato) e può assumere

un valore proveniente da un vocabolario controllato e gerarchico di classi di

oggetti biologici.

• Il Namespace all'interno del quale possiamo identi�care parte di un dato, cioè

tutto ciò che può essere de�nito attraverso l'uso di un singolo identi�catore,


CAPITOLO 5. BIOMOBY

deriva dalla la Gene Ontology Cross-reference Abbreviations List [GOC] che

MOBY ha adottato come suo elenco canonico di Namespace.

• L'ID di un particolare entità di dati che rappresenta un'istanza del Namespace

speci�cato.

Così, per esempio, un MOBY-Object base che rappresenta il record Genbank

per l'Arabidopsis APETALA3 mRNA dovrebbe essere rappresentata dalla seguente

tripla:

<Object namespace = ``Genbank/AC'' id = `ÀY070397.1''/>

UnMOBY-Object leggermente più complesso con lo stesso identi�catore potrebbe

essere VirtualSequence il quale eredita tutte le caratteristiche di Object, ma ha un

addizionale elemento �Length� come payload. Così lo stesso dato potrebbe essere

castato come mostrato nel codice sottostante.

<VirtualSequence namespace = ``Genbank/AC'' id = `ÀY070397.1''>

<Length>960</Length>

</VirtualSequence>

L'oggetto Sequence eredita, inoltre, da VirtualSequence e aggiunge una �Se-

quenceString� come attributo payload. Il tutto è mostrato sotto.

<Sequence namespace = ``Genbank/AC'' id = `ÀY070397.1''>


<SequenceString>

aacaaaajattaaacaaagagag

aagaat


CAPITOLO 5. BIOMOBY

atggcgaga ggagatccagat

caaga..

</SequenceString>

</Sequence>

La tripla, quindi, rappresenta il cuore di tutte le transazioni di MOBY evitando

il passaggio di un modello complesso di dati specialmente quando si lavora con un

largo insieme di interrogazioni e risultati.

BioMOBY cross-references

In aggiunta alla tripla ed al payload i MOBY-Object possono opzionalmente trasportare

un addizionale Cross-Reference Information Block (CRIB).

Il CRIB è una lista di cross referencing MOBY Triples le quali, partendo dalla for-

ma base di un MOBY-Object, possono essere usate direttamente come input alla

nuova query. I cross references sono signi�cativi sia per trasportare più di una sem-

plice sinonima referenza alla tripla primaria, sia per selezionare oggetti conosciuti

dal provider.

Un esempio di quanto detto per l'oggetto MOBYSequence e per la Apetala3 mRNA

potrebbe essere strutturato come segue:

<Sequence namespace = ``Genbank/AC'' id = `ÀY070397.1''>

<CrossReferences>

<Object namespace=``PubMed/PMID'' UD=``11959818''/>

<Object namespace=``Genbank'' UD=``17979335''/>

<Object namespace=``Genbank/Taxa'' UD=``3702''/>

<Object namespace=``GO/Acc'' UD=``0016563''/>


CAPITOLO 5. BIOMOBY

</CrossReferences>


<SequenceString>

aacaaaajattaaacaaagagag

aagaat

atggcgaga ggagatccagat

caaga..

</SequenceString>

</Sequence>

5.2.2 MOBY-Central

BioMOBY permette il discovery dei servizi avendo un registro centralizzato, chia-

mato MOBY-Central, che tiene tutte le informazioni dei servizi registrati. Quindi,

la conoscenza è centralizzata, ma i servizi sono distribuiti.

In generale MOBY-Central è composto da quattro parti fondamentali:

White pages indica chi fornisce i servizi;

Yellow pages permette di classi�care i servizi;

Green pages indica come chiamare ciascun servizio;

MOBY pages permette, dato uno speci�co tipo di dato biologico (ad esempio un

genbank ID, un keyword o una sequenza), di trovare i servizi che prendono esso

come input o lo generano come output.

Saranno gli stessi fornitori dei servizi ad occuparsi della registrazione con MOBY-

Central includendo le seguenti infomazioni:


CAPITOLO 5. BIOMOBY

• Il nome del servizio.

• Il tipo del servizio, tra quelli indicati nella gerarchia Service-type.

• L'oggetto o gli oggetti input dal nome dell'Object-type della gerarchia.

• L'oggetto o gli oggetti output dal nome dell'Object-type della gerarchia.

• Un URI che identi�ca il fornitore del servizio.

• L'URL di dove risiede il servizio.

• Una descrizione in linguaggio naturale.

Considerando una richiesta dell'utente, MOBY-Central la comunica sotto for-

ma di Web Services Description Language (WSDL), il quale è generato da MOBY-

Central al volo. Tutte le informazioni necessarie per generare questo documento sono

presenti nella registrazione del servizio, e così né il fornitore del servizio, né il registro

dovranno memorizzare questo documento.

Al presente momento esso utilizza il suo proprio registro di sistema piuttosto che

un UDDI [DCvR].

Le API MOBY-Central correnti hanno tre tipi di chiamate: register/deregister,

locate e retrieve. La chiamata Registration include l'aggiunta di nuovi oggetti e tipi

di servizi, la registrazione di una nuova istanza di un servizio o la deregistrazione

di un servizio che non esiste più, che è stato modi�cato o che è stato rimosso. La

chiamata Locate ritorna una lista di istanze di servizi che incontrano certi requisiti.

La chiamata Retrieve permette una ricerca più generale sul contenuto del registro.


CAPITOLO 5. BIOMOBY

5.3 Comparazione con myGrid

Molti progetti sono emersi di recente e sottolineano vari aspetti su cui BioMOBY si

focalizza. La nostra trattazione si limiterà ad un confronto con myGrid [myg].

myGrid è un progetto fondato dal Engineering and Physical Sciences Research Coun-

cil e intende estendere la struttura distribuita di Grid attraverso l'uso dell'architet-

tura dei Web Services ed un sistema di discovery.

In rispetto alla scoperta dei dati e all'esecuzione dei servizi myGrid e BioMOBY

seguono lo stesso approccio, infatti, entrambi i progetti hanno simili idee per la

rappresentazione della conoscenza. myGrid, comunque, include tool che gestiscono

work�ow, la personalizzazione del repository dei dati e l'aggiornamento delle infor-

mazioni, tutte regole che non sono incluse nello scopo di BioMOBY.

Nonostante questo, i due progetti hanno sorprendentemente una visione simile ed

entrambi potranno bene�ciare nell'espandere una collaborazione che già è attiva

tra i partecipanti. In particolare, i due progetti adottono la stessa ontologia per

rappresentare una gerarchia dei servizi.

5.4 Il nostro MOBY-Central locale

Per capire cosa MOBY ci mette a disposizione e prendere mano con il sistema, ab-

biamo ritenuto opportuno istallare MOBY-Central in una postazione locale.

Questo ci ha permesso di analizzare nello speci�co i databases ed eseguire delle ope-

razioni su di essi. Ci siamo interfacciati al sistema attraverso il linguaggio Perl e per

prima cosa abbiamo e�ettuato la registrazione e la deregistrazione di alcuni MOBY-

Object e di alcuni namespace. Poi siamo passati ad eseguire le stesse operazioni sui

servizi. In�ne, abbiamo svolto vere e proprie interrogazioni al sistema e chiamate al

5.3 Comparazione con myGrid 105

CAPITOLO 5. BIOMOBY

servizio.

Di seguito vengono dettagiatamente descritti i passi da seguire per l'istallazione

e analizzare i databases presenti.

5.4.1 Istallazione

Ciò che abbiamo istallato nella nostra postazione locale è il MOBY-Central descritto

nel paragrafo 5.2.2. Al tal �ne viene utilizzato soltanto software Open Source facil-

mente scaricabile dalla rete.

Seguendo i seguenti step si può eseguire l'istallazione con successo.

PASSO I

Per prima cosa si richiede di eseguire nel PC l'istallazione di una distribuzione Linux.

Le sostanziali di�erenze tra le distribuzioni nascono con l'aggiunta di ulteriore soft-

ware per l'istallazione e per la gestione, supporto tecnico nonché materiale cartaceo

come manuali e documentazione di vario genere. E' di�cile, però, valutare questo

valore aggiunto e stabilire quale distribuzione possa essere migliore di un'altra visto

che ognuna ha una serie di caratteristiche proprie che la distinguono sotto l'aspetto

della sicurezza, della gestione o della facilità d'uso. Alla luce di quanto detto, abbia-

mo deciso di utilizzare la versione 9.0 della Red Hat per diversi motivi, tra i quali il

fatto che possiede il sistema rpm che gestisce in modo semplice i pacchetti software.

PASSO II

Successivamente si richiede di scaricare ed istallare mySQL (Linux x86 RPM down-

load).

• scaricare MySQL- server- 4.0.18-0.i386.rpm (server) da www.mysql.com;

• scaricare MySQL- client 4.0.18-0.i386.rpm (client programs) da www.mysql.com;

106 5.4 Il nostro MOBY-Central locale

CAPITOLO 5. BIOMOBY

• scaricare MySQL-devel-4.0.18-0.i386.rpm (Librieres and header �les) da

www.mysql.com;

• scaricare MySQL-shared-4.0.18-0.i386.rpm (dinamic client libreries) da

www.mysql.com;

• scaricare MySQL-shared-compat-4.0.18-0.i386.rpm (Dinamic client librieries)

da www.mysql.com;

• una volta svolte queste operazioni, si passa all'istallazione utilizzando il co-

mando rpm. Questo gestisce i pacchetti software organizzati secondo le speci-

�che del formato, che vengono indicati comunemente con l'estenzione �.rpm�.

L'opzione utilizzata nei comandi è �-i� che permette di installare un pacchetto

software nel sistema. L'opzione ��force� inoltre forza l'istallazione senza con-

trolli preventivi dei pacchetti esistenti o sui vincoli di dipendenza. I comandi

da eseguire sono i seguenti.

rpm -i MySQL-server-4.0.18-0.i386.rpm �force

rpm -i MySQL-client-4.0.18-0.i386.rpm �force

rpm -i MySQL-devel-4.0.18-0.i386.rpm �force

rpm -i MySQL-shared-4.0.18-0.i386.rpm

rpm -i MySQL-shared-compat-4.0.18-0.i386.rpm

A questo punto digitando mysql possiamo lavorare con la relativa shell.

PASSO III

Si richiede ora di istallare CPAN che è una raccolta moduli Perl.

1. istallare Bundle::CPAN con la seguente istruzione:

5.4 Il nostro MOBY-Central locale 107

CAPITOLO 5. BIOMOBY

perl -MCPAN -e 'install Bundle::CPAN'

Essa ci permette inoltre di installare LWP.

2. istallare HTML::Parser.

Dopo averlo scaricato da (http://search.cpan.org), decompresso con gunzip e

tar -xvf, entriamo nella cartella HTML-Parsen- 3.36 e digitiamo:

perl Mikefile.PL che comunica al sistema di lanciare l'interprete perl e di

passargli come input il contenuto del �le Mikefile.PL

make

make install

3. istallare Bundle::DBI con la seguente istruzione:

perl -MCPAN -e 'install Bundle::DBI'

4. istallare SOAP::Lite.

Dopo averlo scaricato da (http://www.soaplite.com/), decompresso con gunzip

e tar -xvf, entriamo nella cartella SOAP-Lite-0.60 e digitiamo:

perl Mikefile.PL

make

make install

5. istallare XML::DOM.

Dopo averlo scaricato da (http://search.cpan.org/ tjmather/XML-DOM-1.43/),

decompresso con gunzip e tar -xvf, entriamo nella cartella XML-DOM-1.43

e digitiamo:

perl Mikefile.PL


CAPITOLO 5. BIOMOBY

make

make install

6. istallare DBD::mysql Dopo averlo scaricato da (http://search.cpan.org/ rudy/

DBD-mysql-2.9003/), decompresso con gunzip e tar -xvf, entriamo nella

cartella DBD-mysql-2.9003 e digitiamo:

unset LANG

perl Mikefile.PL

make

make install

PASSO IV

Si richiede ora di veri�care, utilizzando l'istruzione which cvs, se con l'istallazione

della distribuzione Linux e�ettuata al Passo I il CVS è stato istallato. Il CVS è molto

utile perchè permette a più team di sviluppatori distribuiti di accedere a risorse che

si trovono sulla stessa macchina. Se non presente sopperire a questa mancanza.

Nel nostro caso era nella cartella: /usr/bin/cvs.

PASSO V

Passiamo ora ad impostare la variabile di ambiente, che è un'informazione utile alla

sessione shall dell'utente, digitando il seguente comando.

set CVS_RSH=ssh

In questo modo si speci�ca al CVS che si vuole usare ssh, cioè una shell sicura, per

accedere al repository remoto.

PASSO VI

Giunti a questo punto iniziamo l'istallazione di MOBY CODE.


CAPITOLO 5. BIOMOBY

1. Si richiede per prima cosa di eseguire una procedura di login sul server CVS

speci�cando l'opportuna password e successivamente di eseguire un controllo

di CVS moby-live in /moby-live. Il tutto è fatto attraverso i seguenti comandi:

cvs -d :pserver:[email protected]:/home/repository/moby login

Utilizzare la password 'cvs'

cvs -d :pserver:[email protected]:/home/repository/moby checkout

moby-live

cvs update -dP

2. Si passa poi all'istallazione del MOBY Perl Code.

Si deve entrare nella cartella moby-live/perl e digitare le seguenti istruzioni:

perl Mikefile.PL

make

make install

PASSO VII

Successivamente si richiede di istanziare tutti i MOBY CENTRAL DATABASES.

Dopo essere entrati in mysql come root, bisogna creare cinque database (mobycen-

tral, mobyobject, mobynamespace, mobyservice, mobyrelationship) con la seguente

istruzione.

CREATE DATABASES nomedatabase ;

PASSO VIII

Si passa ora alla creazione di un utente per il MOBYCENTRAL DATABASE digi-

tando il comando sottostante.


CAPITOLO 5. BIOMOBY

• GRANT ALL PRIVILEGES ON [each database] TO moby central@localhost

identified by *********;

La psw usata (a posto degli asterischi) per noi è bachi04

• Con la seguente istruzione, exit mysql, si esce dalla shell di MySQL.

• Per ogni database digitare il seguente comando sostituendo a databasename il

nome del database.

mysql -u moby central -p databasename <

/moby-live/Database/databasename.mysql

PASSO IX

IMPOSTA MOBY CENTRAL CGI SUL WEBSERVER. Sapendo che la directory

cgi-bin è nella cartella /var/www/ digitare le seguenti istruzioni che ci permetteno nel

primo caso di copiare il �le MOBY-Central.pl, preservando l'originale, nella cartella

/var/www/cgi-bin e se in quest'ultima è già presente un �le con lo stesso nome, esso

viene sovrascritto e nel secondo caso si attiva la modalità ricorsiva che permette la

copia di directory.

cp /moby-live/Perl/scripts/MOBY-Central.pl /var/www/cgi-bin

cp -r /moby-live/Perl/MOBY /var/www/cgi-bin

Modi�care, inoltre, il �le httpd.conf (/etc/rc5.d/etc/httpd/var/www/) che dovrà

contenere le seguenti variabili di ambiente. Esse devono essere settate per la nostra

con�guarazione come segue.

• SetEnv MOBY_CENTRAL_URL localhost

• SetEnv MOBY_CENTRAL_DBNAME mobycentral

• SetEnv MOBY_CENTRAL_DBUSER moby_central


CAPITOLO 5. BIOMOBY

• etEnv MOBY_CENTRAL_DBPASS *********

• SetEnv MOBY_CENTRAL_DBPORT 3306

In�ne, per rendere attive le modi�che, riavviare Apache.

PASSO IX

In ultimo, si richiede di CONFIGURARE IL CLIENT PROGRAM digitando le

seguenti istruzioni. Sottoliniamo tuttavia che lo svolgimento di questo passo è

opzionale.

export MOBY_SERVER=http://localhost/cgi-bin/MOBY-Central.pl

export MOBY_URI=http://localhost/MOBY/Central

A QUESTO PUNTO L'INSTALLAZIONE E' TERMINATA

Procediamo eseguendo il test del sistema digitando le seguenti istruzioni:

cd /Perl/script/ perl testMOBYClientCentral_v05.pl

Se il test da risultato positivo si può iniziare a lavorare con il sistema.

5.4.2 DataBase

BioMOBY organizza il suo repository in cinque database relazionali: mobycentral,

mobyobject, mobynamespace, mobyservice e mobyrelationship. Essi sono mostrati

nelle Figure 5.4.2, 5.4.2, 5.4.2, 5.4.2 e 5.4.2.

Da sottolineare è il fatto che l'istallazione di MOBY ci permette solo di disporre

della struttura dei database e non dei loro contenuti. Occorre quindi e�ettuare l'o-

perazione di riempimento degli stessi. Questo può essere fatto o inserendo uno ad

uno i servizi che si hanno a disposizione o scaricando il DUMP da BioMOBY.

Noi abbiamo deciso di seguire questa seconda opportunità e abbiamo svolto la

seguente procedura.


CAPITOLO 5. BIOMOBY

Figura 5.3: Schema database mobycentral

Figura 5.4: Schema database mobynamespace


CAPITOLO 5. BIOMOBY

Figura 5.5: Schema database mobyobject

Figura 5.6: Schema database mobyservice

Figura 5.7: Schema database mobyrelationship


CAPITOLO 5. BIOMOBY

1. Per prima cosa abbiamo istallato la java virtual machine e impostato la va-

riabile di ambiente PATH nel �le .basch_pro�le. Poi abbiamo riavviato la

macchina per rendere attive le modi�che.

2. Abbiamo poi, nella cartella /moby-live/Java, compilato le librerie Java con

l'istruzione ./build.sh.

3. In�ne, abbiamo lanciato la seguente comando per editare il �le moby.sql:

./run-cmdline-client -call DUMP > moby.sql

A causa di un bug bisogna modi�care il �le moby.sql inserendo l'istruzione use

databasename prima di utilizzare le rispettive tabelle che saranno riempite digitando

il comando source moby.sql nella shell di mysql.

Da considerare è il fatto che ripetere questa istruzione a distanza di poco tempo

provoca DUMP diversi, questo perchè il sistema è in continuo aggiornamento.

5.5 Servizi preseti

BlastFastaVsArabiProteincoding: blast Fasta sequence against MAtDB Arabidopsis

protein coding genes

BlastRawSeqVsArabiContigs: blast raw sequence against MAtDB Arabidopsis Con-

tigs

BlastRawSeqVsArabiProteincoding: blast raw sequence against MAtDB Arabidopsis

protein coding genes

CorrelatedCoexpression: Returns genes which have a correlation coe�cient, R >

0.7, for the Cho two-cell-cycle data set in yeast. This service is under development,

so availability may be sporadic initially.

5.5 Servizi preseti 115

CAPITOLO 5. BIOMOBY

extractGeneProteinNames: Takes any text (abstract, full text article, etc.) and ex-

tracts names and abbreviations of genes and proteins, with a score (0-1, with 1 being

highest).

fetchAgDoc: Get Agricola document in MEDLINE like format for given Agricola

accession number.

fetchAgID : Search Agricola for given query and get Agricola accession numbers.

FetchFull : Get FullText for given PMID.

GavinSpoke: unstable; under development; subject to rede�nition or deregistration

without notice; please do not use.

GavinSpokeDev : unstable; under development; subject to rede�nition or deregistra-

tion without notice; please do not use.

GbrowseGetReferenceFasta: consumes EMBL id and returns a FASTA object.

getAGILocusCodes:returns a collection of AGI_LocusCodes.

getAlleleFreq : getAlleleFreq.

getArabidopsisImage_by_NASC: Retrieves Arabidopsis Image by NASC code.

getContigsByFreeText : Retrieves contig list for a keyword from MAIZE database.

getContigsByName: Retrieves contig list for a contig name(as keyword) from MAIZE

database.

getDragonLocusAlleles: Retrieves collection of Antirrhinum alleles for a given Locus.

getDragonSimpleAnnotatedImages: Retrieves image collections of Antirrhinum mu-

tants based on their Allele designation.

getElement : Retrieves details about an element with name(as keyword) from MAIZE

database.

getElementsByFreeText : Retrieves element list from MAIZE database by freetext or

keyword.

116 5.5 Servizi preseti

CAPITOLO 5. BIOMOBY

getElementsByName: Retrieves element list from MAIZE database by name.

getElementsForContig : Retrieve elements list from MAIZE database for a contig

name.

getElementsOfType: Retrieve elements list for an element type(as keyword) from

MAIZE database.

getEmblAccession:returns collection of EMBL Accessions.

getEmblDNASequence:returns collection of EMBL DNA Sequences.

getGenotypes: getGenotypes.

getGoTerm: takes a Gene Ontology accession number and returns the term name

and de�nition as a GO_Term object.

getGoTermAssociations: takes a GO term id and retrieves a collection response of

all gene products annotated to that object.

getGOTermsByAGICode: takes an AGI code and returns a collection of GO terms.

getInsertionNamesByAGICode: returns the names of gene insertions by AGI locus

code.

getInsertionsAsGFFByAGICode: returns the gene insertions by AGI locus code in

GFF format.

getInteractingMethods: It returns a list with the di�erent methods where a protein

ID is interacting.

getInteractionMethodDesc: It returns the interaction method's description.

getInteractions: It returns a list with the di�erent interactions where a protein ID is

interacting.

getInteractionsXML: It returns a list with the di�erent IntAct_XML interactions

where a protein IDs is interacting.

getKnownRegulatorsAndTargets: Given a yeast gene/protein identi�er, return known


CAPITOLO 5. BIOMOBY

regulators and targets.

getMIPSArabidopsisProteinSequence:returns collection of MIPS Arabidopsis protein

sequences.

getMIPSCodingCoordinates: gets MIPS Coding Coordinates.

getMIPSFastaProteinSequence: gets MIPS Arabidopsis Protein Sequence in FASTA

format.

getNASC_codebyAGI_locus:Retrieves NASC codes using AGI LocusCodes as input.

getNASC_codebyKeyword :Retrieves NASC codes associated with a Keyword.

getPBfromGO : consumes a Gene Ontology accession number and returns a collection

of associated Pathbase accession numbers.

getPhenotype_by_Keyword : Retrieves all Arabidopsis Phenotypes associated with

a Keyword.

getPhenotype_by_NASC : Retrieves Arabidopsis Phenotype by NASC code.

getPredictedRegulatorsAndTargets: Given a yeast gene/protein identi�er, return pre-

dicted regulators and targets, from Qian et al., Bioinformatics v19, pp1917-1926

(2003).

getProteinSequence: Retrieves Protein sequence for an element (as keyword) from

MAIZE database.

GetPubmed : Retrieve PubMed articles in MEDLINE display format for given PMIDs

getSequenceByAGI takes an AGI_LocusCode and returns the Arabidopsis Protein

Sequence.

GetSGNUnigene: Takes an SGN EST ID and returns unigene data.

getSHound3DNeighboursFromGi : Retrieves a list of protein BLAST neighbours pos-

sessing 3-D structure. Uses redundancy information for the query protein. The

BLAST protein neighbours were calculated using 0.01 maximum E-value cuto�.


CAPITOLO 5. BIOMOBY

getSHoundDNAFromOrganism: Retrieves collection of GI numbers representing a

non-redundant set of all genbank genomic DNA entries for the genome identi�ed by

that taxon identi�er.

getSHoundDNAFromTaxID : Retrieves collection of GI numbers representing all gen-

bank DNA entries for the given taxon identi�er.

getSHoundGODBGetChildrenOf : This function operates on Gene Ontology (GO)

vocabulary graphs. It retrieves a list of processes, functions or components situated

directly below a given GO identi�er in the graphs.

getSHoundGODBGetParentOf : This function operates on Gene Ontology (GO) vo-

cabulary graphs. It retrieves a list of processes, functions or components situated

directly above a given GO identi�er in the graphs.

getSHoundNeighboursFromGi : Retrieves a collection of protein BLAST neighbours.

Uses redundancy information for the query protein. The BLAST protein neighbours

were calculated using 0.01 maximum E-value cuto�.

getSHoundProteinFromOrganism: Retrieves collection of GI numbers representing a

non-redundant set of all genbank Protein entries for the genome identi�ed by that

taxon identi�er. Only works for completed genomes.

getSHoundProteinsFromTaxID : Retrieves collection of GI numbers representing all

genbank protein entries for the given taxon identi�er.

getSplicedSequence: Retrieves Spliced sequence for an element (as keyword) from

MAIZE database.

getTargetPResultByTranscriptCode:takes an AGI_TranscriptCode and returns a Tar-

getP_result

getTaxChildNodes: takes an NCBI taxon ID and returns a collection of taxon id's

that are children of this node in the taxonomic hierarchy.


CAPITOLO 5. BIOMOBY

getTaxNameFromTaxID : takes an NCBI taxon ID and returns the scienti�c name

for the organism represented by that taxon id in NCBI's taxonomy.

getTaxParent : wraps the SeqHound SHoundGetTaxParent function. Takes an NCBI

taxon ID and returns the taxon ID of the parent taxonomic node.

getTestMessage: takes a object and returns a string.

getTranscriptCodesByAGICode: returns the codes identifying transcripts belonging

to the AGI locus code.

getTranscriptSequenceByTranscriptCode: returns the sequence identi�ed by the in-

put transcript code.

getUnsplicedSequence: Retrieves Unspliced sequence for an element (as keyword)

from MAIZE database.

get_ATH_insert_by_EMBL: Retrieves unique Arabidopsis Insert Number by EM-

BL Accession.

get_ATH_insert_by_NASC_code: Retrieves unique Arabidopsis Insert Number by

NASC_code.

get_insert_names_by_AGI : Retrieves all Arabidopsis inserts on a gene by AGI Lo-

cus Code.

GI2Scienti�cName: Get the scienti�c name corresponding to GenBank GI.

Giot : unstable; under development; subject to rede�nition or deregistration without

notice; please do not use.

GiotDev : unstable; under development; subject to rede�nition or deregistration with-

out notice; please do not use.

Homology : Genes are considered to interact when they share homology at the level

of BLAST E-value=1e-6 or better.

keywordToGene: Test service: matches gene symbol to RGD gene record, if avail-


CAPITOLO 5. BIOMOBY

able.

LookupYeastNames: Input is a gene name, in any common format: ORF, standard

names, or alias. Output is all names for input gene. This service provides a way

to look up the possible names for a gene, given its name in one of the common

naming schemes. Data returned are: Standard_Name, ORF_Name, SGD_ID, (one

or more) Alias(es). THIS SERVICE IS UNDER ACTIVE DEVELOPMENT. IT

SHOULD NOT BE RELIED ON FOR CORRECTNESS OR AVAILABILITY.

Melting : Melting: enthalpie, entropy and melting temperature (N. Le Novere).

MIPSBlast : executes blast against MAtDB Arabidopsis protein coding genes.

MOBYSHoundGetGenBankFasta: consumes a NCBI_Acc, NCBI_gi, PIR, Swis-

sProt, Embl, or PDB identi�er and returns the equivalent genbank record as a FAS-

TA object.

MOBYSHoundGetGenBank� : consumes a NCBI_Acc, NCBI_gi, PIR, SwissProt,

Embl, or PDB identi�er and returns the equivalent genbank record as a genbank-

�at�le object.

MOBYSHoundGetGenBankVirtSequence: consumes a NCBI_Acc, NCBI_gi, PIR,

SwissProt, Embl, or PDB identi�er and returns the equivalent genbank record as a

VirtualSequence object (i.e. only the sequence length).

MOBYSHoundGetGenBankWhateverSequence: consumes a NCBI_Acc, NCBI_gi,

PIR, SwissProt, Embl, or PDB identi�er and returns the equivalent genbank record

as a DNA, RNA, AminoAcid sequence object as appropriate.

MtKeyword : Get accession of all Mt entries with <keyword> connection.

parseFromIntAct : Translates from IntAct XML format to BioMoby interaction for-

mat.

PBI_Cluster_Blast : runs the NCBI Blast program with default parameters against


CAPITOLO 5. BIOMOBY

the nt or nr databases (depending on the query sequence) on the 16 node beowulf

cluster at PBI-NRC.

PBI_Parse_Blast : Parses a Blast Text report and retrieves the GI numbers for

every hit as Base MOBY Objects.

PDBtoMotifID : Takes a PDB id and returns all associated Schematikon Motif IDs.

PDBtoSegmentID : Takes a PDB id and returns all associated Schematikon Segment

IDs.

plantspGetDNA: Retrieves a DNA sequence from the PlantsP database (proteins re-

lated to phosphorylation, transporters and ubiquitin).

plantspGetProtein: Retrieves a protein sequence from the PlantsP database (pro-

teins related to phosphorylation, transporters and ubiquitin).

plantspGetRNA: Retrieves a RNA sequence from the PlantsP database (proteins re-

lated to phosphorylation, transporters and ubiquitin).

ProtoServiceDev : unstable; under development; subject to rede�nition or deregistra-

tion without notice; please do not use.

RetrieveGOFromKeywords: takes a keyword as input and returns a collection of GO

terms that are associated with that keyword.

RetrieveMotifNeighbours: Takes a Schematikon structure motif ID and returns a list

of neighbouring segments within 0.2 angstrom RMSD.

RetrieveMotifSupport : Takes a Schematikon structure motif ID and returns support

and unique support for that motif.

RetrieveMotifVoronoiNeighbours: Takes a Schematikon structure motif ID and re-

turns a list of neighbouring segments within the Voronoi domain of the motif.

RetrieveSegmentAttributes: Takes a Schematikon structure segment or structure mo-

tif ID and returns its attributes (PDB id, chain ID, chain position (starting residue),


CAPITOLO 5. BIOMOBY

insert code, length).

RetrieveStructureAnnotation: Takes a Schematikon structure segment or structure

motif ID and returns DSSP, STRIDE, and PROMOTIF annotations.

RetrieveStructureSegmentAminoAcidSequence: Takes a Schematikon structure seg-

ment or structure motif ID and returns amino acid sequence.

RetrieveVorocodeName: Takes a Schematikon structure segment or structure motif

ID and returns Vorocode-Name.

run_ntBlast :uses the Parablast server at the University of Calgary Sun Centre of

Excellence to execute a blastn against the genbank nt database with default para-

meters.

run_PFamHMM : Decypher hardware search service: formats alignment result in

Decypher_Text format.

SearchPubmed : Search PubMed for given query and get PMIDs.

SequenceToFASTA: Converts a GenericSequence or better to a FASTA.

SyntheticLethal : Returns genes which may have synthetic lethal relationship with

query genes (yeast only). Service currently under development, availability may be

sporadic.

test3_SequenceToFASTA: Example service: formats a sequence in FASTA format.

test_SequenceToFASTA: Example service: formats a sequence in FASTA format.

test_SequenceToFASTA: Example service: formats a sequence in FASTA format.

test_u26230 : Test service.

text2accn: Provide NCBI/EMBL/DDBJ accessions for a word.


Capitolo 6

Caso di Studio

Consapevoli delle conoscenze �no ad ora acquisite, che ci permettono di avere una

visione generale del problema e un'analisi dettagliata dello strumento che si vuole

utilizzare, passiamo a descrivere il nostro prototipo che sfrutta le informazioni fornite

da BioMOBY e il livello semantico che le ontologie sono capaci di fornire.

In uno scenario dove si richiede la riduzione dei costi di sviluppo e di ammin-

istrazione, l'interoperabilità con gli attuali sistemi e un certo livello di sicurezza, il

nostro obiettivo è realizzare un Multi Agent System (MAS) [JSW98], il cui model-

lo di coordinazione è ispirato al Matchmaker [PSNS], che permette il discovery del

servizio biomedico capace di soddisfare le richieste degli utenti.

Il percorso che si andrà a seguire mette in luce tutte le tappe intermedie che

hanno portato al lavoro �nale.

Nel primo paragrafo è descritta l'architettura generale del prototipo sottolineando il

modello di coordinazione degli agenti. Nel secondo paragrafo presentiamo il proto-

collo di comunicazione che gli agenti seguono attraverso l'uso dell'ontologia da noi

disegnata. Nel terzo paragrafo verranno analizzati nello speci�co tutti gli attori del

125

CAPITOLO 6. CASO DI STUDIO

sistema ed in�ne nel quarto paragrafo si speci�ca cos'è per noi la qualità, e come

essa viene integrata nel nostro sistema.

Per una maggiore comprensione del tutto, abbiamo deciso di utilizzare i diagram-

mi AUML [OPB00], un'estenzione dell'UML. Questo strumento propone formalismi

per modellare numerose caratteristiche tipiche degli agenti.

6.1 Architettura e modello di coordinazione

Per prima cosa, andiamo ad analizzare un �mondo� dove più agenti comunicano e si

scambiamo informazioni. In questo contesto vogliamo posizionare i nostri agenti e

solo attraverso un attenta analisi dell'architettura generale descritta in Figura 6.1,

possiamo dar loro un ruolo ed un compito.

Scendendo più in particolare andiamo a descrivere la nostra architettura, mostra-

ta in Figura 6.2. In essa possiamo individuare i diversi componenti del sistema e la

loro interazione. L'elemento centrale rappresenta la Knowledge base del nostro MAS

e interagisce con tre �mondi� distinti: uno che permette di arricchire la conoscenza

del sistema realizzando il discovery di nuovi servizi biomedici, uno che permette di

quali�carlo ed in�ne uno che realizza l'applicazione dal lato utente per la ricerca di

servizi che rispondono a determinate caratteristiche.

Il modello di coordinazione del nostro sistema, che riassume ad alto livello l'in-

terazione tra le parti, è mostrato in Figura 6.3.

Gli attori che entrano in gioco, sono di due tipi: Executor Agents e User Agents.

Tra gli Executor Agent possiamo individuare il BioMobyServiceAgent che funge

da colonna portante al sistema in quanto ad esso fanno riferimento tutti gli altri

agenti. Della stessa categoria è il BioMobyDiscoverServiceAgent che interagisce

126 6.1 Architettura e modello di coordinazione


Figura 6.1: Architettura Generale

6.1 Architettura e modello di coordinazione 127


Figura 6.2: L'architettura del nostro prototipo



Figura 6.3: Modello di coordinazione

6.1 Architettura e modello di coordinazione 129


direttamente con la base di conoscenza di MOBY e passa al BioMobyServiceAgent

tutte le informazioni dei servizi disponibili permettendo a quest'ultimo di crearne

un mirror. La sua funzionalità è duplice: da un lato rappresenta un meccanismo di

discovery per il BioMobyServiceAgent, permettendo di incrementare il sapere dello

stesso, dall'altro realizza una reclamizzazione dei servizi registrati in MOBY-Central,

rendendoli così visibili agli altri agenti.

Tra gli User Agents troviamo BioMobyApplicationAgent che permette all'utente,

che ha l'esigenza di ricercare un determinato servizio biomedico, di interfacciarsi con

il mirror dei servizi presenti nel BioMobyServiceAgent che seleziona il servizio che

meglio incontra la richiesta. Questo processo di selezione segue un modello di qualità

studiato appositamente che prende in considerazione precisi parametri biomedici e

tecnologici. Questo argomento verrà trattato in dettaglio nel paragrafo 6.4. In�ne,

abbiamo QualityServiceAgent che è un agente di sistema e funge da certi�catore.

Esso permette di aumentare il livello di qualità di un dato servizio distinguendolo da

uno non certi�cato. La motivazione che ci ha spinto ad inserire questo attore verrà

spiegato nei paragra� 6.3.4 e 6.4.

Passando ad analizzare la comunicazione che si realizza nel nostro sistema, possia-

mo individuare come i vari agenti interagiscono tra loro con un protocollo di richiesta

e risposta sfruttando la capacità descrittiva delle ontologie.

Come mostrato nella Figura 6.4 possiamo notare che per prima cosa s'instaura la

comunicazione tra l'agente di sistema DF, presentato nel Capitolo relativo a JADE,

e il nostro BioMobyServiceAgent. In questo modo il nostro agente si registra nel DF

rendendosi visibile ad agenti di diverse piattaforme e permettendo loro di individuarlo

per poi instaurare una comunicazione diretta. Ne deriva che tutti gli altri attori prima

si mettono in contatto con il DF e poi con il BioMobyServiceAgent.



Figura 6.4: Sequence diagram che mostra la comunicazione tra gli agenti

Giunti a questo punto e avendo fornito una panoramica generale, nei prossimi

paragra� analizzeremo in speci�co il protocollo di comunicazione tra i singoli attori

e il loro comportamento.

6.2 Protocollo di comunicazione:

MOBYOntology e MOBYVocabulary

Il nostro lavoro è partito realizzando un livello di comunicazione basato su scambio di

messaggi in formato String, evolvendosi �no ad un punto in cui si è sentita l'esigenza

di inserire come supporto i linguaggi di contenuto e le ontologie.

Abbiamo quindi utilizzato i concetti descritti nel Capitolo 4 relativo a JADE.

Questi strumenti ci permettono di e�ettuare automaticamente le conversazioni

6.2 Protocollo di comunicazione:MOBYOntology e MOBYVocabulary

131


e le operazioni di veri�ca di conformità alle regole di una certa ontologia condivisa

dagli agenti, consentendoci così di manipolare le informazioni come oggetti Java,

senza il bisogno di lavori extra. Per una migliore comprensione si può osservare la

Figura 6.5.

Figura 6.5: Conversione delle informazioni

Le conversazioni e le operazioni di veri�ca a cui si fa riferimento all'inizio del

paragrafo sono e�ettuate da un gestore di contenuto (un oggetto content manager,

istanza della classe ContentManager). Ciascun agente JADE include un gestore di

contenuto, accessibile attraverso il metodo getContentManager() della classe Agent,

che fornisce i metodi necessari per trasformare gli oggetti Java in stringhe (o sequen-

ze di bytes) e per inserire quest'ultime nel contenuto (lo slot content) del messaggio

ACL. In aggiunta sono forniti i metodi necessari ad e�ettuare l'operazione inver-

sa. Inoltre, il gestore del contenuto provvede alle interfacce per accedere alle varie

funzionalità di conversazione, delegando le operazioni di comunicazione e di veri�ca

ad un'ontologia (cioè un'istanza della classe Ontology) e ad un codec di linguaggio

di contenuto (cioè un'istanza dell'interfaccia Codec). Più in dettaglio, l'ontologia

132 6.2 Protocollo di comunicazione:MOBYOntology e MOBYVocabulary


convalida le informazioni da convertire dal punto di vista semantico, mentre il codec

e�ettua la conversione in stringhe (o sequenza di bytes) in accordo con le regole

sintattiche del relativo linguaggio di contenuto.

I nostri quattro agenti usano un'interfaccia comune MOBYVocabulary che de�nisce

le constanti che rappresentano i termini che costituiscono le speci�che del linguaggio

dei nostri agenti.

La conversazione tra due agenti del nostro sistema segue un semplice protocollo.

Ad esempio, per richiedere un servizio biomedico l'agente BioMobyApplicationAgent

invia un messaggio di tipo REQUEST all'agente BioMobyServiceAgent che, dopo

aver processato la richiesta, risponde con un messaggio di tipo INFORM, se la

transazione è andata a buon �ne, o con un messaggio di tipo NOT UNDERSTOOD,

se non è riuscito a codi�care il contenuto del messaggio. Questo è in accordo con lo

standard FIPA ed è mostrato nella Figura 6.6

Figura 6.6: protocollo di comunicazione

Nel modellare l'interazione tra i vari agenti è utile identi�care concetti pertinen-


133


ti, che implementano l'interfaccia Concept, e azioni, che implementano l'interfaccia

AgentAction, de�nendo questi come classi. Di seguito elenchiamo le classi che sono

usate dalla nostra applicazione:

Memo concetto di mirror dei servizi di MOBY.

Registra azione di registrazione nel mirror del servizio recuperato da MOBY-Central.

RegistraQualità azione di registrazione nel mirror del livello di qualità del servizio

speci�cato.

Richiesta azione di richiesta di un servizio con speci�cate caratteristiche.

Modi�ca azione di modi�ca di un servizio nel mirror.

Deregistra azione di cancellazione di un servizio nel mirror.

Risposta concetto che rappresenta il risultato dell'operazione processata.

Ora analizzeremo i singoli passi che ci permettono di de�nire una speci�ca on-

tologia esaminando l'esempio di richiesta di un servizio biomedico.

Per prima cosa si de�nisce il vocabolario del nostro spazio di comunicazione degli

agenti. Nella classe MOBYVocabulary noi abbiamo le seguenti righe di codice che

de�niscono la terminologia coinvolta nel concetto di fare una richiesta:

public interface MOBYVocabulary

{

...

public static final String RICHIESTA = "richiesta";

public static final String RICHIESTA_NOME = "nome";

public static final String RICHIESTA_TIPO = "tipo";



...

}

Successivamente abbiamo de�nito una classe java che speci�ca la struttura e la

semantica dell'oggetto Richiesta. Sotto è mostrata la classe Richiesta dove abbiamo

seguito l'usuale pratica Object Oriented per dichiarare gli attributi della classe e

aggiungere i metodi get and set che permettono di accedevi.

public class Richiesta implements AgentAction

{

...

private String nome;

private String tipo;

...

public String getNome() {

return nome;

}

public void setNome(String nome) {

this.nome = nome;

}

public String getTipo() {

return tipo;

}

public void setTipo(String tipo) {

this.tipo = tipo;

}


135


...

}

Porgiamo l'attenzione sul fatto che la scelta dei nomi degli attributi dei nostri

oggetti e dei corrispondenti metodi get e set non è causale. Infatti, devono imperati-

vamente combaciare i nomi che sono stati dati a questi attributi quando de�niti nel

vocabolario.

Per esempio, nel vocabolario noi abbiamo deciso che il nome per l'elemento RICHIE-

STA_NOME è �nome�. Così nella classe java, il nome dell'attributo deve essere nome

e i corrispondenti metodi get e set devono essere getNome() e setNome(). Questo

è un importante punto da conoscere perchè durante l'operazione di riempimento

del contenuto del messaggio, il content manager prima legge l'attributo nome che

è associato con la classe Richiesta, e poi cerca nell'ontologia, sotto lo schema di

Richiesta, l'elemento identi�cato dal nome �nome� nel vocabolario. Se non trovato

viene generata un'eccezione.

De�niamo ora lo schema dell'oggetto. Nella classe MOBYOntology troviamo le

seguenti linee di codice che speci�cano lo schema del concetto Richiesta.

public class MOBYOntology extends Ontology implements

MOBYVocabulary {

// ----------> The name identifying this ontology

public static final String ONTOLOGY_NAME = "Moby-Ontology";

// ----------> The singleton instance of this ontology

private static Ontology instance = new MOBYOntology();

// ----------> Method to access the singleton ontology object

public static Ontology getInstance() {



return instance;

}

// Private constructor

private MOBYOntology() {

super(ONTOLOGY_NAME, BasicOntology.getInstance());

try {

// ------- Add Concepts

...

// ------- Add AgentActions

...

// Richiesta

add(cs = new AgentActionSchema(RICHIESTA), Richiesta.class);

cs.add(RICHIESTA_NOME,

(PrimitiveSchema) getSchema(BasicOntology.STRING),

ObjectSchema.OPTIONAL);

cs.add(RICHIESTA_TIPO,

(PrimitiveSchema) getSchema(BasicOntology.STRING),

ObjectSchema.OPTIONAL);

...

} catch (OntologyException oe)

{ oe.printStackTrace(); }

}

}// MOBYOntology

Da evidenziare è il fatto che il costrutto della nostra classe ontologica deve es-

sere de�nito con accesso privato e includere il metodo getIstance() che è pubblico e


137


statico. Esso viene chiamato dai nostri agenti quando vogliono fare riferimento ad

una singola istanza della classe ontologica.

Nella classe AgentActionSchema abbiamo settato diversi metodi add(), alcuni dei

quali sono ereditati dalla classe ConceptSchema che essa eredita. Questi metodi per-

mettono di aggiungere allo schema dell'oggetto, che abbiamo de�nito, gli elementi

che sono usati come slot dal content manager quando riempie il contenuto del mes-

saggio.

Nel nostro caso il metodo add() prende tre argomenti:

• il nome dello slot da aggiungere;

• lo schema dello slot;

• l'opzionalità.

Quest'ultima può assumere due valori: MANDATARY, che indica che lo slot non

può essere nullo, o OPTIONAL nel caso contrario. Di conseguenza se si speci�ca

l'obbligatorietà, questo elemento deve essere imperativamente provvisto quando si

setta il valore dell'attributo corrispondente nella classe java. D'altra parte se si

speci�ca l'opzionalità si può omettere il valore di questo slot.

A questo punto siamo pronti ad usare la nostra ontologia per modellare la comu-

nicazione tra gli agenti.

6.3 Agenti e Behaviours

In questo paragrafo ci occupiamo di analizzare nello speci�co il comportamento di

ogni singolo agente. Vengono messi in evidenza i dettagli dei processi che si veri�cano

138 6.3 Agenti e Behaviours


partendo da un alto livello d'astrazione e operando un'analisi top-down mettendo in

luce i vari concetti presenti.

Comune a tutti gli agenti sarà l'uso dell'ontologia di cui abbiamo parlato nel

paragrafo precedente. Infatti, in ciascuna classe abbiamo come prima cosa registrato,

con il content manager dell'agente, l'ontologia e il linguaggio che sarà usato per

assemblare, codi�care e decodi�care il contenuto del messaggio. Nel nostro caso

utiliziamo un linguaggio di codi�ca il quale è implementato in JADE attraverso la

classe SLCodec e l'ontologia è naturalmente la nostra MOBYOntology.

Le seguenti righe di codice mostrano come registrare il linguaggio e l'ontologia.

public class MOBYServerAgent extends Agent implements

MOBYVocabulary {

...

private Codec codec = new SLCodec();

private Ontology ontology = MOBYOntology.getInstance();

protected void setup() {

// Register language and ontology

getContentManager().registerLanguage(codec);

getContentManager().registerOntology(ontology);

...

}

...

}

6.3 Agenti e Behaviours 139


6.3.1 BioMobyServiceAgent

Il BioMobyServiceAgent è l'attore principale in quanto la sua presenza è di fonda-

mentale importanza nel sistema. Il suo compito non si limita a una semplice funzione

di comunicazione, in quanto interagisce attivamente con gli altri, ma rappresenta sia

la Knowledge base del nostro MAS, cioè il mirror delle informazioni di BioMOBY,

sia il sistema di discovery di qualità.

Tutta la conoscenza viene stabilmente memorizzata in una HashMap dove si

replicano tutte le informazioni presenti nel database di MOBY Central e ritenute

utili per e�ettuare un discovery di qualità.

Tra queste informazioni possiamo trovare: nome, tipo, autority, wsdl, descrizione,

url, ecc.

Nella Figura 6.7 è mostrato il comportamento interno dell'agente analizzato, che

non appena viene creato, si registra nell'agente DF della sua piattaforma. Il tutto

avviene tramite la chiamata della classe RegisterInDF che estende un OneShotBehaviour

e implementa la classe MOBYVocabulary.

In generale un agente che desidera pubblicare uno o più servizi deve fornire al DF

una descrizione che include il suo AID, possibilmente la lista di linguaggi e ontolo-

gie che altri agenti necessitano di conoscere per interagire con esso e la lista dei

servizi pubblicati. Per ciascun servizio pubblicato viene fornita una descrizione che

include il tipo, il nome e il proprietario del servizio. Le classi DFAgentDescription,

ServiceDescription e Property rappresentano le tre astrazioni menzionate. Inol-

tre, per pubblicare un servizio un agente deve creare un proprio descrittore (istan-

za della classe DFAgentDescription) e chiamare il metodo register() della classe

DFService. Il codice sottostante rappresenta in pratica quanto detto.



Figura 6.7: BioMobyServiceAgent



DFAgentDescription dfd = new DFAgentDescription();

dfd.setName(pippo.getAID());

ServiceDescription sd = new ServiceDescription();

sd.setType(SERVIZI);

sd.setName(BIOMOBY);

sd.setOwnership("BaChi");

Non appena completata la registrazione nel DF l'agente BioMobyServiceAgent

si mette in attesa continua di ricevere messaggi, che possono provenire da più agenti,

attraverso l'utilizzo di un cycling behaviour. In quest'ultimo l'agente veri�cherà la

consistenza del messaggio e la classe di appartenenza, tramite la quale, distinguerà

e tratterà in modo opportuno le diverse tipologie dei messaggi entranti utilizzando

distinti behaviour. Nel caso in cui il messaggio non è un'istanza di una delle classi

che caratterizza la comunicazione tra gli agenti, ritornerà al richiedente l'indicazione

dell'errore.

Nel caso in cui si richiede una registrazione, e quindi si lavora con un'istanza

della classe Registra, l'attività del BioMobyServiceAgent, riassunta nella Figura

6.7 come elabora informazione, si sviluppa in una registrazione nella HashMap che

rappresenta il supporto alla memorizzazione dei servizi con l'utilizzo del concetto

Memo. Il codice sottostante descrive il tutto.

...

Memo mem = new Memo();

mem.setNome(reg.getNome());

mem.setTipo(reg.getTipo());

...



memoMap.put(reg.getNome(), mem);

...

Nel caso in cui si richiede una modi�ca, e quindi si lavora con un'istanza della

classe Modifica, l'attività del BioMobyServiceAgent si realizza come un aggiorna-

mento della HashMap con le nuove informazioni che il richiedente ha fornito.

Dopo un breve studio, abbiamo considerato opportuno che il processo di modi�ca

avvenga s'unico campo, cioè quello contenente il WSDL del servizio. Questa scelta

deriva da due motivi: da un lato non avrebbe senso modi�care gli altri campi perchè

porterebbe ad un diverso servizio e in questo caso sarebbe più opportuno e�ettuare

prima una deregistrazione e poi una nuova registrazione, dall'altro lato il WSDL

è l'unico strumento che ci permette di raggiungere il servizio e da qui la necessità

dell'aggiornamento.

Nel caso in cui si richiede una deregistrazione di un servizio, e quindi si la-

vora con un'istanza della classe Deregistra, l'attività del BioMobyServiceAgent si

realizza con una cancellazione nella HashMap del servizio speci�cato.

Nel caso in cui il BioMobyServiceAgent viene inoltrata una richiesta, attraverso

un'istanza della relativa classe, si attiverà un meccanismo di matching tra le richie-

ste dell'utente e le informazioni contenute nella HashMap. Questo processo verrà

dettagliatamente descritto nel paragrafo 6.4.

6.3.2 BioMobyDiscoverServiceAgent

Supponendo di avere in qualche parte del mondo un repository di conoscenza speci-

�ca nel dominio biomedico, la situazione ideale sarebbe quella di permettere al-

l'agente BioMobyServiceAgent di esplorare l'ambiente che lo circonda catturando



tutte le informazioni disponibili e andare ad icrementare la conoscenza della propria

piattaforma.

Tutto questo però non è realizzabile in quanto gli agenti in JADE non suppor-

tano la mobilità inter-piattaforme e quindi siamo stati costretti a creare l'agente

BioMobyDiscoverServiceAgent per costruire un centro di competenza che ingloba

ogni singolo sapere.

Nel nostro caso, esso permette al BioMobyServiceAgent di e�ettuare il disco-

very dei servizi disponibili in MOBY. Facendo riferimento alla Figura 6.2 questo

meccanismo di scoperta potrebbe essere ripetuto m-volte.

Tutto ciò permette anche a chi fornisce i servizi di rendersi visibile e di pubbli-

cizzarsi. Si e�ettua quindi un vero e proprio advertisement delle proprie capacità

cercando di vincere il confronto competitivo con gli atri.

Consapevoli che un servizio nel corso del tempo potrebbe subire cambiamenti o

essere cancellato, abbiamo ritenuto opportuno aggiungere alla funzionalità base, cioè

quella di registrazione, anche la possibilità di modi�ca e cancellazione del servizio.

Figura 6.8: BioMobyDiscoverServiceAgent

Nella Figura 6.8 viene mostrato il comportamento base dell'agente indipenden-

temente dalla funzionalità che si va ad implementare. Non appena viene creato,

l'agente contatta il DF della piattaforma attraverso una chiamata al metodo cer-



caMoby() per ricercare il BioMobyServiceAgent precedentemente registrato.

In generale, per cercare nel DF bisogna creare un DFD dove tutti i principali campi

sono inizializzati con le proprietà desiderate. La ricerca ritorna un array di DFD che

contiene gli AID degli agenti registrati in cui gli attributi incontrano la descrizione

speci�cata.

Nel nostro caso ritorna un solo elemento perchè, come mostrato nel codice sot-

tostante, viene speci�cato il nome dell'agente che si va a ricercare. Naturalmente,

questo equivale a quello usato dal BioMobyServiceAgent quando si è registrato nel

DF.

public void cercaMoby() {

ServiceDescription sd = new ServiceDescription();

System.out.println("Localizzato il server");

sd.setType(SERVIZI);

sd.setName(BIOMOBY);

DFAgentDescription dfd = new DFAgentDescription();

dfd.addServices(sd);

AID aid = new AID("[email protected]:1099/JADE", true);

aid.addAddresses("http://192.168.0.151:7778/acc");

try {

DFAgentDescription[] dfds = DFService.search(this,aid, dfd);

if (dfds.length > 0) {

server = dfds[0].getName();

System.out.println("Localizzato il server");

} else

System.out.println("\nNon è possibile localizzare il server!");



} catch (Exception ex) {

ex.printStackTrace();

System.out.println("\nFallita ricerca nel DF!");

}

}

Figura 6.9: BioMobyDiscoverServiceAgent (registrazione)



Una volta individuato l'agente nel catalogo DF, l'attività elabora informazioni,

mostrata nella Figura 6.8, si diversi�ca a seconda che si voglia realizzare una regi-

strazione, una modi�ca o una cancellazione.

Nel primo caso, come mostrato in Figura 6.9, dopo aver realizzato la connessione con

MOBY attraverso l'utilizzo degli strumenti che esso ci mette a disposizione, vengono

prelevate le informazioni di ogni singolo servizio da passare al BioMobyServiceAgent

creando un'istanza della classe Registra. Il codice sottostante mostra le fasi sopra

descritte.

private void registrazione() {

//Connection to local BioMOBY

Central central = null;

try {

central = new CentralImpl(

"http://192.168.0.246/cgi-bin/MOBY-Central.pl");

} catch (MobyException e)

{System.err.println("errore primo" + e.getMessage());}

try {

...

//recovered the services of the specified type

prova = central.findService(tipi_servizi[q]);

for (int i = 0; i < prova.length; i++) {

//Assigns the respective values to the variables

// using the BioMOBY api.

nome = prova[i].getName();

type = tipi_servizi[q];



...

Registra reg = new Registra();

reg.setNome(nome);

reg.setTipo(type);

...

}

...

} catch (Exception ex)

{ex.printStackTrace();}

}

Nel secondo caso, come mostrato in Figura 6.10, quando si veri�ca un'aggiorna-

mento del WSDL (come spiegato nel paragrafo 6.3.1) dei servizi registrati in MO-

BY, dopo aver realizzato la connessione con quest'ultimo, vengono prelevate le in-

formazioni del servizio da modi�care e passate al BioMobyServiceAgent, creando

un'istanza della classe Modifica.

Nel terzo caso, come mostrato in Figura 6.11, quando si vuole cancellare un

servizio nel mirror di BioMobyServiceAgent, si crea un'istanza della classe Deregistra

speci�cando il nome del servizio. Sarà poi il BioMobyServiceAgent a gestire il tutto.

6.3.3 BioMobyApplicationAgent

Il BioMobyApplicationAgent rappresenta l'interfaccia con gli utenti, in quanto svolge

una funzione di intermediazione tra coloro che sono interessati a sfruttare le poten-

zialità del sistema e il sistema stesso.

La Figura 6.12, mostra in dettaglio come l'agente si comporta. Non appena viene



Figura 6.10: BioMobyDiscoverServiceAgent (modi�ca)



Figura 6.11: BioMobyDiscoverServiceAgent (deregistrazione)



Figura 6.12: BioMobyApplicationAgent



creato l'agente recupera i dati dall'esterno, speci�cati nella Tabella 6.1, che l'utente

possiede o ritiene utili per la ricerca del servizio che più risponde alle sue esigenze.

DATO DESCRIZIONE

nome nome del servizio

desc descrizione del servizio

tipo tipo del servizio

autore autore del servizio

input_dt tipo di dato dell'input

input_ns namespace dell'input

output_dt tipo di dato dell'output

output_ns namespace dell'output

co�Min coe�ciente minimo di precisione nel matching

Tabella 6.1: Input della ricerca

L'agente dopo aver contattato il DF della piattaforma attraverso una chiamata al

metodo cercaMoby(), come precedentemente spiegato, crea una nuova istanza della

classe Richiesta e dopo aver impostato gli opportuni parametri invia il messaggio

al BioMobyServiceAgent, che attivirà l'algoritmo di matching.

6.3.4 QualityServiceAgent

L'agente QualityServiceAgent svolge nel sistema un ruolo non banale in quanto

funge da certi�catore.

La logica su cui si basa questo approccio è simile a quello del peer review [BP], da

tempo adottato dalle riviste biomediche: l'ente revisore de�nisce a priori i criteri di



valutazione del servizio e, dai risultati della loro applicazione, ne certi�ca la qualità.

Oltre ai limiti dovuti alla soggettività e alla diversità di giudizio dei revisori questi

sistemi tendono ad introdurre inevitabilmente una gerarchia tra i servizi disponibili

nella rete e una forma di censura, che in parte contrasta con la natura e la �loso�a

stessa di Internet.

La necessità di introdurre un certi�catore nel sistema è sorta perchè in Internet

è di�cile valutare la qualità delle informazioni e dei servizi che vengono o�erti in

quanto ci si scontra con informazioni non accurate e molto incomplete.

Dopo un attento studio, che presenteremo in dettaglio nel paragrafo 6.4, abbiamo

de�nito un modello di qualità, sul quale abbiamo stilato un �le XML, come mostrato

sotto, che contiene tutti i parametri più signi�cativi per il processo di discovery.

Certo è che essi sono quelli che maggiormente ci permettono di quanti�care la qualità

del servizio.

<?xml version="1.0" ?>

- <quality>

<target key="target" value="bioinformatico" />

- <affidabilita>

<entry key="credAutore" value="5" />

<entry key="certificato" value="SI" />

<entry key="lucro" value="SI" />

</affidabilita>

- <qualitaInfo>

<entry key="pubblicita" value="SI" />

<entry key="consultazioneConsum" value="SI" />

</qualitaInfo>



<privacy key="privacy" value="SI" />

- <aggiornamento>

<entry key="intervallo" value="mensile" />

<entry key="ultimoAgg" value="18/04/2000" />

</aggiornamento>

<usabilita key="usabilita" value="SI" />

- <aspettiFormali>

<entry key="upDate" value="90" />

<entry key="velocita" value="1500" />

</aspettiFormali>

</quality>

Come mostrato in Figura 6.13, l'agente non appena viene creato, recupera i dati

dall'esterno (nome del servizio e �le XML) e poi fa la ricerca del BioMobyServiceAgent

nel DF attraverso la chiamata al metodo cercaMoby(). Successivamente crea un'is-

tanza della classe RegistraQualita, e dopo aver impostato gli opportuni parametri

invia il messaggio al BioMobyServiceAgent che provvederà alla registrazione.

6.4 La qualità in Internet

La qualità può essere de�nita come la totalità delle caratteristiche di un'entità che

in�uenzano la sua capacità di soddisfare bisogni dichiarati e impliciti. La qualità delle

risorse in Internet non può essere de�nita come una grandezza a sé stante. Esistono

criteri per valutare la coerenza interna di una risorsa, ma la vera valutazione è diretta

ad accertarne l'e�cacia. In altre parole si tratta di accertare se un determinato target

di utenza può considerarla o meno soddisfacente rispetto ai suoi speci�ci bisogni

154 6.4 La qualità in Internet


Figura 6.13: QualityServiceAgent

6.4 La qualità in Internet 155


informativi. In letteratura troviamo centinaia di liste di controllo [dce02] contenenti

criteri per valutare le risorse nel Web. Tuttavia, questo non è il punto principale né

quello di partenza. Prima di creare una lista di requisiti ideali di qualità, dovremmo

controllare attentamente il contesto, che per noi è quello biomedico, in cui la qualità

stessa si esprime.

Nei successivi sottoparagra� vengono analizzati i tre livelli di matching che le

richieste possono soddisfare, vengono poi elencati i criteri di qualità che idealmente

un servizio, o più in generale un'informazione biomedica, dovrebbe soddisfare. In�ne,

si descrive come è stato sviluppato il processo di matching nel nostro prototipo.

6.4.1 Tre livelli di matching

Idealmente, quando un richiedente cerca un servizio, il sistema ne dovrebbe recupe-

rare uno che incontra esattamente le richieste fatte. In pratica, è molto improbabile

che tale servizio sia disponibile, così solitamente si recupererà un servizio con capa-

cità �su�cientemente simili� a quelle richieste.

Naturalmente il problema di questa a�ermazione è spe�cicare cosa signi�ca �su�-

cientemente simile�. Nella sua interpretazione più forte, un servizio memorizzato e

una richiesta sono �su�cientemente simili� quando essi descrivono esattamente lo

stesso servizio. Questa de�nizione è troppo restrittiva in quanto il richiedente non

conosce a priori come un servizio è rappresentato ed ha una sua idea soggettiva di

ciò che esso dovrebbe fare. Per dare una de�nizione più rilassata del concetto, noi

necessitiamo di permettere incontri con grado di esattezza �essibile.

Quindi, una delle s�de del sistema è localizzare i servizi che il richiedente può uti-

lizzare nonostante le di�erenze dalla richiesta. Ulteriormente, il sistema potrebbe

essere abile a caratterizzare la distanza tra la richiesta e il matching trovato così che



il richiedente potrebbe prendere consapevolmente una decisione.

Per indirizzarci a questo problema, il sistema identi�ca tre livelli di matching:

Exact match è il più alto grado di matching e si veri�ca quando le richieste sono

soddisfatte dal servizio con una percentuale superiore al 90%.

Plug-in match risulta quando il servizio fornito è più generale del servizio richiesto,

ma in pratica esso può essere usato in sostituzione del servizio ideale che il

richiedente piacerebbe usare. Questo match si veri�ca quando le richieste sono

soddisfatte in una percentuale compresa tra il 10 e il 90% inclusi.

Relaxed match è il più basso grado di matching e si veri�ca quando le richieste

sono soddisfatte dal servizio con una percentuale inferiore al 10%.

6.4.2 Criteri generali di valutazione della qualità

Dalla nostra ricerca abbiamo capito che per avere qualità nel Web bisogna soddisfare

un serie di requisiti cardine che elencheremo in seguito.

Scopo della risorsa

• perchè è stato sviluppato (obiettivi)?

• su cosa ha puntato?

Target di utenza

• per chi è stato sviluppato? (professionisti del settore medico-sanitario, grande

pubblico, gioventù, giovani, bambini, ecc. )

Affidabilità

• il nome dell'autore (il nome dell'organizzazione responsabile del documento) è

indicato chiaramente?



• quali sono le credenzialità dell'autore? Possono essere veri�cate?

• il sito fornisce le informazioni sull'autore (es. nome completo, indirizzo, numero

di telefono, e-mail, ecc.)?

• se un'organizzazione è responsabile delle informazioni, è un'organizzazione

stimabile riconosciuta come autorità in mateia?

• se le informazioni mediche sono fornite da un non professionista, questo viene

detto chiaramente?

• i produttori del sito hanno un interesse commerciale?

• il luogo fornisce garanzie di qualità usate per accertarsi che le informazioni

fornite sul sito rispondano ad un alto livello?

• il sito include collegamenti per altri luoghi simili?

• chi è il webmaster o l'amministratore del sistema?

Qualità delle informazioni

• le informazioni sono originali?

• include un processo di revisione? (La politica deve citare posizione, quali�ca e

nome di chi rivede).

• speci�ca dettagliatamente il processo di approvazione de�nitiva (responsabilità

e quali�ca compresi)?

• c'è una corrispondenza tra la copertura e l'accuratezza dell'informazione pre-

sentata e lo scopo della risorsa?



• tutte le informazioni su tutto il trattamento sono fornite con prova scienti�ca

(pubblicazioni mediche, rapporti o altri) identi�cata chiaramente?

• i trattamenti (generici) alternativi sono descritti?

• c'è la possibilità di distinguere chiaramente i fatti dalle opinioni?

• richiama il con�itto di interesse?

• include una politica sulla pubblicità (sponsor e istituzioni che �nanziano la

risorsa)?

• include un procedimento per la consultazione del consumatore?

• si accerta che i luoghi osservino le limitazioni di copyright su tutto il materiale

(immagini comprese ed altri mezzi) usato nella preparazione delle risorse?

Contenuti

• per le malattie o le circostanze, indica:

� le cause

� come impedirlo

� come riconoscerlo

� come è diagnosticato

� trattamenti e procedure (ed alternative)

� la qualità della vita associata con la malattia dopo la cura

• per le informazioni sui trattamenti, copre:

� come i trattamenti funzionano



� quali sono i loro bene�ci e rischi

� quali sono gli e�etti sulla qualità della vita

� qual'è l'e�etto probabile del non-trattamento?

Trattamento corretto dei dati raccolti dagli utenti

• nel sito si è fatto riferimento alla legge sulla privacy?

• ci si è accertati che le informazioni mediche o altri dati personali forniti siano

mantenuti assolutamente con�denziali?

Aggiornamento

• ogni quanto tempo il sito è aggiornato?

• la data di creazione e ultimo aggiornamento è chiaramente visibile?

• ci sono altre caratteristiche per indicare se le informazioni sono mantenute

aggiornate?

• tutte queste informazioni sono chiare e facili da capire?

Aspetti formali

• è coerente l'architettura ipertestuale?

• il sito è ben organizzato e presentato logicamente?

• c'è adeguatezza rispetto alle speci�che u�ciali per il corretto uso di HTML?

• c'è adeguatezza rispetto alle linee guida per l'accessibilità dei contenuti (ad

esempio la Web Accessibility Initiative del W3C)?



• c'è la possibilità di utilizzare plug-in o hardware particolari per poter accedere

alla risorsa o ad una sua parte?

• c'è leggibilità del testo, delle immagini e del video?

• c'è la possibilità di una stampa di qualità?

• il sito include rilevanti e creativi usi gra�ci?

• quando è richiesto un software addizionale è disponibile un link per accedervi?

• intestazioni, caratteri e spazi bianchi sono usati in modo appropriato?

• la combinazione dei colori di testo e sfondo è leggibile?

• c'è interattività (forum e Chat)?

• c'è un aiuto in linea e/o di Frequently Asked Questions (FAQ)?

• c'è stabilità della risorsa durante un dato periodo di tempo?

• è garantita velocità di accesso al server?

Navigabilità

• le risorse nel sito sono facili da trovare?

• il sito è user-friendly?

• la navigazione attraverso di�erenti aree è consistente?

• i link interni e esterni sono appropriati?

• nuove informazioni sono facili da trovare?

• è disponibile un motore di ricerca all'interno del sito?



• la prima pagina di ogni directory è chiamata Index.html?

• sono fornite traduzioni in altre lingue?

Funzioni quantitative

• c'è un meccanismo che conteggia il numero di visitatori del sito?

• c'è un meccanismo che conteggia il numero di comunicati stampa?

Uso di standard riconosciuti (come determinati metadati) per l'aiuto

- indicizzazione della risorsa.

6.4.3 Algoritmo di matching

L'algoritmo di matching che abbiamo sviluppato viene eseguito all'interno del

BioMobyServiceAgent, come mostrato in �gura 6.14 e soddisfa i seguenti punti.

• Supportare �essibili semantici incontri sulla base delle ontologie disponibili.

• Realizzare incontri che minimizzano i falzi positivi e i falzi negativi. Inoltre, i

servizi richiesti dovrebbero avere un minimo di controllo sul livello di �essibilità

che il sistema premette.

• Incoraggiare registrazioni oneste e richieste che tengono in considerazione il cos-

to da sostenere nel caso in cui il non incontro sia provocato da false dichiarazioni.

• Realizzare incontri e�cienti che diano risultati in tempi brevi.

Il ciclo principale dell'algoritmo di matching è mostrato nel codice sottostante. In

esso si evidenzia che le richieste vengono confrontate con tutti i parametri dei servizi

memorizzati nel mirror e per ogni servizio si calcola il coe�ciente che misura il grado



Figura 6.14: Processo di matching



di incontro. Ad ogni iterazione del ciclo interno viene memorizzato, in un vettore di

appoggio, il nome del servizio ed il corrispettivo coe�ciente. Successivamente viene

estratto dal vettore il servizio con coe�ciente massimo.

match (request){

recordMatch = empty list

forall service in mirror do{

recordMatch.addElement(service, coff)

}

return best(recordMatch);

}

Successivamente verà dettagliatamente spiegato l'algoritmo di matching suddivi-

dendo la parte che utilizza le informazioni provenienti da MOBY da quella che sfrutta

le informazioni fornite dal certi�catore.

Il matching sulle informazioni di MOBY

Al �ne di realizzare il matching tra i servizi e le richieste, la prima fase di analisi

ci ha portato a considerare le informazioni presenti nella nostra base di conoscenza.

Esse sono: nome, descrizione, tipo, autore, input simple datatype, input simple

namespace, input set datatype, input set namespace, output simple datatype, output

simple namespace, output set datatype e output set namespace.

Dopo aver fatto un attento studio sul valore dei singoli dati a nostra disposizione,

abbiamo ordinato gli elementi assegnando loro un certo peso, come mostrato in

Tabella 6.2, al �ne di calcolare il coe�ciente che può assumere un valore variabile

tra zero e cento.



DAT

IMIR

ROR

DAT

IRIC

HIE

DEN

TE

PESO

nome

nome

51

descriz

ione

descriz

ione

4

tipo

tipo

2

autore

autore

4

inpu

tsim

pleda

tatype∨

inpu

tsetda

tatype

inpu

t_dt

13

inpu

tsim

plena

mespa

ce∨

inpu

tsetna

mespa

ceinpu

t_ns

15

(inpu

tsim

pleda

tatype∧

inpu

tsim

plena

mespa

ce)∨

(inpu

tsetda

tatype∧

inpu

tsetna

mespa

ce)

inpu

t_dt∧

inpu

t_ns

17

output

simpleda

tatype∨

output

setda

tatype

output_dt

18

output

simplena

mespa

ce∨

output

setna

mespa

ceou

tput_ns

20

(outpu

tsim

pleda

tatype∧ou

tput

simplena

mespa

ce)∨

(outpu

tsetda

tatype∧ou

tput

setna

mespa

ce)

output_dt∧

output_ns

22

Tabella 6.2: Peso dei match



Descriveremo ora brevemente le motivazioni che ci hanno spinto ad assegnare i

relativi valori ad ognuno dei campi considerati.

Il nome del servizio è il parametro più importante perchè si presuppone che se

l'utente lo conosca, la ricerca dovrà necessariamente restituire il servizio speci�ca-

to. Per soddisfare questo bisogno il peso attribuito ad esso è cinquantuno e quindi

maggiore della somma del peso di tutti gli altri attributi. Se il valore assegnato fosse

stato minore della metà più uno, si sarebbe corso il rischio di estrarre un servizio

diverso da quello richiesto.

Per maggiore chiarezza facciamo l' esempio che l'utente dall'esterno speci�chi tutti

i campi. Ad ogni iterazione del ciclo interno viene calcolato il coe�ciente che risul-

terà essere al massimo pari a quarantanove, se si incontrano tutti i campi ad eccetto

del nome, e minimo pari a cinquantuno quando si incontra il servizio richiesto. Ciò

dimostra che il servizio restituito sarà esattamente quello indicato.

Il parametro descrizione, che viene inserito dall'esterno, è costituito da parole

chiavi che verranno ricercate all'interno della descrizione di ogni singolo servizio mem-

orizzato nel mirror. Il peso complessivo associato a questo match è pari a quattro,

ma potrà assumere valori di�erenti a seconda delle diverse occorrenze dei termini

speci�cati nella richiesta.

Descriviamo ora il procedimento che permette di calcolare il peso di questo coe�-

ciente. Per prima cosa si genera un array di interi la cui dimenzione è pari al numero

di parole provenienti dall'esterno.

Ad ogni iterazione del ciclo interno, si calcola un valore percentuale che permette

di valutare tutte le possibili combinazioni che possono assumere le occorrenze delle

parole chiavi.

Se ad esempio, le parole chiave che andiamo ad inserire sono �all Arabidopsis Pheno-



types�, tra il servizio getPhenotype_by_Keyword, con descrizione Retrieves all Ara-

bidopsis Phenotypes associated with a Keyword, e il servizio getPhenotype_by_NASC,

con descrizione Retrieves Arabidopsis Phenotype by NASC code, quello che avrà

coe�ciente più alto sara il primo.

Il parametro tipo ha peso pari a due. Abbiamo dato poca importanza a questo

campo in quanto può assumere solamente sette diversi valori (service, retrieval, res-

olution, parsing, registration, analysis, NCBI_Blast). Resterà quindi facile per l'u-

tente scegliere quello più adeguato e rendendo il campo poco discriminante per la

scelta del miglior servizio.

Il parametro autore, che rappresenta semplicemente il suo nome e non speci�ca

le sue credenzialità, ha peso pari a quattro in quanto si presuppone che un servizio

possa essere maggiormente identi�cato con il nome dell'autore rispetto al tipo, ma

allo stesso tempo si tratta di un informazione non di conoscenza comune e quindi

non è stato possibile assegnargli un peso maggiore.

Abbiamo deciso di assegnare un valore più alto ai parametri relativi all'input e

all'output in quanto si presume che se un utente richiede un servizio ha chiaro in

mente l'output che vuole che gli sia restituito e allo stesso tempo ha a disposizione

un certo tipo di input che gli permette in un secondo momento di sfruttare il servizio.

Dato che BioMoby distingue gli input e gli output in due tipi, Simple e Set, e che per

ognuno di essi speci�ca tipo di dato e namespace si è dovuto operare la distinzione

come mostrato in Tabella 6.2.

Da sottolineare il fatto che per noi non c'è di�erenza se si tratta di un tipo Simple o

Set in quanto se prendiamo singolarmente gli elementi del Set, essi sono dello stesso

tipo dell'elemento Simple.

Inoltre, abbiamo deciso di dar maggior importanza ai match che si veri�cano tra



namespace piuttosto che tra i tipi di dati perchè essi riescono a precisare maggior-

mente cìò che il servizio prende in input o restituisce come output.

Mettiamo in evidenza, in�ne, che in generale viene dato un peso maggiore all'output

piuttosto che all'input. Questo presume che se un utente richiede un servizio ha un'e-

sigenza che deve soddisfare con un dato output, mentre l'input se lo può procurare

in un secondo momento e cioè dopo che ha individuato il servizio stesso.

Ulteriormente permettiamo al richiedente di speci�care quanto vicino alla richie-

sta deve essere il servizio trovato. A questo scopo utilizziamo un coe�ciente che ci

permette di valutare l'adeguatezza del servizio. Se non viene inserito dall'esterno

dall'utente il suo valore di default è 10% che corrisponde al relaxed match descritto

precedentemente.

Il matching sulle informazioni del certi�catore

L'algoritmo di matching, dopo aver analizzato le informazioni di MOBY e dopo

aver stilato una graduatoria di servizi, passa ad analizzare le informazioni che il

certi�catore gli mette a disposizione, se queste esistono. In caso contrario l'algoritmo

termina.

Attraverso la chiamata del metodo maneggiaXml(), al quale viene passato il �le

XML contenente le informazioni, si calcola un secondo coe�ciente dando un pe-

so a ciascuno dei parametri mostrati in Tabella 6.3. Esso ci permette di �ltrare

ulteriormente i servizi.

Il concetto di a�dabilità si suddivide in tre sottoparametri. Il primo assegna

all'autore un determinato valore, che varia da zero a cinque, in base alla sua pro-

fessionalità. Di tipo booleano è il secondo parametro, che permette di individuare

che l'autore sia conforme a standard dettati da altri certi�catori. In�ne, l'ultimo



PARAMETRI SOTTOPARAMETRI

a�dabilita credAutore

certi�cato

lucro

qualitaInfo pubblicità

consultazioneConsum

privacy privacy

aggiornamento intervallo

ultimoAgg

usabilità usabilita

aspettiFormali upDate

velocita

Tabella 6.3: Parametri di qualità del certi�catore



parametro, anch'esso di tipo booleano, ci permette di costatare se chi ci mette a

disposizione il servizio ha �ni di lucro.

Il secondo concetto discriminante riguarda la qualità delle informazioni. In

questo caso ci chiediamo se si veri�ca una politica sulla pubblicità, cioè ci sono

sponsor ed istituzioni che �nanziano la risorsa, e se si realizza un procedimento per

la consultazione del consumatore. Entrambi i parametri sono di tipo booleano.

Il terzo concetto relativo alla privacy indica, attraverso un booleano, che la

politica in materia di privacy, di protezione dei dati e il sistema di trattamento dei

dati personali, incluso il trattamento non visibile agli utenti, devono essere de�niti

chiaramente secondo la legislazione vigente.

Il quarto concetto ci permette di veri�care che l'aggiornamento sia chiaro e

periodico. A tal �ne si speci�cano sia l'intervallo di tempo con cui questa azione si

ripete, che può assumere i valori giornaliero, mensile e annuo, sia la data dell'ulti-

mo aggiornamento. Se quest'ultimo si è veri�cato entro i precedenti trenta giorni

concorre all'incremento del coe�ciente.

Il quinto concetto si riferisce all'usabilità del servizio. Quando, come in questi

casi ci si rivolge ad un pubblico particolare, la presentazione e i contenuti delle

informazioni devono essere adattate il più possibile al destinatario. Si deve quindi

avvantaggiare un servizio che sia facile da comprendere e da utilizzare.

In�ne, con il concetto di aspetti formali vogliamo individuare due parametri

prettamenti tecnici che ci speci�cano l'up-date del servizio, cioè quanto tempo il

servizio è attivo in una giornata e la sua velocità di esecuzione espressa in millisecondi.


Conclusioni

Allo stato attuale la miriade di informazioni e di servizi presenti in Internet nel

dominio biomedico rende di�cile all'utente capire qual è il servizio che risponde più

e�centemente alle sue esigenze.

Il lavoro è stato sviluppato per supportare gli utenti nelle ricerche cliniche e

biomediche. Ciò è stato possibile grazie allo studio, all'implementazione e all'uti-

lizzo di un modello di qualità che sfrutta le informazioni che BioMOBY e l'ente

certi�catore mettono a disposizione.

Partendo dal fatto che ciò che abbiamo realizzato è un matching qualitativo,

alcuni degli ulteriori vantaggi portati dal prototipo riguardano la riduzione dei tempi

di attesa da parte dell'utente, una maggiore credibilità dei risultati ottenuti, una

maggiore disponibilità di informazioni e la possibilità di scelta della precisione del

matching.

Un esempio d'utilizzo del nostro sistema può essere:

�Un ricercatore biomedico è esperto di un gene, la proteina relativa e le mutazioni

conosciute, nonché le associate patologie. Desidera progettare un esperimento di

microarray per analizzare l'espressione genica (quanto produce il gene) in di�eren-

ti tessuti, normali e patologici. L'esperimento gli consente di evidenziare insieme

all'espressione genica del gene sotto studio anche quella di altri geni, nelle stesse

171

CONCLUSIONI

condizioni. Desidera quindi compilare una lista aggiornata di geni che potrebbero

essere coinvolti negli stessi percorsi biochimici (catena di reazioni biochimiche legate

tra loro). Per questo pensa di utilizzare la gene ontology annotation che mette in

relazione geni con processi biologici e percorsi biochimici. Per raggiungere i suoi

obiettivi deve ricerca la descrizione per 'GO', 'Gene' e 'Ontology'. �

Il risultato ottuneto dall'interrogazione di BioMOBY applicando la query:

select servicename,url,contact_email,description

from service_instance

where description like %Gene%

and description like %Ontology%

and description like %GO%

è il seguente:

servicename: getGoTerm

url: http://mobycentral.cbr.nrc.ca/cgi-bin/Services/Services.cgi

contact_email: [email protected]

description: takes a Gene Ontology accession number and returns the

term name and definition as a GO_Term object

servicename: getSHoundGODBGetParentOf



description: This function operates on Gene Ontology (GO) vocabulary

graphs. It retrieves a list of processes, functions or

172

CONCLUSIONI

components situated directly above a given GO identifier

in the graphs.

servicename: getSHoundGODBGetChildrenOf



description: This function operates on Gene Ontology (GO) vocabulary

graphs. It retrieves a list of processes, functions or

components situated directly below a given GO identifier

in the graphs.

Se, invece, interroghiamo il nostro sistema, utilizzando a pieno le sue capaci-

tà riusciamo ad ottenere il servizio che meglio soddisfa le esigenze dell'utente. Il

risultato ottenuto è il seguente:

servicename: getGoTerm


Possiamo notare, quindi, che il nostro prototipo e�ettivamente porta un valore

aggiunto a al discovery dei servizi.

I possibili sviluppi di questo lavoro potranno essere:

• personalizzare la richiesta al target (informatici, bioinformatici, biologi, ...);

• inserire un'ontologia per descrivere le richieste dell'utente veri�cando così la

consistenza delle stesse;

• inserire un'ontologia che permetta di introdurre una corretta e utile descrizione

dei servizi;

173

CONCLUSIONI

• introdurre e quanti�care ulteriori parametri di certi�cazione;

• rendere il certi�catore dinamico evitando di avere informazioni obsolete;

• gestire delle richieste complesse che potranno essere soddifate solamente da

una sequenza di servizi;

• recuperare ulteriori servizi da repository diversi dal MOBY-Central;

• allargare il dominio di applicazione del modello.

Concludendo, la progettazione di un modello di qualità e l'implementazione del-

lo stesso, usando una tecnologia ad agenti, ci ha permesso di allargare le nostre

conoscenze ed a�rontare in maniera �essibile e costruttiva i problemi che si presen-

tavano di volta in volta. Quello che ci auspichiamo è che il lavoro fatto �n d'ora

non vada perso, ma sia una buona base per realizzare qualcosa di utile alla società

di ricercatori e non solo.

Certo è che essere riuscite a raggiungere questo primo traguardo partendo dal nulla

è stato per noi una grande soddisfazione.

174

Appendice

175

Appendice A

Lista degli acronimi e dei relativi

signi�cati

Di seguito vengono riportati gli acronimi menzionati all'interno del lavoro.

(A)

ACC Agent Communication Channel

ACL Agent Comunication Language

ACM Agent Comunication Language

ACO Ant Colony Optimization

AID Agent Identi�er

AMS Agent Management System

AP Agent Platform

API Application Programme Interface

AUML Agent Uni�ed Modelling Language

177

APPENDICE A. LISTA DEGLI ACRONIMI E DEI RELATIVISIGNIFICATI

(C)

CA Communicative Act

CDL Capability Description Language

CGI Common Gateway Interface

CORBA Common Object Request Broker Architecture

CRIB Cross-Reference Information Block

(D)

DCOM Distributed Component Object Model

DF Directory Facilitator

DDBJ DNA Data Bank of Japan

DNA Deoxyribose Nucleic Acid

(E)

EMBL European Molecular Biology Laboratory

ERP Enterpriser Resource Planning

(F)

FAQ Frequently Asked Questions

FIPA Fondation for Intelligence Physical Agents

FSM Finite State Machine

FIFO First In First Out

178


(G)

GO Gene Ontology

GUID Global Unique Identi�er

(H)

HAP Home Agent Platform

HON Health On the Net Foundation

HTTP Hypertext Transmission Protocol

(I)

IDL Interface De�nition Language

IEEE Institute Electrical Electronic Engineers

IIOP Internet Inter-ORB Protocol

(J)

J2EE Java 2 Enterpriser Edition

J2ME Java 2 Micro Edition

J2SE Java 2 Standard Edition

JADE Java Agent DEvelopment Framework

(K)

KM Knowledge Management

179


(L)

LAN Local Area Network

(M)

MAS Multi Agent System

MedLEE Medical Language Extraction and Encoding System

MTP Message Transport Protocol

(N)

NCBI National Center for Biotechnology Information

(O)

OMG Open Management Group

OMNI Organising Medical Networked Information

(P)

PDB Protein (Structure) Data Base

(Q)

QoS Quality of Service

180


(R)

RDF Resource Description Framework

RDN Resource Discovery Network

RMI Remote Method Invocation

RMSD Root Mean Square Deviation

RPC Remote Procedural Call

RUH Rouen University Hospital

(S)

SL Semantic Language

SOAP Simple Object Access Protocol

(T)

TILAB Telecom Italian Labs

TS Tuple Space

TuCSoN Tuple Center Spread over Network

(U)

UDDI Universal Description Discovery and Integration

UML Uni�ed Modelling Language

(W)

WSDL Web Services Description Language

181


(X)

XML Extensible Markup Language

182

Appendice B

AUML

Di seguito viene presa in esame una delle più note proposte di estensione dell'UML:

l'Agent UML (AUML).

Attualmente l'AUML non è ancora un vero standard ma piuttosto un obiettivo. Le

estensioni �nora proposte sono il frutto degli sforzi di diversi ricercatori, tra cui

James Odell, H.Van Dyke Parunak, Bernhard Bauer, Federico Bergenti, Agostino

Poggi, Jörg P.Müller e molti altri.

Le principali estensioni dell'AUML riguardano i seguenti argomenti:

Protocolli di interazione: formalizzano le sequenze di messaggi scambiati tra due

o più agenti. Generalmente vengono rappresentati con diagrammi di sequenza

(opportunamente modi�cati), ma possono anche essere modellati con diagram-

mi di attività, di collaborazione o di stato.

Classi di agenti: rappresentate con diagrammi delle classi.

Elaborazione interna agli agenti: rappresentata con diagrammi dinamici, soprat-

tutto attività e stato.

183

APPENDICE B. AUML

Modellamento dei ruoli: rappresentazione dei molteplici ruoli che un agente può

assumere in una conversazione.

L'AUML propone, inoltre, formalismi per modellare numerose altre caratteristi-

che tipiche degli agenti, come ad esempio l'eventuale mobilità, l'uso di agenti come

interfacce verso sistemi, e relazioni complesse tra agenti.

Verranno ora presi in esame i principali aspetti dell'AUML, evidenziando in partico-

lare le di�erenze rispetto all'UML. E' necessario premettere che, non essendo ancora

AUML uno standard, ne esistono numerose versioni, ognuna con qualche piccola dif-

ferenza rispetto alle altre. L'AUML qui descritto si basa sui seguenti documenti di

lavoro (working documents): [OPB00], [B.B00], [B.B01].

Protocolli di interazione: i diagrammi di protocollo

Un protocollo di interazione tra agenti (AIP, Agent Interaction Protocol) descrive

un modello di comunicazione, ovvero la sequenza consentita dei messaggi scambiati

ed eventuali vincoli sui contenuti di tali messaggi.

L'AUML rappresenta un AIP con un'estensione del sequence diagram: il diagramma

di protocollo (Protocol diagram). La Figura B.1 mostra un esempio del Contract

Net, uno dei protocolli di negoziazione più di�usi.

L'intero protocollo è racchiuso in un package: in questo modo il protocollo rap-

presenta un'entità a sé all'interno del progetto. Nell'UML i package raggruppano

soltanto classi, mentre in AUML possono raggruppate qualsiasi elemento. Il proto-

collo, inoltre, è anche un pattern, un modello personalizzabile, i cui parametri sono

elencati nel riquadro tratteggiato.

Come in un sequence diagram di UML, la dimensione verticale rappresenta il tempo

184

APPENDICE B. AUML

Figura B.1: Protocollo Contract Net.

185

APPENDICE B. AUML

che scorre dall'alto verso il basso, dove la linea verticale è chiamata lifeline, linea

di vita, e le parti spesse sono dette attivazioni. Nella dimensione orizzontale non

si trovano oggetti, come in UML, bensì ruoli. In questo esempio i ruoli sono Ini-

tiator, l'entità che dà inizio alla conversazione, e Participant, o Respondent, l'entità

che riceve il primo messaggio. Le frecce a punta sottile indicano l'invio di messaggi

asincroni da un'entità all'altra. E' anche possibile aggiungere dei numeri a destra e

a sinistra delle frecce per indicare la molteplicità.

Rispetto ai diagrammi classici, sono stati aggiunti dei simboli per indicare delle

�decisioni� circa i messaggi da inviare. Il signi�cato dei simboli è mostrato nella

Figura B.2.

Figura B.2: Relazioni tra atti comunicativi.

I messaggi sono anche chiamati �atti comunicativi� (CA, Communication Act).

Nella Figura B.1, l'Initiator inizia la conversazione con un atto �call-for-proposal�, e

il Participant può scegliere di rispondere con �refuse�, �propose� o �not-understood�

(la �x� indica l'or esclusivo tra i messaggi). La nota �deadline� indica il tempo limite

oltre il quale un'eventuale proposta da parte di Participant verrà automaticamente

ri�utata dall'Initiator.

Il Protocol diagram può esprimere anche la concorrenza dell'elaborazione. Ad

186

APPENDICE B. AUML

esempio, i due frammenti di diagramma presenti in Figura B.3, mostrano il caso

�exclusive or�. Quello a sinistra è quello utilizzato nell'esempio in Figura B.1. Quello

di destra �spezza� la linea di vita in più linee. Tuttavia il signi�cato di tali linee varia

a seconda del contesto: può indicare che i messaggi sono raccolti da thread di�erenti

all'interno dell'agente, oppure che l'agente assume un ruolo diverso a seconda di quale

messaggio elabora.

Figura B.3: Thread concorrenti.

Dato che un protocollo è un modello (template) i cui parametri generici sono

chiamati unbound parameters, volendo applicare il pattern ad un caso concreto, oc-

corre sostituirli con i loro valori e�ettivi (bound parameters).

Questo modo di utilizzare i modelli fa parte dell'AUML, non dell'UML. Nell'esempio

in Figura B.4, i nomi dei ruoli sono stati sostituiti dai nomi e�ettivi degli agenti,

la deadline generica è diventata un istante di tempo e sono stati introdotti due tipi

diversi di messaggio �refuse�.

187

APPENDICE B. AUML

Figura B.4: Istanza di un template di protocollo.

Altre rappresentazioni delle interazioni tra agenti

I protocolli e, più in generale, le interazioni tra due o più agenti possono essere

visualizzati anche con altri tipi di diagrammi. Non esiste un diagramma migliore

in assoluto: dipende sia dalla persona che lo traccia, sia dal protocollo speci�co.

Inoltre, creare più diagrammi per rappresentare la stessa cosa aiuta a considerare il

problema da tutti i punti di vista.

I diagrammi di collaborazione e diagrammi di sequenza, ad esempio, si distin-

guono semplicemente dal fatto che nei primi, gli oggetti (o i ruoli, o gli agenti) pos-

sono essere posizionati in qualunque punto, mentre, nei nei secondi, devono trovarsi

tutti nella prima riga in alto. Inotre, nei primi, la dimensione temporale non è

esplicita, ma indicata da numeri progressivi associati ai messaggi scambiati.

Per altri tipi di protocolli possono risultare più utili i diagrammi di attività. Essi

forniscono una rappresentazione gra�ca che rende possibile una visualizzazione molto

semplice dei processi e degli eventi (trigger) che li attivano, soprattutto per quanto

188

APPENDICE B. AUML

riguarda le elaborazioni concorrenti asincrone. Inoltre sono molto indicati per espri-

mere comunicazioni simultanee tra più agenti.

Nella Figura B.5 viene utilizzato un diagramma di attività per descrivere un'inte-

razione complessa tra quattro agenti, facenti parte di un ipotetico sistema di com-

mercio elettronico, rappresentati da altrettante corsie. Si noti come alcune attività

siano svolte concorrentemente, tranne in un punto dove la sequenza è sincronizzata

dall'agente ECN (che qui sta per Electronic Commerce Network). La notazione è

quella classica dell'UML.

Figura B.5: Protocollo rappresentato come Activity Diagram.

Un altro modo di rappresentare i protocolli è quello di usare i diagrammi di stato.

Essi sono usati raramente, in quanto in genere si preferisce avere una visione �orienta-

ta agli agenti� (diagrammi di interazione), oppure �orientata ai processi�, (diagrammi

di attività). Il terzo tipo di visione è quella �orientata allo stato�.

In �gura B.6, il protocollo attraversa due stati principali, ognuno dei quali con-

tiene al proprio interno altri stati annidati; le transizioni tra gli stati sono del tipo

189

APPENDICE B. AUML

�Agente:messaggio�. Gli stati del diagramma hanno un signi�cato concettuale e ge-

neralmente non corrispondono ad alcun oggetto implementato. Ad esempio, esistono

gli agenti A e B, ma non esiste un oggetto �Requested� in quanto si tratta semplice-

mente di uno stato del protocollo.

Questo modo di vedere il problema ha un punto di forza molto importante: fornisce

dei vincoli ben precisi al protocollo. Ad esempio, osservando la Figura B.6, ci si rende

subito conto che l'agente B può inviare il messaggio �commit� all'agente A soltanto

se il protocollo è nello stato �Requested�.

Figura B.6: Protocollo rappresentato come Statechart.

Classi di agenti

Nella programmazione orientata agli oggetti, una classe è un modello per creare

oggetti concreti, chiamati istanze della classe: analogamente, in un paradigma ad

agenti, possiamo de�nire una �classe di agenti� (�agent class�) come un modello per

190

APPENDICE B. AUML

creare agenti concreti.

Quando si progetta un sistema ad agenti occorre dunque una notazione per distin-

guere, in un diagramma delle classi, quali tra esse rappresentano gli agenti e quali

sono invece classi ordinarie.

L'AUML propone un nuovo simbolo per indicare un'agent class, mostrato nella Figu-

ra B.7 a sinistra. Alternativamente, è possibile utilizzare la classica notazione UML,

mostrato a destra, con l'aggiunta di uno stereotipo �agent�.

Figura B.7: Diverse rappresentazioni di una classe di agenti.

Elaborazione interna agli agenti

Nel descrivere i processi interni di un agente, spesso è necessario rappresentare at-

tività svolte da altri agenti: l'AUML introduce nuovi simboli per rendere possibile

tutto ciò. Nei diagrammi di attività, come mostrato in Figura B.8, i rettangoli con

interruzioni agli angoli indicano attività esterne.

Invece nei diagrammi di stato, Figura B.9, le attività esterne sono modellate con

frecce tratteggiate.

191

APPENDICE B. AUML

Figura B.8: Activity Diagram esteso.

Figura B.9: Statechart esteso.

192

APPENDICE B. AUML

Modellamento dei ruoli

Nell'ambito dei sistemi multi-agente, un ruolo (�agent-role�) è un insieme di agenti

che soddisfano certe proprietà, in termini ad esempio di interfacce, servizi o�erti o

comportamento. Il concetto di ruolo è già presente nell'UML, che prevede anche

la possibilità di classi�cazione multipla e di classi�cazione dinamica. L'implemen-

tazione di un agente può dunque soddisfare numerosi ruoli, e un sistema multi-agente

può essere de�nito, oltre che in termini di classi di agenti, anche in termini di ruoli.

Per indicare che una classe di agenti supporta alcuni ruoli, si usa la seguente no-

tazione:

nome\-classe\-agente / ruolo1, ruolo2, ...

Inoltre, per indicare che un certo numero di istanze (agenti concreti) soddisfano

certi ruoli e appartengono ad una classe, si usa la notazione:

istanza1, istanza2, ... / ruolo1, ruolo2, ... : nome-classe-agente

Indicare i ruoli in un diagramma delle classi è semplice; i problemi sorgono quando

si vogliono utilizzare diagrammi dinamici per rappresentare interazioni tra agenti in

cui intervengono cambiamenti di ruolo.

Le Figure B.10 e B.11 mostrano come sia possibile modellare i ruoli con i classici

diagrammi di sequenza UML.

La Figura B.10 riporta diverse linee di vita per ogni agente, una per ogni ruolo

che rappresenta; la �gura B.11, invece, si concentra soltanto sui ruoli. La complessità

di questi diagrammi è evidente, risultando spesso confusi e di di�cile lettura.

193

APPENDICE B. AUML

Figura B.10: Modellamento dei ruoli conforme all'UML.

Figura B.11: Rappresentazione alternativa alla Figura A.10.

194

APPENDICE B. AUML

L'AUML propone due possibili estensioni per rendere più agevole la rappresen-

tazione dei ruoli nelle conversazioni. La stessa interazione delle Figure B.10 e B.11

viene descritta nelle Figure B.12 e B.13 utilizzando delle nuove notazioni.

Figura B.12: Modellamento dei ruoli con l'AUML

In Figura B.12, gli agenti sono indicati soltanto una volta ciascuno, e ad ogni

linea di vita è associato un ruolo indicato dallo stereotipo �role�; in Figura B.13,

invece, le barre di attivazione vengono �etichettate� con il nome del ruolo.

Ovviamente, come mostrato in Figura B.14, è possibile anche utilizzare i dia-

grammi di collaborazione, che, come si è già detto, hanno lo stesso potere espressivo

dei diagrammi di sequenza.

Altre estensioni proposte per i diagrammi di collaborazione e per i diagrammi di

attività sono riportate in [OPB00].

195

APPENDICE B. AUML

Figura B.13: Rappresentazione alternativa alla Figura A.12.

Figura B.14: Collaboration diagram AUML del protocollo di Figura A.10.

196

Bibliogra�a

[ABH+] A. Ankolekar, M. Burstein, J.R. Hobbs, O. Lassila, D. Martini, D. Mc-

Dermott, S.A. McIlraith, S. Narayanan, T. Payne, M. Paolucci, and

K. Sycara. DAML-S: Web service description for the semantic web.

[ACEP98] M. Aiello, N. Cancedda, B. Errico, and M. Pizzonia. Intelligenza

Arti�ciale: Un Approccio Moderno. UTET, 1998.

[Bar03] L. Barbieri. Web services, protocolli e strumenti interoperabilità ed

evoluzioni future, 2003.

[B.B00] J.Odell B.Bauer, J.P.Müller. Agent uml: A formal-

ism for specifying multiagent interaction, 2000. Url:

http://www.auml.org/auml/working/Bauer-AOSE2000.pdf.

[B.B01] B.Bauer. Uml class diagrams: Revisited in the context of agent-

based systems, 2001. Url: http://www.auml.org/auml/working/Bauer-

AOSE2001.pdf.

[BCPR] F. Bellifemine, G. Caire, A. Poggi, and G. Rimassa. JADE a white

paper. http://jade.tilab.com/ Volume 3 - n.3.

197

BIBLIOGRAFIA

[Beo03] Luciano Beolchi. Telemedicine Glossary. European Commission,

Information Society Directorate-General, �fth edition, 2003.

[Ber96] P. Bernstein. Middleware: a model for distributed system services.

Commun. ACM, 39(2):87 � 98, February 1996.

[BHR97] J. Baumann, F. Hohl, and K. Rothermel. Mole: Concepts of a mobile

agent system. Technical Report 1997/15, University of Stuttgart, August

1997.

[BK03] R. Braumandl and D. Kossmann. Quality of services in an informa-

tion economy. ACM Transactions on Internet Tecnology, 3(4):291 � 333,

November 2003.

[BNG] L. Baresi, E. Di Nitto, and C. Ghezzi. Inconsistency and Ephemerality

in a World of e-Services.

[BP] M. Bonati and C. Pandol�. L'informazione medico scienti�ca su internet:

certi�cazione, qualità e respondabilità.

[BS91] D. E. Bakken and R. D. Schlichting. Tolerating failures in the bag-of-tasks

programming paradigm. pages 248 � 255, 1991.

[BS98] G. Blair and J.B. Stefani. Open distributed processing and multimedia.

Reading, Ma: Addison-Wesley, 1998.

[BvHH+] S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuin-

ness, P. F. Patel-Schneider, and L. Andrea Stein. Owl web ontology

language reference. Technical report. W3C Recommendation.

198

BIBLIOGRAFIA

[BWY00] A. Barua, A. B. Whinston, and F. Yin. Value and productivity in the

internet economy. IEEE Computer, may 2000.

[Caia] G. Caire. JADE tutorial. applications-de�ned content languages and

ontologies. http://jade.tilab.com/.

[Caib] G. Caire. JADE tutorial. jade programming for beginners.

http://jade.tilab.com/.

[Cei] U. Cei. Quale strategia per i web services?

[Cer02] E. Cerami. Web services for bioinformatics, May 2002.

[CG98] Luca Cardelli and Andrew D. Gordon. Mobile ambients. In Maurice Ni-

vat, editor, Foundations of Software Science and Computational Struc-

tures, volume 1378 of Lecture Notes in Computer Science, pages 140�155.

Springer-Verlag Berlin Heidelberg, 1998.

[CKR+98] P. Ciancarini, A. Knoche, D. Rossi, R. Tolksdorf, and F. Vitali. Co-

ordinating multi-agents applications on the www: a reference archi-

tecture. In Proceedings of 3rd IEEE International Symposium on Au-

tonomous Decentralized Systems (ISADS), volume 24, pages 362�375.

IEEE Transactions on Software Engineering, May 1998.

[CLM03] J. Chung, K. Lin, and R. Mathieu. Web services computing: Advancing

software interoperability. IEEE Computer, 36(10):35 � 37, October 2003.

[CLZ] Giacomo Cabri, Letizia Leonardi, and Franco Zambonelli. Coordination

models for internet applications based on mobile agents.

199

BIBLIOGRAFIA

[CLZ00] G. Cabri, L. Leonardi, and F. Zambonelli. MARS: A programmable

coordination architecture for mobile agents. IEEE Internet Computing,

4(4):26�35, AUG 2000.

[CMM04] F. Corradini, L. Mariani, and E. Merelli. An agent base approac to tool

integration. Journal of Software Tools Tecnology Transfer. To appear,

2004.

[Coa] The OWL-S Services Coalition. Owl-s: Semantic markup for

web-services.

[Com0a] D. Comer. Internetworking with tcp/ip, volume 1: Principles, protocos

and architecture. Upper Saddle River, NJ: Prentice Hall, 2000a.

[Cow] D. Cowan. How to use arguments or properties to con�gure your agent.

Technical report. http://sharon.cselt.it/projects/jade.

[Cri] B. Crigger. Fondamenti del codice di ehealt dell'etica.

http://www.ihealthcoalition.org/.

[CS] D. Charnock and S. Shepperd. DISCERN on internet.

http://www.disvern.org.uk/.

[Cur89] B. Curties. Modeling coordination from �eld experiments, 1989. In pro-

cedings of the Conference on Organizational Computing, Coordination

and Collaboration: Theories and Tecnologies for Computer-Supported

Work.

[dam] Daml-s home page. http://www.daml.org/services/2003.

200

BIBLIOGRAFIA

[dce02] Commissione delle comunità europee. Criteri di qualità per i siti web

contenenti informazioni di carattere medico. Technical report, November

2002. eEurope 2002.

[DCvR] T. Dellwood, L. Clément, and C. von Riegen. Uddi spec tecnichal

committee speci�cation. Technical report. W3C Recommendation.

[DGMS02] M. Dorigo, L. M. Gambardella, M. Middendorf, and T. Stützle, editors.

Special Section on �Ant Colony Optimization�. IEEE Transactions on

Evolutionary Computation, 6(4), 317�365, 2002.

[DSW] K. Decker, K. Sycara, and M. Williamson. Middle-agents for the internet.

pages 578�583.

[DWS96] K. Decker, M. Williams, and K. Sycara. Matchmaking and brokering. In

ICMAS-96, May 1996.

[DZ83] J. Day and H. Zimmerman. The osi reference model. Proceedings of the

IEEE, 71(12):1334 � 1340, December 1983.

[FG96] S. Franklin and A. Graesser. A taxonomy for autonomous agents. Proc.

Third Int'l Workshop on Agent Theories, Architectures, and Languages,

pages 21 � 35, 1996.

[�p] Fipa home page. http://www.�pa.org.

[Fou89] National Science Foundation. A report by the nsf-iris review panel

for research on coordination theory and technology. NSFF Form and

Publication Unit, Washington, D.C., 1989.

201

BIBLIOGRAFIA

[Fou91] National Science Foundation. Coordination theory and collaboration

tecnology workshop summary. Washington, D.C., June 1991.

[Fra03] Frauenheim. Ibm gives free trial for dna tool. IBM, April 2003.

[GC92] D. Gelernter and N. Carriero. Coordination languages and their

signi�cance. Communications of the ACM, 35(2):96�107, Feb 1992.

[Gel85] D. Gelernter. Generative communication in linda. ACM Transactions on

Programming Languages and Systems, January 1985.

[Ger03] A. V. Gershman. Ecco in che modo i servizi web ride�niranno l'economia

del servizio, 2003.

[GOC] Gene ontology cross-reference abbreviations list.

http://www.geneontology.org/doc/go.xrf_abbs.

[Gri03] D. Grimshaw. JADE administrative tutorial, May 2003.

[Hay99] C.C. Hayes. Agents in a nutshell - a very brief intorduction. IEEE Trans.

Know. Data Eng., 11(1):127 � 132, Jan. 1999.

[Hoa74] C. Hoare. Monitors: An operating system structuring concept. Commun.

ACM, 17(10):549 � 557, October 1974.

[H.S96] H.S.Nwana. Software agents: an overview. Knowledge Engineering

Review, September 1996.

[jad] Jade home page. http://jade.tilab.com.

[JJQ+00] M. Jarke, M.A. Jeusfeld, C. Quix, T. Sellis, and P. Vassiliadis. Metadata

and data warehouses quality. Fundamentals of data warehouses, 2000.

202

BIBLIOGRAFIA

[JSW98] N.R. Jennings, K. Sycara, and M. Wooldridge. A road map of agent

research and development. Autonomous Agent and Multi-Agent System

Journal, 1(1):7 � 38, 1998.

[JW98] N. Jennings and M. Wooldridge. Application of intelligent agents. Agent

Technology Fondations, Applications, and Markets, pages 3 � 26, 1998.

[K+93] W. Kim et al. On resolving schematic heterogeneity in multidatabase

systems. Distributed And Parallel Databases, 1:251�279, 1993.

[KBH+] T. Kawamura, J.A. De Blasio, T. Hasegawa, M. Paolucci, and

K. Sycara. Preliminary Report of Public Experiment of Semantic Service

Matchmaker with UDDI Business Registry. Carnegie Mellon Univerity.

[KS01] M. Klusch and K. Sycara. Brokering and matchmaking for coordination

of agent societies: A survey. In Andrea Omicini, Franco Zambonelli,

Matthias Klusch, and Robert Tolksdorf, editors, Coordination of Internet

Agents: Models, Technologies, and Applications, chapter 8, pages 197�

224. Springer-Verlag, March 2001.

[LFP99] Y. Labrou, T. Finin, and Y. Peng. Agent communication languages: The

current landscape. IEEE Intellingent Systems, march 1999.

[LO98] D. B. Lange and M. Oshima. Programming and deploying Java mobile

agents with Aglets. Addison-Wesley, Reading, Massachusett, 1998.

[Mal88] T. W. Malone. What is coordination theory, 1988. Working Paper no.

2051-88. MIT Sloan School of Management, Cambridge, Mass.

[Mana] A. T. Maners. Infrastructure - level web services. Web Services Journal.

203

BIBLIOGRAFIA

[Manb] A. T. Maners. Registering a web services in uddi. Web Services Journal.

[Manc] A. T. Maners. Soap and security. Web Services Journal.

[Mand] A. T. Maners. Ws-i & w3c. Web Services Journal.

[MC88a] T. W. Malone and K. G. Crowston. Toward an interdisciplinary theory

of coordination, 1988. Teach. Rep. no. 120. Massachusetts Intitute of

Technology, Center for Coordination Science , Cambridge, Mass.

[MC88b] M. Mangel and C. W. Clark. Dynamic modeling in behavioral ecology,

1988. Princeton University Press, Princeton, N.J.

[MC94] T. W. Malone and K. Crowston. The interdisciplinary study of

coordination. ACM Computing Surveys, March 1994.

[McD03] D. McDermott. Surface syntax for owl-s-pai, October 2003.

[Mea94] P. Meas. Agents that reduce work and information overload. Commun.

ACM, 37(7):31 � 40, July 1994.

[MM] L. Mainetti and S. Mainetti. Tecnologie per la realizzazione di portali

web. Politecnico di Milano.

[myg] mygrid home page. http://www.mygrid.org.uk.

[Neu94] B. Neuman. Scale in distributed systems. Readings in Distributed

Computing Systems. Los Alamitos, CA: IEEE, pages 463 � 489, 1994.

[NFK+00] M. Nodine, J. Fowler, T. Ksiezyk, B. Perry, M. Taylor, and A. Un-

ruh. Active information gathering in infosleuth. Cooperative Information

Systems, 9(1-2), 2000.

204

BIBLIOGRAFIA

[Nil98] Nils J. Nilsson. Intelligenza Arti�ciale. Apogeo, 1998.

[Nwa96] H. Nwana. Software agents: an overview. Know. Eng. Rev, 11(3):205 �

244, October 1996.

[ont] Fipa abstract architecture speci�cation.

http://www.�pa.org/specs/�pa00001/.

[OPB00] J. Odell, H. Parunak, and B. Bauer. Extending uml for agents, 2000.

Url: http://www.jamesodell.com/ExtendingUML.pdf.

[os] Url: http://www.opensource.org/docs/de�nition_plain.php.

[OZ98] Andrea Omicini and Franco Zambonelli. TuCSoN: a coordination model

for mobile information agents. In David G. Schwartz, Monica Divitini,

and Terje Brasethvik, editors, 1st International Workshop on Innovative

Internet Information Systems (IIIS'98), pages 177�187, Pisa, Italy, 8�9

June 1998. IDI � NTNU, Trondheim (Norway).

[OZ99a] A. Omicini and F. Zambonelli. Coordination for internet application

development. Journal of Autonomous Agents and Multiagent Systems,

2(3), September 1999.

[OZ99b] A. Omicini and F. Zambonelli. Tuple centres for the coordination

of Internet agents. In 1999 ACM Symposium on Applied Computing

(SAC'99), pages 183�190, San Antonio, TX, USA, 28 February � 2

March 1999. ACM. Special Track on Coordination Models, Languages

and Applications.

205

BIBLIOGRAFIA

[OZKT98] A. Omicini, Franco Zambonelli, Matthias Klusch, and Robert Tolksdorf.

Coordination of Internet Agents. Models, Technologies and Applications.

Springer, 1998.

[Per03] C. Perltz. Web services orchestration and coreography. IEEE Computer,

36(10):46 � 52, October 2003.

[PKPSa] M. Paolucci, T. Kawamura, T.R. Payne, and K. Sycara. Importing the

Semantic Web in UDDI. Carnegie Mellon Univerity.

[PKPSb] M. Paolucci, T. Kawamura, T.R. Payne, and K. Sycara. Semantic

Matching of Web Services Capabilities. Carnegie Mellon Univerity.

[P.M96] A. Wexelblat P.Maes. Software agents, 1996. Url:

http://pattie.www.media.mit.edu/people/pattie/.

[PPD+95] R. Pike, D. Presotto, S. Dorward, B. Flandrena, K. Thompson, H. Trick-

ey, and P. Winterbottom. Plan 9 from bell labs. Computing Systems,

8(3):221 � 254, Summer 1995.

[PS97] Holger Peine and Torsten Stoplmann. The architecture of the Ara plat-

form for mobile agents. In Kurt Rothermel and Radu Pepescu-Zeletin,

editors, Mobile Agents. First Interation Workshop, MA '97, number 1219

in Lecture Notes in Computer Science, pages 50�61, Berlin, Germany,

April 1997. Springer-Verlag.

[PSNS] M. Paolucci, K. Sycara, T. Nishimura, and N. Srinivasan. Toward

Semantic Web Service Matchmaker . Carnegie Mellon Univerity.

206

BIBLIOGRAFIA

[PTM98] J. Protic, M. Tomasevic, and V. Milutinovic. Distributed shared memory,

concepts and systems. Los Alamitos, CA: IEEE Computer Society Press,

1998.

[Sco02] The Stencil Scope. The evolution of UDDI.org white paper, July 2002.

[SdF] M. Sheshagiri, M. desJardins, and T. Finin. A planner for Composing

Services Described in DAML-S .

[SFKH03] S. Schulz, M. Friedrich, W. Küchlin, and T. Hüttner. A rmi-security-

extension using the permi framework. In Proceedings of 2003 Netobject

Days, Erfurt, Germany, September 2003. transit.

[Sho02] Scott Short. Creare XML Web Service. Mondadori Informatica, �rsth

edition, 2002.

[Sin92] B. Singh. Interconnected roles: A coordinated model, 1992. CT-84-92.

Microelectronics and Computer Technology Corp., Austin, Tex.

[SKL99] A. Sheth, V. Kashyap, and T. Lima. Semantic information brokering:

How can a multi-agent approach help? pages 303�322, July 1999.

[Sle01a] B. Sleeper. De�ning web services. The Stencil Scope, June 2001.

[Sle01b] B. Sleeper. Why uddi will succeed, quietly: two factors push web services

forwoard. The Stencil Scope, April 2001.

[SRvS] M. Sabou, D. Richards, and S. van Splunter. An experience report on

using daml-s.

[Ste99] W. Stevens. Unix network programming - networking apis: Sockets and

xti. Cli�s, NJ: Prentice Hall, 1999.

207

BIBLIOGRAFIA

[SWKL02] K. Sycara, S. Wido�, M. Klusch, and J. Lu. Larks: Dynamic matchmak-

ing among heterogeneous software agents in cyberspace. Autonomous

Agents and Multi-Agent Systems, (5):173�203, 2002.

[SWM] Smith, Welty, and McGuinness. Owl web ontology language guide.

Technical report. W3C Recommendation.

[SZ96] K. Sycara and D. Zend. Coordination of multiple intelligent software

agents. Cooperative Information Systems, 5(2-3), 1996.

[Tan96] A. Tanenbaum. Computer networks. Englewood Cli�s, NJ: Prentice Hall,

1996.

[Tan01] A. Tanenbaum. Modern operating systems. Upper Saddle River, NJ:

Prentice Hall, 2001.

[TBB03] M. Turner, D. Budgen, and P. Brereton. Turninig software into a services.

IEEE Computer, 36(10):38 � 44, October 2003.

[Tea02a] HealthIndite Editorial Team. Assessment of content for healtinsite,

December 2002. ninth version.

[Tea02b] HealthIndite Editorial Team. Publishing standards for healtinsite,

December 2002. third version.

[tNF] Health On the Net Foundation. Hon code. http://www.hon.ch/.

[TPR01] M. Tomaiuolo, A. Poggi, and G. Rimassa. Multi user and sicurity support

for multi agent system, September 2001.

[TS03] A. S. Tanenbaum and M. Van Steen. Distributed Systems principles and

paradigms. Prentice Hall, 2003.

208

BIBLIOGRAFIA

[TSS+97] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. Wether-

all, and G. J. Minden. A survey of active network research. IEEE

Communications Magazine, 35(1):80�86, January 1997.

[TWW03] T. Thompson, R. Weil, and M.D. Wood. Cpxe: Web services for internet

imaging. IEEE Computer, 36(10):54 � 62, October 2003.

[TYS+03] T. Tsai, H. Yu, H. Shih, P. Liao, R. Yang, and S. Chou. Ontology-

mediated integration of web services. IEEE Computer, 36(10):46 � 52,

October 2003.

[UDDa] UDDI. UDDI executive white paper. http://www.udddi.org/.

[UDDb] UDDI. UDDI tecnical white paper. http://www.udddi.org/.

[VN] J. Vaucher and A. Ncho. JADE tutorial and primer. http://jade.cselt.it/.

[WGFS03] M.D. Wilkinson, D. Gessler, A. Farmer, and L. Stein. The biomoby

project explores open-source, simple, extensible protocols for enabling

biological database interoperability, 2003. Procedings of the virtual

conference on genomics and bioinormatics. (3):17-27.

[Wie92] G. Wiederhold. Mediators in the architecture of future information

systems. IEEE Computer System, 25(3):38 � 49, March 1992.

[WJ95a] M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and

practise. Knowledge Engineering Review, 10(2):115 � 152, 1995.

[WJ95b] Michael J. Wooldridge and Nicholas R. Jennings. Agent theories, ar-

chitectures and languages: A survey. In Michael J. Wooldridge and

209

BIBLIOGRAFIA

Nicholas R. Jennings, editors, Intelligent Agents: ECAI-94 Workshop

on Agent Theories, Architectures and Languages. Springer-Verlay, 1995.

[WL02] M.D. Wilkinson and M. Links. Biomoby: an open source biological web

services proposal. Brie�ngs in Bioinformatics, December 2002.

[WLW98] H. Wang, M.K. Lo, and C. Wang. Consumer privacy concerns about

internet marketing. Commun. ACM, 41(3):63 � 70, March 1998.

[WN99] W.Shen and D.H. Norrie. Agent-based systems for intelligent manufac-

turing: A state-of-the-art survey. Knowledge and Information Systems,

1(2):129 � 156, 1999.

[Woo98] M. Wooldridge. Agent-based computing. Interoperable Communication

Networks, 1(1):71 � 96, Jan 1998.

[Woo99] M. Wooldridge. Intelligent agents, in multiagent systems: A modern

approach to distributed arti�cial intelligence. G. Weiss, 1999. MIT Press,

Cambridge, MA.

[WSG+] C. Wroe, R. Stevens, C. Goble, A. Roberts, and M. Wood. A suit of

DAML+OIL ontologies to describe bioinformatics web services and data.

[Zon03] R. Zonin. Sviluppo di applicazioni in web services. Network News,

(123):18 � 20, March 2003.

210

Documents

Tesi - Un modello di qualità per la scelta di servizi Web in ambito Biomedico (il ruolo dei modelli