3.Rendiconto scientifico delle attivitą presso le sedi partecipanti

Unità di       Universita' degli Studi di CATANIA

Responsabile ANTONELLA DI STEFANO

Quota Cofinanziamento Murst  31.040.000

Quota Cofinanziamento Ateneo  38.400.000 (RD+RA certificata)

Fondi complessivi utilizzati il primo anno  21.934.722

Illustrazione dell'attivita' svolta

L'unit… di Catania e' coinvolta nel Tema 1 - "Metodologie di Progetto di Basi di Dati Distribuite". I risultati ottenuti nel primo anno sono quelli previsti nella proposta e sono descritti nei rapporti TR1-R03 e TR1-R04, e includono anche il prototipo software ARCA - Autonomous Remote Cooperating Agents, una piattaforma Java-based per la programmazione degli agenti mobili. Le attivita' di ricerca svolte durante il primo anno hanno mirato alla definizione di un modello transazionale ad agenti mobili ed alla realizzazione di un framework ad agenti mobili nel quale successivamente integrare le funzionalita' necessarie a supportare il modello transazionale proposto. Sono stati valutati diversi framework esistenti per la programmazione di applicazioni ad agenti mobili e cio' ha portato alla progettazione ed implementazione di una piattaforma proprietaria Java-based, denominata ARCA - Autonomous Remote Cooperating Agents (disponibile all'indirizzo http://netra.cdc.unict.it/ARCA). Nel progettare tale piattaforma, Š stato curato in modo particolare l'aspetto relativo alla collaborativit… tra agenti e sono stati implementati due modelli di cooperazione. Il primo modello Š basato sul message passing esplicito ed offre la possibilit… ad un agente di inviare, in modo affidabile, un messaggio ad un agente destinatario; il messaggio Š caratterizzato da un'informazione di tipo, che consente una sorta di etichettatura del messaggio, da una priorit… e dai dati che esso trasporta. In ricezione, l'agente destinatario ha a disposizione un set di primitive molto versatili in grado di imporre, sui messaggi da acquisire, un "filtro" basato sul tipo, sulla priorit… e/o sull'agente sorgente del messaggio. Il secondo modello di cooperation, denominato agent action invocation, Š invece basato su una sorta di remote method invocation e consente, al sender agent, di invocare in modo sincrono, asincrono o one-way, uno dei metodi dell'oggetto/agente che quest'ultimo ha deciso di rendere pubblico all'ambiente distribuito. Questi modelli consentono di far fronte a tutte le esigenze di collaborativit… tra agenti richieste da un'applicazione ad agenti mobili. Nell'affrontare lo studio delle transazioni ad agenti mobili distribuite in Internet, la ricerca Š partita dall'analisi di alcuni standard di servizi transazionali, tra cui il CORBA Transaction Service adatto agli ambienti object-oriented. E' stato quindi definito un framework object oriented, denominato Mobile Transaction Environment, per l'esecuzione ed il management di transazioni distribuite ad agenti mobili. Esso si basa sostanzialmente sulla rielaborazione del concetto di subtransaction, la quale viene incapsulata in un agente mobile che, creato nel sito di avviamento della transazione distribuita, raggiunge il sito di competenza ed esegue localmente la computazione legata alla subtransaction. Partendo quindi da una struttura a grafo aciclico di una transazione distribuita, Š stato definito il mapping tra le subtransactions e l'insieme di agenti mobili cooperanti che partecipano alla transazione (denominati TransactionAgent), ed il comportamento che gli agenti stessi devono seguire affinche' la transazione evolva e si concluda nel rispetto delle ACID properties. Nel progettare il Mobile Transaction Environment sono stati considerati i seguenti punti: 1. indipendenza dalla tipologia di risorse transazionali da trattare; 2. massima flessibilit… nel management della transazione, ossia nessuna ipotesi di base sui protocolli che regolano il rispetto delle ACID properties e quindi possibilit… di implementare tecniche proprietarie; 3. possibilit… di sfruttare la mobilit… per distribuire la conoscenza sulla struttura della transazione e sulle risorse da essa utilizzate, in modo che ci• possa essere di aiuto per i protocolli di atomic commitment e concurrency control; 4. possibilit… di interfacciamento al Web; Per permettere l'interfacciamento con ambienti eterogenei il modello prevede la presenza, in ogni sito dell'ambiente distribuito, di agenti statici, denominati ResourceAgent: ognuno di essi, ha la funzione di interfaccia tra una risorsa locale e l'ambiente transazionale ad agenti. Il ResourceAgent Š pertanto composto da due porzioni: una site-independent usata per cooperare, tramite un opportuno Agent Coordination Language (ACL) comune all'ambiente distribuito, con gli agenti che compongono la transazione, ed una site-dependent, in cui le richieste di accesso sulla risorsa transazionale, eseguite dagli agenti tramite l'ACL, vengono tradotte nelle relative system call locali per la gestione della risorsa stessa. L'utilizzo dei ResourceAgent permette di non fare assunzioni a priori sulla tipologia delle risorse transazionali presenti nei vari siti della rete. Per evitare di fare ipotesi sul tipo di ACL da utilizzare (es. KQML o altro), le interfacce sia con il ResourceAgent che con le altre entit… del modello sono definite utilizzando il CORBA-IDL. In particolare, per il ResourceAgent le operazioni di base possibili sono l'apertura di una transazione, il commit, il rollback ed il recovery. Per quanto riguarda la flessibilita', gli oggetti del modello sono stati definiti in modo da consentire al programmatore della transazione di implementare tecniche ad hoc per la garanzia delle ACID properties. Pur rendendo possibile l'integrazione di altre soluzioni per il concurrency control e per il committment, il modello prevede comunque un protocollo di two-phase locking, e, per il committment, un protocollo distribuito asincrono ad una fase il quale, con opportune modifiche, si Š rivelato particolarmente adatto ad un ambiente ad agenti mobili. Nel modello proposto, gli oggetti per il management della transazione sono denominati TransactionContext: essi sono agenti mobili che rappresentano il "contesto di una subtransaction" eseguita in un determinato sito. Il TransactionContext Š composto da due porzioni: la prima contiene le informazioni di stato della subtransaction, ovvero l'elenco dei ResourceAgent coinvolti, gli eventuali lock acquisiti e l'elenco dei siti relativi alle subtransaction direttamente connesse (padri o figli), la seconda contiene il codice di management della subtransaction, ovvero i protocolli per la gestione delle ACID properties per la relativa transazione distribuita. In seguito alla migrazione di un TransactionAgent, il solo codice del TransactionContext viene clonato ed installato nel nuovo sito insieme all'agente transazionale, al contrario delle informazioni di stato le quali, essendo relative solo alla subtransaction del sito di origine non Š necessario che viaggino in rete. La migrazione del codice del TransactionContext consente di distribuire nei vari siti, gi… durante l'esecuzione della transazione, gli eventuali protocolli transazionali proprietari. Tuttavia, se si Š scelto di utilizzare i protocolli predefiniti, tale migrazione non sar… necessaria, ma occorrer… semplicemente creare, nel nuovo sito, un'istanza del TransactionContext di default, il quale conterr… gi… i protocolli richiesti. E' altres possibile decidere di migrare tutto o parte delle informazioni di stato del TransactionContext, in modo da distribuire ai vari siti, gi… durante l'esecuzione della transazione, la conoscenza sulla struttura della transazione distribuita stessa; ci• pu• consentire l'implementazione di protocolli pi— efficienti di commitment o di concurrency control distribuito. Per quanto concerne l'interfacciamento al Web sono state implementate delle classi utilizzabili da Applet Java in grado di "mediare" la comunicazione tra il browser dell'utente ed il framework transazionale. In particolare, i metodi presenti consentono l'avviamento di una nuova transazione, la notifica all'utente dei risultati ed il controllo dell'evoluzione della transazione stessa. Riguardo l'architettura a supporto di transazioni real-time distribuite su Intranet, l'attivit… di ricerca condotta durante il secondo semestre del primo anno di attivit… ha riguardato lo studio di un'architettura funzionale a supporto delle transazioni di un Distributed Real Time Database System (DRTDS). Lo scenario in esame Š costituito da un insieme di nodi, con caratteristiche omogenee, tra loro connessi da una Intranet. Nel modello qui considerato, i dati sno distribuiti su pi— server e le transazioni generate da un client possono essere opportunamente suddivise in sottotransazioni, ognuna delle quali va eseguita su un server. Pi— specificatamente, si distinguono due categorie di transazioni: 1. transazioni locali, che coinvolgono un unico server; 2. transazioni globali, inoltrate su un server ed ivi suddivise, in base alle risorse cui richiedono di accedere, in sottotransazioni da eseguire su vari server. Ogni transazione globale Š modellata da un Direct Acyclic Graph (DAG), che si suppone noto nel momento in cui essa Š generata. Ogni nodo del DAG rappresenta una sottotransazione; i nodi figli rappresentano le sottotransazioni che potranno essere attivate solo dopo che la sottotransazione madre avr… terminato la sua esecuzione. Il tempo di esecuzione stimato nel caso peggiore (worst case execution time) di una transazione locale si suppone noto. Per quanto riguarda una transazione globale, noti i tempi di esecuzione nel caso peggiore di tutte le sue sottotransazioni, il tempo di esecuzione stimato nel caso peggiore si ricava dal DAG della transazione. Il sistema Š firm, per cui se una transazione, nel corso dell'esecuzione, supera la deadline, non viene pi— considerata valida e viene abortita. Ogni server del database distribuito Š individuato dall'identificatore presso cui risiede e da una porta. Entrambi i valori devono essere noti al client che desideri richiedere l'esecuzione di una sua transazione su un server. L'architettura proposta prevede l'esistenza su ciascun host di un modulo, detto Network Manager, che riceve le richieste di transazione generate dai client e le inoltra ad un particolare processo, chiamato Selector, che si occupa di instradarle verso gli opportuni destinatari. Sono stati previsti moduli diversi per la gestione delle transazioni globali (Global Transaction Manager, Master) e delle transazioni locali (Mediator). Questi moduli si occupano, tra l'altro, dell'assegnazione delle deadline (nel caso delle sottotransazioni di una transazione globale viene utilizzato il DAG della transazione globale). L'esecuzione delle transazioni Š schedulata in base ad un parametro di priorit… ed Š affidata a dei moduli detti Worker Tread, che interagiscono con un altro modulo (Lock Manager), che implementa il controllo di concorrenza, per quanto concerne l'accesso alle risorse condivise. Su ciascun host Š anche presente un modulo (Message Manager) che gestisce sia i messaggi che indicano che una sottotransazione in esecuzione su un altro server ha terminato, e che quindi Š possibile mandare in esecuzione le sottotransazioni figlie residenti sul server corrente, sia i messaggi relativi al committment delle transazioni globali (regolato dal Master della transazione stessa). I risultati ottenuti, oltre ad essere descritti nei rapporti tecnici elencati alla fine della presente relazione, hanno portato a due pubblicazioni su riviste internazionali e due pubblicazioni in atti di convegni internazionali con revisione. Prodotti: T1-R03. "Vincoli temporali di transazioni real-time distribuite su un'Intranet" A. Di Stefano, L. Lo Bello, C. Santoro T1-R04. "Modeling distributed transactions by means of mobile agents" A. Di Stefano, L. Lo Bello, C. Santoro ARCA - Autonomous Remote Cooperating Agents - http://netra.cdc.unict.it/ARCA

Schema riassuntivo dei fondi utilizzati (cifre spese o impegnate)
 

Voce di spesa	Cifra spesa o impegnata	Descrizione
Materiale inventariabile	3.286.160
Grandi Attrezzature	0.000
Materiale di consumo	1.642.757
Spese per calcolo ed elaborazione dati	0.000
Personale a contratto	0.000
Servizi esterni	0.000
Missioni	17.005.805
Altro	0.000