BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei"

Transcript

1 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 ( ) Abstract L obiettivo di questo articolo è descrivere la progettazione e l implementazione di un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web con software di comune distribuzione nelle macchine locali. Il sistema è stato poi esteso per aumentare la QoS introducendo un cluster di server. 1 Introduzione Questo progetto nasce da una esigenza sempre più comune nello sviluppo di sistemi software: la collaborazione tra elementi eterogenei, ovvero scritti in linguaggi diversi ed operanti in diversi sistemi operativi. Lo scopo del progetto è fornire un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web (installata su un server) con software di comune distribuzione nelle macchine locali (es: Microsoft Outlook e Microsoft Pocket Outlook). Poiché i dati possono essere modificati sia sui dispositivi locali che sul server, la sincronizzazione deve essere intelligente, cioè deve poter capire a quale dei due sistemi prestar fede, e prevedere diverse politiche di sincronizzazione e variarla nel tempo, eventualmente prevedendo la possibilità di interpellare l utente stesso in caso di dubbio. Si consideri inoltre che, mentre il server web è sempre on-line, gli altri sistemi possono effettuare modifiche anche off-line e solo in seguito eseguire la sincronizzazione. Nella prossima parte sarà analizzato il problema nei suoi aspetti critici, sondando possibili alternative di soluzione. La terza sezione tratterà delle scelte effettuate nella soluzione, e la quarta mostrerà i dettagli principali dell implementazione. La quinta parte esaminerà un estensione del sistema, introducendo la replicazione del server. 2 Analisi del problema Il problema evidenzia tre importanti aspetti che devono essere affrontati con riguardo: l eterogeneità, il coordinamento tra le entità e le politiche di sincronizzazione. 2.1 Eterogeneità Le entità sono in generale software diversi che girano su piattaforme diverse, e soprattutto che organizzano le informazioni in modo diverso. Perciò è necessario in qualche modo tradurre le informazioni in una struttura logica unica per poterle confrontare. Questa potrebbe essere una struttura astratta creata dal sistema o un vero e proprio file esportato dalle diverse entità in uno standard comune. Questo secondo caso appare più interessante in

2 quanto permette la progettazione di un unico software di sincronizzazione, di cui qualunque programma di terze parti può usufruire previa la realizzazione di un plugin di esportazione ad hoc. 2.2 Coordinamento tra entità La presenza del server web sempre on-line richiama subito l idea di un sistema client/server, che facilita molto la sincronizzazione in quanto è possibile permettere ad una sola entità di monitorare l intera operazione. Questo modello però comporta un alto carico di lavoro sul server, che è prevedibile lavori con diversi utenti contemporaneamente. Non è perciò da escludere una implementazione secondo il modello P2P, considerando che ogni entità ha, a prescindere, la stessa veridicità per quanto riguarda le informazioni che contiene. 2.3 Politiche di sincronizzazione Occorre considerare innanzitutto che in generale le entità, escluso il server web, potrebbero effettuare modifiche sulle informazioni in modalità off-line. Inoltre lo stesso utente potrebbe voler attualizzare le informazioni da due dispositivi diversi contemporaneamente. La sincronizzazione deve essere quindi un operazione atomica, perché sia garantita la consistenza dei dati. Il sistema deve poi prevedere diverse politiche di sincronizzazione, dipendenti dal tempo (ad esempio: è la prima sincronizzazione, e quindi in generale le informazioni locali non sono aggiornate, o il contrario) e dal luogo (ossia dal dispositivo); occorre quindi che queste politiche siano facilmente modificabili e che il sistema ne sia indipendente. 3 Scelte progettuali 3.1 Eterogeneità e politiche di sincronizzazione Il problema dell eterogeneità ha portato alla scelta del Java come linguaggio di implementazione, in quanto è indipendente dalla piattaforma su cui gira, ed è largamente diffuso anche nelle tecnologie mobili. Per permettere il confronto dei dati si è pensato ad un formato standard in cui rappresentarli, ed è stato scelto come linguaggio l Xml, standard sempre più in uso che presenta forti vantaggi in quanto a usabilità e leggerezza, nonché diffusione. Sarà necessario perciò realizzare un exporter (in un linguaggio di programmazione qualunque!) per ogni diverso sistema che vuole interagire attraverso la nostra applicazione. Ma, grazie a questo standard, è anche possibile immaginare che vengano implementati sistemi a partire dal formato Xml da noi utilizzato come standard. Sarà utilizzato l Xml anche per la definizione delle politiche da seguire, rendendone così facile la configurazione. 3.2 Coordinamento Il nostro sistema presenta una forte asimmetria: da una parte abbiamo un server web, sempre on-line ma che deve gestire l accesso di più utenti allo stesso tempo (e anche dello stesso utente da più postazioni); dall altra delle entità che lavorano sia on-line che off-line, e lavorano con un singolo utente. Perciò, nonostante le riflessioni sulla parità di ruolo di tutte le entità, la scelta più efficace appare essere quella di un sistema client/server. È però necessario che il carico di lavoro sul server sia minimo. Ogni operazione di sincronizzazione è quindi effettuata rispetto al server, visto che è l unica entità sempre on-line, il quale ha quindi il solo compito di fornire la sua versione dei dati, nonché di impedire l accesso ai dati dello stesso utente da più postazioni, e garantire l atomicità e la consistenza delle operazioni di sincronizzazione. Compito del client è quindi fare richiesta di sincronizzazione al server ed effettuare il confronto dei dati. In questo modo sarebbe anche facilmente implementabile una politica che preveda l interrogazione diretta del client: l esecuzione avverrebbe sempre in locale, e non comporterebbe un carico di lavoro maggiore da parte del server e della rete. 4 Implementazione Il middleware è stato implementato tralasciando, oltre agli exporter (che come si è già detto sono componenti di fatto esterne al sistema), l interfaccia grafica. È perciò contemplata ma non implementata la possibilità di interrogare direttamente l utente in caso di dubbio. 2

