Analisi ed Ottimizzazione dell Architettura Software di un Gateway Domotico Intelligente

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Analisi ed Ottimizzazione dell Architettura Software di un Gateway Domotico Intelligente"

Transcript

1 POLITECNICO DI TORINO Corso di Laurea in Ingegneria Gestionale Tesi di Laurea Specialistica Analisi ed Ottimizzazione dell Architettura Software di un Gateway Domotico Intelligente Relatori: prof. Fulvio Corno ing. Dario Bonino Candidato: Luca Semprini Dicembre 2012

2 ii

3 Indice 1 Introduzione Scenario Obiettivi Struttura del documento Il framework OSGi Vantaggi e svantaggi di OSGi Architettura del framework OSGi Module Layer Life Cycle Layer Service Layer Servizi dinamici Service Tracker Declarative Service OSGi Service Compendium Device Access Specification Event Admin Service Specification Monitor Admin Service Specification Configuration Admin Service Specification Il gateway DOG DogOnt DogOnt ontology DogOnt rules Architettura di Dog Dog Core Dog Drivers Dog Add-ons iii

4 4 Analisi di DOG Analisi dei bundle DogExecutor DogDeviceManager DogNotificationManager DogStateMonitor DogScheduler Altre specifiche OSGi e riepilogo delle conformità Configuration Admin Service Specification Remote Services Specification Riepilogo delle conformità Criticità di DOG Classificazione delle criticità Riepilogo delle criticità Verso DOG Ordinamento delle criticità Dog Test Meccanismi di comunicazione in DOG Event Admin Service Gestione dello stato dei device in DOG Monitor Admin Service Dog Scheduler Conclusioni e sviluppi futuri 91 Bibliografia 93 iv

5 Elenco delle figure 2.1 Livelli del framework OSGi Diagramma di stato del Life Cycle Layer OSGi Architettura dei Remote Service Diagramma delle classi della Device Access Specification Diagramma delle classi del Event Admin Service Diagramma delle classi del Monitor Admin Service Primo diagramma di sequenza del Monitor Admin Service Secondo diagramma di sequenza del Monitor Admin Service Esempio di interazione con il Configuration Admin Service Architettura del Configuration Admin Service Diagramma di sequenza di un Managed Service Architettura di un Intelligent Domotic Environment che utilizza DOG Struttura di DogOnt ontology Esempio di interconnessione tra una lampada ed uno switch Architettura di DOG Core layer di DOG Struttura dei Driver in DOG Servizi dei principali bundle di DOG Dipenze del DogExecutor da altri bundle Servizi del bundle DogExecutor Diagramma delle classi del bundle DogExecutor Interazione tra i bundle dell esempio relativo al DogExecutor Diagramma di sequenza dell esempio relativo al DogExecutor Dipenze del DogDeviceManager da altri bundle Servizi del bundle DogDeviceManager Diagramma delle classi del bundle DogDeviceManager Diagramma di sequenza dell esempio relativo al DogDeviceManager Servizi del bundle DogNotificationManager Diagramma delle classi del bundle DogNotificationManager Interazione tra i bundle dell esempio relativo al DogNotificationManager 55 v

6 4.14 Diagramma di sequenza dell esempio relativo al DogNotificationManager Servizi del bundle DogStateMonitor Diagramma delle classi del bundle DogStateMonitor Interazione tra i bundle della prima parte dell esempio relativo al DogStateMonitor Interazione tra i bundle della seconda parte dell esempio relativo al DogStateMonitor Primo diagramma di sequenza dell esempio relativo al DogStateMonitor Secondo diagramma di sequenza dell esempio relativo al DogState- Monitor Servizi del bundle DogScheduler Diagramma delle classi del bundle DogScheduler Interazione tra i bundle della prima parte dell esempio relativo al DogScheduler Interazione tra i bundle della seconda parte dell esempio relativo al DogScheduler Diagramma di sequenza dell esempio relativo al DogScheduler Diagramma delle classi dei bundle DogSemanticHouseModelTest e DogTest Confronto tra i diversi meccanismi di comunicazione previsti in DOG Servizi del bundle org.eclipse.equinox.event Confronto della gestione degli eventi in DOG 2.3 e in DOG Diagramma delle classi della rappresentazione degli stati in DOG Servizi del bundle MonitorAdmin in DOG Confronto della differente interazione con gli altri bundle del sistema del DogStateMonitor (DOG 2.3) e del DogMonitorAdmin (DOG 3) Servizi del bundle DogScheduler in DOG vi

7 Capitolo 1 Introduzione 1.1 Scenario I sistemi domotici sono disponibili sul mercato da diversi anni ma la loro diffusione, sia in contesti domestici (Home Automation) che, più in generale, negli edifici (Building Automation), è aumentata solo recentemente. Tra i fattori che hanno portato a questa nuova tendenza bisogna ricordare la maggiore disponibilità di dispositivi, con costi sempre più contenuti, e il crescente interesse attorno a tematiche quali il risparmio energetico, la sicurezza e la qualità della vita, con particolare attenzione per le persone disabili. In realtà, l affermazione di questi sistemi è ancora limitata da alcune criticità. Innanzitutto non esiste uno standard unico per la comunicazione tra dispositivi, in quanto spesso i produttori utilizzano dei protocolli di comunicazione proprietari. Inoltre questi dispositivi sono di frequente un evoluzione dei componenti elettrici tradizionali (e.g., interruttori o relè) e permettono, quindi, solo semplici interazioni di automazione. Verso la fine degli anni 90 la progettazione dei sistemi domotici aderiva alla filosofia dominante delle smart home. Con questo termine si indicano abitazioni che grazie all utilizzo intensivo di hardware e software dedicati permettono di realizzare interazioni di automazione uomo-ambiente anche molto complesse. Questo modello non ha avuto molta fortuna in quanto, per queste tipologie di impianti, i costi risultano essere molto alti e, inoltre, risulta difficoltosa l introduzione di nuove funzionalità, non previste in fase di progettazione. Negli ultimi anni si tende sempre più ad abbandonare il modello classico di Smart Home a favore dei cosiddetti ambienti domotici intelligenti (IDE, Intelligent Domotic Environment) i quali prevedono l estensione degli impianti domotici standard tramite un nodo centrale che prende il nome di gateway domotico. Questi ha il compito di rendere possibile la comunicazione tra dispositivi disomogenei e la realizzazione di scenari domotici avanzati. In questa tesi viene utilizzato come riferimento 1

