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

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

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

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 2008/2009 Questi lucidi sono stati prodotti sulla

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

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

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

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

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

Componenti Web: client-side e server-side

Componenti Web: client-side e server-side Componenti Web: client-side e server-side side Attività di applicazioni web Applicazioni web: un insieme di componenti che interagiscono attraverso una rete (geografica) Sono applicazioni distribuite logicamente

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

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

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

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

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

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

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

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

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

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

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

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

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

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

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

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

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

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

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

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

Corso di Ingegneria del software Como. Prof. Marco Brambilla. Cruscotto auto. Aramini Antonio Umberto

Corso di Ingegneria del software Como. Prof. Marco Brambilla. Cruscotto auto. Aramini Antonio Umberto Corso di Ingegneria del software Como Prof. Marco Brambilla Cruscotto auto Aramini Antonio Umberto Tema d esame: Si vuole realizzare un sistema embedded per autoveicoli che gestisce tutto il pannello di

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

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

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012 Sapienza Università di Roma Facoltà di Ingegneria dell Informazione, Informatica e Statistica Corso di Laurea in Ingegneria Informatica ed Automatica Corso di Laurea in Ingegneria dei Sistemi Informatici

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

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

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

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

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

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

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

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

2009. STR S.p.A. u.s. Tutti i diritti riservati

2009. STR S.p.A. u.s. Tutti i diritti riservati 2009. STR S.p.A. u.s. Tutti i diritti riservati Sommario COME INSTALLARE STR VISION CPM... 3 Concetti base dell installazione Azienda... 4 Avvio installazione... 4 Scelta del tipo Installazione... 5 INSTALLAZIONE

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

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

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

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

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

SPSS Inc. Data Access Pack - Istruzioni di installazione per Windows

SPSS Inc. Data Access Pack - Istruzioni di installazione per Windows i SPSS Inc. Data Access Pack - Istruzioni di installazione per Windows Per ulteriori informazioni sui prodotti software SPSS Inc., visitare il sito Web all indirizzo http://www.spss.it o contattare: SPSS

Dettagli

Architetture e strumenti per la sicurezza informatica

Architetture e strumenti per la sicurezza informatica Università Politecnica delle Marche Architetture e strumenti per la sicurezza informatica Ing. Gianluca Capuzzi Agenda Premessa Firewall IDS/IPS Auditing Strumenti per l analisi e la correlazione Strumenti

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

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

Istruzioni di installazione di IBM SPSS Modeler Text AnalyticsServer per UNIX

Istruzioni di installazione di IBM SPSS Modeler Text AnalyticsServer per UNIX Istruzioni di installazione di IBM SPSS Modeler Text AnalyticsServer per UNIX IBM SPSS Modeler Text Analytics Server può essere installato e configurato per essere eseguito su un computer su cui è in esecuzione

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

19. LA PROGRAMMAZIONE LATO SERVER

19. LA PROGRAMMAZIONE LATO SERVER 19. LA PROGRAMMAZIONE LATO SERVER Introduciamo uno pseudocodice lato server che chiameremo Pserv che utilizzeremo come al solito per introdurre le problematiche da affrontare, indipendentemente dagli specifici

Dettagli

Server-side Programming: Java servlets Parte II

Server-side Programming: Java servlets Parte II Corso di Laurea Specialistica in Ingegneria Informatica Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni Corso di Reti di Applicazioni Telematiche a.a. 2009-2010 Server-side Programming:

Dettagli

Ingegneria del Software: UML Class Diagram

Ingegneria del Software: UML Class Diagram Ingegneria del Software: UML Class Diagram Due on Mercoledì, Aprile 1, 2015 Claudio Menghi, Alessandro Rizzi 1 Contents Ingegneria del Software (Claudio Menghi, Alessandro Rizzi ): UML Class Diagram 1

Dettagli

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 i Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 ii Copyright 2005-2015 Link.it srl Release Notes di OpenSPCoop2 iii Indice 1 Versione 2.1 1 1.1 Gestione del protocollo

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

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