3 Il sistema comprende due sottosistemi in comunicazione tra loro: il client e il server. Entrambi sono stati realizzati secondo una logica di layer, così da facilitare la modifica ed il riutilizzo dei componenti. Local Software WebServer-DB GUI Importer Policy Importer Application Layer Application Layer Network Layer Network Layer Disegno 1: Layers L atomicità dell operazione è realizzata tramite le operazioni di Lock e UnLock che operano sul server a livello Application. In figura 1 e 2 sono riportate le strutture logiche del Client e del Server, ad un livello di astrazione tale da riportare solo i metodi essenziali. Figura 1 Il client ruota attorno alla classe AppLayer, che si serve delle altre classi del sistema. Il dialogo col server è reso trasparente grazie alla classe NetLayer, che implementa il layer di rete, la quale, una volta istanziata, maschera tutto il dialogo di rete con due chiamate di invio e ricezione di file. Figura 2 Il server è stato implementato a partire dal basic remoting pattern Singleton. Questo ci permette di avere una classe istanziata una sola volta, la classe Framework, che, oltre a prendersi carico dell inizializzazione dello Stub e quindi dell infrastruttura di rete, gestisce il delicato accesso alla LockList, nonché la classe LockManager, responsabile di monitorare la lista. Essendo un singleton ha tra l altro il vantaggio di poter essere chiamata da chiunque ne abbia la visibilità (come il NetLayer). Si noti inoltre la classe NetUtility: questa classe composta esclusivamente di metodi statici si può considerare come un semplice middleware per standardizzare la comunicazione tra i componenti del sistema. Fornisce il passaggio di due tipi di dato: messaggio e file. La classe XmlUtility provvede invece tutti i metodi per manipolare i file xml. L interazione tra client e server è riportata in fig. 3. Come si vede il server ha un comportamento passivo, in quanto aspetta le interrogazioni del client e non è preoccupato dell esito dell operazione. Al contrario il client conosce perfettamente l esito delle operazioni e, in caso di errore, può agire di conseguenza. 3

