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

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

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

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

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

Configurazione avanzata di IBM SPSS Modeler Entity Analytics

Configurazione avanzata di IBM SPSS Modeler Entity Analytics Configurazione avanzata di IBM SPSS Modeler Entity Analytics Introduzione I destinatari di questa guida sono gli amministratori di sistema che configurano IBM SPSS Modeler Entity Analytics (EA) in modo

Dettagli

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONNECTING FIRST AND SECOND LIFE Università degli studi di Catania Facoltà di Ingegneria 26 Gennaio 2009 Sommario 1 Introduzione 2 Middleware Middleware:

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

MailStore Proxy è disponibile gratuitamente per tutti i clienti di MailStore Server all indirizzo http://www.mailstore.com/en/downloads.

MailStore Proxy è disponibile gratuitamente per tutti i clienti di MailStore Server all indirizzo http://www.mailstore.com/en/downloads. MailStore Proxy Con MailStore Proxy, il server proxy di MailStore, è possibile archiviare i messaggi in modo automatico al momento dell invio/ricezione. I pro e i contro di questa procedura vengono esaminati

Dettagli

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata Giampiero Carboni Davide Travaglia David Board Rev 5058-CO900C Interfaccia operatore a livello di sito FactoryTalk

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Rational Asset Manager, versione 7.1

Rational Asset Manager, versione 7.1 Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Note Prima di utilizzare queste informazioni e il prodotto

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

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

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it Zabbix 4 Dummies Dimitri Bellini, Zabbix Trainer Quadrata.it Relatore Nome: Biografia: Dimitri Bellini Decennale esperienza su sistemi operativi UX based, Storage Area Network, Array Management e tutto

Dettagli

IT Service Management, le best practice per la gestione dei servizi

IT Service Management, le best practice per la gestione dei servizi Il Framework ITIL e gli Standard di PMI : : possibili sinergie Milano, Venerdì, 11 Luglio 2008 IT Service Management, le best practice per la gestione dei servizi Maxime Sottini Slide 1 Agenda Introduzione

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

TeamPortal. Servizi integrati con ambienti Gestionali

TeamPortal. Servizi integrati con ambienti Gestionali TeamPortal Servizi integrati con ambienti Gestionali 12/2013 Modulo di Amministrazione Il modulo include tutte le principali funzioni di amministrazione e consente di gestire aspetti di configurazione

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

Manuale installazione KNOS

Manuale installazione KNOS Manuale installazione KNOS 1. PREREQUISITI... 3 1.1 PIATTAFORME CLIENT... 3 1.2 PIATTAFORME SERVER... 3 1.3 PIATTAFORME DATABASE... 3 1.4 ALTRE APPLICAZIONI LATO SERVER... 3 1.5 ALTRE APPLICAZIONI LATO

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

Guida all'installazione ed uso dell'app RXCamLink

Guida all'installazione ed uso dell'app RXCamLink Guida all'installazione ed uso dell'app RXCamLink Questa guida riporta i passi relativi all'installazione ed all'utilizzo dell'app "RxCamLink" per il collegamento remoto in mobilità a sistemi TVCC basati

Dettagli

IDom. Omnicon SRL Via Petrarca 14 20843 Verano Brianza (MB) info@omnicon.it

IDom. Omnicon SRL Via Petrarca 14 20843 Verano Brianza (MB) info@omnicon.it IDom MANUALE UTENTE Omnicon SRL Via Petrarca 14 20843 Verano Brianza (MB) info@omnicon.it 2 COPYRIGHT Tutti i nomi ed i marchi citati nel documento appartengono ai rispettivi proprietari. Le informazioni

Dettagli

dei processi di customer service

dei processi di customer service WHITE PAPER APRILE 2013 Il Business Process Orchestrator dei processi di customer service Fonte Dati: Forrester Research Inc I marchi registrati citati nel presente documento sono di proprietà esclusiva

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

Processi ITIL. In collaborazione con il nostro partner: Processi ITIL In collaborazione con il nostro partner: NetEye e OTRS: la piattaforma WÜRTHPHOENIX NetEye è un pacchetto di applicazioni Open Source volto al monitoraggio delle infrastrutture informatiche.

Dettagli

Milano, Settembre 2009 BIOSS Consulting

Milano, Settembre 2009 BIOSS Consulting Milano, Settembre 2009 BIOSS Consulting Presentazione della società Agenda Chi siamo 3 Cosa facciamo 4-13 San Donato Milanese, 26 maggio 2008 Come lo facciamo 14-20 Case Studies 21-28 Prodotti utilizzati

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