8 1 Introduzione il gateway DOG (Domotic OSGi Gateway), sviluppato dal gruppo e-lite [1] del Politecnico di Torino. Come si può intuire dal nome, DOG utilizza come tecnologia fondante OSGi, un framework Java particolarmente indicato per sistemi modulari e dinamici. L utilizzo di questo framework permette, ad esempio, di riconoscere e di aggiungere al sistema nuovi device in modo dinamico, cioè senza dover riavviare il gateway. Un altra importante caratteristica di DOG è l utilizzo di un ontologia (DogOnt) per descrivere l intero sistema domotico e per poter fornire delle funzionalità avanzate, sfruttando l informazione contenuta in questa rappresentazione con sistemi basati sull inferenza logica. 1.2 Obiettivi L obiettivo della tesi è di analizzare l architettura di DOG, mettendo in risalto le soluzioni positive e le criticità con riferimento a quanto previsto dal framework OSGi e, più in generale, dai principi della buona programmazione. DOG, infatti, è il risultato del lavoro di diverse persone in diversi anni e, prima di questa tesi, non è mai stato accompagnato da una documentazione unica ed esaustiva circa la sua struttura e il suo funzionamento. L analisi è incentrata in particolare sui moduli core, cioè quelle parti, responsabili del funzionamento di base del gateway, senza le quali l intero sistema non riuscirebbe a funzionare. Il risultato di questa tesi è, in prima istanza, quello di fornire una documentazione dell attuale versione di DOG, utilizzando nello specifico uno standard consolidato come UML. Inoltre, a partire da questi dati sono state evidenziate e classificate le problematiche presenti in ciascun modulo del gateway. Criticità alle quali, infine, sono stati proposti dei miglioramenti possibili, in parte progettati e implementati nel dettaglio. 1.3 Struttura del documento La tesi è così strutturata: nei primi due capitoli vengono spiegati nel dettaglio i concetti chiave su cui si basa l intero documento. In particolare sono approfonditi il funzionamento e le specifiche del framework OSGi (capitolo 2), cercando anche di analizzare brevemente il OSGi Service Compendium (sezione 2.4), e la struttura generale del gateway DOG (capitolo 3). Nel capitolo 4 si sposta il focus sull analisi della versione 2.3 di DOG, analizzando uno ad uno i principali componenti da cui è formato e classificandone le principali criticità. Le problematiche accennate in questa parte sono approfondite nel dettaglio nel capitolo 5, nel quale vengono presentate delle soluzioni concrete per migliorare l architettura e il funzionamento del gateway. 2

9 1.3 Struttura del documento Infine, nel capitolo 6 vengono esposte le conclusioni della tesi e presentate altre modifiche di DOG non ancora realizzate e su cui concentrarsi in futuro. 3

10 1 Introduzione 4

11 Capitolo 2 Il framework OSGi Il framework OSGi (Open Service Gateway initiative) è il risultato di anni di lavoro della OSGi Alliance, organizzazione fondata nel 1999 da alcune delle più importanti aziende del settore ICT tra cui Ericsson, IBM e Oracle. Questa piattaforma mette a disposizione dei suoi utilizzatori un framework Java general purpose altamente flessibile, in quanto i suoi componenti, chiamati bundle, possono essere installati e modificati a runtime. Gran parte della fortuna di questa piattaforma è dovuta all utilizzo di OSGi, a partire dal 2003, come runtime per il noto ambiente di sviluppo integrato Eclipse. In realtà, adattare Equinox, il progetto che si occupava, e che tuttora si occupa, della gestione dei plug-in in Eclipse, alle specifiche OSGi fu molto complesso e faticoso. Ciò nonostante questa collaborazione fu particolarmente fruttuosa per entrambi i progetti. Infatti da allora Equinox è diventata l implementazione di riferimento delle specifiche OSGi. Questo da un lato ha permesso a questa piattaforma di essere vista in una nuova ottica da parte di milioni di sviluppatori di software e dall altro ha portato ad un notevole aumento nell utilizzo di Equinox in diversi scenari, dai server ai sistemi embedded. Al giorno d oggi tutti i principali vendor di application server utilizzano OSGi come runtime ma il suo utilizzo si estende anche in altri settori, come dimostrano i recenti progetti sviluppati dalla Nasa Maestro ed Ensemble. Il componente fondamentale di un sistema OSGi è un entità chiamata bundle. I bundle eseguiti all interno di una piattaforma OSGi sono indipendenti gli uni dagli altri ma possono collaborare tra di loro secondo alcuni meccanismi. Ciascun bundle dichiara una sua API (Application Programming Interface) pubblica, definisce le dipendenze specifiche che ha nei confronti di altri bundle e nasconde la sua implementazione interna secondo il modello black box. Questa semplice descrizione fa intuire come OSGi definisca un robusto meccanismo di separazione, concetto chiave per avere un sistema modulare. In realtà non è sufficiente definire in modo formale delle recinzioni robuste ma è necessario anche definire per i cancelli che permettono di attraversarle. Questo è il compito dei servizi che, come vedremo nelle sezioni 5

