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

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

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

Dettagli

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

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

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

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

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

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

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

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

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

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

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

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

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

1. SISTEMA INFORMATICO GESTIONALE

1. SISTEMA INFORMATICO GESTIONALE 1. SISTEMA INFORMATICO GESTIONALE 1.1 Introduzione Il sistema informatico gestionale, che dovrà essere fornito insieme ai magazzini automatizzati (d ora in avanti Sistema Informatico o semplicemente Sistema),

Dettagli

Il Provvedimento del Garante

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

Dettagli

Architettura SW Definizione e Notazioni

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

Dettagli

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

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

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

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

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

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

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

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

Ingegneria del Software Progettazione

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

Dettagli

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

IBM i5/os: un sistema progettato per essere sicuro e flessibile

IBM i5/os: un sistema progettato per essere sicuro e flessibile IBM i5/os garantisce la continua operatività della vostra azienda IBM i5/os: un sistema progettato per essere sicuro e flessibile Caratteristiche principali Introduzione del software HASM (High Availability

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

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

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete Sistemi Operativi di Rete Estensione dei Sistemi Operativi standard con servizi per la gestione di risorse in rete locale Risorse gestite: uno o più server di rete più stampanti di rete una o più reti

Dettagli

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand!

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand! Introduzione Qui di seguito vengono esposte le risposte alle domande più frequenti relative a Oracle Siebel CRM On Demand. Inoltre, il Solutions Launchpad che contiene il link a questo documento offre

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

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

Prot: Del: Allegato Capitolato Tecnico. Sistema GAIA. Sistema informativo di governo dell Ambiente e flussi informativi ambientali verso gli utenti

Prot: Del: Allegato Capitolato Tecnico. Sistema GAIA. Sistema informativo di governo dell Ambiente e flussi informativi ambientali verso gli utenti REPUBBLICA ITALIANA Regione Siciliana ASSESSORATO TERRITORIO ED AMBIENTE Via Ugo La Malfa, 169 Palermo Prot: Del: Allegato Capitolato Tecnico Sistema GAIA Sistema informativo di governo dell Ambiente e

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

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

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

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

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

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

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

Dettagli

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

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

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

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

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

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

Applicazione: SAI - Sistema di Audit Interno

Applicazione: SAI - Sistema di Audit Interno Riusabilità del software Catalogo delle applicazioni: Amministrativo/Contabile Applicazione: SAI Sistema di Audit Interno Amministrazione: Agenzia delle Entrate Responsabile dei sistemi informativi Nome

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Approfondimenti tecnici su framework v6.3

Approfondimenti tecnici su framework v6.3 Sito http://www.icu.fitb.eu/ pagina 1 I.C.U. "I See You" Sito...1 Cosa è...3 Cosa fa...3 Alcune funzionalità Base:...3 Alcune funzionalità Avanzate:...3 Personalizzazioni...3 Elenco Moduli base...4 Elenco

Dettagli

BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari. Advanced Advanced Technology Solutions

BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari. Advanced Advanced Technology Solutions BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari Advanced Advanced Technology Solutions La soluzione integrata per la distribuzione dell informativa dei mercati finanziari

Dettagli

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

COMPETENZE IN ESITO (5 ANNO) ABILITA' CONOSCENZE

COMPETENZE IN ESITO (5 ANNO) ABILITA' CONOSCENZE MAPPA DELLE COMPETENZE a.s. 2014-2015 CODICE ASSE: tecnico-professionale QUINTO ANNO PT1 scegliere dispositivi e strumenti in base alle loro caratteristiche funzionali; Progettare e realizzare applicazioni

Dettagli

Virtuality 2002. Distributed Training Facility, ovvero il contatto interattivo, multimediale e distribuito tra Istruttore e Studente

Virtuality 2002. Distributed Training Facility, ovvero il contatto interattivo, multimediale e distribuito tra Istruttore e Studente D F Distributed Training Facility, ovvero il contatto interattivo, multimendiale e distribuito tra Istruttore e Studente abstract In un momento in cui prodotti, applicazioni e procedure divengono sempre

Dettagli

Architettura del software: dai Casi d Uso al Modello

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

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Parte II: Reti di calcolatori Lezione 10

Parte II: Reti di calcolatori Lezione 10 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 10 Giovedì 9-04-2015 1 Database distribuiti e gerarchici

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

Seminario di Sistemi Distribuiti: RPC su SOAP

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

Dettagli

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

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

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 di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

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

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

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

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

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

Linea LINEA SYSTEMS vers. 4.0

Linea LINEA SYSTEMS vers. 4.0 Linea LINEA SYSTEMS vers. 4.0 Categoria COMPUTO E CAPITOLATO Famiglia SISTEMI DI CONTROLLO Tipologia SISTEMA DI SUPERVISIONE GEOGRAFICO Modello TG-2000 WIDE AREA Pubblicata il 01/09/2006 TESTO PER COMPUTO

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

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

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

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

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

Video Comunicazione su Rete Internet

Video Comunicazione su Rete Internet Video Comunicazione su Rete Internet 1 Introduzione alla comunicazione video su rete Internet. La rapida evoluzione dell Information Technology negli ultimi anni ha contribuito in maniera preponderante

Dettagli

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

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

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Auditing di Eventi. Daniele Di Lucente

Auditing di Eventi. Daniele Di Lucente Auditing di Eventi Daniele Di Lucente Un caso che potrebbe essere reale Un intruso è riuscito a penetrare nella rete informatica della società XYZ. Chi è l intruso? Come ha fatto ad entrare? Quali informazioni

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

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

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

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

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

MULTIPRESA MPP SERIE INTELLIGENTE. Servizi specialistici per il controllo remoto. Manuale utente

MULTIPRESA MPP SERIE INTELLIGENTE. Servizi specialistici per il controllo remoto. Manuale utente MULTIPRESA MPP SERIE INTELLIGENTE Servizi specialistici per il controllo remoto Manuale utente M U L T I P R E S A M P P S E R I E I N T E L L I G E N T E Manuale utente Powered by Corso Francia 35, 00138

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

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

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

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

Framework Rich Client Application

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

Dettagli

Enterprise Application Integration

Enterprise Application Integration POLITECNICO DI TORINO Facoltà di Ingegneria dell Informazione Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea Specialistica Enterprise Application Integration Studio e realizzazione

Dettagli

C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa!

C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa! C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa! EC CONSULTING Via A. Grandi, 21 20090 Vimodrone (MI) TEL.: 02.27408094 FAX: 02.27409150 e-mail info@ecconsulting.it web www.ecconsulting.it

Dettagli

Si S curezza a sw w net il c orr r e r tto design del t uo s istema i nform r atico una soluzione

Si S curezza a sw w net il c orr r e r tto design del t uo s istema i nform r atico una soluzione Sicurezza asw net il corretto design del tuo sistema informatico una soluzione Sicurezza asw net un programma completo di intervento come si giunge alla definizione di un programma di intervento? l evoluzione

Dettagli