PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY"

Transcript

1 Giampiero Allamprese 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 di un middleware che consenta di realizzare un servizio di accesso remoto a un repository da parte di utenti operanti in ambienti eterogenei e su piattaforme diverse. In particolare il caso concreto preso in considerazione come problema di partenza è quello della realizzazione di uno strumento con il quale un team di sviluppo software possa accedere al repository centrale in cui sono conservati i sorgenti dell applicazione in via di sviluppo, reperire i file da modificare e ampliare e, dopo averlo fatto, salvarli sul repository stesso, secondo opportune politiche di interazione e sincronizzazione. Il progetto pone l accento sulla realizzazione del middleware che garantisce la comunicazione tra gli utenti e il server centrale, garantendo politiche flessibili e intercambiabili e utilizzando un formato standard per la trasmissione di dati. La gestione in sé del repository, per quanto riguarda organizzazione di file e cartelle, replicazione dei dati e autenticazione è demandata al livello applicativo del server e non è trattata in questo progetto. INTRODUZIONE Uno strumento fondamentale per i progettisti di software delle moderne Software House consiste nella possibilità di organizzare e memorizzare il codice prodotto man mano che si procede nello sviluppo di un applicazione, in maniera efficiente e che consenta una corretta interazione da parte dei membri del team di sviluppo. La soluzione più immediata e diffusa è quella che prevede l utilizzo di uno spazio disco (il repository appunto) su una macchina remota affidabile e sicura, su cui vengono mantenuti tutti i file di codice dell applicazione, a cui i vari sviluppatori possono accedere per ottenere una copia dei sorgenti su cui lavorare localmente. Una volta modificati, i file dovranno poi essere salvati sul server aggiornando il contenuto del repository. Questo progetto vuole affrontare la problematica della realizzazione di un middleware di supporto che consenta di realizzare la comunicazione appena descritta tra utenti e server, consentendo di applicare in maniera flessibile politiche diverse di interazione e sincronizzazione, con la possibilità di operare in un ambiente eterogeneo sia per applicazioni sia per piattaforme. Lo scopo è quello di realizzare uno strumento modulare flessibile e interoperabile, al fine di implementare un generico servizio di accesso a un repository contenente dati utilizzabili da utenti diversi, senza necessariamente legarsi al caso specifico dello sviluppo di software. L interoperabilità e la flessibilità nella configurazione delle politiche richiedono un

2 formato standard per la rappresentazione dei dati. Nella seconda sezione dell articolo si analizzeranno le criticità principali del problema, nella terza sezione si descriveranno le scelte effettuate in fase di progettazione e la architettura prevista per il sistema, la quarta sarà dedicata all implementazione e alla descrizione di un caso di prova. 2 CRITICITA DEL SISTEMA 2.1 Gestione flessibile dell interazione e della sincronizzazione Caratteristica fondamentale per la realizzazione di un sistema flessibile è la possibilità di configurarne il comportamento da parte dello strato applicativo superiore in tempo reale e in maniera semplice. In particolare in un sistema di questo tipo si possono immaginare diverse politiche di gestione dell accesso al repository e di interazione tra clients e server. La soluzione più semplice è quella di tipo lock modify - unlock, che prevede una gestione sequenziale dei singoli file: un utente richiede un sorgente, ne ottiene il lock,lo copia e lo modifica in locale e solo dopo avere aggiornato il repository rilascia il lock e consente ad altri di modificare quello stesso file. Naturalmente un approccio di questo tipo è logicamente semplice ed evita problemi di consistenza ma limita fortemente la parallelizzazione del lavoro. Una soluzione più efficace, ma anche molto più complessa è quella che prevede la possibilità per tutti di accedere allo stesso file e di modificarlo in parallelo, dopodiché l applicazione di gestione del repository riceverà tutti i file aggiornati e cercherà di ottenerne un unica versione tramite un operazione di merging. Il middleware dovrà dunque supportare politiche di interazione e sincronizzazione diverse (non soltanto i due esempi presentati, naturalmente) in maniera semplice ed efficiente, e senza interruzione di servizio, tenendo conto che suo compito sarà solo quello di garantire meccanismi di comunicazione adeguati alla politica scelta, lasciando poi all applicazione lato server la responsabilità di implementarla logicamente (nel secondo esempio fatto il middleware dovrà solo fare in modo di consegnare all applicazione le diverse versioni del file e sarà poi quest ultima a effettuare il merging). Dovrà quindi essere presente nell applicazione di gestione del repository un modulo con cui il middleware si possa interfacciare per inoltrare le richieste dei clienti e ottenere i file desiderati nel formato standard di comunicazione. 2.2 Modalità di comunicazione La comunicazione dovrà essere evidentemente di tipo client/server, in quanto l architettura stessa di un repository ad accesso remoto è di questo tipo. Si può presumere che le primitive che lato client inoltrano le richieste al server siano bloccanti, in quanto l applicazione che richiederà il sorgente che si trova sul repository non avrà altre elaborazioni da svolgere fino a quando non si sia reperito il file. D altra parte volendo rendere il sistema flessibile e slegato dal caso specifico dello sviluppo software si può anche pensare ad un supporto che possa mettere a disposizione primitive che non blocchino l applicazione che le invoca. Le richieste servite saranno poi caratterizzate da un diverso grado di difficoltà: richieste come l ottenimento di un file in sola lettura o creazione di file e directory non pongono grandi problemi e possono essere gestite in maniera relativamente semplice; il servizio più complesso e problematico, invece, è quello che prevede di fornire all utente un file a cui possano essere apportate modifiche che successivamente