12 2 Il framework OSGi seguenti, permettono ai bundle di interagire tra di loro. 2.1 Vantaggi e svantaggi di OSGi Il concetto di bundle rappresenta uno dei principali vantaggi di OSGi ed è proprio grazie a questo livello di astrazione che è possibile avere una buona rappresentazione dei moduli di un sistema complesso. Infatti, i package Java hanno una granularità troppo fine per essere dei moduli di un applicazione e i file JAR (Java ARchive) sono solamente un meccanismo per esportare il software senza alcun impatto sull esecuzione del sistema [8]. Questo significa che in Java, senza i bundle, non è possibile specificare delle dipendenze e, pertanto, non è facile avere un sufficiente livello di modularità. I bundle vengono tipicamente implementati utilizzando dei file JAR, ai quali, però, vengono aggiunte informazioni circa la loro identità e le loro dipendenze. Gli effetti di questa semplice idea sono duplici: i produttori e i consumatori di un servizio software possono esprimere ciascuno la propria parte del contratto mentre l ambiente di esecuzione ha le informazioni per imporre il rispetto dei vincoli dichiarati. Questi contratti possono essere statici, quando vengono dichiarate delle dipendenze tra bundle, oppure dinamici, quando si ricorre al meccanismo dei servizi. Un altro vantaggio è che OSGi, essendo stato inizialmente progettato per il mondo embedded, ha mantenuto negli anni anche una notevole compattezza. La specifica del suo nucleo è infatti composta da solo 27 tipi Java. A questi vantaggi si contrappongono una maggiore complessità nella scrittura del codice, in quanto non è più possibile far riferimento a tipi Java come avviene nei sistemi fortemente accoppiati (tightly coupled systems). Bisogna infatti ricorrere a meccanismi, tipici di scenari dove viene richiesta maggiore flessibilità (loosely coupled systems), come ad esempio il Context class loader o o l utilizzo di Class.forName. 2.2 Architettura del framework OSGi Secondo le OSGi Service Platform Core Specification [2] il framework OSGi è strutturato in 5 livelli (Figura 2.1): (i) Execution Environment; (ii) Security Layer; (iii) Module Layer; (iv) Life Cycle Layer; (v) Service Layer. Il livello dell Execution Environment si trova al di sopra dell hardware o del sistema operativo e serve per evitare che i bundle dipendano direttamente dal namespace utilizzato dall ambiente specifico (e.g., Java SE 5, Google Android). Infatti l ambiente Java mette a disposizione tutti i package nel namespace java.* ma purtroppo questi possono variare da un ambiente di esecuzione ad un altro. L Execution Environment definisce come i framework possono informare i bundle circa gli ambienti di esecuzione disponibili. 6

13 2.2 Architettura del framework OSGi Figura 2.1. Livelli del framework OSGi Il Security Layer è l unico livello trasversale del framework e può essere attivato opzionalmente. Questo livello si appoggia sull architettura di sicurezza di Java 2 e va a colmare alcune lacune di quest ultima. Il codice può essere autenticato dalla piattaforma o tramite il firmatario, o tramite la location. La gestione dei permessi associati a delle porzioni di codice spetta a dei servizi, definiti nei livelli superiori. I tre livelli rimasti, cioè il Module Layer, il Life Cycle Layer ed il Service Layer, sono fondamentali per la comprensione e l utilizzo di OSGi e, pertanto, sono approfonditi a parte nelle sezioni seguenti Module Layer Il Module Layer definisce un modello per suddividere un applicazione Java in moduli, cercando di superare i limiti del modello di deployment classico di Java. Per realizzare questa modularizzazione si utilizza il concetto di bundle. Un bundle non è altro che un file JAR che: Contiene le risorse necessarie (file class ma anche HTML, JAR, icone e altri tipi di file) per svolgere alcune funzionalità; Contiene un file manifest (file MANIFEST.MF contenuto nella directory META- INF del bundle) che serve a descrivere il contenuto del file JAR e a fornire informazioni sul bundle che questo file rappresenta; Può contenere della documentazione opzionale nella directory OSGI-OPT. Il file manifest contiene a sua volta un elenco di header, ciascuno con una propria sintassi, che permette di descrivere il bundle. I più importanti campi header sono: 7

14 2 Il framework OSGi Bundle-SymbolicName: rappresenta il nome del bundle, è un header obbligatorio; Bundle-Version: permette di definire la versione del bundle, è obbligatorio e, assieme al precedente header, permette di individuare in modo univoco un bundle in OSGi; Export-Package: definisce i package che il bundle mette a disposizione degli altri bundle del sistema; Import-Package: definisce le dipendenze che il bundle presenta rispetto ai package degli altri bundle del sistema; Require-Bundle: definisce una dipendenza che il bundle presenta rispetto a degli interi bundle del sistema. Quando un bundle esporta un package è come se stesse dicendo che è in grado di fornire questo package agli altri componenti del sistema. I package che vengono esportati rappresentano l interfaccia pubblica del bundle, mentre tutti gli altri rappresentano i dettagli implementativi e, pertanto, non devono essere visibili dall esterno. Quando viene definita l importazione di un package è possibile indicare anche la versione o un intervallo di versioni che sono richieste dal bundle. L header Require-Bundle è da utilizzare solo quando strettamente necessario perché riduce, rispetto all utilizzo dell Import-Package, la possibilità di riutilizzare i bundle in scenari differenti. Sulla base delle informazioni contenute nel file manifest il framework OSGi risolve le dipendenze e collega i bundle tra di loro a runtime. Di seguito viene riportato un esempio di un file manifest di un bundle del sistema che verrà analizzato nei prossimi capitoli. Manifest - Version : 1.0 Bundle - ManifestVersion : 2 Bundle - Name : DogExecutor Bundle - SymbolicName : DogExecutor Bundle - Version : Bundle - Activator : it. polito. elite. domotics. dog2. dogexecutor. DogExecutorActivator Bundle - RequiredExecutionEnvironment : JavaSE -1.6 Import - Package : org. osgi. framework ; version =" " Require - Bundle : Dog2Library ; bundle - version =" ", osgi. cmpn ; bundle - version =" ",DogOntLibrary ; bundle - version =" " Life Cycle Layer Il Life Cycle Layer mette a disposizione una API per gestire i bundle del Module Layer (infatti necessita di questo livello per poter funzionare) e definisce l intero 8

