Questo sito si avvale di cookie necessari al funzionamento ed per le finalità illustrate nella cookie policy.

Se vuoi saperne di più consulta la Cookie Policy. Chiudendo questo banner, o proseguendo la navigazione, acconsenti all’uso dei cookie.

CBD

CBD

Il CBD (Condivisore di Banche Dati) nasce per essere integrato a banche dati già esistenti con l’obiettivo di ridurre a zero l’invasività. Il CBD viene affiancato ad hoc a banche dati eterogenee (Oracle, MS SQL Server e MySql) e su piattaforme differenti (Microsoft Vista e XP, Sun Solaris, Linux) ed immagazzina informazioni da tali sistemi, generando una banca dati comune. La sincronizzazione tra i diversi CBD dislocati nei sistemi clienti permette la condivisione delle informazioni e quindi l'utilizzo da parte degli utenti.

Il concetto di partenza è l'integrazione di data base anche molto distanti tra loro, per condividere informazioni di qualsiasi tipo (documenti, immagini, video...) in maniera sicura e dare la possibilità ad utenti di accedere, visualizzare, inserire e scaricare informazioni da qualsiasi dispositivo attraverso il browser, sempre garantendo la sicurezza delle transazioni. Inoltre, i nodi di una rete CBD sono tra loro sincronizzati ed i clienti di tale rete possono connettersi a qualsiasi nodo senza perdere informazioni.

Il CBD si rivolge a tutti quegli utenti che abbiano necessità di condividere informazioni; non ha l'obiettivo di integrare distinte procedure proprietarie, ma è stato elaborato per affiancarsi a sistemi esistenti oppure per operare da solo.

Il suo obiettivo è quello di permettere a banche dati eterogenee, appartenenti a strutture pubbliche o private, di condividere dati. Tali strutture lavorano infatti con le proprie banche dati e possiedono informazioni e concetti simili, espressi in maniera diversa; il sistema CBD, in modo completamente non invasivo, “cattura” i dati comuni e permette di allinearli e condividerli opportunamente tra le diverse strutture.

L’affiancamento del sistema CBD non modifica il meccanismo di utilizzo per gli utenti delle procedure preesistenti, ma affianca loro informazione e servizi in maniera trasparente.

 

La figura seguente riporta le funzionalità del sistema CBD.

 

fig1


I clients possono connettersi in maniera sicura sfruttando il protocollo HTTPs.

 

fig2

 

Al client è richiesta la disponibilità di un semplice browser.

 

fig3

 

I vantaggi sono molteplici ed evidenti:

 

  • L’utente può cambiare terminale (ad esempio usare l’applicativo dall’ufficio o in viaggio) senza dover installare nulla.
  • I nodi server sono più mantenibili dei client, perché presenti in numero sensibilmente minore.
  • Il mercato della telefonia mobile coinvolge molti attori, ognuno dei quali possiede un proprio sistema operativo. Il CDB tende in questo caso ad evitare che ogni nuovo dispositivo - nella versione precedente di architettura – richieda una sessione di test di verifica ed eventualmente una nuova versione del software.

 


fig4

 

Il CBD è una applicazione web based: di conseguenza, il client è rappresentato da un comune browser, il cui sistema è stato testato sui prodotti più diffusi come Internet Explorer, Firefox, Chrome, Opera, Safari (tali browser coprono le quote di mercato per oltre il 95% degli utenti).

 

fig5

 

Gran parte del lavoro è stata dedicata all'aspetto della sicurezza e dell'adattamento dei dati:

 

  • I dati sono cifrati prima di essere inviati in rete e solo il destinatario é in grado di decifrare l’informazione usando la chiave comune.
  • Login e password utilizzati per l’autenticazione non viaggiano in chiaro.
  • Gli utenti autorizzati possono svolgere tutte e sole le operazioni previste per il loro profilo di utente, mentre gli utenti non autorizzati sono rifiutati dal sistema. 
  • Per effettuare verifiche off-line degli accessi e delle operazioni svolte, gli accessi e le operazioni sono tracciati in apposititi file di log.
  • Il sistema nasconde il path reale delle risorse agli utenti: le URL diventano quindi dei riferimenti logici dei dati effettivi in modo da mascherarne l’effettiva posizione all’interno del file system.
  • L’utente amministratore è l’unico in grado di creare, abilitare, disabilitare, modificare e cancellare gli account.

 