3 dovranno essere salvate sul repository. Questa richiesta richiede una maggiore complessità di gestione a causa delle problematiche di sincronizzazione e consistenza che pone. In effetti le diverse politiche di gestione delle richieste implementabili nel middleware riguardano soprattutto la modalità con cui viene gestita questa particolare richiesta, in quanto le altre saranno gestite all incirca sempre nello stesso modo. 2.3 Supporto all interoperabilità Per garantire il supporto ad ambienti eterogenei sia a livello software che di piattaforma, è indispensabile che il middleware utilizzi un formato standard per la rappresentazione dei dati, con cui sistemi diversi possano scambiarsi dati e informazioni e con cui si possano anche implementare le politiche e la configurazione del sistema. E importante anche scegliere un linguaggio di programmazione con cui implementare il servizio che sia indipendente dalla piattaforma e portabile. 2.4 Affidabilità Per garantire una adeguata affidabilità del sistema e la possibilità di fornire il servizio senza interruzioni sarà necessario prevedere la possibilità di replicare il server che riceve le richieste dei client. La gestione dell affidabilità del servizio di repository vero e proprio (ad esempio la possibilità di utilizzare un file system distribuito e replicato, di rendere il servizio accedibile da diversi nodi, ecc..) viene demandata invece all applicazione. 3 ARCHITETTURA DEL SISTEMA 3.1 Formato dati Come formato standard per la comunicazione dei dati e la definizione dei file di configurazione si è scelto XML, per la diffusione e la comodità offerta. Come linguaggio invece si è scelto il Java per le sue caratteristiche di portabilità e la diffusione anche in ambienti mobili. 3.2 Server File di configurazione Il server conterrà un file di configurazione in formato xml, tramite il quale verranno specificate informazioni necessarie alla corretta fornitura del servizio. In particolare saranno specificate: La politica di fornitura del servizio (ad es. Lock-Modify-Unlock) I parametri fondamentali per la comunicazione, quali tempi di timeout e numero di ritrasmissioni Il percorso delle cartelle in cui salvare i file xml ricevuti dai client e dall applicazione di gestione del repository Il nodo su cui si trova l applicazione a cui inoltrare le richieste. Un parametro che indichi la presenza di un proxy, seguito da informazioni sul nodo in cui si trova Modificando il file di configurazione si otterrà una modifica in tempo reale del comportamento del server. All arrivo di ogni richiesta da parte degli utenti, infatti, l applicazione accederà al file xml per verificare con quale politica dovrà essere gestita e con quali parametri di comunicazione, adattando il proprio comportamento in maniera completamente dinamica. La specifica del nodo su cui si trova l applicazione di gestione del repository è essenziale a causa della replicazione del server di comunicazione; se infatti il server principale non è attivo e si utilizza una copia, l applicazione potrebbe non

4 essere più accedibile in locale, ma solo tramite un riferimento remoto. Naturalmente se l applicazione prevede anch essa una replicazione sugli stessi nodi in cui è replicato il server del middleware, si potrà continuare ad interagire con essa in locale, senza bisogno di accessi remoti. L indicazione della presenza o meno di un proxy, è invece necessaria per far sì che il sistema possa supportare con facilità sia la presenza di un proxy, e la conseguente replicazione del server, sia una comunicazione diretta tra client e server. Fornitura del servizio All arrivo di una richiesta da parte di un client il server analizzerà il proprio file di configurazione per capire come deve essere gestita. successivamente inoltrerà la richiesta al modulo di interfaccia dell applicazione superiore fornendo il file xml contenente il profilo dell utente necessario per la procedura di autenticazione e specificando il file richiesto o invato dall utente. In caso di richiesta di un file da parte dell utente, dopo averlo ottenuto già tradotto in formato xml, sarà inviato al client. Se il file era invece stato inviato dall utente si manderà semplicemente la conferma dell avvenuta operazione. 3.3 Client Profilo utente Sul client saranno presenti due file xml: un primo contente il profilo dell utente che vuole effettuare una richiesta al repository, e un secondo di configurazione. Il file di profilo non è strettamente necessario ai fini delle operazioni svolte dal middleware, ma si è ritenuto comunque indispensabile prevedere uno strumento di questo tipo, poiché è evidente che per l applicazione di gestione del repository è necessario sapere quale utente richiede una determinata operazione per capire se è autorizzato a compierla e se devono essere utilizzate particolari preferenze legate a quello stesso utente. Il profilo, quindi, conterrà le informazioni necessarie all identificazione dell utente e all autenticazione da parte del gestore del repository. Nel file di configurazione, invece, saranno specificati tutti i dati necessari alla comunicazione (indirizzo del server, tempi di timeout, percorso delle cartelle dei file temporanei, ecc ) Per il profilo si è scelto di utilizzare un file xml, che verrà poi inviato al server insieme alla richiesta del file, per rendere l applicazione il più possibile flessibile e adattabile. Se infatti il protocollo di autenticazione richiedesse nuove e diverse informazioni da parte dell utente non sarebbe necessario riscrivere le classi del middleware ma basterebbe cambiare e aggiornare il contenuto del file di profilo. Comunicazione Il client metterà a disposizione dell utente diversi tipi di richieste per il repository: Richiesta di file in sola lettura Richiesta di file da modificare Richiesta di creazione di nuovi file o cartelle Allo stesso modo, poi, con cui il server può dinamicamente modificare la politica con cui gestire le richieste che gli arrivano, il client può definire modalità diverse per inoltrare le richieste (ad es. può essere preferibile avere a disposizione primitive che non blocchino l applicazione esterna che le ha chiamate). Basterà indicare nel file di configurazione la modalità scelta e il sistema automaticamente la utilizzerà. 3.4 Proxy Per gestire la replicazione volta a garantire l affidabilità e la disponibilità