15 2.2 Architettura del framework OSGi ciclo di vita dei bundle nel sistema, cioè come questi vengono lanciati, installati, aggiornati, fermati e disinstallati. Il ciclo di vita di un bundle è rappresentato in Figura 2.2. Tutti i bundle si trovano inizialmente nello stato installed, da cui possono passare in quello resolved se tutte le loro dipendenze risultano essere risolte. A questo punto il bundle può essere lanciato o invocando il metodo start sul bundle stesso o in modo automatico dal framework qualora sia impostato l autostart setting sul bundle in esame. Lo stato in questo modo passa da resolved a starting. Allora il framework procede normalmente eseguendo il bundle activator specificato nel file manifest del bundle, come si può notare nel codice presentato nella sezione 2.2. L activator è una classe Java che implementa l interfaccia BundleActivator, la quale a sua volta definisce due metodi start e stop per lanciare e fermare il bundle. Fintanto che il metodo start non ritorna il controllo al chiamante, il bundle risulterà nello stato starting, per passare solo successivamente allo stato active. In modo analogo, quando bisogna fermare un bundle, ad esempio per l arresto dell intero sistema, questo permane nello stato active finché il metodo stop non ritorna. Solo a questo punto il bundle transita nello stato stopping e nuovamente in quello resolved. All interno del metodo stop bisogna provvedere a liberare tutte le risorse che in precedenza sono state allocate dal bundle. Figura 2.2. Diagramma di stato del Life Cycle Layer OSGi In realtà, per ottimizzare l utilizzo delle risorse del sistema, spesso si preferisce utilizzare una differente modalità di attivazione: la lazy activation. Questa consiste nel far restare il bundle nello stato starting finché non vi sia una richiesta esplicita di caricamento di una sua classe. Quando il bundle si trova nuovamente nello stato resolved, può essere riavviato (tornando nuovamente nello stato starting) oppure disinstallato (transitando nello 9

16 2 Il framework OSGi stato uninstalled), diventando in questo ultimo caso non più disponibile nel sistema. In OSGi tutti questi cambiamenti di stato vengono propagati attraverso eventi. Questo layer in particolare si occupa di due tipologie di eventi: BundleEvent: eventi generati quando cambia lo stato dei bundle del framework; FrameworkEvent: eventi generati quando il framework viene lanciato, quando è stato cambiato lo start level del framework, quando si verifica un errore o un warning e quando i package relativi al framework vengono aggiornati. Lo stesso Framework OSGi viene realizzato sfruttando i concetti espressi in questi livelli e nel successivo. Il bundle che lo rappresenta, noto con la nomenclatura di System Bundle, si differenzia però dai bundle tradizionali perché il suo ciclo di vita non può essere gestito. Infatti viene avviato automaticamente quando il framework viene eseguito e, quando viene fermato o disinstallato, ciò comporta evidentemente anche la terminazione dell intero sistema. Per approfondimenti su questi argomenti si rimanda a [2]. Per interagire con il System Bundle definito in Eclipse Equinox è possibile utilizzare la Console view, premendo il tasto Invio per vedere il prompt osgi>. A questo punto, digitando il comando ss, viene mostrata la lista dei bundle attualmente installati nel sistema in esame. Di seguito è riportato un frammento del risultato visibile dopo aver invocato questo comando sul sistema che andremo ad analizzare nei capitoli seguenti. In questo caso oltre al System Bundle (id = 0) sono presenti nel sistema altri 58 bundle. osgi > ss Framework is launched. id State Bundle 0 ACTIVE org. eclipse. osgi_ R36x_v ACTIVE DogRulesBundle_ ACTIVE DogDeviceManager_ ACTIVE MeasureLibrary_ ACTIVE DriverEliteTemperatureSensor_ ACTIVE DriverEliteButton_ ACTIVE BticinoC2Driver_ ACTIVE KnxIPNetworkDriver_ ACTIVE Dog2Library_ ACTIVE DriverEliteShutterActuator_ ACTIVE DogExecutor_ ACTIVE DogNotificationsManager_ ACTIVE DogState_ Per interagire con il framework si possono, inoltre, utilizzare i comandi start e stop, seguiti dall id del bundle, per avviare e fermare uno dei bundle installati nel 10

17 2.2 Architettura del framework OSGi sistema. Per avere informazioni su tutti i comandi basta invece utilizzare il comando help Service Layer Il solo utilizzo delle dipendenze tra bundle rappresenta un meccanismo limitato per la creazione di sistemi modulari dinamici. Per questo motivo in OSGi viene fornito il Service Layer, livello che mette a disposizione un modello collaborativo dinamico integrato con il Life Cicle Layer. Lo strumento che rende possibile tutto ciò è il service registry. Questo funziona come una bacheca che permette di coordinare tre soggetti diversi: i bundle che definiscono le interfacce dei servizi, i bundle che implementano e registrano gli oggetti che rappresentano i servizi e i bundle che ricercano ed utilizzano i servizi. Grazie al service registry questa collaborazione è anonima, infatti i bundle che sfruttano un servizio non conoscono quali bundle lo hanno registrano e viceversa. I servizi sono generalmente definiti utilizzando un interfaccia che deve essere pubblica e deve trovarsi nei package che vengono esportati dal bundle. Altri bundle, spesso anche lo stesso, possono implementare questa interfaccia e registrare il servizio con il nome dell interfaccia stessa utilizzando il metodo registerservice. Quando il bundle non deve più fornire il servizio, ad esempio quando viene fermato, viene invocato il metodo unregister. È buona norma non includere le classi che implementano il servizio nei package esportati dal bundle. Infine altri bundle agiscono come consumatori di servizi. Innanzitutto questi devono importare i package in cui sono definite le interfacce del servizio. Poi, grazie ai metodi getservicereference e getservice, devono provvedere a ricercare i servizi che desiderano utilizzare, specificando come chiave il nome dell interfaccia del servizio. A questo punto possono usufruire del servizio finché questo è registrato da altri bundle. Poiché il service registry tiene traccia di quanti bundle stanno utilizzando un determinato servizio, è molto importante rilasciare i servizi quando non sono più utilizzati. Per effettuare questa operazione OSGi mette a disposizione il metodo ungetservice. È necessario precisare che più bundle possono utilizare lo stesso servizio in modo concorrente e che un bundle può offrire diversi servizi contemporaneamente. Il Service Layer risulta essere fortemente correlato al OSGi Life Cycle Layer perché la gestione dinamica dei servizi è spesso influenzata dal ciclo di vita dei bundle. Infatti, quando un bundle viene avviato, inizia generalmente a ricercare i servizi di cui ha bisogno e a registrare i servizi che deve offrire. Quando invece un bundle viene fermato, è allora suo dovere rilasciare i servizi che ha utilizzato e rimuovere dal service registry i servizi implementati. Anche questo livello utilizza degli eventi per comunicare delle informazioni sul cambiamento di stato dei componenti di cui è responsabile. In particolare vengono generati dei ServiceEvent quando viene registrato, rimosso o modificato in alcune 11