Per consentire all'utente di poter usufruire al meglio dei dati scaricati e contemporaneamente di gravare il meno possibile sulla rete, è stato implementato un meccanismo di adattamento. In fase di upload, il sistema crea delle copie delle immagini e dei filmati con risoluzione e dimensione minori, in modo da averne una per ogni livello impostato.

 

fig6

In fase di download, il sistema riconosce il terminale mobile dell'utente e scarica l'immagine o il filmato più opportuno per la risoluzione del terminale.

Nella sala EAD presso Progesi SpA, é stato allestito il test bed per testare il sistema; l'elenco dei nodi possibili – in termini di sistema operativo e RDBMS – è presentato nella tabella seguente:

 
fig7
Nel test bed Progesi, sono state scelte le configurazioni più atipiche e difficili, poiché è molto probabile che il RDBMS SQL Server sia installato su sistemi Windows (stessa casa produttrice), o MySql su Linux (entrambi open source), pertanto nella figura che segue sono rappresentati i nodi del sistema con i relativi sistemi operativi e RDBMS.
 

fig8

Di seguito sono riportati invece i client ed i relativi browser utilizzati per connettersi ai nodi CBD.

fig9

Per la fase di misurazione, è stato predisposto un PC con due schede di rete e la capacità di variare la banda di rete disponibile.

La fase di test è stata organizzata in due macroattività:

 

  • Validazione del sistema CBD
  • Scenari e misurazioni di prestazioni.

 

Modello astratto del sistema

 

Oltre alla fase di testing per la validazione dei requisiti stabiliti, il gruppo di lavoro ha elaborato, sviluppato e validato un modello astratto del sistema.

In particolare, è stata prodotta una estensione del modello a reti di code del CBD utilizzando la notazione LQN (Layering Queueing Network) e, successivamente, dei tool per la validazione e la simulazione del modello.

Lo scopo del modello astratto è la rappresentazione più fedele possibile del comportamento del sistema CBD:in questa chiave è stato studiato il codice sorgente relativo alle principali funzionalità dell'applicazione e sono stati misurati i tempi di esecuzione di ogni funzionalità in vari scenari.

Tale studio di dettaglio ha consentito di parametrizzare il modello astratto, scegliendo un livello di astrazione preciso e fissando alcune caratteristiche, come ad esempio il tipo e la grandezza dei file impiegati nelle fasi di upload/download, e assumendo fissi nel tempo i parametri responsabili della potenza di calcolo (velocità processore server e velocità di trasmissione della rete).

Una versione semplificata dei componenti del modello e dei relativi pesi è presentata nella figura seguente.

 

fig10

 

La validazione del modello astratto è stata ottenuta misurando e confrontando tempi di esecuzione delle singole funzionalità, al variare di parametri tra sistema reale e sistema astratto. I principali indici di prestazioni che sono stati valutati con diverse situazioni di workload sono:

 

  • Tempo di servizio dei task del modello al variare del numero degli utenti: in particolare il tempo per effettuare le operazioni base dell'applicazione;
  • Tempo di attesa degli utenti per usufruire di un determinato servizio al variare della molteplicità dei task (proprietà multi-thread dei sistemi client-server);
  • Utilizzazione della CPU del server all'aumentare del carico ad essa sottoposto.

 

I test eseguiti hanno permesso di effettuare stress-test per misurare le performance del sistema per le singole funzionalità; sono stati misurati i tempi di attesa al variare del numero delle richieste e i tempi di risposta in condizioni molto critiche. Questi test hanno permesso di individuare i colli di bottiglia dei vari moduli software e quindi di avviare l’introduzione di modifiche migliorative attraverso l’inserimento di alcuni thread in parallelo. 

I grafici successivi mostrano il risultato del test, ottenuto fissando una limitazione di banda tra il client e il server e facendo il download di file di diverse dimensioni. Il test studia il comportamento della banda rilevata dal software e il suo errore rispetto a quella teorica fissata e rispetto ad un delta calcolato come rapporto tra la dimensione del file e la banda teorica.

Le limitazioni di banda sono di: 512, 256, 128, 64, 6.4 KB/s. Al variare della banda i grafici mostrano che si ha un valore minimo d’errore di misurazione indipendente dalla limitazione di banda e stimabile circa ad un download pari a 0,5MB.

Il risultato che ci interessa particolarmente è l’asintoto orizzontale per un valore di errore di circa l’8-9%: tale asintoto indipendente dalle limitazioni mostra che l’errore delle nostre misurazioni non supera mai il 9%, garantendo una adeguata validazione alle misure precedenti.

 

Definizioni:

fig11

fig12