5 del sistema si è deciso di utilizzare un pattern Proxy. Sarà dunque presente un entità intermedia a cui i client si rivolgeranno, che identificherà tra un insieme di server replicati quello da utilizzare per ottenere il servizio. Anche il proxy, dunque, avrà un suo file di configurazione in cui saranno elencati i vari nodi su cui cercare un server attivo, a partire da un server principale, che tendenzialmente ma non necessariamente sarà quello che si trova sullo stesso nodo dell applicazione di gestione del repository. La replicazione quindi prevede un modello Master/Slave, con un unica copia attiva, e una serie di copie di riserva pronte a sostituire il server principale in caso di problemi. Il modello è quello di un sistema di replicazione a copie fredde. Si è deciso di effettuare questa scelta poiché a seconda della politica utilizzata dal server le informazioni di stato da trasmettere cambierebbero, e sarebbe eccessivamente oneroso implementare una soluzione in grado di supportare tutte le possibilità. Inoltre va considerato che le informazioni di stato interesserebbero solo le richieste di ottenimento e modifica dei file, mentre le altre possono essere eseguite immediatamente e senza particolari accorgimenti da parte del server; dunque solo una parte delle richieste ricevute sarebbe realmente interessata a una aggiornamento dei server in standby. Un accorgimento fondamentale è che il server, nel caso in cui salti solo il collegamento col proxy, ma sia comunque in grado di servire eventuali richieste in coda, si renda conto immediatamente di non essere più il master, in modo da interrompere le richieste rimaste da servire. Queste potranno essere perciò reinoltrate al proxy dal client e girate al master attualmente funzionante con una minima perdita di priorità. Ciò limiterebbe fortemente i danni provocati dalla caduta del server, rendendo quindi la soluzione a copie fredde non eccessivamente penalizzante. All arrivo di una richiesta da parte del client, quindi, il proxy tenterà di contattare il server principale, e in caso di mancata risposta proverà uno dopo l altro tutti i server di riserva. Trovata una copia attiva comunicherà all utente l indirizzo al quale connettersi. Il server, a sua volta, al termine di ogni operazione di get+commit interrogherà il proxy per verificare di essere ancora il master, e in caso contrario potrà tempestivamente cancellare le richieste rimaste. 4 IMPLEMENTAZIONE Il sistema è stato suddiviso in tre package principali: client, server e proxy, ognuno dei quali contiene le classi utilizzate dai relativi attori della comunicazione. Inoltre è stato realizzato un ulteriore package tools, contenete classi che implementano funzionalità di base utilizzate da tutti gli altri package. 4.1 CLIENT La struttura del client può essere analizzata a partire dal diagramma delle classi riportato di seguito in Figura 1. La classe principale, ClientComunicator, contiene tutte le primitive con cui un applicazione di livello superiore può inoltrare richieste a un repository remoto. Per gestire le richieste dell utente il ClientComunicator si appoggia alla classe ClientBlockComManager, che implementa effettivamente il protocollo di comunicazione con il server, appoggiandosi a sua volta alla classe SendReceive del package tools che realizza le primitive di comunicazione di base.