18 2 Il framework OSGi sue proprietà un servizio. Per poter gestire questi eventi OSGi mette a disposizione dei ServiceListener. Remote Services Lo strumento locale del service registry può anche essere esteso ad applicazioni esterne al framework OSGi grazie all utilizzo dei Remote Services [2]. In particolare un componente che prende il nome di distribution provider può utilizzare lo stesso meccanismo di disaccoppiamento tra bundle per esportare un servizio OSGi creando un opportuno endpoint (exported service in Figura 2.3). Allo stesso modo, grazie a dei proxy, un distribution provider permette di utilizzare dei servizi esterni ad OSGi come se si trattasse di servizi offerti da bundle interni al sistema (imported service in Figura 2.3). Questa specifica è molto importante perché fornisce un preciso meccanismo per poter interagire con l esterno, delegando ai distribution provider il compito di occuparsi dei protocolli di comunicazione. Inoltre, è facile reperire in rete diverse implementazioni open source (e.g. Eclipse ECF, Apache CXF) conformi con la Remote Service Specification ed in grado di gestire i principali protocolli. Date le implementazioni dei distribution provider, i vari bundle, al momento di registrare un servizio, devono solo specificare tramite delle Remote Service Properties se ed in che modo esportare il loro servizio al di fuori del framework. Figura 2.3. Architettura dei Remote Service 12

19 2.3 Servizi dinamici 2.3 Servizi dinamici Una delle criticità dei sistemi dinamici è l impossibilità di fare assunzioni a priori circa la disponibilità di determinate risorse. Infatti, quando si utilizza OSGi, il risultato di un operazione potrebbe dipendere dall ordine con cui i bundle sono stati eseguiti ed hanno di conseguenza registrato o ricercato i servizi. Tutto ciò può essere evitato gestendo in modo opportuno i ServiceEvent che il framework mette a disposizione. Purtroppo questa operazione comporta l utilizzo di una discreta porzione di codice complesso, ripetuto in diversi bundle, per gestire la concorrenza e i diversi modi con cui i servizi possono essere registrati o rimossi. Per questo motivo sono stati introdotti negli anni dei meccanismi per facilitare la gestione dei servizi. Nella release 2 di OSGi è stato aggiunto il Service Tracker ed infine, a partire dalla release 4, è possibile utilizzare i Declarative Service Service Tracker I Service Tracker, come descritto nella Tracker Specification in [3], sono dei meccanismi per tener traccia degli eventi (e.g., registrazione, modifica) che riguardano servizi che corrispondono ad una determinata specifica. Rispetto allo scenario descritto nella sezione 2.2.3, il bundle non deve più ricercare il servizio a cui è interessato ma deve solamente creare un oggetto ServiceTracker, specificando in particolare come parametri l interfaccia del servizio e il ServiceTrackerCustomizer. Questo oggetto, che implementa l omonima interfaccia, presenta tre metodi nei quali bisogna specificare il comportamento previsto qualora venga aggiunto (metodo addingservice), modificato (metodo modifiedservice) o rimosso (metodo removedservice) il servizio specificato in precedenza. In questi metodi è necessario prevedere situazioni in cui siano disponibili anche più istanze dello stesso servizio. Infatti, ad esempio qualora l attuale implementazione del servizio non fosse più disponibile, è plausibile ricercare un altra implementazione. In modo analogo bisogna controllare che, nel caso in cui venga rimosso un servizio, questo sia esattamente quello in uso e non un implementazione alternativa. È inoltre buona norma comunicare al Service Tracker, tramite il metodo close, quando il servizio non viene più utilizzato dal bundle. Questo metodo è speculare al metodo open che viene chiamato per avviare il Service Tracker, dopo che questo è stato correttamente configurato. Utilizzare i Service Tracker è in realtà abbastanza complicato non appena cresce il numero di servizi monitorati nello stesso bundle, ad esempio, è facile commettere errori nella configurazione dei ServiceTrackerCustomizer. Inoltre utilizzando questo meccanismo non è possibile ottenere un buon compromesso tra semplicità e scalabilità del codice [8]. La pratica abbastanza diffusa di utilizzare i Service Tracker non appena servono all interno dei bundle peggiora la situazione. Questa abitudine, 13