IBM UrbanCode Deploy Live Demo

IBM UrbanCode Deploy Live Demo Dal 1986, ogni giorno qualcosa di nuovo Marco Casu IBM UrbanCode Deploy Live Demo La soluzione IBM Rational per il Deployment Automatizzato del software 2014 www.gruppoconsoft.com Azienda Nata a Torino

Dettagli

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti Dai sistemi concorrenti ai sistemi distribuiti Problemi nei sistemi concorrenti e distribuiti I sistemi concorrenti e distribuiti hanno in comune l ovvio problema di coordinare le varie attività dei differenti

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE

PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE Il grande successo della programmazione orientata agli oggetti non ha limitato la ricerca di nuovi paradigmi e tecnologie che possano

Dettagli

ITIL. Introduzione. Mariosa Pietro

ITIL. Introduzione. Mariosa Pietro ITIL Introduzione Contenuti ITIL IT Service Management Il Servizio Perchè ITIL ITIL Service Management life cycle ITIL ITIL (Information Technology Infrastructure Library) è una raccolta di linee guida,

Dettagli

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

Descrizione tecnica Indice

Descrizione tecnica Indice Descrizione tecnica Indice 1. Vantaggi del sistema Vertical Booking... 2 2. SISTEMA DI PRENOTAZIONE ON LINE... 3 2.1. Caratteristiche... 3 I EXTRANET (Interfaccia per la gestione del programma)... 3 II

Dettagli

CORPORATE OVERVIEW. www.akhela.com

CORPORATE OVERVIEW. www.akhela.com CORPORATE OVERVIEW www.akhela.com BRIDGE THE GAP CORPORATE OVERVIEW Bridge the gap Akhela è un azienda IT innovativa che offre al mercato servizi e soluzioni Cloud Based che aiutano le aziende a colmare

Dettagli

IT-BOOK. Domini Hosting Web marketing E-mail e PEC

IT-BOOK. Domini Hosting Web marketing E-mail e PEC 5 giugno 09 IT-BOOK Configurazioni e cartatteristiche tecniche possono essere soggette a variazioni senza preavviso. Tutti i marchi citati sono registrati dai rispettivi proprietari. Non gettare per terra:

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY Con Kaspersky, adesso è possibile. www.kaspersky.it/business Be Ready for What's Next SOMMARIO Pagina 1. APERTI 24 ORE SU 24...2

Dettagli

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory FILE SYSTEM : INTERFACCIA 8.1 Interfaccia del File System Concetto di File Metodi di Accesso Struttura delle Directory Montaggio del File System Condivisione di File Protezione 8.2 Concetto di File File

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

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 secondo ITIL Il valore aggiunto dell Open Source Servizi IT Hanno lo scopo di

Dettagli

Agilent OpenLAB Chromatography Data System (CDS)

Agilent OpenLAB Chromatography Data System (CDS) Agilent OpenLAB Chromatography Data System (CDS) EZChrom Edition e ChemStation Edition Requisiti hardware e software Agilent Technologies Informazioni legali Agilent Technologies, Inc. 2013 Nessuna parte

Dettagli

Studio di retribuzione 2014

Studio di retribuzione 2014 Studio di retribuzione 2014 TECHNOLOGY Temporary & permanent recruitment www.pagepersonnel.it EDITORIALE Grazie ad una struttura costituita da 100 consulenti e 4 uffici in Italia, Page Personnel offre

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

1 EJB e Portal Component Object http://desvino.altervista.org

1 EJB e Portal Component Object http://desvino.altervista.org 1 EJB e Portal Component Object http://desvino.altervista.org In questo tutorial studiamo come sfruttare la tecnologia EJB, Enterprise JavaBean, all interno del SAP Netweaver Portal. In breve, EJB è un

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra

UNIVERSITÀ DEGLI STUDI DI BERGAMO. PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra PROPOSTE di TIROCINI/TESI di LAUREA - Prof. Patrizia Scandurra A seguire alcune proposte di tirocini/tesi in tre ambiti dell ingegneria del software (non del tutto scorrelati): (1) Model-driven driven

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

PASSIONE PER L IT PROLAN. network solutions

PASSIONE PER L IT PROLAN. network solutions PASSIONE PER L IT PROLAN network solutions CHI SIAMO Aree di intervento PROFILO AZIENDALE Prolan Network Solutions nasce a Roma nel 2004 dall incontro di professionisti uniti da un valore comune: la passione

Dettagli

PROFILI ALLEGATO A. Profili professionali