4 Figura 3 L interazione è divisa in due fasi: lock e sync. Questa divisione non è solo logica: la connessione viene chiusa alla fine di ogni fase. Questo per ottimizzare l utilizzo della banda e minimizzare l occupazione delle porte del server. Inoltre, pensando alla possibilità che il processo di sincronizzazione interagisca con l utente, evita di mantenere aperta una connessione inoperosa. In questo modo però il server resterebbe all oscuro di un eventuale fallimento del processo di sincronizzazione, e non potrebbe eliminare la lock effettuata dal client. Per questo è stato pensato un monitor che, dato un tempo massimo di validità della lock, controlla periodicamente il registro di lock per scartare le entry scadute. L eterogeneità è stata risolta, come detto, dall utilizzo di un formato standard basato sull Xml. Il layer Application del client quindi effettuerà una comparazione tra il documento locale, riportato dall Importer, e quello remoto, ricevuto dal Network Layer. Le scelte saranno guidate dalla politica impostata nel file di policy, anch esso in xml. Un esempio di file di policy è il seguente: <?xml version="1.0" encoding="iso "?> <!-- Local: creato in locale. Remote: creato in rem.--> <policy> <new> <!-- possibilità: keep/skip/ask --> <local> keep </local> <remote> skip </remote> </new> <different> <!-- possibilità: keeplocal/keepremote/ask--> <localnewer> keeplocal </localnewer> <remotenewer> keeplocal </remotenewer> <samedate> keepremote </samedate> </different> </policy> Il sistema è stato sviluppato con il framework Eclipse usando Java JRE 1.5. E stato testato in ambiente Windows. 5 Estensione: Server replicati Vogliamo ora incrementare la Qualità del Servizio del nostro sistema. In particolare vogliamo far sì che, in caso di caduta del server, sia ancora possibile fruire del servizio in modo trasparente all utente che lavora da un dispositivo client: vogliamo quindi garantire un servizio sempre attivo 24/7. Visto che abbiamo considerato l exporter server-db come un componente esterno, non ci occuperemo della fault-tolerance del database, in quanto supporremo già fornito da terze parti. Nel nostro sistema fornire un servizio attivo 24/7 vuol dire far si che, in caso di caduta di un server, ce ne sia un altro che possa fornire lo stesso servizio, e questo conservando l atomicità dell azione rispetto all utente. Quindi è necessario avere un sistema replicato in cui tutti i server vedano la tabella dei lock aggiornata. La soluzione proposta prevede di avere un cluster di server secondo il modello del bilanciamento di carico. Ogni copia può realizzare il protocollo di scambio con il client, e il sistema provvede alla sincronizzazione e al bilanciamento. 4

5 Per la gestione dei server si introduce un nuovo componente, chiamato Broker, che dovrà occuparsi della ricezione della richiesta da parte del client, l assegnazione di un server, nonché del monitoraggio e della sincronizzazione del cluster. In questo modo, però, il collo di bottiglia creato dalla possibile caduta del server è solo spostato ad un altra entità. Per questo anche il Broker dovrà essere a sua volta replicato. Figura 4 Il client ora non interrogherà più direttamente il server, ma dovrà contattare il broker. Questi gli dovrà passare il riferimento ad un server. Perciò cambierà leggermente il protocollo di comunicazione, che sarà realizzato come in figura 5. Come si può vedere, dal lato client c è un solo significativo cambiamento: la contrattazione del server come fase iniziale. Contrattazione determinata dalla presenza del messaggio change server. Anche dal lato server i cambiamenti sono minimi: la possibilità di ricevere un ping e il messaggio di lock indiretto lock <username> ##Broker, il cui significato sarà spiegato in seguito. La limitatezza di queste modifiche fa si che sia il client che il server siano ancora compatibili con il precedente protocollo: è ancora possibile la comunicazione diretta client-server senza alcuna mediazione. L introduzione del broker ci permette di delegare a questi il monitoraggio ed il bilanciamento dei server. Il broker sarà in possesso di una lista dei server attivi e di una lista dei server offline, e istanzierà dei processi di monitoraggio per poter aggiornare il contenuto delle liste. In particolare saranno presenti due oggetti attivi, ServerManager e ServerRestore. Il primo monitorerà i server attivi, e, in caso di caduta di uno di questi, li sposterà nella lista dei server offline. Il secondo controllerà i server offline tentando di ripristinare quelli che sono tornati raggiungibili. La struttura logica del broker è riportata in figura 6. Figura 6 Figura 5 La ServerList è stata implementata come un singleton doppio, estendendo la 5

