PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

Save this PDF as:
 WORD  PNG  TXT  JPG

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ARCHIVIA PLUS: ARCHIPROTO PEC

ARCHIVIA PLUS: ARCHIPROTO PEC ARCHIVIA PLUS: ARCHIPROTO PEC Istruzioni per la configurazione e l utilizzo del modulo di protocollazione PEC Versione n. 2012.05.25 Data : 25/05/2012 Redatto da: Veronica Gimignani Luca Mattioli Approvato

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

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

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

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

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

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

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

INTERNET EXPLORER Breve manuale d uso

INTERNET EXPLORER Breve manuale d uso INTERNET EXPLORER Breve manuale d uso INDICE INTRODUZIONE... 3 COME IMPOSTARE LA PAGINA INIZIALE... 3 LA WORK AREA... 3 LE VOCI DI MENU... 5 IL MENU FILE... 5 IL MENU MODIFICA... 6 IL MENU VISUALIZZA...

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

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

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

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

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

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

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

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

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

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

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati.

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati. LA RETE INFORMATICA NELL AZIENDA Capire i benefici di una rete informatica nella propria attività. I componenti di una rete I dispositivi utilizzati I servizi offerti LA RETE INFORMATICA NELL AZIENDA Copyright

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

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

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

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

Servizi Remoti. Servizi Remoti. TeamPortal Servizi Remoti

Servizi Remoti. Servizi Remoti. TeamPortal Servizi Remoti 20120300 INDICE 1. Introduzione... 3 2. Consultazione... 4 2.1 Consultazione Server Fidati... 4 2.2 Consultazione Servizi Client... 5 2.3 Consultazione Stato richieste... 5 3. Amministrazione... 6 3.1

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

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

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

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

Guida rapida per l utilizzo del servizio OwnCloud-MIUR (versione 1.6)

Guida rapida per l utilizzo del servizio OwnCloud-MIUR (versione 1.6) Sommario Introduzione... 2 L utilizzo dell OwnCloud con il browser.... 3 Istruzioni per l installazione del client OwnCloud... 4 Utilizzo del client OwnCloud per il caricamento dei giustificativi contabili....

Dettagli

Gestione WEB Viaggi e Turismo

Gestione WEB Viaggi e Turismo Pag. 1 di 11 Gestione WEB Viaggi e Turismo Pag. 2 di 11 SOMMARIO 1. INTRODUZIONE...3 2. CARATTERISTICHE E VANTAGGI DI IN.TOUR...4 3. FUNZIONALITA E STRUTTURA SOFTWARE E HARDWARE...6 4. STRUTTURA E CONTENUTI

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

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

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

Ti consente di ricevere velocemente tutte le informazioni inviate dal personale, in maniera assolutamente puntuale, controllata ed organizzata.

Ti consente di ricevere velocemente tutte le informazioni inviate dal personale, in maniera assolutamente puntuale, controllata ed organizzata. Sommario A cosa serve InfoWEB?... 3 Quali informazioni posso comunicare o ricevere?... 3 Cosa significa visualizzare le informazioni in maniera differenziata in base al livello dell utente?... 4 Cosa significa

Dettagli

ARGO DOC Argo Software S.r.l. e-mail: info@argosoft.it -

ARGO DOC Argo Software S.r.l. e-mail: info@argosoft.it - 1 ARGO DOC ARGO DOC è un sistema per la gestione documentale in formato elettronico che consente di conservare i propri documenti su un server Web accessibile via internet. Ciò significa che i documenti

Dettagli

1) GESTIONE DELLE POSTAZIONI REMOTE

1) GESTIONE DELLE POSTAZIONI REMOTE IMPORTAZIONE ESPORTAZIONE DATI VIA FTP Per FTP ( FILE TRANSFER PROTOCOL) si intende il protocollo di internet che permette di trasferire documenti di qualsiasi tipo tra siti differenti. Per l utilizzo

Dettagli

Progetto Gennaio 2013: Social Chat Internazionale

Progetto Gennaio 2013: Social Chat Internazionale UNIVERSITÀ DEGLI STUDI DI MILANO, DIPARTIMENTO DI INFORMATICA LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE CORSO DI RETI DI CALCOLATORI ANNO ACCADEMICO 2011/2012 Progetto Gennaio 2013: Social Chat Internazionale

Dettagli

N.B.: DISPONIBILITA INVERNO 2014 FAQ ACS700 versione 9

N.B.: DISPONIBILITA INVERNO 2014 FAQ ACS700 versione 9 N.B.: DISPONIBILITA INVERNO 2014 FAQ ACS700 versione 9 1) Quali sono le principali differenze fra ACS790 e la ACS700 versione 9? La nuove release di ACS offre le seguenti nuove funzionalià: Possibilità

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

Soluzione Immobiliare

Soluzione Immobiliare SOLUZIONE IMMOBILIARE SOLUZIONE IMMOBILIARE è un software studiato appositamente per la gestione di una Agenzia. Creato in collaborazione con operatori del settore, Soluzione si pone sul mercato con l

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

IBM SPSS Statistics per Linux - Istruzioni di installazione (Licenza per sito)