PROFILI ALLEGATO A. Profili professionali ALLEGATO A Profili professionali Nei profili di seguito descritti vengono sintetizzate le caratteristiche di delle figure professionali che verranno coinvolte nell erogazione dei servizi oggetto della

Dettagli

un occhio al passato per il tuo business futuro

un occhio al passato per il tuo business futuro 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 un occhio al passato per il tuo business futuro BUSINESS DISCOVERY Processi ed analisi per aziende virtuose Che cos è La Business Discovery è un insieme

Dettagli

DigitPA egovernment e Cloud computing

DigitPA egovernment e Cloud computing DigitPA egovernment e Cloud computing Esigenze ed esperienze dal punto di vista della domanda RELATORE: Francesco GERBINO 5 ottobre 2010 Agenda Presentazione della Società Le infrastrutture elaborative

Dettagli

SYSKOPLAN REPLY IMPLEMENTA PER IL GRUPPO INDUSTRIALE SCHOTT UNA SOLUZIONE SAP CRM SU BASE SAP HANA E OPERATIVA IN 35 PAESI.

SYSKOPLAN REPLY IMPLEMENTA PER IL GRUPPO INDUSTRIALE SCHOTT UNA SOLUZIONE SAP CRM SU BASE SAP HANA E OPERATIVA IN 35 PAESI. SYSKOPLAN REPLY IMPLEMENTA PER IL GRUPPO INDUSTRIALE SCHOTT UNA SOLUZIONE SAP CRM SU BASE SAP HANA E OPERATIVA IN 35 PAESI. Come gruppo industriale tecnologico leader nel settore del vetro e dei materiali

Dettagli

Boot Camp Guida all installazione e alla configurazione

Boot Camp Guida all installazione e alla configurazione Boot Camp Guida all installazione e alla configurazione Indice 4 Introduzione 5 Cosa ti occorre 6 Panoramica dell installazione 6 Passo 1: verifica la presenza di aggiornamenti. 6 Passo 2: apri Assistente

Dettagli

La gestione dei servizi non core: il Facility Management

La gestione dei servizi non core: il Facility Management La gestione dei servizi non core: il Facility Management ing. Fabio Nonino Università degli studi di Udine Laboratorio di Ingegneria Gestionale Dipartimento di Ingegneria Elettrica, Gestionale e Meccanica

Dettagli

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it ISO 9001: 2008 Profilo Aziendale METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it Sede legale: * Viale Brodolini, 117-60044 - Fabriano (AN) - Tel. 0732.251856 Sede amministrativa:

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

SISSI IN RETE. Quick Reference guide guida di riferimento rapido

SISSI IN RETE. Quick Reference guide guida di riferimento rapido SISSI IN RETE Quick Reference guide guida di riferimento rapido Indice generale Sissi in rete...3 Introduzione...3 Architettura Software...3 Installazione di SISSI in rete...3 Utilizzo di SISSI in Rete...4

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

F O R M A T O E U R O P E O

F O R M A T O E U R O P E O F O R M A T O E U R O P E O P E R I L C U R R I C U L U M V I T A E INFORMAZIONI PERSONALI Nome Indirizzo Laura Bacci, PMP Via Tezze, 36 46100 MANTOVA Telefono (+39) 348 6947997 Fax (+39) 0376 1810801

Dettagli

CMN4i (Vers. 1.1.0 del 27/02/2014)

CMN4i (Vers. 1.1.0 del 27/02/2014) CMN4i (Vers. 1.1.0 del 27/02/2014) Il monitoring che permette di avere la segnalazione in tempo reale dei problemi sul vostro sistema IBM System i Sommario Caratterisitche... Errore. Il segnalibro non

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Ottimizzazione della gestione del data center con Microsoft System Center

Ottimizzazione della gestione del data center con Microsoft System Center Ottimizzazione della gestione del data center con Microsoft System Center Declinazione di responsabilità e informazioni sul copyright Le informazioni contenute nel presente documento rappresentano le conoscenze

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l.

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. Babel S.r.l. - P.zza S. Benedetto da Norcia 33, 00040 Pomezia (RM) www.babel.it

Dettagli

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto Scheda descrittiva del programma Open-DAI ceduto in riuso CSI-Piemonte in rappresentanza del Consorzio di progetto Agenzia per l Italia Digitale - Via Liszt 21-00144 Roma Pagina 1 di 19 1 SEZIONE 1 CONTESTO

Dettagli

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Data Sheet IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Panoramica Le medie aziende devono migliorare nettamente le loro capacità

Dettagli