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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 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 la

Dettagli

Applicazione: OIL Online Interactive helpdesk

Applicazione: OIL Online Interactive helpdesk Riusabilità del software - Catalogo delle applicazioni: Gestione ICT Applicazione: OIL Online Interactive helpdesk Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi

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

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

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36 10. Design Patterns Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 10. Design Patterns 1 / 36 Problemi Ci focalizziamo nelle problematiche riguardanti la

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

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

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

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

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

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

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

FileMaker Pro 12. Guida di FileMaker Server

FileMaker Pro 12. Guida di FileMaker Server FileMaker Pro 12 Guida di FileMaker Server 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker è un marchio di FileMaker,

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

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

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

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

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

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

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

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

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

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

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

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

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

Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione

Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione UNIVERSITA DEGLI STUDI DI FERRARA Corso di Laurea in informatica Anno Accademico 2011-2012 Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione Relatore:

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

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

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

Ingegneria del Software Progettazione

Ingegneria del Software Progettazione Ingegneria del Software Progettazione Obiettivi. Approfondire la fase di progettazione dettagliata che precede la fase di realizzazione e codifica. Definire il concetto di qualità del software. Presentare

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

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

Progetto e sviluppo di un applicazione per il pilotaggio remoto di reti

Progetto e sviluppo di un applicazione per il pilotaggio remoto di reti tesi di laurea Progetto e sviluppo di un applicazione per il pilotaggio remoto di reti di sensori Anno Accademico 2011/2012 relatore Ch.mo prof. Marcello Cinque candidato Andrea Fretta Matr. 534003135

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

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

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

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

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

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

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

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

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

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

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Ingegneria del Web SISTEMA DI PREFETCHING CLIENT-SIDE PER

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

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

Dettagli

tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana candidato Manganiello Felice Matr. 534/001569

tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana candidato Manganiello Felice Matr. 534/001569 tesi di laurea CONFRONTO TRA SOLUZIONI COMMERCIALI PER LA REALIZZAZIONE Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana candidato Manganiello Felice Matr. 534/001569 CONFRONTO TRA SOLUZIONI

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

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

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Il software di base Software

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

Corso Analista Programmatore Java Corso Online Analista Programmatore Java

Corso Analista Programmatore Java Corso Online Analista Programmatore Java Corso Analista Programmatore Java Corso Online Analista Programmatore Java Accademia Futuro info@accademiafuturo.it Programma Generale del Corso Analista Programmatore Java Tematiche Trattate Modulo Uno

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

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

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che Prefazione In questo volume completiamo l esplorazione del linguaggio Java che abbiamo iniziato in Java Fondamenti di programmazione. I due testi fanno parte di un percorso didattico unitario, come testimoniano

Dettagli

Android development. Sviluppo di Mobile Apps sul sistema operativo di Google

Android development. Sviluppo di Mobile Apps sul sistema operativo di Google Android development Sviluppo di Mobile Apps sul sistema operativo di Google Agenda Giorni: Gio 14/04/2011 Ven 15/04/2011 Gio 21/04/2011 Ven 22/04/2011 Suddivisione: Mattina: teoria Pomeriggio: pratica

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

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

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

Corso Programmazione Java Android. Programma

Corso Programmazione Java Android. Programma Corso Programmazione Java Android Programma 1.1 Obiettivo e modalità di fruizione L obiettivo del corso è di fornire le conoscenze tecniche e metodologiche per svolgere la professione di Programmatore

Dettagli

Organizzazioni nel Grid Computing

Organizzazioni nel Grid Computing Il ruolo delle Organizzazioni nel Grid Computing Un primo sguardo a Globus - Parte 5 Organizzazioni di Grid Computing Panoramica sui prodotti software Primo sguardo a Globus Dott. Marcello CASTELLANO La

Dettagli

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

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

DomoNet e DomoPredict: due framework open-source per l'interoperabilità domotica e l'ambient Intelligence

DomoNet e DomoPredict: due framework open-source per l'interoperabilità domotica e l'ambient Intelligence Istituto di Scienza e Tecnologie dell'informazione A Faedo (ISTI) Laboratorio di domotica DomoNet e DomoPredict: due framework open-source per l'interoperabilità domotica e l'ambient Intelligence Dario

Dettagli

Informatica di Base. Il software

Informatica di Base. Il software di Base 1 Sistemi informatici Hardware Microprocessore Memoria Periferiche di input e output Software Software di sistema Programmi applicativi 2 Il sw applicativo Il sw applicativo è costituito dall insieme

Dettagli

Standard Tecnologici Regione Basilicata ALLEGATO C03

Standard Tecnologici Regione Basilicata ALLEGATO C03 Standard Tecnologici Regione Basilicata ALLEGATO C03 UFFICIO S. I. R. S. Standard Tecnologici ver. 2.1 ultimo agg.: 06/06/2012 CONTROLLO DEL DOCUMENTO Data APPROVAZIONI Autore Redatto da: 27/05/2012 Dott.

Dettagli

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix I veri benefici dell Open Source nell ambito del monitoraggio IT Georg Kostner, Department Manager Würth Phoenix IT Service Management secondo ITIL Il valore aggiunto dell Open Source Servizi IT Hanno

Dettagli

Informatica di Base - 6 c.f.u.

Informatica di Base - 6 c.f.u. Università degli Studi di Palermo Dipartimento di Ingegneria Informatica Informatica di Base - 6 c.f.u. Anno Accademico 2007/2008 Docente: ing. Salvatore Sorce Il Sistema Operativo Gerarchia del software

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