Analisi

 

S.O.M.A.

Il punto di partenza e' costituito dal sistema S.O.M.A.(Secure Open Mobile Agent), sviluppato presso il D.E.I.S (Dipartimento di Elettronica Informatica e Sistemistica) dell' Universita' di Bologna. S.O.M.A. e' una piattaforma per la realizzazione di applicazioni ad agenti mobili, costituita da un middleware di servizi tra i quali: sistema di nomi, comunicazione, mobilita', monitoraggio, sicurezza. Il framework oggetto del presente progetto (D.I.A.Log.A.) e' basato su S.O.M.A. e ne rappresenta una estensione.

Quali servizi offrire

La prima fondamentale scelta rigurda il tipo di servizi che il framework dovra' offrire allo sviluppatore di applicazioni. D.I.A.Log.A e' composto da una parte di estensione di S.O.M.A. (middleware layer) e dallo scheletro di una applicazione ad agenti coordinati (agent layer). Il livello middleware comprende un motore inferenziale di base costituito da un'interprete del linguaggio Prolog, un motore inferenziale definibile dall'utente (scritto in Prolog), una base di conoscenza globale (anch'essa definibile facoltativamente). Il livello agente comprende un agente stazionario con compiti di coordinazione centrale e di interfaccia verso l'utente e di uno o piu' agenti mobili. Gli agenti trasportano il componente definito dall'utente che contiene la logica della applicazione (Attore), fornendogli i servizi del livello sottostante. La comunicazione tra coordinatore ed agenti mobili avviene tramite il meccanismo a scambio di messaggi fornito da S.O.M.A.

Motivazioni:

Il linguaggio Prolog e' un linguaggio di tipo logico-dichiarativo nato negli anni settanta come risultato degli studi sul principio di risoluzione e sulla dimostrazione automatica di teoremi. E' oggi uno dei principali linguaggi impiegati per la realizzazione di sistemi basati sulla conoscenza. Prolog puo' essere impiegato in un SE sia come linguaggio di realizzazione sia come nucleo di base estendibile. Questo giustifica la scelta di un interprete Prolog come motore inferenziale di base offerto dal Framework, lasciando all'utente la liberta' di estenderlo. La scelta di integrare l'interprete nel livello middleware anziche' nell'agente mobile, d'altra parte, e' motivata dal fatto che, trattandosi di un servizio del framework e dunque invariante rispetto alla applicazione, si riduce cosi' al minimo indispensabile il codice effettivamente trasferito, con relativo overhead. A questo proposito, una delle caratteristiche di D.I.A.Log.A e' quella di offrire alla applicazione (ovvero al componente attore definito dall'utente) l'astrazione di motore d'inferenza mobile virtuale. Con questo termine si intende il fatto che, benche' il motore inferenziale (con la relativa base di conoscenza) sia un oggetto diverso per ogni nodo visitato, dal punto di vista del suo utilizzo da parte dell'attore e' come se venisse spostato. Ad esempio, supponiamo che l'applicazione asserisca un certo fatto sul nodo host1 (ad esempio q(1)), dopodiche' si sposti verso host2. In questo caso q(1) e' un fatto vero anche sul nodo host2, perche' si e' trasferito lo stato delle interazioni tra attore e motore inferenziale. Questo consente un uso molto "naturale" della base di conoscenza da parte della applicazione. Le clausole contenute nella base di conoscenza globale sono le uniche che contravvengono a questa regola. La base di conoscenza globale fa parte del livello middleware del sistema, il suo utilizzo e' facoltativo. Essa puo' contenere clausole che lo sviluppatore considera di uso generale e la cui differenza rispetto a cio' che viene asserito (o ritrattato) dall'attore e' che esse sono sempre valide all'arrivo di un'agente su un nuovo nodo, anche se, per esempio, una di esse era stata ritrattata precedentemente. Sono clausole, per cosi' dire, di "default". Nell'ottica di fornire dei meccanismi flessibili di uso quanto piu' possibile generale, il framework prevede la possibilita' di definire un terzo tipo di conoscenza, la conoscenza "locale". Maggiori dettagli saranno discussi nel capitolo seguente.