6 Figura 1 L aver incapsulato tutto il protocollo di comunicazione del middleware lato client in questa classe fa sì che se si volesse realizzare un diverso protocollo, oppure lo stesso protocollo con modalità diverse (ad esempio usando il pattern poll object si potrebbe avere una soluzione non bloccante), sarebbe possibile farlo senza modificare le altre classi. La dinamicità del sistema descritta prima, per cui specificando una modalità di gestione delle richieste nel file di configurazione questa viene applicata in tempo reale, deriva proprio dal fatto che è sufficiente realizzare più di una classe di questo tipo e che il ClientComunicator interrogando il file xml capisca quale deve utilizzare. Per questo è stata definita l interfaccia ClientComManager che indica quali primitive devono realizzare classi di questo tipo, lasciando però, ovviamente, completa libertà sul come realizzarle. Il sistema una volta letto il file xml creerà a tempo di esecuzione un istanza di una classe il cui nome è definito dalla seguente notazione: Client valore letto nel file xml ComManager. Nel progetto sviluppato la classe ClientBlockComManager realizza il protocollo di comunicazioni con primitive bloccanti per l applicazione che invoca i metodi del ClientComunicator. Le altre due classi del package servono per la lettura dei dati contenuti nel file di configurazione: la classe ClientConfig incapsula tutte le proprietà indicate nel file e i relativi valori; la classe ClientXmlManager, invece, realizza il metodo readxml() con cui si accede al file xml e si aggiorna il contenuto della classe ClientXmlManager. Per fare questo si utilizzano i metodi della classe statica XmlFileReader contenuta nel package tools, che consente di accedere a un file xml e leggerne il contenuto, grazie alle librerie jdom importate nel progetto che rendono l operazione molto più semplice rispetto alle funzionalità offerte dalle normali classi Java. Il file di configurazione del client avrà questo formato: 4.2 SERVER La struttura del server è rappresentata dal diagramma delle classi presentato in Figura 2.

7 Figura 2 La classe principale in questo caso è ServerComunicator, che realizza il pattern Singleton dal momento che si vuole che ci sia un solo server attivo su un nodo. Questo oggetto nel proprio costruttore fa partire il thread ServerAcceptThread, che si incarica di creare la ServerSocket in ascolto e tramite una accept ottenere le socket di connessione con i vari client. Prima di passare la gestione delle richieste alle classi sottostanti, però, viene effettuata una prima receive sulla socket appena creata per capire se si è in contatto con un client o con un proxy. In quest ultimo caso il proxy vorrà semplicemente verificare se il server è online e farlo diventare il master se non lo è già, e quindi sarà sufficiente rispondere in maniera affermativa, senza delegare il compito ad altre classi. Le richieste del client, invece, vengono gestite da un oggetto della classe ServerLMUComManager. Come nel caso del client, poiché si vogliono poter realizzare diverse politiche di gestione delle richieste, queste sono incapsulate all interno di una classe e dei thread che questa fa partire. La classe viene identificata dal file di configurazione e creata dinamicamente proprio come prima. In questo caso si è deciso di implementare una politica di gestione delle richieste di tipo lock-modify-unlock. La classe ServerLMUComManager identificherà l operazione richiesta dal client e invocherà due differenti Thread per la loro gestione. Il ServerFileFolderThread si incaricherà delle richieste di file in sola lettura, e di creazione di file o cartelle. Queste operazioni non sono particolarmente complesse da gestire e saranno servite immediatamente creando un thread per ogni richiesta ricevuta. Il ServerCommitThread, invece, dovrà gestire le richieste di file da modificare, che, secondo la politica che si vuole implementare, dovranno essere rigidamente sequenzializzate. Dunque verrà creato un Thread diverso non più per ogni richiesta, ma per ogni file richiesto, in modo che se un client richiede un file che già un altro utente sta modificando, la sua richiesta verrà accodata e servita dal thread dopo che il client precedente avrà fatto l operazione di commit. La coda di richieste da servire è implementata da un oggetto della classe ServerQueue. Tale oggetto contiene al suo interno un vettore di stringhe che identificano i file attualmente gestiti da un thread, e dunque in fase di modifca da parte di un client; inoltre, per ogni file memorizzato sarà mantenuto un vettore di prenotazioni, rappresentate dalla classe Booking, che conterranno tutte le informazioni necessarie e la socket da usare per la gestione della richiesta quando sarà il suo turno. Naturalmente l oggetto ServerQueue deve essere unico nell applicazione e tutti si suoi metodi saranno synchronized poiché accedibili da più thread contemporaneamente. Ovviamente una politica di tipo lockmodify-unlock richiede che sia definito un tempo massimo di possesso da parte di un utente del diritto di modifica di un file. Scaduto questo tempo la richiesta sarà annullata e si passerà alla gestione della richiesta successiva in coda, se presente.