6 peculiarità del singleton alle due liste di cui necessitiamo. Si noti che, nonostante l analogia col server, la classe Broker non è un singleton come la classe server.application.framework. Questo perché nel broker tutta la parte a livello di applicazione riguarda la ServerList, e perciò è a questa classe che è stato applicato il pattern. Le informazioni dei server sono incapsulati nella classe serializable ServerInfo. E perciò possibile inviarli ad oggetti remoti (quali i client) grazie ai nuovi metodi getobj e sendobj aggiunti alla classe NetUtility, a cui è stata anche aggiunta la funzione connect(serverinfo). La ServerList incapsula i server nella classe ServerListInfo, che estende la ServerInfo aggiungendo l attributo use che permette di utilizzare un algoritmo di bilanciamento di carico: ad ogni chiamata getworkingserver viene scelto il server con il parametro use maggiore, e allo stesso tempo viene incrementato di uno il valore di tutti i server. I parametro del server scelto viene poi decrementato del numero dei server presenti. Viene qui assunta nuovamente una politica positivista: il server ritornato è sicuramente on-line. Questa scelta, basata sull esistenza di un doppio monitoraggio (si veda il prossimo capoverso), permette di risparmiare il tempo altrimenti perso da una verifica dello stato del server. La sincronizzazione viene effettuata con una strategia positivista al momento stesso delle chiamata da parte dell utente: mentre il server scelto viene messo in comunicazione con l utente, agli altri server viene inviata la stessa richiesta con il suffisso ##Broker. Questo viene codificato dal server come una richiesta differente, in quanto eseguirà solo le operazioni che riguardano la lock. In questo modo si suppone che l esecuzione sul server scelto vada a buon fine. Questa scelta è stata dettata dalla volontà di minimizzare i cambiamenti, e supportata dalla relativa semplicità dell operazione. Si è deciso quindi di seguire una politica simile all aggiornamento eager di tutte le copie, ma le copie secondarie eseguono l operazione solo parzialmente, e non c è una fase di accordo finale. La chiamata agli altri server viene eseguita attraverso il ServerManager: questo permette di aggiornare la lista dei server attivi. Il ServerManager può essere eseguito anche come processo indipendente che si ripete ad intervalli regolari, in modo da migliorare il throughput al momento della richiesta da parte del cliente nel caso di un lungo intervallo di inattività del sistema. Il ServerRestore viene istanziato come un processo indipendente che, ad intervalli regolari, effettua una ping su tutti i server offline. Nel caso di risposta affermativa avvia la procedura di restore schematizzata in figura 7. Figura 7 Viene richiesto alla ServerList un WorkingServer, e a questi viene richiesto di comunicare al server in fase di restoring la lista delle lock. In seguito viene reinserito tra i server attivi. L operazione usa nuovamente i metodi sendobj e receiveobj di NetUtility, perciò anche la classe Lock ora implementa l interfaccia Serializable. La replicazione del broker è realizzata attraverso un cluster statico (nel nostro caso 2 istanze) a copie attive, una primaria ed una secondaria: entrambi i broker possono operare in maniera indipendente, e non è necessaria nessuna fase di aggiornamento tra i due, in quanto ognuno monitora comunque i server attivi. Il client avrà l indirizzo di entrambi, e potrà 6

7 accedere alla copia secondaria in caso non sia disponibile quella primaria. Sarebbe interessante, come attività futura, sviluppare in modo più completo questa replicazione, ad esempio condividendo tra i broker le informazioni di bilanciamento del carico dei server, o sfruttando il broker secondario per il controllo dello stato dei server. Le modifiche al client per adattarlo a questa estensione sono minime: è stato modificato unicamente il layer di rete, introducendo la possibilità della contrattazione del server con il broker, ad eccezione dell aggiunta di un ulteriore parametro nella configurazione per conoscere anche l indirizzo del broker secondario. Si è approfittato del cambiamento per eseguire anche una refactory del codice sfruttando la nuova classe ServerInfo dove possibile. E possibile eliminare il broker e creare un sistema di coordinamento per cui un server si prende dinamicamente l incarico di coordinatore. E possibile implementare un layer di rete alternativo che utilizzi un altra tecnologia (es: bluetooth) per la comunicazione tra un dispositivo comunque connesso alla rete (che può comportarsi quindi come un server, essendo sincronizzato con il server principale) ed uno che non può connettersi. Il server ha subito anch esso i cambiamenti principalmente nel Network Layer, per adattarlo alle nuove funzionalità come la comunicazione con il broker ed il restoring, ed ha subito qualche modifica anche nel layer applicativo: oltre alla modifica già citata della classe Lock, si sono aggiunti nuovi metodi nel Framework e nella LockList per l invio e la ricezione dell intera lista. 6 Conclusioni È stato realizzato un middleware di sincronizzazione per sistemi eterogenei, che prevede l utilizzo di un formato standard basato sull xml per il confronto dei dati, la possibilità di definire politiche di sincronizzazione anch esse in xml, che si basa su di un modello client/server. Il middleware è stato progettato ed implementato, rispondendo a tutti i requisiti. Lo si è poi esteso aumentandone la Qualità di Servizio, introducendo un cluster di server gestito da un broker a sua volta replicato. Grazie ad una politica positivista, il servizio non ha perso significativamente velocità, guadagnando in disponibilità. 6.1 Sviluppi futuri E possibile modificare il cluster di server utilizzando una politica non positivista, e quindi con un protocollo di coordinazione tra broker e server più complesso ma più affidabile. 7

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

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

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

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