20 2 Il framework OSGi evidentemente, da un lato semplifica l utilizzo dei Service Tracker ma dall altro introduce nel software numerosi riferimenti ad OSGi. Per cercare di ridurre al minimo queste dipendenze è importante includere il codice che riguarda i Service Tracker nell activator e non nel codice responsabile della logica applicativa Declarative Service A partire dalla release 4 di OSGi (si veda la Declarative Service Specification [3]) vengono introdotti i Declarative Service per risolvere il problema dei servizi dinamici. Questo meccanismo consiste nel dichiarare in un file XML i servizi che il bundle deve offrire e quelli che deve utilizzare. Tutto ciò deve avvenire in modo dichiarativo, come fa intuire il nome, e pertanto non deve essere caricato alcun codice del bundle per determinare se i suoi prerequisiti siano stati soddisfatti. Come conseguenza i bundle che utilizzano i Declarative Service generalmente non necessitano più di un activator. Il concetto fondamentale per i Declarative Service è quello di component. Questa entità viene definita in un file XML all interno della cartella OSGI-INF del bundle utilizzando il tag <scr:component>. In realtà in OSGi un bundle può contenere anche più component, o definendo più tag <scr:component> all interno dello stesso file XML o semplicemente specificando più file XML. Di seguito viene riportata una porzione di codice, ripresa da [3], in cui il component in esame registra e implementa un servizio utilizzando rispettivamente l interfaccia EventHandler (tag <service> e <provide>) e la classe HandlerImpl (tag <implementation>). Quest ultimo tag, più in generale, permette di definire la classe che il Framework deve avviare quando viene lanciato il bundle, il compito dell activator con i Declarative Service viene cioè svolto dal Framework stesso (per la precisione dal Service Component Runtime). Qualora sia necessario chiamare dei metodi per avviare e per fermare il bundle questi vengono specificati grazie agli attributi activate e deactivate del tag <scr:component>. <xml version =" 1.0 " encoding ="UTF -8"> <scr : component name =" example. handler " xmlns : scr =" http :// www. osgi. org / xmlns / scr /v1.2.0 "> < implementation class =" com. acme. HandlerImpl "/> <service > < provide interface = " org. osgi. service. event. EventHandler "/> </ service > </ scr : component > Per poter utilizzare dei servizi, registrati da un altro bundle tramite il service registry, è invece necessario utilizzare i tag <reference>. In questo caso occorre specificare tramite gli attributi name e interface, rispettivamente, il nome del servizio, univoco solo all interno del component, e il nome esteso dell interfaccia con cui è registrato il servizio a cui si è interessati. Vengono poi messi a disposizione altri 14

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Uno scorcio sul mondo OSGi e OSGi enterprise: modularita' e dinamismo

Uno scorcio sul mondo OSGi e OSGi enterprise: modularita' e dinamismo Uno scorcio sul mondo OSGi e OSGi enterprise: modularita' e dinamismo Giacomo Pallotti giacomo.pallotti@gmail.com abstract... Modularità e Dinamismo Modularità e Dinamismo in Java e JEE Diario di un bravo

Dettagli

Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti

Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti POLITECNICO DI TORINO III Facoltà di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica Tesi di Laurea Specialistica Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Progettazione e Implementazione di API WebSocket per il Gateway Dog

Progettazione e Implementazione di API WebSocket per il Gateway Dog Corso di Laurea in Ingegneria Informatica Tesi di Laurea Magistrale Progettazione e Implementazione di API WebSocket per il Gateway Dog Relatori: Fulvio Corno Luigi De Russis Candidato: Teodoro Montanaro

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

WEB SERVER EMBEDDED PER APPLICAZIONI DI DOMOTICA. Fig. 1 - Architettura di un web server embedded

WEB SERVER EMBEDDED PER APPLICAZIONI DI DOMOTICA. Fig. 1 - Architettura di un web server embedded WEB SERVER EMBEDDED PER APPLICAZIONI DI Cristian Randieri Per far fronte alle esigenze di sviluppatori che intendono gestire applicazioni professionali per la domotica e la home building automation sfruttando

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Programmazione in ambiente

Programmazione in ambiente Università Politecnica delle Marche Dipartimento di Ingegneria dell Informazione Programmazione in ambiente Android Laura Montanini - laura.montanini@univpm.it Corso di Tecnologie per le TLC 2013-2014

Dettagli

La Smart Home Hackathon & JEMMA La reference implementation di Energy@Home

La Smart Home Hackathon & JEMMA La reference implementation di Energy@Home La Smart Home Hackathon & JEMMA La reference implementation di Energy@Home Riccardo Tomasi, Ivan Grimaldi Pervasive Technologies Area, Istituto Superiore Mario Boella Demo & Reference Implementation Working

Dettagli

Realizzazione di un sistema di logging prototipale per la piattaforma

Realizzazione di un sistema di logging prototipale per la piattaforma tesi di laurea Realizzazione di un sistema di logging prototipale per la piattaforma Android Anno Accademico 2011 / 2012 relatore Ch.mo prof. Marcello Cinque candidato Dario De Meis Matr. 528 / 741 Smartphone

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE INTRODUZIONE L ingegneria del software è la disciplina tecnologica e gestionalerelativa alla realizzazione sistematica e alla manutenzione di un software rispettando

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

PROGETTO AMS Autonomic Maintenance System

PROGETTO AMS Autonomic Maintenance System PROGETTO AMS Autonomic Maintenance System Progettazione e Sviluppo di un PROTOTIPO di Piattaforma Informatica per la Gestione Autonomica, Integrata e Collaborativa della Manutenzione RELAZIONE TECNICO-SCIENTIFICA

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa.

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa. Introduzione alla tecnologia JMX 1 Viene analizzata l architettura sottostante le Java Managment Extensions (JMX) mostrandone un utilizzo applicativo e analizzando altri possibili scenari d uso di Ivan

Dettagli

Log Manager. 1 Connessione dell apparato 2. 2 Prima configurazione 2. 2.1 Impostazioni di fabbrica 2. 2.2 Configurazione indirizzo IP e gateway 3

Log Manager. 1 Connessione dell apparato 2. 2 Prima configurazione 2. 2.1 Impostazioni di fabbrica 2. 2.2 Configurazione indirizzo IP e gateway 3 ver 2.0 Log Manager Quick Start Guide 1 Connessione dell apparato 2 2 Prima configurazione 2 2.1 Impostazioni di fabbrica 2 2.2 Configurazione indirizzo IP e gateway 3 2.3 Configurazione DNS e Nome Host