8 Per fare ciò il ServerCommitThread, all inizio di ogni gestione di una richiesta di file attiva un TimeoutThread che, scaduto il valore di timeout specificato nel file di configurazione, avvertirà il thread di gestione che interromperà l attesa della commit. Al termine dell operazione di commit, inoltre, il thread proverà a contattare il proxy per verificare di essere il master, in modo che, in caso di risposta negativa, possa interrompere la richiesta servita e mettersi in standby. Le richieste rimaste in coda verranno quindi tempestivamente cancellate e potranno, se riproposte dai client, essere accodate al nuovo master senza perdere troppa priorità Infine per far sì che ogni server rimanga in standby fino a quando il proxy non lo indica come master si usa la classe statica Go, il cui valore è di default false, e viene messo a true solo in caso di ricezione di un messaggio da parte del proxy. Per ultimo va notato che la realizzazione della classe di interfacciamento con l applicazione che gestisce il repository viene demandata all applicazione stessa, che si incaricherà anche della traduzione da e in xml dei file. Il sistema definisce semplicemente un interfaccia, ServerApplInterface, che indica quali metodi devono essere implementati da questa classe. Essa sarà acceduta in locale se l applicazione si trova sullo stesso nodo del server, altrimenti si utilizzerà rmi come sistema di riferimenti remoti. 4.3 PROXY Il diagramma delle classi del proxy è il seguente: Figura 3 Anche in questo caso la classe principale, Proxy, è un singleton. Essa farà partire due thread: ProxyAcceptThread è incaricato della gestione delle richieste dei client, mentre ProxyAcceptSrvThread gestirà quelle dei server. Innanzitutto l elenco dei server disponibili viene letto dal file di configurazione e inserito in un oggetto di tipo ProxyServerList. Esso è unico per tutto il proxy e al suo interno sono indicati il master originario, il master attuale, i server che risultano online, e quelli che risultano offline. Quando un client inoltra la propria richiesta essa viene raccolta dalla classe ProxyAcceptThread, che effettuata la accept invocherà un ProxyQueryThread che si incaricherà di verificare che il server che risulta come master sia attivo. Se così non è verranno prima provati tutti i server online e poi quelli offline fino a quando non ne verrà trovato uno correttamente funzionante. In questo caso si invierà al client l indicazione dell indirizzo al quale connettersi, aggiornando il master se è cambiato e inserendo nella offline list tutti i server che non hanno risposto.

9 Se nessun server ha risposto viene inviato al client un messaggio di errore che faccia terminare la funzione invocata senza aspettare lo scadere del timeout. Il ProxyAcceptSrvThread, invcece, resterà in attesa di richieste di connessione da parte dei server che alla fine di un operazione di commit vogliono verificare di essere il master. Se così non è il thread verificherà comunque che il server sia almeno nell elenco dei server online, dato che evidentemente è funzionante. La comunicazione tra client, proxy e server potrà dunque essere schematizzata con il seguente diagramma: Prima di tutto il client contatta il proxy, il quale identificato un server funzionante lo setta come master, lo fa partire e ne restituisce l indirizzo al client. Questo a sua volta riproporrà la richiesta al server il quale risponderà con un acknowledge. A questo punto il client invierà il proprio profilo utente, e ricevuto un ulteriore acknowledge rimarrà in attesa del file richiesto o invierà il file modificato a seconda dell operazione che deve eseguire. 5 SVILUPPI FUTURI Possibili sviluppi futuri per il middleware possono essere l implementazione di altre politiche di gestione rispetto a quelle implementate per il client e per il server. Si può inoltre pensare di sviluppare anche una serie di funzionalità che consentano di gestire la problematica dell autenticazione e della gestione dei diritti, demandati qui a livello applicativo. Inoltre si può anche pensare ad un maggiore coordinamento tra server per realizzare un sistema a copie calde se lo si ritenesse indispensabile per una aumento delle prestazioni. 6 CONCLUSIONI Si è realizzato un middleware che consente la comunicazione tra una serie di client e un servizio di repository remoto, per soddisfare diverse tipologie di richieste. Il sistema presentato garantisce un utilizzo flessibile e interoperabile e permette grazie alla sua modularità di essere significativamente espanso in futuro, aggiungendo nuove politiche e modalità di gestione che potranno essere integrate facilmente semplicemente configurando gli opportuni file di configurazione. Si è inoltre anche realizzata una replicazione del server di comunicazione per garantire una buona affidabilità del sistema grazie ad un proxy in grado di dirigere la richiesta dell utente verso un server funzionante.

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

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

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

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

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

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 (modulo di Informatica II)

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

Dettagli

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

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

Laurea Specialistica in Informatica, Tecnologie Informatiche Anno Accademico 2008/2009 Reti Applicazioni e Servizi

Laurea Specialistica in Informatica, Tecnologie Informatiche Anno Accademico 2008/2009 Reti Applicazioni e Servizi Laurea Specialistica in Informatica, Tecnologie Informatiche Anno Accademico 2008/2009 Reti Applicazioni e Servizi Implementazione di una MIDlet che realizza un sistema di voto Christian Tiralosi Sviluppatori:

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

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

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

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144 Mobilità di Codice Abbiamo già visto come un dato host possa trasmettere un oggetto (serializzabile) ad un altro host. Quest ultimo potrà eseguire l oggetto pur non possedendo il bytecode della classe

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 Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

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

Dettagli

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

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Si precisa in ogni caso che questa guida rapida non esime dalla lettura del Manuale utente presente nell ambiente del Servizio Telematico Doganale.