Dettagli

Database e reti. Piero Gallo Pasquale Sirsi

Database e reti. Piero Gallo Pasquale Sirsi Database e reti Piero Gallo Pasquale Sirsi Approcci per l interfacciamento Il nostro obiettivo è, ora, quello di individuare i possibili approcci per integrare una base di dati gestita da un in un ambiente

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

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

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

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

Dettagli

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

27/03/2013. Contenuti

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

Dettagli

La Document Orientation. Come implementare un interfaccia

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

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

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

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Progetto Virtualizzazione

Progetto Virtualizzazione Progetto Virtualizzazione Dipartimento e Facoltà di Scienze Statistiche Orazio Battaglia 25/11/2011 Dipartimento di Scienze Statiche «Paolo Fortunati», Università di Bologna, via Belle Arti 41 1 La nascita

Dettagli

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

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

Dettagli

L E I N F O R M A Z I O N I P E R F A R E

L E I N F O R M A Z I O N I P E R F A R E L E I N F O R M A Z I O N I P E R F A R E C E N T R O Con InfoBusiness avrai Vuoi DATI CERTI per prendere giuste DECISIONI? Cerchi CONFERME per le tue INTUIZIONI? Vuoi RISPOSTE IMMEDIATE? SPRECHI TEMPO

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

Il Contesto. Riassunto

Il Contesto. Riassunto Temento Systems mostra come la tecnologia Jtag Boundary-Scan integrata in un sistema automatico di collaudo possa aumentare la copertura del test di schede complesse altrimenti non collaudabili. Il Contesto

Dettagli

Descrizione generale. Architettura del sistema

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

Dettagli

WEB TECHNOLOGY. Il web connette. LE persone. E-book n 2 - Copyright Reserved

WEB TECHNOLOGY. Il web connette. LE persone. E-book n 2 - Copyright Reserved WEB TECHNOLOGY Il web connette LE persone Indice «Il Web non si limita a collegare macchine, ma connette delle persone» Il Www, Client e Web Server pagina 3-4 - 5 CMS e template pagina 6-7-8 Tim Berners-Lee

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

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

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

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Turbodoc. Archiviazione Ottica Integrata

Turbodoc. Archiviazione Ottica Integrata Turbodoc Archiviazione Ottica Integrata Archiviazione Ottica... 3 Un nuovo modo di archiviare documenti, dei e immagini... 3 I moduli di TURBODOC... 4 Creazione dell armadio virtuale... 5 Creazione della

Dettagli

L e A p p l i c a z i o n i

L e A p p l i c a z i o n i L e A p p l i c a z i o n i I software necessari per la gestione degli accessi in dial-up. B L U E P R O X Y L I T E 2 B L U E N A T 3 B L U E P R O X Y P L U S 4 B L U E M A I L S E R V E R 5 B L U E

Dettagli

LICARUS LICENSE SERVER

LICARUS LICENSE SERVER UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Sicurezza dei Sistemi Informatici LICARUS LICENSE SERVER

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

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

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

Dettagli

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

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 1. ABSTRACT Al giorno d oggi, l enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che

Dettagli

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

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

Dettagli

MDaemon e Outlook Connector for MDaemon

MDaemon e Outlook Connector for MDaemon MDaemon e Outlook Connector for MDaemon Introduzione...2 Cos'è il groupware...2 Che cosa significa groupware?...2 Cos è WorldClient...2 MDaemon e l evoluzione delle funzionalità groupware...3 Nuove funzionalità

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

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

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T1 B2 Significato e proprietà della OOP 1 Prerequisiti Concetto ed elementi della comunicazione Allocazione e deallocazione della memoria Compilazione di un programma Spazio

Dettagli

OmniAccessSuite. Plug-Ins. Ver. 1.3

OmniAccessSuite. Plug-Ins. Ver. 1.3 OmniAccessSuite Plug-Ins Ver. 1.3 Descrizione Prodotto e Plug-Ins OmniAccessSuite OmniAccessSuite rappresenta la soluzione innovativa e modulare per il controllo degli accessi. Il prodotto, sviluppato

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

Come Funziona. Virtualizzare con VMware

Come Funziona. Virtualizzare con VMware Virtualize 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

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

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli

FileMaker Pro 13. Utilizzo di una Connessione Desktop Remota con FileMaker Pro13