IBM SPSS Statistics per Linux - Istruzioni di installazione (Licenza per sito) IBM SPSS Statistics per Linux - Istruzioni di installazione (Licenza per sito) Le seguenti istruzioni sono relative all installazione di IBM SPSS Statistics versione 21 con licenza per sito. Questo documento

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

PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione

PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione Portale Numero Verde Vivisol pag. 1 di 31 INDICE 1. INTRODUZIONE...3 2. SCHERMATA PRINCIPALE...4 3. REPERIBILITÀ...5 4. RICERCA

Dettagli

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi PRIVACY E SICUREZZA LA PRIVACY DI QUESTO SITO In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano. Tale politica

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

HORIZON SQL CONFIGURAZIONE DI RETE

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

Dettagli

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

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

IBM Implementation Services per Power Systems Blade server

IBM Implementation Services per Power Systems Blade server IBM Implementation Services per Power Systems Blade server Questo allegato descrittivo del servizio ( Allegato ) è tra il Cliente (nel seguito denominato Cliente ) e IBM Italia S.p.A. (nel seguito denominata

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

Manuale Utente. versione 1.2.0.6. BIS S.r.l.

Manuale Utente. versione 1.2.0.6. BIS S.r.l. Manuale Utente versione 1.2.0.6 BIS S.r.l. Via Trieste, 31 20080 Bubbiano MI Italia Tel.: +39 02 90834207 Fax: +39 02 90870542 e-mail: info@bilanceonline.it P.IVA e C.F.: 03774900967 INDICE 1 INTRODUZIONE...

Dettagli

Strumento evoluto di Comunicazione con i Venditori

Strumento evoluto di Comunicazione con i Venditori Strumento evoluto di Comunicazione con i Venditori GAS 2 net è una soluzione web-based compliant con le definizioni di strumento evoluto come richiesto dalla normativa vigente (Del. AEEG n 157/07, Del.

Dettagli

Appunti di Sistemi Distribuiti

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

Dettagli

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

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

WOPSpesometro Note sull utilizzo v. 5.0.0 marzo 2015 (comunicazione dati 2012, 2013 e 2014)

WOPSpesometro Note sull utilizzo v. 5.0.0 marzo 2015 (comunicazione dati 2012, 2013 e 2014) WOPSpesometro Note sull utilizzo v. 5.0.0 marzo 2015 (comunicazione dati 2012, 2013 e 2014) Sommario: 1) Attivazione del prodotto; 2) Configurazione; 3) Contribuente; 4) Gestione operazioni rilevanti ai

Dettagli

Manuale Utente Amministrazione Trasparente GA

Manuale Utente Amministrazione Trasparente GA Manuale Utente GA IDENTIFICATIVO DOCUMENTO MU_AMMINISTRAZIONETRASPARENTE-GA_1.0 Versione 1.0 Data edizione 03.05.2013 1 Albo Pretorio On Line TABELLA DELLE VERSIONI Versione Data Paragrafo Descrizione

Dettagli

Sviluppata da: Lo Russo - Porcelli Pag. 1 di 6 6FRSR utilizzare il DBMS Postgresql per imparare il linguaggio SQL.

Sviluppata da: Lo Russo - Porcelli Pag. 1 di 6 6FRSR utilizzare il DBMS Postgresql per imparare il linguaggio SQL. Pag. 1 di 6 6FRSR utilizzare il DBMS Postgresql per imparare il linguaggio SQL. 2ELHWWLYL GD UDJJLXQJHUH SHU JOL VWXGHQWL alla fine dell esercitazione gli studenti dovranno essere in grado di: 1. utilizzare

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

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

Messaggi volatili. Matteo Zignani. 10 gennaio 2015

Messaggi volatili. Matteo Zignani. 10 gennaio 2015 UNIVESITÁ DEGLI STUDI DI MILANO LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE PROGETTO LABORATORIO DI RETI DI CALCOLATORI Messaggi volatili Matteo Zignani 10 gennaio 2015 1 PRESENTAZIONE DEL PROBLEMA Lo studente

Dettagli

Al fine di pubblicare le informazioni di un condominio sul WEB è necessario che l amministratore proceda con le seguenti fasi:

Al fine di pubblicare le informazioni di un condominio sul WEB è necessario che l amministratore proceda con le seguenti fasi: CONDOMINI SUL WEB Cosa si intende per condomini sul Web? Dalla versione 1.45 del programma Metodo Condomini l amministratore ha la possibilità di rendere fruibili via WEB ai condòmini (proprietari e conduttori)

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

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

Firewall applicativo per la protezione di portali intranet/extranet

Firewall applicativo per la protezione di portali intranet/extranet Firewall applicativo per la protezione di portali intranet/extranet Descrizione Soluzione Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO (MI)

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

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

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

Dettagli

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

GESTIONE COMMESSE IMPIANTI

GESTIONE COMMESSE IMPIANTI GESTIONE COMMESSE IMPIANTI Dedicato ad Aziende di Impianti Elettrici, Idraulici, etc. Lo scopo del progetto è quello di : Migliorare la gestione dei preventivi Rendere più flessibili le analisi dei costi

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

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

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

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

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

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

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

Dettagli