Dettagli

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript tesi di laurea di difetti all interno di codice Javascript Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Domenico Amalfitano candidato Vincenzo Riccio Matr.

Dettagli

APPENDICE A Servlet e Java Server Page

APPENDICE A Servlet e Java Server Page APPENDICE A Servlet e Java Server Page A.1 Cosa è una Servlet e come funziona Una servlet è un particolare tipo di applicazione Java, in grado di essere eseguita all'interno di un web server e di estenderne

Dettagli

Corso Android Corso Online Sviluppo su Cellulari con Android

Corso Android Corso Online Sviluppo su Cellulari con Android Corso Android Corso Online Sviluppo su Cellulari con Android Accademia Futuro info@accademiafuturo.it Programma Generale del Corso di Sviluppo su Cellulari con Android Programma Base Modulo Uno - Programmazione

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

Dettagli

Corso Android Corso Online Programmatore Android

Corso Android Corso Online Programmatore Android Corso Android Corso Online Programmatore Android Accademia Domani Via Pietro Blaserna, 101-00146 ROMA (RM) info@accademiadomani.it Programma Generale del Corso Modulo Uno - Programmazione J2ee 1) Programmazione

Dettagli

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Salerno Formazione, società operante nel settore della didattica, della formazione professionale e certificata

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

www.zetaqlab.com C-Light Web-based Management Software

www.zetaqlab.com C-Light Web-based Management Software www.zetaqlab.com C-Light Web-based Management Software WEB-BASED MANAGEMENT SOFTWARE C-Light è l applicazione per la gestione locale (intranet) e remota (internet) di ogni impianto d automazione integrabile

Dettagli

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

IBM Tivoli Endpoint Manager for Lifecycle Management

IBM Tivoli Endpoint Manager for Lifecycle Management IBM Endpoint Manager for Lifecycle Management Un approccio basato sull utilizzo di un singolo agente software e un unica console per la gestione degli endpoint all interno dell intera organizzazione aziendale

Dettagli

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI PROCEDURA DI SELEZIONE PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, ANALISI, SVILUPPO, MANUTENZIONE ADEGUATIVA, CORRETTIVA ED EVOLUTIVA DI SISTEMI INFORMATIVI SU PIATTAFORMA IBM WEBSPHERE BPM (EX LOMBARDI)

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Programmazione server-side: Java Servlet

Programmazione server-side: Java Servlet Programmazione server-side: Java Servlet Corso di Applicazioni Telematiche A.A. 2006-07 Lezione n.11 parte II Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Cos

Dettagli

Corso Base. Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO

Corso Base. Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO Corso Base Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO Java Java è un Linguaggio di Programmazione orientato agli oggetti. Un Linguaggio di Programmazione è un linguaggio ad alto livello, dotato

Dettagli

L iniziativa Cloud DT

L iniziativa Cloud DT L iniziativa Cloud DT Francesco Castanò Dipartimento del Tesoro Ufficio per il Coordinamento Informatico Dipartimentale (UCID) Roma, Luglio 2011 Il Cloud Computing Alcune definizioni Il Cloud Computing

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base)

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base) Sistema Operativo (Software di base) Il Sistema Operativo Il sistema operativo è un insieme di programmi che opera sul livello macchina e offre funzionalità di alto livello Es.organizzazione dei dati attraverso

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA Elaborato di Tecnologie del Software per Internet JMSWEB 2 SISTEMA PER LO SCAMBIO DI MESSAGGI TRA APPLICAZIONI

Dettagli

TinyOS. Sistema operativo open-source per wireless sensor network sviluppato dall Università di Berkley e centro ricerche Intel www.tinyos.

TinyOS. Sistema operativo open-source per wireless sensor network sviluppato dall Università di Berkley e centro ricerche Intel www.tinyos. Sistema operativo open-source per wireless sensor network sviluppato dall Università di Berkley e centro ricerche Intel www.tinyos.net Outline Wireless Sensor Network 1 Wireless Sensor Network Caratterisiche

Dettagli

Un sistema di identificazione basato su tecnologia RFID

Un sistema di identificazione basato su tecnologia RFID tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ch.mo prof. Massimo Ficco candidato Alessandro Ciasullo Matr. 831/166 Obiettivo Progettazione ed implementazione

Dettagli

Nuvola It Data Space

Nuvola It Data Space MANUALE UTENTE INDICE 1. Descrizione servizio... 3 1.1. Informazioni sul servizio di Telecom Italia... 3 1.2. Ruoli e Autenticazione per il servizio di Telecom Italia... 3 1.3. Strumenti... 5 1.4. Documentazione...

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware.

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware. http://159.149.98.238/lanzavecchia/docum enti/sscta.htm Sistemi informatici Hardware Microprocessore Memoria Periferiche di input e output Software Software di sistema Programmi applicativi 1 2 Il sw applicativo

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Implementazione di un servizio VoIP in ambienti SOA per mobile computing

Implementazione di un servizio VoIP in ambienti SOA per mobile computing tesi di laurea Implementazione di un servizio VoIP in ambienti SOA per mobile computing Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo correlatore ing. Marcello Cinque candidato Vittorio

Dettagli

Programmazione Android

Programmazione Android Programmazione Android Giovanni Perbellini, Stefano Cordibella Università di Verona EDALab S.r.l. Agenda Introduzione Android Overview Ambiente di sviluppo Esempi Helloworld Weather 2 1 Cos è Android?

Dettagli

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

Dettagli

Sommario. Introduzione ai firewall. Firewall a filtraggio dei pacchetti. Il firewall ipfw. Definizione e scopo Classificazione