FileMaker Pro 13. Utilizzo di una Connessione Desktop Remota con FileMaker Pro13 FileMaker Pro 13 Utilizzo di una Connessione Desktop Remota con FileMaker Pro13 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054

Dettagli

REGISTRO FACILE (Software per il produttore dei rifiuti)

REGISTRO FACILE (Software per il produttore dei rifiuti) REGISTRO FACILE (Software per il produttore dei rifiuti) Gestire i rifiuti non è mai stato così semplice INDICE: Pag. 1. Caratteristiche 2 2. Installazione 3 3. Richiesta per l attivazione 5 4. Attivazione

Dettagli

1 Progetto di laboratorio di reti I

1 Progetto di laboratorio di reti I 1 Progetto di laboratorio di reti I In questo documento sono descritte le specifiche per la realizzazione del progetto. Vedremo innanzitutto le caratteristiche richieste nel codice e nella relazione, per

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

Gate Manager. Come accedere alla rete di automazione da un PC (Rete cliente) COME ACCEDERE ALLA RETE DI AUTOMAZIONE DA UN PC (RETE CLIENTE)...

Gate Manager. Come accedere alla rete di automazione da un PC (Rete cliente) COME ACCEDERE ALLA RETE DI AUTOMAZIONE DA UN PC (RETE CLIENTE)... Come accedere alla rete di automazione da un PC (Rete cliente) COME ACCEDERE ALLA RETE DI AUTOMAZIONE DA UN PC (RETE CLIENTE)...1 1 INDICE...ERROR! BOOKMARK NOT DEFINED. 2 INTRODUZIONE...2 3 COSA VI SERVE

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

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

Dettagli

Il CMS Moka. Giovanni Ciardi Regione Emilia Romagna

Il CMS Moka. Giovanni Ciardi Regione Emilia Romagna Il CMS Moka Giovanni Ciardi Regione Emilia Romagna Moka è uno strumento per creare applicazioni GIS utilizzando oggetti (cartografie, temi, legende, database, funzioni) organizzati in un catalogo condiviso.

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

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

Dettagli

Guida all installazione di METODO

Guida all installazione di METODO Guida all installazione di METODO In questo documento sono riportate, nell ordine, tutte le operazioni da seguire per una corretta installazione di Metodo. Per procedere con l installazione è necessario

Dettagli

Sistema Informatico per l Elaborazione dei Ruoli e la Gestione Integrata degli Avvisi

Sistema Informatico per l Elaborazione dei Ruoli e la Gestione Integrata degli Avvisi S.IN.E.R.G.I.A. Sistema Informatico per l Elaborazione dei Ruoli e la Gestione Integrata degli Avvisi Manuale Operativo SINERGIA Manuale Operativo S.IN.E.R.G.I.A. 2.5 Pagina 1 di 26 SOMMARIO PRESENTAZIONE...

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

P.D.M. (Product Document Management) Hierarchycal Tree

P.D.M. (Product Document Management) Hierarchycal Tree DOKMAWEB P.D.M. (Product Document Management) Hierarchycal Tree BBL Technology Srl Via Bruno Buozzi 8 Lissone (MI) Tel 039 2454013 Fax 039 2451959 www.bbl.it www.dokmaweb.it BBL Technology srl (WWW.BBL.IT)

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

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

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

Dettagli

Componenti Web: client-side e server-side

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

Dettagli

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015 ASSE DISCIPLINA DOCENTE MATEMATICO INFORMATICA Cattani Barbara monoennio CLASSE: quinta CORSO D SEZIONE LICEO SCIENZE APPLICATE

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

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano Il DNS e la gestione degli indirizzi IP Appunti a cura del prof. ing. Mario Catalano Indirizzi fisici e indirizzi astratti Ogni macchina all interno di una rete è identificata da un indirizzo hardware

Dettagli

M46 GDS documentazione Verticale R0

M46 GDS documentazione Verticale R0 1. Introduzione 2. Soluzione proposta 1. Inserimento e/o modifica dei contratti 2. Inserimento e/o modifica dati anagrafici degli articoli 3. Avanzamento flusso documentale ordine di acquisto 3. Personalizzazione

Dettagli

EASYORDER per ipad White Paper

EASYORDER per ipad White Paper EASYORDER per ipad White Paper SOMMARIO Tour dell app EASYORDER...2 Avvio ed anagrafiche base...2 Appuntamenti e giro visite...6 Catalogo prodotti...8 Ordini di vendita... 11 Documenti... 16 Personalizzazioni...

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Motore di riempimento DB (generatore dati per simulazione)

