Semantic coordination tuple centres for eHealth Systems

In questa tesi partendo dai limiti sintattici dello scambio di Electronic Patient Records (EHRs), si arriva alla creazione di un framework che supporti lo scambio di informazioni semantiche. Il framework creato si chiama Semantic TuCSoN ed è una estensione di TuCSoN (Tuple Centres Spread over the Network). Semantic TuCSoN viene modellato per il contesto eHealth definendo gli agenti e le politiche di coordinamento atte allo scambio di EHR. Questo framework vine infine testa per verificarne le performance allo scopo di valutare un suo ulteriore utilizzo.

BioTuCSoN: biochemical extension of TuCSoN to support self-organising coordination

Starting from pervasive computing paradigm, we want to face the new system's requirements, concerning, mainly, self-organisation, situatedness and adaptivity, through the definition and execution of nature-inspired patterns. They are extracted by the study of dynamics in biological systems and we consider for their implementation the biochemical tuple spaces model. In particular, the aim of the thesis is to design and realize a first biochemical extension of TuCSoN (technology based on tuple spaces model) and, then, to verify its capabilities by means of a proper case study, that deals with local self-organisation and competition of services in an open and highly-dynamic environment.

Coordination as a Service (CaaS) in the Cloud

Nel primo capitolo si è studiata la nuova tecnologia del Cloud Computing, fornendo una semplice analisi di tutte le caratteristiche principali, gli attori coinvolti e i relativi metodi di distribuzione e servizi offerti. Nel secondo capitolo si è introdotta la nozione di coordination as a service, discutendone le relative astrazioni che compongono l'architettura logica. Successivamente si è preso in considerazione il modello di coordinazione TuCSoN definendo cosa si intende per nodo, agente, centro di tuple e agent coordination context ed è stato analizzato il relativo linguaggio di coordinazione attraverso il quale essi interagiscono. Nel terzo capitolo sono state riviste ed estese le nozioni di TuCSoN, precedentemente acquisite, nell'ambito del Cloud Computing ed è stato fornito un modello astratto ed una possibile architettura di TuCSoN in the Cloud. Sono stati analizzati anche gli aspetti di un possibile servizio di tale genere nello scenario di servizio pay-per-use. Infine nel quarto ed ultimo capitolo si è sviluppato un caso di studio in cui si è implementata un'interfaccia per l'attuale CLI di TuCSoN sottoforma di applet, che è stata poi inserita nel Cloud attraverso la piattaforma PaaS Cloudify.

Agents, nodes & resources: Universal naming system for a coordination middleware

La tesi si propone di sviluppare un modello, l'architettura e la tecnologia per il sistema di denominazione del Middleware Coordinato TuCSoN, compresi gli agenti, i nodi e le risorse. Identità universali che rappresentano queste entità, sia per la mobilità fisica sia per quella virtuale, per un Management System (AMS, NMS, RMS) distribuito; tale modulo si occupa anche di ACC e trasduttori, prevedendo questioni come la tolleranza ai guasti, la persistenza, la coerenza, insieme con il coordinamento disincarnata in rete, come accade con le tecnologie Cloud. All’interno dell’elaborato, per prima cosa si è fatta una introduzione andando a descrivere tutto ciò che è contenuto nell’elaborato in modo da dare una visione iniziale globale del lavoro eseguito. Di seguito (1° capitolo) si è descritta tutta la parte relativa alle conoscenze di base che bisogna avere per la comprensione dell’elaborato; tali conoscenze sono relative a TuCSoN (il middleware coordinato con cui il modulo progettato dovrà interfacciarsi) e Cassandra (sistema server distribuito su cui si appoggia la parte di mantenimento e salvataggio dati del modulo). In seguito (2° capitolo) si è descritto JADE, un middleware da cui si è partiti con lo studio per la progettazione del modello e dell’architettura del modulo. Successivamente (3° capitolo) si è andati a spiegare la struttura e il modello del modulo considerato andando ad esaminare tutti i dettagli relativi alle entità interne e di tutti i legami fra esse. In questa parte si è anche dettagliata tutta la parte relativa alla distribuzione sulla rete del modulo e dei suoi componenti. In seguito (4° capitolo) è stata dettagliata e spiegata tutta la parte relativa al sistema di denominazione del modulo, quindi la sintassi e l’insieme di procedure che l’entità consumatrice esterna deve effettuare per ottenere un “nome universale” e quindi anche tutti i passaggi interni del modulo per fornire l’identificatore all’entità consumatrice. Nel capitolo successivo (5° capitolo) si sono descritti tutti i casi di studio relativi alle interazioni con le entità esterne, alle entità interne in caso in cui il modulo sia o meno distribuito sulla rete, e i casi di studio relativi alle politiche, paradigmi e procedure per la tolleranza ai guasti ed agli errori in modo da dettagliare i metodi di riparazione ad essi. Successivamente (6° capitolo) sono stati descritti i possibili sviluppi futuri relativi a nuove forme di interazione fra le entità che utilizzano questo modulo ed alle possibili migliorie e sviluppi tecnologici di questo modulo. Infine sono state descritte le conclusioni relative al modulo progettato con tutti i dettagli in modo da fornire una visione globale di quanto inserito e descritto nell’elaborato.

Coordination nel Cloud: Elasticità in Respect

L'elasticità è un concetto fondamentale nell'ambito del cloud computing, ma propone problemi di coordinazione che, se non compresi nella loro natura, rischiano di renderla inefficiente. Tramite il concetto di “elasticità consapevole della coordinazione” (coordination-aware elasticity), in questa tesi si discute come si possa espandere il linguaggio per l’elasticità cloud SYBL in modo che possa eseguire alcune funzioni elastiche tramite il linguaggio di coordinazione ReSpecT.