Multi agent System per la gestione di feed RSS. Obiettivi  Progettazione di un sistema ad agenti basato su tucson per la gestione di feed RSS  Sviluppo.

Presentazione sul tema: "Multi agent System per la gestione di feed RSS. Obiettivi  Progettazione di un sistema ad agenti basato su tucson per la gestione di feed RSS  Sviluppo."— Transcript della presentazione:

1 Multi agent System per la gestione di feed RSS

2 Obiettivi  Progettazione di un sistema ad agenti basato su tucson per la gestione di feed RSS  Sviluppo di un’applicazione client per svolgere le funzionalità di feed aggregator  Estensione del sistema per il supporto alla replicazione dei centri di tuple

3 Funzionalità principali  Recupero di un feed RSS  Ricerca di feed RSS basata su parole chiave  Iscrizione ad un feed RSS E’ stato scelto di realizzare un agente per ogni singola funzionalità:  Integrazione in sistemi ad agenti preesistenti  Maggiore semplicità del singolo agente

4 Architettura di base

5 Retrieve Agent 1. Riceve le richieste di feed RSS 2. Invia le informazioni relative al canale 3. Invia le informazioni relative alle notizie del canale

6 Search Agent 1. Riceve le richieste di ricerca 2. Invia le informazioni sul numero di risultati ottenuti 3. Invia i singoli risultati

7 Subscription Agent 1. Riceve richieste di iscrizione a feed RSS 2. Riceve richieste di disiscrizione a feed RSS 3. Invia una messaggio di conferma 4. Invia le notizie aggiornate

8 Gestione della replicazione Approccio utilizzato orientato a:  Indipendenza dal contesto applicativo  Indipendenza dalle particolari interazioni  Facile riusabilità per l’estensione in sistemi ad agenti basati su tucson preesistenti Ipotesi di replicazione:  Guasto singolo  Conoscenza a priori dei nodi che partecipano alla replicazione  Non sono state fatte ipotesi di gerarchia tra i nodi

9 Modello di replicazione

10 Procedura di recupero da guasti  Ogni nodo mantiene la persistenza dei centri di tuple locali  Ogni nodo tiene traccia degli eventi che non è riuscito ad inoltrare al nodo caduto.  Il nodo caduto, alla riattivazione, richiede la sincronizzazione agli altri nodi  I nodi presenti nel cluster inoltrano tutti gli eventi registrati

11 Procedura di recupero da guasti

12 Accesso al cluster di nodi  Accesso trasparente delle applicazioni client al cluster di nodi – controllo implicito  Utilizzo dell’Aspect Oriented Programming per inoltrare le operazioni al nodo opportuno

13 Demo

14 Conclusioni e sviluppi futuri Pros:  Soluzione indipendente dal contesto applicativo  Approccio AOP permette una facile riutilizzabilità Cons:  Possibilità di inconsistenze (mancanza supporto AB)  Mancanza del supporto al guasto multiplo Sviluppi futuri  Supporto all’atomic broadcast  Supporto al guasto singolo  Politiche di aggiornamento “più intelligenti”