Motore di riempimento DB (generatore dati per simulazione) SISTEMI DISTRIBUITI prof. S.Pizzutilo Motore di riempimento DB (generatore dati per simulazione) Studente: Alessandro Balestrucci 617937 Corso di Laurea: Informatica Magistrale Dipartimento di Informatica

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

Gestione remota archivi cartelle sanitarie e di rischio informatizzate

Gestione remota archivi cartelle sanitarie e di rischio informatizzate Gestione remota archivi cartelle sanitarie e di rischio informatizzate L odierna realtà economica impone alle aziende di differenziarsi sempre più dai concorrenti, investendo in tecnologie che possano

Dettagli

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com 2015 Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi

Dettagli

@CCEDO: Accessibilità, Sicurezza, Architettura

@CCEDO: Accessibilità, Sicurezza, Architettura Rev. 8, agg. Settembre 2014 @CCEDO: Accessibilità, Sicurezza, Architettura 1.1 Il Sistema di Gestione della Sicurezza Per quanto riguarda la gestione della Sicurezza, @ccedo è dotato di un sistema di autenticazione

Dettagli

Morret Mobile Robot Remote Tunneling

Morret Mobile Robot Remote Tunneling UNIVERSITÀ DI BRESCIA FACOLTÀ DI INGEGNERIA Dipartimento di Elettronica per l Automazione Laboratorio di Robotica Avanzata Advanced Robotics Laboratory Corso di Robotica (Prof. Riccardo Cassinis) Morret

Dettagli

LinkMail, comunica facile!

LinkMail, comunica facile! LinkMail, comunica facile! DEM IL DIRECT EMAIL MARKETING L Email è uno strumento conosciuto, ma probabilmente ancora non ne viene riconosciuto e compreso appieno l elevato potenziale. Un attenta pianificazione

Dettagli

LinkMail, comunica facile!

LinkMail, comunica facile! LinkMail, comunica facile! DEM Il Direct Email Marketing L Email è uno strumento conosciuto, ma probabilmente ancora non ne viene riconosciuto e compreso appieno l elevato potenziale. Un attenta pianificazione

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

Co.El.Da. Software S.r.l. Coelda.Ne Caratteristiche tecniche

Co.El.Da. Software S.r.l.  Coelda.Ne Caratteristiche tecniche Co..El. Da. Software S..r.l.. Coelda.Net Caratteristiche tecniche Co.El.Da. Software S.r.l.. Via Villini Svizzeri, Dir. D Gullì n. 33 89100 Reggio Calabria Tel. 0965/920584 Faxx 0965/920900 sito web: www.coelda.

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo.

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo. Pro COMMERCIALE (La farmacia può decidere di accettare o meno l allineamento commerciale di un prodotto) ACCETTARE IL PRODOTTO SOSTI- TUTIVO (La farmacia può decidere di accettare o meno il prodotto sostitutivo)

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Antonio Brunetti, Mathias Galizia, Fabio Campanella

Antonio Brunetti, Mathias Galizia, Fabio Campanella Atti Progetto AQUATER, Bari, 31 ottobre 2007, 9-14 LA BANCA DATI DEI PROGETTI DI RICERCA E L ARCHIVIO DOCUMENTALE DEL CRA Antonio Brunetti, Mathias Galizia, Fabio Campanella Consiglio per la Ricerca e

Dettagli

EyesDGTV. Your digital terrestrial television. Soluzioni Informatiche

EyesDGTV. Your digital terrestrial television. Soluzioni Informatiche EyesDGTV Your digital terrestrial television Soluzioni Informatiche Cos è EyesDGTV è la soluzione che Betacom propone per la televisione digitale terrestre. Basata su tecnologie consolidate, quali J2EE

Dettagli

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

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

Dettagli

Presentation of: MEDIASTORE ARCHIVE

Presentation of: MEDIASTORE ARCHIVE Presentation of: MEDIASTORE ARCHIVE Application module Release Ver.1.1 Proposed by WWW. SI-MEDIA.TV 1 MediaStore Archive MediaStore Archive e una piattaforma composta da più software che si occupano di

Dettagli

MATRICE DELLE FUNZIONI DI DRAGON NATURALLYSPEAKING 12 CONFRONTO TRA EDIZIONI DEL PRODOTTO