Si precisa in ogni caso che questa guida rapida non esime dalla lettura del Manuale utente presente nell ambiente del Servizio Telematico Doganale. GUIDA RAPIDA versione 25 febbraio 2010 SERVIIZIIO TELEMATIICO DOGANALE Avvertenze: Questa guida vuole costituire un piccolo aiuto per gli operatori che hanno già presentato richiesta di adesione al servizio

Dettagli

Si precisa in ogni caso che questa guida rapida non esime dalla lettura del manuale utente presente nell ambiente del Servizio Telematico Doganale.

Si precisa in ogni caso che questa guida rapida non esime dalla lettura del manuale utente presente nell ambiente del Servizio Telematico Doganale. GUIDA RAPIDA versione 11 marzo 2008 SEERVIIZZIIO TTEELLEEMATTIICO M DOGANALLEE G Avvertenze: Questa guida vuole costituire un piccolo aiuto per gli operatori che hanno già presentato richiesta di adesione

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. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 10 Giovedì 3-04-2014 1 Reti per la distribuzione

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

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

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

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

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

INTRODUZIONE AL SISTEMA DI INVIO

INTRODUZIONE AL SISTEMA DI INVIO INTRODUZIONE AL SISTEMA DI INVIO Il Ministero dell Economia e delle Finanze (MEF) mediante la propria rete telematica, cura il collegamento senza oneri aggiuntivi, per l accesso al servizio telematico

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

Socket & RMI Ingegneria del Software - San Pietro

Socket & RMI Ingegneria del Software - San Pietro Socket & RMI Ingegneria del Software - San Pietro Socket È possibile trattare la comunicazione di rete allo stesso modo con cui è possibile trattare la lettura da file. La classe Socket rappresenta la

Dettagli

Informatica di Base - 6 c.f.u.

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

Dettagli

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

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

Introduzione a Oracle 9i

Introduzione a Oracle 9i Introduzione a Oracle 9i Ing. Vincenzo Moscato - Overview sull architettura del DBMS Oracle 9i L architettura di Oracle 9i si basa sul classico paradigma di comunicazione client-server, in cui sono presenti

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

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

12.5 UDP (User Datagram Protocol)

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

Dettagli

MANUALE D USO Agosto 2013

MANUALE D USO Agosto 2013 MANUALE D USO Agosto 2013 Descrizione generale MATCHSHARE è un software per la condivisione dei video e dati (statistiche, roster, ) delle gare sportive. Ogni utente abilitato potrà caricare o scaricare

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

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

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

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

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

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193 Servers Activatable Nelle lezioni precedenti abbiamo detto che una referenza remota ad un server di tipo UnicastRemoteObject rimane valida finchè il server è in esecuzione. Quando il server termina, o

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

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

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

Dettagli

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell

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

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

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

Dettagli

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

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

21/02/2013 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE CERTIFICATI VERSIONE 1.0

21/02/2013 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE CERTIFICATI VERSIONE 1.0 MANUALE DI ISTRUZIONI DELL APPLICAZIONE SID GENERAZIONE VERSIONE 1.0 PAG. 2 DI 39 INDICE 1. PREMESSA 4 2. INSTALLAZIONE 5 3. ESECUZIONE 6 4. STRUTTURA DELLE CARTELLE 7 5. CARATTERISTICHE GENERALI DELL

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

Java Server farm. M. Danelutto. Progetto conclusivo LPRb A.A. 2006-2007. Versione 1.0