Una soluzione per il Provisioning e la Software Distribution

Una soluzione per il Provisioning e la Software Distribution Una soluzione per il Provisioning e la Software Distribution Scenario Svariati server, con funzione in base all'area di competenza, dislocati nel territorio su Nodi Periferici collegati in rete (VPN) Un

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

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

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

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

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

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

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

Manuale utente. ver 1.0 del 31/10/2011

Manuale utente. ver 1.0 del 31/10/2011 Manuale utente ver 1.0 del 31/10/2011 Sommario 1. Il Servizio... 2 2. Requisiti minimi... 2 3. L architettura... 2 4. Creazione del profilo... 3 5. Aggiunta di un nuovo dispositivo... 3 5.1. Installazione

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

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo F.O.A.M. Free Object Access Method Un introduzione Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo Il protocollo FOAM. FOAM (Free Object Access Method) è un protocollo

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Guida ai Servizi Internet per il Referente Aziendale

Guida ai Servizi Internet per il Referente Aziendale Guida ai Servizi Internet per il Referente Aziendale Indice Indice Introduzione...3 Guida al primo accesso...3 Accessi successivi...5 Amministrazione dei servizi avanzati (VAS)...6 Attivazione dei VAS...7

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

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

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili

Var Group Approccio concreto e duraturo Vicinanza al Cliente Professionalità e metodologie certificate In anticipo sui tempi Soluzioni flessibili Var Group, attraverso la sua società di servizi, fornisce supporto alle Aziende con le sue risorse e competenze nelle aree: Consulenza, Sistemi informativi, Soluzioni applicative, Servizi per le Infrastrutture,

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

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

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

Configuration of a distributed system as emerging behavior of autonomous agents

Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents : Questo documento illustra la strategia

Dettagli

Didit Interactive Solution

Didit Interactive Solution Didit Interactive Solution Didit Interactive Solution Moonway.it Versione Italiana Data: Settembre 2008 Contenuti Introduzione... 3 Componenti Windows Richiesti... 3 Guidelines Generali di Configurazione...

Dettagli

Atlantis Land Technical Resources Product: A02-RA3 / A02-RA3+ / A02-WRA4-54G /A02-RA440 Subject: Remote Wake On LAN Language: Italiano

Atlantis Land Technical Resources Product: A02-RA3 / A02-RA3+ / A02-WRA4-54G /A02-RA440 Subject: Remote Wake On LAN Language: Italiano Atlantis Land Technical Resources Product: A02-RA3 / A02-RA3+ / A02-WRA4-54G /A02-RA440 Subject: Remote Wake On LAN Language: Italiano INTRODUZIONE Quando i pacchetti di WoL generati da una postazione

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

Protezione. Sistemi Operativi mod. B 16.1

Protezione. Sistemi Operativi mod. B 16.1 Protezione Scopi della Protezione Dominio di Protezione Matrice d Accesso Implementazione della Matrice d Accesso Revoca dei Diritti d Accesso Sistemi Basati su Abilitazioni Protezione basata sul linguaggio

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

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

ProgettAzione V anno Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni

ProgettAzione V anno Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni Web service Hello world con Visual Studio 2012 Si tratta di un semplice esempio di web service, infatti come tutti I programmi

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

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

Università degli Studi di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android

Università degli Studi di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android Università degli Studi di Napoli Federico II FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM Progetto di un applicazione Android Briscola bluetooth Candidati: Giuliano Formato Daniele

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

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

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

Dettagli

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Soluzioni di strong authentication per il controllo degli accessi

Soluzioni di strong authentication per il controllo degli accessi Abax Bank Soluzioni di strong authentication per il controllo degli accessi Allegato Tecnico Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO

Dettagli

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO 1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO Quello che generalmente viene chiamato sistema di automazione d edificio si compone di diverse parti molto eterogenee tra loro che concorrono, su diversi livelli

Dettagli