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 di un’applicazione client per svolgere le funzionalità di feed aggregator  Estensione del sistema per il supporto alla replicazione dei centri di tuple

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

Architettura di base

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

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

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

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

Modello di replicazione

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

Procedura di recupero da guasti

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

Demo

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”