Java Server farm. M. Danelutto. Progetto conclusivo LPRb A.A. 2006-2007. Versione 1.0 Java Server farm M. Danelutto Progetto conclusivo LPRb A.A. 2006-2007 Versione 1.0 1 Server farm Lo scopo del progetto é la realizzazione di un server farm (vedi la definizione di server farm di Wikipedia

Dettagli

INNOVAZIONE XNOTTA PER PORTALI TURISTICI

INNOVAZIONE XNOTTA PER PORTALI TURISTICI INNOVAZIONE XNOTTA PER PORTALI TURISTICI 1. Introduzione La nostra attività è partita dall esame dei sistemi di gestione dei Portali turistici; tutti hanno pensato ad una ottima interfaccia, ad un buon

Dettagli

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

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

Dettagli

Parte II: Reti di calcolatori Lezione 12

Parte II: Reti di calcolatori Lezione 12 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 12 Giovedì 16-04-2015 1 Confronto architetture C/S e

Dettagli

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

Dettagli

Internet e protocollo TCP/IP

Internet e protocollo TCP/IP Internet e protocollo TCP/IP Internet Nata dalla fusione di reti di agenzie governative americane (ARPANET) e reti di università E una rete di reti, di scala planetaria, pubblica, a commutazione di pacchetto

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Nota Tecnica Premium HMI 4.0.1152 TN0022

Nota Tecnica Premium HMI 4.0.1152 TN0022 Premium HMI 4.0.1152 Introduzione Il documento raccoglie le note di rilascio per la versione 4.0.1152 di Premium HMI. Le principali novità introdotte riguardano i seguenti aspetti: Nuove funzioni per una

Dettagli

Applicazioni distribuite

Applicazioni distribuite Applicazioni distribuite Maurizio Cozzetto 1 agosto 2009 Un pò di teoria Ricordiamo che un'applicazione distribuita è un'applicazione composta da più programmi (almeno 2) posti in esecuzione su macchine

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

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n.

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n. DigitPA VISTO l art. 6, comma 1 bis, del decreto legislativo 7 marzo 2005 n. 82 (indicato in seguito con l acronimo CAD), come modificato dal decreto legislativo 30 dicembre 2010 n. 235; VISTI gli articoli

Dettagli

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo Come funziona il WWW Il funzionamento del World Wide Web non differisce molto da quello delle altre applicazioni Internet Anche in questo caso il sistema si basa su una interazione tra un computer client

Dettagli

Manuale d uso. Applicazione client Postecert Firma Digitale per Postemailbox

Manuale d uso. Applicazione client Postecert Firma Digitale per Postemailbox per Postemailbox Documento pubblico Pagina 1 di 22 Indice INTRODUZIONE... 3 REQUISITI... 3 SOFTWARE... 3 HARDWARE... 3 INSTALLAZIONE... 3 AGGIORNAMENTI... 4 AVVIO DELL APPLICAZIONE... 4 UTILIZZO DELL APPLICAZIONE...

Dettagli

IN-CHF on line Procedura di Installazione

IN-CHF on line Procedura di Installazione IN-CHF on line IN-CHF on line Procedura di Installazione Heart Care Foundation onlus www.heartcarefound.org Associazione Nazionale Medici Cardiologi Ospedalieri www.anmco.it Centro Studi ANMCO Firenze

Dettagli

ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL

ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL.1. Introduzione Legalmail è un servizio di posta elettronica che garantisce un elevato grado di affidabilità e sicurezza. Esso consente al Cliente

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Bibliografia: Utenti e sessioni

Bibliografia: Utenti e sessioni Bibliografia: Utenti e sessioni http: protocollo stateless http si appoggia su una connessione tcp e lo scambio nel contesto di una connessione si limita a invio della richiesta, ricezione della risposta.

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee

Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee Sommario 1 Introduzione... 2 2 Garanzia Giovani... 2 3 La Cooperazione Applicativa... 2 3.1 Presa in carico del cittadino... 3 3.1.1 Adesione

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

RMI. Prova pratica di Sistemi Distribuiti:

RMI. Prova pratica di Sistemi Distribuiti: Prova pratica di Sistemi Distribuiti: RMI Di Nicola Milella Al fine di toccare con mano queste tecnologie e capirne i rispettivi pro e contro si è deciso di sviluppare un applicazione distribuita sfruttando

Dettagli

Corso di Informatica

Corso di Informatica CdLS in Odontoiatria e Protesi Dentarie Corso di Informatica Prof. Crescenzio Gallo crescenzio.gallo@unifg.it Funzioni dei Sistemi Operativi!2 Le funzioni principali del SO Gestire le risorse dell elaboratore

Dettagli

1. RETI INFORMATICHE CORSO DI LAUREA IN INGEGNERIA INFORMATICA SPECIFICHE DI PROGETTO A.A. 2013/2014. 1.1 Lato client

1. RETI INFORMATICHE CORSO DI LAUREA IN INGEGNERIA INFORMATICA SPECIFICHE DI PROGETTO A.A. 2013/2014. 1.1 Lato client RETI INFORMATICHE - SPECIFICHE DI PROGETTO A.A. 2013/2014 1. RETI INFORMATICHE CORSO DI LAUREA IN INGEGNERIA INFORMATICA SPECIFICHE DI PROGETTO A.A. 2013/2014 Il progetto consiste nello sviluppo di un

Dettagli

Real Time Control (RTC): modalità di invio dei dati

Real Time Control (RTC): modalità di invio dei dati C EQAS - CNR External Quality Assessment Schemes CNR - Istituto di Fisiologia Clinica Real Time Control (RTC): modalità di invio dei dati R. Conte, A. Renieri v.1.1-15/11/2012 Introduzione Il programma

Dettagli

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione

Dettagli

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

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

Dettagli

Ricette SSN online Manuale utente Versione client 3.x.x

Ricette SSN online Manuale utente Versione client 3.x.x Pag. 1 di 15 Ricette SSN online Manuale utente Versione client 3.x.x Pag. 2 di 15 1. REVISIONI AL DOCUMENTO... 3 2. INTRODUZIONE AL SISTEMA DI INVIO TELEMATICO... 3 3. CLIENT RICETTESSNONLINE... 4 3.1

Dettagli

Modello documento MU_ModelloManualeUtente_v01.0.dot

Modello documento MU_ModelloManualeUtente_v01.0.dot Regione del Veneto Direzione Sistemi Informativi 145 145-Catasto Impianti Termici Manuale Utente Versione 1.0 Modello documento MU_ModelloManualeUtente_v01.0.dot Data 30/12/2014 Pag.: 1/31 SOMMARIO 1 COPYRIGHT...

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni server

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni server Versione 30.5.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/: applicazioni 1 La logica dei socket Abbiamo visto che un applicazione client si connette

Dettagli

Replica con TeraStation 3000/4000/5000/7000. Buffalo Technology

Replica con TeraStation 3000/4000/5000/7000. Buffalo Technology Replica con TeraStation 3000/4000/5000/7000 Buffalo Technology Introduzione La funzione di replica consente di sincronizzare una cartella in due diversi dispositivi TeraStation quasi in tempo reale. Il

Dettagli

BDCC : Guida rapida all utilizzo

BDCC : Guida rapida all utilizzo BDCC : Guida rapida all utilizzo 1 Sommario 1. Funzionamento del sistema... 3 1.1 Cos è e cosa contiene la BDCC... 3 1.2 Meccanismi di funzionamento della BDCC... 3 1.3 Organizzazione di contenuti all

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

BACKUP OnLine. Servizi di backup e archiviazione remota. SCHEDA PRODOTTO Versione 1.7

BACKUP OnLine. Servizi di backup e archiviazione remota. SCHEDA PRODOTTO Versione 1.7 BACKUP OnLine Servizi di backup e archiviazione remota SCHEDA PRODOTTO Versione 1.7 1 1. INTRODUZIONE Il servizio Backup OnLine mette a disposizione un sistema di backup e archiviazione a lungo termine

Dettagli

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Funzioni di Esportazione Importazione 1 Indice AIRONE GESTIONE RIFIUTI... 1 FUNZIONI DI ESPORTAZIONE E IMPORTAZIONE... 1 INDICE...

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

RMI Remote Method Invocation

RMI Remote Method Invocation RMI Remote Method Invocation [Pagina intenzionalmente vuota] (1 12 2004) slide 4:1/18 (p.106) Un applicazione RMI è un applicazione distribuita ad oggetti. Applicazione RMI tipica, strutturata in: server:

Dettagli

Il sistema di I/O. Hardware di I/O Interfacce di I/O Software di I/O. Introduzione

Il sistema di I/O. Hardware di I/O Interfacce di I/O Software di I/O. Introduzione Il sistema di I/O Hardware di I/O Interfacce di I/O Software di I/O Introduzione 1 Sotto-sistema di I/O Insieme di metodi per controllare i dispositivi di I/O Obiettivo: Fornire ai processi utente un interfaccia

Dettagli

Cod. SWUM_00399_it RCCL

Cod. SWUM_00399_it RCCL Cod. SWUM_00399_it RCCL Libreria di comunicazione CISS Manuale utente Aggiornamento 2/9/2008 Sommario 1. Presentazione... 3 2. Installazione del prodotto... 3 3. Applicazione di esempio... 4 4. Per iniziare

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

Basi di Dati prof. A. Longheu. 5 Progettazione fisica

Basi di Dati prof. A. Longheu. 5 Progettazione fisica Basi di Dati prof. A. Longheu 5 Progettazione fisica Progettazione Fisica Per effettuare la progettazione fisica, ossia l implementazione reale del modello logico creato nella fase della progettazione

Dettagli

19. LA PROGRAMMAZIONE LATO SERVER

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

Dettagli

SCP - Scuola di Calcolo Parallelo - Scheduler per programmi paralleli. Mattia Sessolo I.T.I.S. V.Volterra San Donà di Piave

SCP - Scuola di Calcolo Parallelo - Scheduler per programmi paralleli. Mattia Sessolo I.T.I.S. V.Volterra San Donà di Piave SCP - Scuola di Calcolo Parallelo - Scheduler per programmi paralleli Mattia Sessolo I.T.I.S. V.Volterra San Donà di Piave 2006-2007 Introduzione Questo programma è stato ideato per facilitare e automatizzare

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

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

PC/CSA. Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada

PC/CSA. Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada PC/CSA Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada PC/CSA-SPF-1.0 Versione del 18.04.2001 SOMMARIO 1 INTRODUZIONE

Dettagli

MANUALE D USO DEL SOFTWARE APPLICATIVO ADB-TOOLBOX (VERSIONE 1.7 E SUPERIORI) UTILIZZO DEI SERVIZI WMS-WFS-WCS E DEL CATALOGO CSW

MANUALE D USO DEL SOFTWARE APPLICATIVO ADB-TOOLBOX (VERSIONE 1.7 E SUPERIORI) UTILIZZO DEI SERVIZI WMS-WFS-WCS E DEL CATALOGO CSW Ministero dell Ambiente e della Tutela del Territorio e del Mare MANUALE D USO DEL SOFTWARE APPLICATIVO ADB-TOOLBOX (VERSIONE 1.7 E UTILIZZO DEI SERVIZI WMS-WFS-WCS E DEL CATALOGO CSW Titolo Autore Oggetto

Dettagli