Sommario. Introduzione ai firewall. Firewall a filtraggio dei pacchetti. Il firewall ipfw. Definizione e scopo Classificazione Sesta Esercitazione Sommario Introduzione ai firewall Definizione e scopo Classificazione Firewall a filtraggio dei pacchetti Informazioni associate alle regole Interpretazione delle regole Il firewall

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Pag. 1 di 16 Redatto da F. Fornasari, C. Simonelli, E. Croci (TAI) Rivisto da E.Mattei (TAI) Approvato

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Perl e Win32: installazione e utilizzo. -Introduzione -Disponibilità -ActivePerl: Installazione -Moduli: Installazione tramite PPM -Perl e IIS -Link

Perl e Win32: installazione e utilizzo. -Introduzione -Disponibilità -ActivePerl: Installazione -Moduli: Installazione tramite PPM -Perl e IIS -Link Perl e Win32: installazione e utilizzo -Introduzione -Disponibilità -ActivePerl: Installazione -Moduli: Installazione tramite PPM -Perl e IIS -Link 1 Introduzione: Perl, acronimo di Pratical Extraction

Dettagli

Prefazione. Contenuti

Prefazione. Contenuti Prefazione Il sistema operativo costituisce uno dei componenti fondamentali di ogni sistema di elaborazione, in particolare è quello con cui l utente entra direttamente in contatto quando accede al sistema,

Dettagli

Analisi e sviluppo di un componente per un ESB open source

Analisi e sviluppo di un componente per un ESB open source tesi di laurea Anno Accademico 2010/2011 relatore Ch.mo prof. Porfirio Tramontana correlatore Ing. Ciro Romano candidato Rosario Celotto Matr. 534/1459 Introduzione L attività svolta è stata l analisi

Dettagli

Roadmap verso RES Suite EV 1.0. Rino Adamo

Roadmap verso RES Suite EV 1.0. Rino Adamo Roadmap verso RES Suite EV 1.0 Rino Adamo Agenda Docet EV: ha già compiuto il suo primo anno di vita Si evolve sempre più nella componente di documentazione del SW dipartimentale con attenzione alle evoluzioni

Dettagli

Applicazione: GAS - Gestione AcceSsi

Applicazione: GAS - Gestione AcceSsi Riusabilità del software - Catalogo delle applicazioni Gestione ICT Applicazione: GAS - Gestione AcceSsi Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi Nome

Dettagli

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1 Gli XML Web Service Prof. Mauro Giacomini Medica 2008/2009 1 Definizioni i i i Componente.NET che risponde a richieste HTTP formattate tramite la sintassi SOAP. Gestori HTTP che intercettano richieste

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi Linguaggio Java Robusto Non permette costrutti pericolosi Eredità Multipla Gestione della Memoria Orientato agli oggetti Ogni cosa ha un tipo Ogni tipo è un oggetto (quasi) Protegge e gestisce dagli errori

Dettagli

Streaming Tool per CoFFEE

Streaming Tool per CoFFEE Streaming Tool per CoFFEE a cura di Gerardo Lombardo CoFFEE Cooperative Face-to-Face Educational Environment Groupware Suite di applicazioni distribuite (in LAN) per il problem solving collaborativo in

Dettagli

Capitolo 2 -- Silberschatz

Capitolo 2 -- Silberschatz Struttura dei Sistemi Operativi Capitolo 2 -- Silberschatz Struttura di un sistema operativo Servizi di un sistema operativo Interfaccia Utente Chiamate di sistema Tipi di chiamate Programma di sistema

Dettagli

Windows Deployment Services. Marco Ivan Palumbo Project & Services Manager Venco Group Services Gruppo Venco S.p.A. 06/03/2014

Windows Deployment Services. Marco Ivan Palumbo Project & Services Manager Venco Group Services Gruppo Venco S.p.A. 06/03/2014 Windows Deployment Services Marco Ivan Palumbo Project & Services Manager Venco Group Services Gruppo Venco S.p.A. 06/03/2014 Scalability Deep Customization Deployment Automation Window Deployment Services

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

SMD: a sensor data distribution service for FIN-BOX middleware for the interoperability in systems of systems Anno Accademico 2011/2012

SMD: a sensor data distribution service for FIN-BOX middleware for the interoperability in systems of systems Anno Accademico 2011/2012 tesi di laurea specialistica SMD: a sensor data distribution service for FIN-BOX middleware for the Anno Accademico 2011/2012 relatore Ch.mo prof. Stefano Russo correlatori Ch.mo prof. Domenico Cotroneo

Dettagli

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico Impossibile visualizzare l'immagine. Struttura di un sistema operativo Struttura dei Sistemi Operativi Servizi di un sistema operativo Interfaccia Utente Capitolo 2 -- Silberschatz Chiamate di sistema

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

Dettagli

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Mattia Gentilini Relatore: Renzo Davoli Laurea Specialistica in Informatica I Sessione A.A. 2005/2006

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Breve introduzione curata da Alessandro Benedetti. Struts2-Introduzione e breve guida

Breve introduzione curata da Alessandro Benedetti. Struts2-Introduzione e breve guida Breve introduzione curata da Alessandro Benedetti Struts2-Introduzione e breve guida 22-11- 2008 1 Struts 2 Costruisci,attiva e mantieni! Apache Struts 2 è un framework elegante ed estensibile per creare

Dettagli

Virtualizzazione. Orazio Battaglia

Virtualizzazione. Orazio Battaglia Virtualizzazione Orazio Battaglia Definizione di virtualizzazione In informatica il termine virtualizzazione si riferisce alla possibilità di astrarre le componenti hardware, cioè fisiche, degli elaboratori

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

Enrico Fagnoni BOTK IN A NUTSHELL

Enrico Fagnoni <e.fagnoni@e-artspace.com> BOTK IN A NUTSHELL Enrico Fagnoni BOTK IN A NUTSHELL 20/01/2011 1 Business Ontology ToolKit Business Ontology Toolkit (BOTK) è un insieme estensibile di strumenti per realizzare applicazioni basate

Dettagli