MATRICE DELLE FUNZIONI DI DRAGON NATURALLYSPEAKING 12 CONFRONTO TRA EDIZIONI DEL PRODOTTO MATRICE DELLE FUNZIONI DI DRAGON NATURALLYSPEAKING 12 CONFRONTO TRA EDIZIONI DEL PRODOTTO Precisione del riconoscimento Velocità di riconoscimento Configurazione del sistema Correzione Regolazione della

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Approfondimenti. Contenuti

Approfondimenti. Contenuti Approfondimenti dott. Stefano D. Fratepietro steve@stevelab.net C I R S F I D Università degli studi di Bologna stevelab.net Creative Commons license Stefano Fratepietro - www.stevelab.net 1 Contenuti

Dettagli

Comune di Spoleto QUESITI E RISPOSTE. Quesito n. 1 Per partecipare alla gara è necessario il possesso della certificazione ISO 20000:2005?

Comune di Spoleto QUESITI E RISPOSTE. Quesito n. 1 Per partecipare alla gara è necessario il possesso della certificazione ISO 20000:2005? Procedura aperta per fornitura chiavi in mano di una suite applicativa gestionale Web based completamente integrata e comprensiva dei relativi servizi di assistenza e manutenzione QUESITI E RISPOSTE Quesito

Dettagli

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito LEZIONE 3 Il pannello di amministrazione di Drupal, configurazione del sito Figura 12 pannello di controllo di Drupal il back-end Come già descritto nella lezione precedente il pannello di amministrazione

Dettagli

SIMULAZIONE PROVA SCRITTA ESAME DI STATO. PER LA DISCIPLINA di SISTEMI

SIMULAZIONE PROVA SCRITTA ESAME DI STATO. PER LA DISCIPLINA di SISTEMI SIMULAZIONE PROVA SCRITTA ESAME DI STATO PER LA DISCIPLINA di SISTEMI L assessorato al turismo di una provincia di medie dimensioni vuole informatizzare la gestione delle prenotazioni degli alberghi associati.

Dettagli

Introduzione. Perché è stato scritto questo libro

Introduzione. Perché è stato scritto questo libro Introduzione Perché è stato scritto questo libro Sul mercato sono presenti molti libri introduttivi a Visual C# 2005, tuttavia l autore ha deciso di scrivere il presente volume perché è convinto che possa

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

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

REALIZZAZIONE DI UN LABORATORIO REMOTO PER ESPERIENZE DI ROBOTICA EDUCATIVA: LATO CLIENT

REALIZZAZIONE DI UN LABORATORIO REMOTO PER ESPERIENZE DI ROBOTICA EDUCATIVA: LATO CLIENT TESI DI LAUREA REALIZZAZIONE DI UN LABORATORIO REMOTO PER ESPERIENZE DI ROBOTICA EDUCATIVA: LATO CLIENT RELATORE: Prof. Michele Moro LAUREANDO: Marco Beggio Corso di laurea Specialistica in Ingegneria

Dettagli

comunicazione a tutto campo

comunicazione a tutto campo comunicazione a tutto campo Software GESTIONALE PBX Asterisk Introduzione Rubrica Telefonica Condivisa Il crescente bisogno di velocità e snellezza in tutte le operazioni aziendali, compreso l'ambito della

Dettagli

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

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

Dettagli

Requisiti della Business Intelligence

Requisiti della Business Intelligence Realizzazione di un sistema informatico on-line bilingue di gestione, monitoraggio, rendicontazione e controllo del Programma di Cooperazione Transfrontaliera Italia - Francia Marittimo finanziato dal

Dettagli

Aspetti applicativi e tecnologia

Aspetti applicativi e tecnologia Aspetti applicativi e tecnologia Premessa Architetture usate per i database Le prime applicazioni erano definite monolitiche, cioè un unico computer (mainframe) gestiva sia le applicazioni che i dati,

Dettagli

CAPITOLATO TECNICO. Versione Data di rilascio Commenti 1.0 24.05.2012 Capitolato tecnico. Capitolato tecnico Versione 1.0 del 24 maggio 2012 pag.

CAPITOLATO TECNICO. Versione Data di rilascio Commenti 1.0 24.05.2012 Capitolato tecnico. Capitolato tecnico Versione 1.0 del 24 maggio 2012 pag. CAPITOLATO TECNICO PER L ACQUISIZIONE IN ECONOMIA DELLA FORNITURA AVENTE AD OGGETTO IL MODULO DI APPRENDIMENTO E DISCOVERY POL DEL PROGETTO PORTALE DELLA PUBBLICITÀ LEGALE, ESTENSIONE DEL PROGETTO ITALIA.GOV.IT

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli