“Catalogo dei File Grezzi con meta-dati di base” (CFG)

Progettazione e sviluppo di un “Catalogo dei File
Grezzi con meta-dati di base” (CFG) in tecnologia
Web
DCSS/SIP-A
Francesco Altarocca e Gaetano Sberno
7 giugno 2005
Sommario
Il processo di archiviazione dei documenti e dei dati, con lo smantellamento dei vecchi sistemi
Mainframe e l’introduzione di sistemi di informatica personale, è stato trasferito dal centro alla
periferia come altrove anche all’Istat. Da qualche anno, pertanto, è emersa l’esigenza di conservare,
accanto alla documentazione amministrativa di supporto, anche le informazioni di base necessarie per
la conduzione delle indagini e, alla loro conclusione, le basi dei dati elaborati.
Oltre all’esigenza di archiviare informazioni, è importante infatti avere la possibilità di confrontarle,
integrarle e distribuirle. Ciò spiega il notevole incremento registrato recentemente nel numero e nella
dimensione delle banche dati.
Tali contenitori sono alimentati da informazioni che provengono da fonti eterogenee e che vengono
rilasciate in formati differenti.
Nella situazione attuale, però, lo scambio tra le unità e servizi dell’Istituto, dei dati prodotti e dei
microdati è reso difficile e talvolta impossibile da una gestione troppo personalizzata di tale
documentazione.
Per reperire le informazioni necessarie ad alimentare le banche dati occorrono tempi e risorse ingenti.
In questo documento si propone un software capace di catalogare e raccogliere in maniera coerente,
efficiente, affidabile e standardizzata dati provenienti da indagini statistiche.
L’utente, utilizzando il “Catalogo dei File Grezzi” (CFG), ha a disposizione una procedura di
archiviazione utilizzabile sia per ottenere le informazioni desiderate, sia per archiviare le proprie.
Il CFG non solo consente una più agevole attività di raccolta delle informazioni per alimentare le
banche dati, ma può esser impiegato anche come punto di riferimento per la condivisione dei
documenti tra diverse unità e servizi.
Indice
SOMMARIO
PREMESSA
1. INTRODUZIONE
2. ARCHITETTURA FUNZIONALE
2.1 Funzionalità del CFG
2.2 La mappa del “Catalogo dei File Grezzi”
2.3 Gli utenti del CFG
2.4 La documentazione
3. ARCHITETTURA LOGICA E IMPLEMENTAZIONE
3.1 Architettura del sistema
3.1.1 Il modello multi-tier
3.1.2 Architettura di CFG
3.1.3 Note sull’usabilità e sull’interfaccia utente
3.2 I moduli del CFG
3.2.1 I ruoli dei moduli
3.3 Le interazioni tra i moduli
3.3.1 I linguaggi di scripting e il PHP
3.3.2 La richiesta di una pagina
3.3.3 Download di un file
3.3.4 Upload di un file
3.4 Il database
3.5 Note sulla integrabilità con altri sistemi e sviluppi futuri
4. ARCHITETTURA FISICA
4.1 Tipo di licenze del software utilizzato
4.2 Le piattaforme utilizzate
4.2.1 La piattaforma hardware
4.2.2 La piattaforma software
4.2.3 Note sulle piattaforme hardware/software
4.3 Scelte implementative
4.4 Il meccanismo di upload dei file
4.4 La robustezza, la sicurezza e il meccanismo di autenticazione
4.5 Registrazione degli eventi e generazione di report sull'utilizzo del servizio
5. MANUALE DELL'UTENTE
5.1 Introduzione
5.2 Accesso al servizio
5.3 L'utente esterno
5.3.1 Cambiare la password
5.3.2 Scaricare e ricercare documenti
5.4 L'utente interno
5.4.1 Configurazione e prerequisiti per il caricamento dei documenti
5.4.2 Scaricare ed installare il Java Runtime Environment
5.4.3 Scaricare ed installare il certificato per il corretto funzionamento dell'applet
5.4.4 Inserire un documento
5.4.5 Visualizzare la lista dei file archiviati
5.4.6 Modifica delle informazioni relative ad un documento archiviato
6. MANUALE DELL'AMMINISTRATORE
6.1 Le attività di manutenzione dell’amministratore
6.1.1 Attività ordinarie
6.1.2 Attività straordinarie
6.2 Struttura delle directory sul server
6.2.1 L'utente amministratore
6.2.2 La gestione degli utenti
6.2.3 Utility
7 BIBLIOGRAFIA
7.1 RFC (Request for Comments): Standard utilizzati in CFG
7.2 Siti internet (al 23/3/2005)
Premessa
Nella realizzazione del CFG si è ravvisata l’opportunità di creare uno strumento, per la raccolta e la
conservazione dei dati, più elastico rispetto ai metodi utilizzati nell’Istituto (server FTP, condivisione
di cartelle, ecc.) e che, oltre a consentire l’inserimento di qualsiasi tipo di formato di file, offrisse
anche la possibilità di aggiungere informazioni descrittive dei dati raccolti al fine di agevolarne l’uso
nel corso di eventuali elaborazioni successive.
Pur non volendo, infatti, intervenire nell’omogeneizzazione dei file1, necessaria per l’inserimento dei
dati in un qualunque data warehouse, il CFG snellisce alcune attività.
Da un lato, raccoglie i dati dispersi e consente, grazie all’aggiunta di alcune note descrittive, un
utilizzo degli stessi da parte degli utenti in tempi e modi diversi. Dall’altro, agevola e assiste gli utenti
nelle procedure di archiviazione.
Infatti il CFG è impiegato anche come un contenitore di informazioni per i servizi o per le altre unità
dell’Istituto. É frequente che persone dello stesso servizio scambino dati fra loro per fare confronti,
integrazioni e quant’altro si renda necessario. Con l’utilizzo del CFG è sufficiente che colui che ha
accesso ai dati, registrandoli, li metta a disposizione in maniera definitiva. In questo modo una persona
autorizzata che ha bisogno di qualche documento può interrogare il catalogo e reperire le informazioni
che vi sono contenute. Tale meccanismo di raccolta, oltre a diminuire i tempi per la ricerca dei dati,
incoraggia i responsabili delle indagini a non adottare soluzioni autoreferenziali per quanto riguarda
l’archiviazione e la gestione della documentazione statistica a propria disposizione. La gestione e
l’archiviazione dei dati svolta in modo corretto e coerente consente, successivamente, di reperire le
informazioni registrate ricorrendo a meccanismi immediati, semplici e trasparenti.
A titolo di esempio, nel corso di normali attività di lavorazione può capitare di perdere dati e/o
informazioni a causa:
• del deterioramento del supporto di memorizzazione;
• di uno scorretto passaggio di consegne;
• di dimenticanze (ad esempio una password smarrita o una codifica non documentata);
• dall’errata errata gestione delle versioni dei documenti.
L’obiettivo del CFG è di contribuire a risolvere questo tipo di problemi ed orientare gli utenti ad
assumere un comportamento meno arbitrario nella gestione e nell’archiviazione dei dati.
1
Gli standard utilizzati dai “produttori” d'informazione (Access, SAS, SPSS, ASCII, Excel, Word...) sono estremamente
vari. Questo comporta una notevole difficoltà nel predisporre procedure automatiche che consentano di ricondurre le
informazioni ad un unico schema. In genere, infatti, tali attività vengono eseguite manualmente o, laddove automatizzate
solo parzialmente, necessitano sempre dell’intervento di un operatore.
1. Introduzione*
Il “Catalogo dei File Grezzi” (CFG) è stato inizialmente pensato come uno dei moduli di SISPA
(“Sistema Informatico Statistico sulla pubblica Amministrazione”) con lo scopo di archiviare i file di
dati e meta-dati che potrebbero essere utilizzati per alimentare il data warehouse. Lo schema generale
di SISPA, le interazioni fra i moduli di cui si compone e i flussi informativi tra le componenti sono
riportati in Figura 1.1.
Figura 1.1: Struttura del sistema informativo SISPA
É possibile vedere che il sistema, partendo da fonti eterogenee, richiede che le informazioni in ingresso
vengano ulteriormente trasformate al fine di renderle confrontabili.
La versatilità del CFG è data proprio dalla capacità di organizzare le informazioni provenienti da
molteplici fonti come illustrato nella Figura 1.2.
Nel caso del caricamento dei dati in SISPA, ad esempio, i dati statistici provengono da varie sorgenti:
• i documenti prodotti all'interno del servizio (“Servizio sulle Istituzioni Pubbliche e Private”)
(SIP);
• le informazioni provenienti dagli altri servizi interni all'Istituto e dal Sistema Statistico
Nazionale (SISTAN).
*
A cura di Francesco Altarocca
Figura 1.2: Flusso delle informazioni
Il modulo CFG semplifica, inoltre, l’attività del responsabile addetto al caricamento del data
warehouse, agevolando la ricerca e il download di informazioni e documenti. Infatti tutti i dati
necessari ad alimentare SISPA si troveranno all’interno del CFG.
Spesso i documenti delle indagini sono archiviati senza alcun tipo di informazione che ne descriva il
contenuto rendendo difficile, in un secondo tempo, capirne il significato. Il CFG oltre a razionalizzare
l'archiviazione dei dati e meta-dati consente di conservare informazioni supplementari.
Il CFG agevola e assiste l'utente, utilizzando una interfaccia intuitiva, in modo che le operazioni di
archiviazione e di recupero dei documenti risultino semplici e veloci da effettuare.
Numerose sono state le problematiche che sono state affrontate e che hanno condizionato le scelte
tecniche e progettuali adottate.
In primo luogo si è scelto di utilizzare un browser Web per i numerosi vantaggi che ne derivano:
• la familiarità dell’ambiente;
• la diffusione della tecnologia;
• il supporto;
• semplicità di utilizzo;
• non c’è bisogno di software particolare;
• portabilità su piattaforme diverse;
• non si deve distribuire il software ogni volta che sono effettuate modifiche.
Questo tipo di scelta impone, di fatto, delle forti limitazioni sulla dimensione dei file da caricare. Per
questo motivo sono state adottare tecniche ed accorgimenti particolari che verranno illustrati in
seguito.
Inoltre, non sono state imposte limitazioni sul formato del documento da inserire. Tale scelta non
vincola l’utente a utilizzare specifici formati permettendo di utilizzare il software preferito per eseguire
le proprie attività. L’inserimento di dati, senza nessuna conversione2 in un formato specifico o senza
l’utilizzo di procedure di ETL3, agevola non poco l’utente addetto all’archiviazione. Infatti è
sufficiente immettere poche informazioni relative al documento e farne l’upload. Ovviamente questa
libertà si paga negando qualsiasi tipo di “confronto” fra i dati immessi. Altri moduli di SISPA, che
richiedono l’intervento di un operatore, sono stati progettati e realizzati per “pulire”, convertire ed
omogeneizzare i dati.
A causa della tipologia di informazioni gestite è stato necessario realizzare un sistema robusto, sicuro e
con un adeguato meccanismo di autenticazione. Infatti, il software è realizzato in maniera tale da
permettere l’accesso esclusivamente alle persone autorizzate, discriminando gli utenti a seconda delle
funzioni operative che sono chiamati a svolgere.
In previsione di sviluppi futuri o cambio di piattaforme hardware/software è stata prestata la massima
attenzione nella scelta degli strumenti da utilizzare, preferendo dove possibile, prodotti corredati da
codice sorgente e con licenze meno restrittive.
Si è pensato, inoltre, di offrire la possibilità di gestire i documenti immessi per mezzo di cancellazioni
e modifiche. A tale scopo sono state predisposte delle procedure per la registrazione degli eventi e la
generazione di report che consentono di: monitorare gli accessi, monitorare il sistema e l’uso che ne
viene fatto, tenere traccia del numero dei documenti prelevati o immessi e altre interessanti statistiche.
Infine è stata prestata particolare attenzione a fornire un sistema completo e ben documentato,
corredando le procedure di due manuali d'uso (uno per l'utente e uno per l'amministratore), per
consentire una gestione e un utilizzo “autonomo” e per agevolare l'attività manutentiva.
In fase di sviluppo sono stati predisposti gli strumenti atti a consentire la massima efficienza
nell'attività manutentiva.
Quest'ultima, comunque, deve essere svolta dal gestore del sistema che dovrà prestare particolare
attenzione nella gestione e nella scelta degli interventi da effettuare (revisione, modifica ed eventuali
aggiornamenti).
Viste le problematiche esposte sopra, si è pensato di tenere presente le diverse responsabilità e le
diverse possibilità di interazione di ogni utente. I profili di utenza previsti sono:
• l'utente incaricato all'archiviazione dei file (utente interno);
• l'utente abilitato alla sola interrogazione del catalogo ed al prelievo di file (utente esterno);
• il gestore dell'archivio dei file (amministratore).
Le informazioni raccolte attraverso il CFG consentiranno di archiviare in maniera coerente oltre ai file
di dati per il caricamento di SISPA, anche i file e i documenti delle indagini (tracciati record e modelli
dei questionari, ecc.) con la possibilità di prelevarli e cercarli, qualora si rendesse necessario, in modo
semplice e efficiente.
2
In Istat sono presenti archivi di meta-dati, come ad esempio ARMIDA, che archiviano i meta-dati in maniera uniforme ed
omogenea. Questo è possibile solo grazie ad una conversione preliminare all’inserimento delle basi di dati nell’archivio.
3
In [8] per ETL (Extraction, Transformation and Loading) si intendono le procedure di correzione delle incoerenze, per la
integrazione di dati mancanti al fine di fondere sorgenti statistiche eterogenee secondo uno schema comune.
2. Architettura funzionale*
2.1 Funzionalità del CFG
Le funzioni che qualsiasi tipologia di utente può svolgere con il CFG sono le seguenti:
• accesso al servizio per mezzo di autenticazione attraverso la specificazione di nome utente e
password: l’utente dovrà preventivamente essere inserito nella lista delle persone abilitate
all’uso del sistema attraverso la creazione di un account;
• cambio della password: l’utente deve essere in grado di cambiare la password tramite una
maschera nella quale si richiede, per motivi di sicurezza, la password valida nel momento in
cui si intende modificarla;
• ricerca dei documenti: sono disponibili diversi modi per ricercare un documento inserito nel
catalogo. Ognuno di questi è caratterizzato da un “metodo” diverso:
o Navigatore: permette di “navigare” tra i documenti in una struttura organizzata in una
gerarchia: il primo livello di gerarchia partiziona l'insieme dei documenti contenuti nel
CFG per anno. Il secondo livello di gerarchia distingue i documenti, all'interno di ogni
anno, in base all'indagine;
o Ricerca: è possibile inserire dei termini in una casella di testo per cercarli non solo
nella denominazione dell'indagine, ma anche nell'anno, nel codice PSN e nella tipologia
di file inserito (dati, tracciati, ...). Se, a titolo di esempio, si fosse interessati ai dati dei
“Bilanci consuntivi degli enti di diritto allo studio universitario”, relativi all'anno 1999,
si dovrebbe inserire: “dati bilanci univ 1999”;
o Lista: visualizza l'elenco completo dei documenti che sono stati inseriti in CFG. Le
indagini elencate seguono il seguente ordine:
Nome dell'indagine (lessicografico crescente);
Anno (numerico decrescente);
• accesso ad una scheda che contiene le informazioni del file selezionato, indipendentemente dal
metodo con il quale sono stati trovati i documenti che interessano all’utente. Tale scheda
visualizza i dettagli (indagine, anno, tipologia di file, formato dell’input, note) e permette di
scaricare il documento;
• inserimento di un documento nel catalogo. Per procedere bisognerà specificarne le
caratteristiche richieste (indagine, anno, tipologia di file, formato dell’input, note, nome del
file) e caricarlo sul server;
• visualizzazione della lista dei file inseriti. Sarà, infatti, disponibile una lista dei file che l’utente
ha precedentemente inserito nel catalogo;
• modifica e gestione delle informazioni. Attraverso la funzione descritta al passo precedente è
possibile accedere alla maschera di modifica del documento. Si potranno modificare tutte le
informazioni che sono state inserite in precedenza, ad eccezione del nome del file, aggiungere
note, cancellare il documento. Sarà possibile modificare esclusivamente i dati di supporto al
documento inserito. Si è pensato di negare la possibilità di cambiare il documento inserito
perché in questo modo non si possono cancellare i file e quindi non si possono perdere
documenti importanti. Si può sempre “eliminare” un file, tuttavia, in questo caso, il file non è
eliminato fisicamente, ma viene messo in uno stato nel quale non può più essere visualizzato
*
A cura di Francesco Altarocca
•
•
(le informazioni di supporto e il file vengono mantenute). Questa scelta permette di
“storicizzare” le versioni precedenti dei documenti;
gestione degli utenti. É possibile, inserire un nuovo utente, modificarne il profilo, visualizzare
la lista di quelli inseriti nel sistema e disabilitare un particolare utente;
visualizzazione statistiche sull’utilizzo del sistema. Quest’attività consente all’amministratore
di capire, attraverso dei semplici report, se il servizio è utilizzato in maniera corretta e con
quale frequenza.
Tutte le pagine condividono la stessa struttura per omogeneità e coerenza dell’interfaccia utente. A
seconda dell’utente e dell’operazione che si sta effettuando possono cambiare una o più aree della
pagina. Le funzioni sopra esposte sono espletate mediante la “navigazione” di una o più pagine. L'area
del browser che visualizza il contenuto delle pagine del CFG è stata suddivisa in tre sotto aree (Figura
2.1):
“Intestazione”: accompagnerà l'utente per tutta la sessione di lavoro e consentirà di avere un
punto di riferimento stabile. Da questa porzione di schermo è infatti possibile accedere alle
principali pagine del CFG (tornare alla pagina iniziale, visualizzare le informazioni su SISPA e
su CFG e accedere all'Help in linea) e accedere al servizio;
“Pannello Laterale”: è situato alla sinistra dello schermo, mostra un menù contenenti le
operazioni che l'utente è autorizzato a compiere;
“Pannello Principale”: visualizza il dettaglio dell'operazione che si sta compiendo.
Figura 2.1: Struttura delle pagine HTML
Come si è visto, la struttura delle pagine è quella normalmente utilizzata nelle applicazioni Web.
Le funzioni che potranno essere svolte con l’utilizzo dell’applicazione e dei vari moduli verranno
descritte in modo dettagliato nel Capitolo 5.
2.2 La mappa del “Catalogo dei File Grezzi”
Di seguito è riportata la struttura del pannello posto a sinistra della pagina del CFG. Il pannello è
diviso in sezioni, alcune delle quali potrebbero essere disattivate (non visibili) per determinati utenti in
base alle autorizzazioni concesse dal gestore del sistema. Si rimanda, per una descrizione dettagliata
delle diverse funzioni, al Capitolo 5. (Manuale dell'utente) e al Capitolo 6. (Manuale
dell'amministratore).
Gestione Utenti [sezione]
1. Nuovo utente [funzione]
2. Lista utenti [funzione]
Utility [sezione]
1. Stat Upload[funzione]
2. Stat Download [funzione]
Gestione File [sezione]
1. Nuovo file [funzione]
2. Lista file [funzione]
Download [sezione]
1. Navigatore [funzione]
2. Ricerca [funzione]
3. Liste [funzione]
Tools [sezione]
1. Mod. Password [funzione]
Il CFG, come si è visto dalle sezioni e dalle funzioni, è estremamente semplice e intuitivo. L’obiettivo,
infatti, è quello di agevolare l’utente nell’archiviazione dei propri documenti. L’intestazione, invece,
contiene dei pulsanti che consentono di autenticarsi e accedere al sistema (Pulsante Login), tornare alla
pagina iniziale e visualizzare una breve introduzione sul CFG (pulsante Home), ottenere informazioni
dettagliate su SISPA e CFG (pulsante Info) e consultare la guida in linea (Pulsante Aiuto).
2.3 Gli utenti del CFG
I diversi compiti e responsabilità che sono state immaginate per l’interazione con il sistema e per una
semplice attività di gestione e di amministrazione sono:
L'utente catalogatore o utente interno:
questa tipologia potrà inserire le informazioni relative al documento che vuole immagazzinare
nel CFG; potrà modificare o integrare le informazioni precedentemente inserite e verificare
l'esatto inserimento dei dati. Inoltre potrà visualizzare i file contenuti nell'archivio e scaricarli.
L'accesso alla catalogazione verrà consentito esclusivamente agli utenti abilitati
dall'amministratore secondo le politiche dettate dai responsabili del sistema.
L'utente utilizzatore dei file o utente esterno:
l'utilizzatore potrà interrogare il database per verificare se nell'archivio sono contenuti i dati o i
documenti cercati. Nel caso in cui questi siano disponibili l'utente potrà, attraverso semplici
meccanismi, scaricare il materiale. A questo utente non è permesso aggiornare i dati relativi ai
documenti inseriti o inserirne di nuovi.
Il gestore o amministratore:
i gestori si dovranno far carico di numerose attività: supporto agli utenti (assistenza e
formazione); gestione dell'ambiente di archiviazione e delle abilitazioni; aggiornamento delle
procedure, backup del sistema e di quant'altro si renda necessario per un corretto
funzionamento; monitoraggio degli accessi e delle semplici statistiche sull'utilizzo del servizio.
La struttura degli utenti e la granularità delle autorizzazioni4 è stata pensata in modo semplice al fine di
facilitare l’attività dell’amministratore. Nell’attività di gestione quest’ultimo dovrà scegliere tra le tre
tipologie di utenza descritte prima senza concedere privilegi specifici né gestire gruppi di utenti.
2.4 La documentazione
La documentazione è una parte fondamentale di ogni sistema software. Durante il ciclo di vita di un
applicativo possono infatti verificarsi numerosi eventi. Ad esempio, possono sorgere dei problemi
dopo il rilascio, oppure può accadere che lo sviluppatore debba occuparsi di altre attività e non possa
più seguire il progetto, e così via.
Spesso si tende a trascurare l’utilità di questa attività, ma se viene effettuata regolarmente è possibile
allungare il ciclo di vita del sistema, risolvendo i problemi connessi all’attività di manutenzione e di
ampliamento delle funzionalità in tempi brevi e quindi agevolmente.
Produrre una manualistica dettagliata e completa è stato uno degli obiettivi principali nella
progettazione e nello sviluppo del modulo. É stato adottato un linguaggio di scripting molto semplice
da imparare e soprattutto sono stati utilizzati standard consolidati con lo scopo di rendere autonomo
l’amministratore del catalogo. Esistono decine di testi5 e numerose risorse sul Web che consentono di
ottenere informazioni utili per quanto riguarda tali standard.
In realtà l’amministratore dovrà eseguire interventi sull’applicazione solamente nel caso in cui
vengano riscontrate anomalie nelle procedure del sistema oppure se si vuole dotare il sistema di nuove
funzionalità. La normale attività dell’amministratore è descritta nel Capitolo 6. (Manuale
dell'amministratore).
4
Con granularità delle autorizzazioni si intende il livello cui è possibile intervenire nell’attività di controllo delle
autorizzazioni. É possibile, ad esempio, scegliere un livello di minor dettaglio che consente a tutti i componenti di una
particolare classe di utenti di accedere ad una risorsa. Di contro un livello di maggior dettaglio potrebbe concedere
l’accesso in base all’utente e non più alla classe. Una granularità troppo “fine” introduce complicazioni progettuali e
implica uno sforzo maggiore nel gestire un sistema mentre una grossolana riduce le complicazioni ma anche la precisione.
5
É possibile accedere alla documentazione degli standard utilizzati dal sito http://www.rfc-editor.org. Sebbene questa
documentazione sia ufficiale, risulta più agevole consultare testi meno “formali” e più leggeri come ad esempio: “HTML”
di Luca Cattaneo, “Fondamenti di JavaScript” di John Pollock e “Fondamenti di Internet” di Raymond Greenlaw e Ellen
Hepp. Oltre ai testi riportati in bibliografia e a quelli appena citati sono disponibili numerose risorse sul Web. Un buon
punto di partenza è il sito http://www.html.it.
3. Architettura logica e implementazione*
Ai fini dello sviluppo del CFG sono state affrontate diverse tipologie di problemi. Ogni problema
suggerisce naturalmente una serie di alternative alla sua soluzione. Si è cercato, quindi, un
denominatore comune per la scelta della tecnologia o del paradigma da adottare per risolverlo. É stata
prestata particolare attenzione alla minimizzazione del numero complessivo di strumenti utilizzati, alla
scelta di strumenti specifici per le diverse funzioni da espletare e ai meccanismi di comunicazione per
mezzo dei quali tali strumenti avrebbero potuto comunicare.
Un’importante conseguenza della complessità del sistema è che la scelta di un “componente” può
avere delle conseguenze anche nella scelta delle altre componenti. Come unico vincolo, in fase di
progetto, è stata imposta l'adozione di un browser Web come strumento per l'interazione con il sistema.
Le ragioni di questa scelta sono state esposte nell’introduzione.
L’architettura delle applicazioni basata su pagine Web utilizza protocolli che sono stati sviluppati
precedentemente e con scopi diversi da quelli che si prefigge tale tecnologia. Per questo motivo molte
delle operazioni che possono essere eseguite con programmi stand-alone o dagli altri applicativi clientserver (che utilizzano client ad hoc) sono difficili da implementare. Spesso bisogna ricorrere ad
espedienti che sono poco eleganti dal punto di vista teorico. Alcune volte, quindi, si preferisce
scendere a compromessi, sacrificando alcune caratteristiche che un buon software dovrebbe possedere,
quali ad esempio la portabilità e la sicurezza, per non utilizzare tecnologie più potenti ma più
complicate ed “espressive”.
La tecnologia Java, oltre ad essere un linguaggio di programmazione general purpose, permette ad un
comune browser di eseguire un programma, chiamato applet, all’interno di una pagina. Quando in una
pagina è contenuta un’applet il codice eseguibile (bytecode) di quest’ultima è scaricato ed eseguito un
ambiente virtuale (Java Virtual Machine). In questo modo si eliminano i limiti citati in precedenza.
Il Java è un linguaggio ad oggetti che possiede interessanti proprietà tra le quali si ricordano: la
portabilità, la gestione dei thread, la sicurezza e la robustezza. Un’altra importante caratteristica è che
le specifiche del linguaggio Java e della Java Virtual Machine sono aperte ma coperte da copyright.
Questo vuol dire che è possibile reimplementare il compilatore Java o l'interprete a Runtime del
bytecode senza la necessità di chiedere autorizzazioni.
3.1 Architettura del sistema
3.1.1 Il modello multi-tier
Negli anni ’80 e ’90, grazie all’introduzione delle reti di computer e del modello client-server6, si è
assistito ad una evoluzione delle tecniche di progettazione del software. Questo ha implicato
l’adozione di un diverso approccio allo sviluppo delle applicazioni. Infatti si deve operare una
divisione dei compiti, per portare a termine un’attività complessa, tra le componenti client e server,
tenendo ben presente l’aumentata capacità elaborativa e di memorizzazione dei client. Con l’avvento
*
A cura di Francesco Altarocca
Per client-server si intende un modello in cui due entità, il client e il server (che possono operare su macchine distinte),
attraverso lo scambio di messaggi collaborano per eseguire un determinata attività. I server erogano un servizio, i client lo
utilizzano.
6
di Internet e dei nuovi protocolli di comunicazione, tale paradigma ha subito una ulteriore evoluzione:
si è assistito alla nascita di ambienti client-server di tipo distribuito. Si è passati ad applicazioni
progettate e realizzate secondo strati software diversi (applicazioni multi-tier), distribuiti su computer
diversi in base alle varie esigenze, ai carichi di lavoro, alla struttura dell’applicazione, ecc. I vantaggi
derivanti dall’adozione di tali approcci sono: l’aumento della scalabilità7 dell’applicazione, la sua
manutenibilità, la razionalizzazione del processo di progettazione, il riuso del codice e
dell’applicazione e delle sue componenti. Di contro si assiste ad un incremento della complessità della
progettazione e dello sviluppo che implica un’approfondita conoscenza di tutte le componenti
necessarie alla realizzazione del sistema.
Una tra le più semplici applicazioni multi-tier è la three-tier composta da: lo strato di presentazione, lo
strato che cabla la logica del programma (business logic) e lo strato per la persistenza dei dati (data
storage).
L’utilizzo di questo approccio consente di disaccoppiare la logica del programma dalla presentazione
dei dati e i dati dalla business logic. In questo modo, se si vuole sostituire uno strato, per far fronte ad
una nuova esigenza, sarà necessario intervenire su una sola componente del sistema e non su tutto
l’applicativo.
3.1.2 Architettura di CFG
Per la realizzazione di questo sistema sono stati utilizzati dei moduli, combinati e modellati in modo
opportuno, al fine di creare una funzione complessa e altamente personalizzata. Per far ciò sono stati
utilizzati molteplici strumenti, ognuno specializzato in un compito specifico. Sono state pensate ed
realizzate delle procedure e dei meccanismi per consentire, alle diverse parti che compongono il
sistema, l'interazione e lo scambio d'informazioni. Tali moduli “dialogano” tra di loro attraverso vari
sistemi di comunicazione e forniscono ad ogni modulo vicino un “servizio”; l'interazione e lo scambio
di messaggi fra i moduli e i servizi, permette al CFG di fornire una funzione più complessa e
maneggevole per l'utente finale. I motivi che hanno influenzato la scelta dei diversi “piccoli” moduli
per la realizzazione del CFG sono:
• l'alta specializzazione del componente;
• la robustezza;
• la facile integrazione con gli altri moduli;
• la larga diffusione commerciale;
• la facile manutenzione;
• lo standard de facto del mercato;
• la facile portabilità;
• l’indipendenza (per quanto possibile) dagli standard proprietari o meglio non aperti.
Tutto questo permette, inoltre, una semplice modifica o sostituzione di alcune porzioni del sistema,
qualora per un motivo qualsiasi si renda necessario, senza la necessità di dover stravolgere
completamente il sistema.
7
Con scalabilità si intende la capacità di un sistema di far fronte all’aumento del “carico di lavoro” tramite l’acquisizione di
ulteriori “moduli” elaborativi.
3.1.3 Note sull’usabilità e sull’interfaccia utente
Nella fase di progettazione e di realizzazione della parte del CFG che interagisce direttamente con
l'utente (interfaccia utente), è stata prestata particolare attenzione al livello di conoscenza atteso che
l’utilizzatore finale (amministratore e utente interno/esterno) deve avere per essere in grado di
interagire con il sistema. Tali accortezze hanno permesso di sviluppare un prodotto fruibile da
chiunque e gestibile anche da persone che non hanno un adeguato livello di conoscenza dei sistemi
software sottostanti. Al fine di raggiungere questo obiettivo sono state imposte restrizioni e sono state
effettuate numerose semplificazioni cercando nel contempo di mantenere la maggiore flessibilità
possibile.
La struttura e la logica del CFG, infatti, risulta semplice ed immediata: un pannello laterale permette di
scegliere l'operazione da effettuare; il pannello centrale visualizza i dettagli dell'operazione che si sta
effettuando.
3.2 I moduli del CFG
Lo schema generale di CFG, contenente anche una rappresentazione delle interazioni fra le diverse
componenti, è visibile in Figura 3.1.
Figura 3.1: Schema dell’interazione tra i componenti
É importante osservare che nella rappresentazione è visibile un solo server nel quale “girano” tutti i
processi server. In realtà è possibile mettere ogni componente server (FTP, Web, DB) in macchine
separate. Una tale organizzazione potrebbe essere adottata qualora si rendessero necessarie delle
prestazioni più elevate dovute ad un consistente aumento del numero degli utenti o dei file scaricati.
3.2.1 I ruoli dei moduli
Nella Tabella 2.3 sono riportate le funzioni che ogni componente svolge all'interno del sistema e le
loro interazioni. Si rimanda alla sezione 4.2.2 (La piattaforma software) per la descrizione delle scelte
tra diversi sistemi software.
Servizio
Windows 2000
Server http
Server ftp
Java
Php
Mysql
Tabella 2.3: Interazione e funzioni dei moduli
Funzione
Interazione
Sistema operativo sottostante
Fornisce un ambiente sul quale gli altri server
(HTTP, FTP, DBMS) operano
Presentazione, interazione con l’utente, (PHP) Attraverso questo linguaggio di
autenticazione utente, download file
scripting il server Web presenta all’utente i
contenuti dinamici.
(Java) Attraverso un applet (client ftp), che
Upload dei file nell’archivio
“gira” sul browser, consente all’utente di fare
l’upload sul server ftp.
Client ftp (applet firmata: viene eseguita (Server ftp) Utilizza il servizio ftp per scaricare
tramite browser)
i file sul server.
Statistiche, gestione utenti, ricerca, gestione (Mysql) Utilizza il motore DBMS per reperire
e inserimento file, presentazione documenti, informazioni sugli utenti e sui documenti
interrogazione DBMS
inseriti.
Contenitore informazioni sugli utenti e sui
documenti
Nel Capitolo 6. (Manuale dell'amministratore) verrà illustrato in modo dettagliato il ruolo di ogni
modulo e i meccanismi che permettono l'intercomunicazione fra le parti.
3.3 Le interazioni tra i moduli
Di seguito sono evidenziati i flussi di informazioni e le responsabilità di ogni sotto-sistema che
compone il CFG riguardanti alcune importanti tipologie di operazione che è possibile effettuare. Nella
sezione successiva verrà presentata una breve panoramica sul meccanismo utilizzato per produrre
pagine dinamiche.
3.3.1 I linguaggi di scripting e il PHP
I linguaggi di scripting sono nati per consentire al programmatore di intervenire in maniera semplice
ed efficace sul codice di una applicazione senza la necessità di ricompilare il sorgente. Infatti, nei
normali linguaggi di programmazione il codice è compilato e il prodotto di questa attività è un
“oggetto” autonomo in grado di essere eseguito senza l’ “aiuto” di altri programmi. Nei linguaggi di
scripting, invece, il codice sorgente (script), tipicamente un file di testo contenente le istruzioni in un
particolare linguaggio, viene elaborato da un interprete ed eseguito. L’interprete si occupa: di
verificare che il programma sia scritto in modo corretto, di tradurre il programma in modo che la
macchina fisica possa eseguirlo, di preparare l’ambiente di esecuzione e di eseguire il codice. Il
processo è costituito in modo tale da permettere di modificare il codice in qualsiasi momento e di
ottenere quindi i risultati senza compilare nuovamente l’applicazione. Questo vantaggio si traduce in
prestazioni più modeste: ogni volta che lo script è lanciato l’interprete deve eseguire numerose
operazioni preliminari alla esecuzione del programma. Talvolta queste fasi vengono saltate ricorrendo
a meccanismi di caching8.
A causa della frequenza con la quale sono aggiornate la pagine Web dinamiche i linguaggi di scripting
vengono normalmente preferiti ai classici linguaggi di programmazione.
Il PHP (PHP: Hypertext Preprocessor) è un linguaggio di script Open Source con una sintassi semplice
e con una buona libreria di funzioni. Le prime versioni di questo linguaggio sono state progettate con
lo scopo specifico di soddisfare le esigenze dello sviluppo di pagine Web dinamiche ma, nel corso
degli anni, il linguaggio ha subito numerosi miglioramenti. Nelle ultime versioni di PHP sono state
introdotte alcune caratteristiche dei linguaggi di programmazione orientata agli oggetti. Inoltre il
linguaggio è ora disponibile non solo per l’integrazione con i server Web ma anche per produrre script
stand-alone.
3.3.2 La richiesta di una pagina
Quando un utente, attraverso il proprio browser, richiede una pagina dinamica, il server riceve la
richiesta e, attraverso una serie di elaborazioni, restituisce un risultato (tipicamente una pagina). Lo
stesso browser, assieme alla richieste, può inviare al server HTTP9 anche ulteriori informazioni. Le
richieste sono inoltrate al server per mezzo di due meccanismi distinti specificati nel protocollo HTTP:
POST e GET. Grazie a questi è possibile eseguire il codice degli script tenendo conto di parametri ed
elaborando quindi un output “personalizzato”. Ad esempio, è possibile inviare, attraverso l’uso di
maschere (form10), il cognome di un autore di libri e ricevere come risultato la lista dei libri scritti
datto stesso.
Il server elabora lo script e interroga la base di dati, formatta il risultato e lo restituisce al client
(browser).
Ricapitolando il server Web soddisfa la richiesta di un client eseguendo i seguenti passi (Figura 3.2):
• compila, in tempo reale, ed esegue il codice contenuto (ed eventualmente delle richieste al
database server);
• restituisce al server Web l’output da inviare al client (browser Web).
L’output del traduttore PHP può essere di qualsiasi tipo, uno stream di testo o uno stream di byte: i dati
possono rappresentare un semplice testo, un’immagine, un filmato, ecc. Nella risposta (response
HTTP) al client viene inviato il content-type che permette di specificare il tipo di informazione che il
server sta inviando. In questo modo il browser potrà interpretare le informazioni in maniera corretta.
8
La cache di un interprete consente di compilare lo script una volta soltanto e mantenere il risultato di questa operazione
finché il sorgente non viene modificato. In questo modo si riescono ad eliminare molte fasi che risultano ridondanti e
quindi inutili.
9
HTTP (Hyper Text Transfer Protocol) è un protocollo che consente ad un client e un server Web di dialogare.
L’interazione avviene attraverso lo scambio di messaggi ASCII e ogni singola interazione si svolge secondo il seguente
schema: apertura di una connessione TCP fra client e server, invio di una singola richiesta (request) da parte del client,
invio della risposta (response) da parte del server, chiusura della connessione TCP.
10
Esistono anche altri meccanismi di passaggio dei parametri come, ad esempio, le ancore con parametri specificati nella
URL (Uniform Resource Locator).
Figura 3.2: Elaborazione di una pagina Web dinamica
Database
Interprete
PHP
4
Dati
6
Response
5
Output
1
Request
interrogazione
3
Client
Server
Web
2
3.3.3 Download di un file
Il download di un file avviene facendo richiesta della risorsa, mediante HTTP e URL, al server Web.
Quest’ultimo, se la risorsa è rilevata, la recupera dal file system sottostante, invia un content-type
adeguato e poi il flusso di byte.
3.3.4 Upload di un file
Il meccanismo per soddisfare una richiesta di questo tipo e al contempo mantenere l’interazione con
l’utente semplice ed immediata, merita una descrizione più dettagliata perché più complesso. Pertanto
si rimanda il lettore al paragrafo 4.4 Il meccanismo di upload dei file) che tratta anche di aspetti legati
all’architettura fisica del sistema e alle piattaforme software utilizzate.
3.4 Il database
Le informazioni, necessarie al funzionamento del catalogo, sono inserite in un database relazionale.
Quando un nuovo documento è registrato dall’utente, viene inserito un record nella tabella (Tabella
3.1). Il record immagazzinato servirà in futuro per l'identificazione e per la ricerca del documento.
Tabella 3.1: Informazioni da archiviare per ogni documento
Campo
Descrizione
Tipo
id
identificativo del file
contatore
nome_file
nome del file (senza il path)
testo
id_utente
identificativo dell’operatore
testo
id_tipo_indagine identificativo tipo indagine
testo
formato
formato del file (SAS, Excel, Word,……) testo
versione
versione del formato
testo
id_tfi
identificativo tipo formato per input
testo
anno
anno dell’indagine (su quattro cifre)
numerico
note
note sul file
memo
tipo_file
dati/questionario/tracciato/codici
testo
data_ins
time stamp dell’inserimento
time stamp
archiviato
collocazione e identificativo file
testo
cancellato
record cancellato dall’utente
si/no
11
Nec.
chiave
sì
sì
sì
sì
no
no
sì
no
sì
sì
no
no
Le informazioni contenute nella tabella descrivono in maniera sintetica il formato del file,
l’organizzazione del contenuto, il “proprietario”, la data d’inserimento, l’anno di riferimento
dell’indagine ed eventuali note. Il campo archiviato consente di descrivere la collocazione del
documento una volta archiviato su un qualsiasi supporto di memorizzazione e il nome del supporto
(qualora per l'archiviazione siano richiesti più di un'unità di memorizzazione).
Il campo cancellato permette all'utente di inserire nuovamente un file che già è stato registrato. Inoltre
quando un documento è segnato come “cancellato”, il corrispondente file non viene cancellato. In
questo modo è impossibile cancellare per errore un file che invece si desiderava conservare.
Le informazioni necessarie per consentire l'accesso attraverso autenticazione, per individuare il profilo
e quindi le azioni che l'utente può effettuare nel sistema, sono riassunte nella Tabella 3.2. Il campo id è
la chiave della tabella e quindi deve essere univoco (ogni utente deve avere un diverso identificativo).
Campo
Id
Password
Nome
Cognome
Attivo
Profilo
Tabella 3.2: Informazioni relative all’utente
Descrizione
identificativo (user name)
password dell’utente
nome dell’operatore
cognome dell’operatore
indica se l’utente può accedere al sistema
profilo dell’utente
Tipo
testo
testo
testo
testo
testo
testo
Data la loro staticità, le informazioni relative alle indagini sono state “cablate” all’interno di un script
PHP. In qualunque momento, attraverso poche e semplici modifiche, è possibile trasferire tali
informazioni su una nuova tabella del database.
3.5 Note sulla integrabilità con altri sistemi e sviluppi futuri
L’utilizzo di strumenti e paradigmi standard è stato, fin dall’inizio della progettazione, uno dei vincoli
fondamentali da rispettare. Il cambiamento di parti del sistema risulta più veloce e non perturba altri
sotto-sistemi se, a scapito di tecnologie proprietarie o “chiuse”, si fa ricorso a standard consolidati
11
Specifica il campo necessario per l’inserimento del record. Se un campo necessario non viene specificato, l’inserimento
non può essere effettuato.
oppure a software e tecnologie “aperti”. Non è raro infatti che, a causa di politiche organizzative,
grazie all’utilizzo di nuovi software più performanti o con nuove funzionalità, si possa sostituire
qualche “componente” del sistema. Nel caso di utilizzo di sistemi “aperti”, l’intervento sul codice e
quindi l’impatto sull’intero sistema risulterebbe estremamente limitato e circoscritto.
Nondimeno qualora si volesse passare ad una diversa piattaforma hardware o software, come ad
esempio un server IBM con AIX o SUN con Solaris, sarebbe sufficiente portare fisicamente tutto il
codice sulle nuove macchine e reinstallare dei software generici che svolgano le stesse funzioni di
quelli usati sulla precedente architettura.
Gli scenari immaginabili per sviluppi futuri sono molteplici e possono concorrere ad automatizzare
alcune attività legate all’attività di archiviazione e di alimentazione delle banche dati.
Si può pensare, ad esempio, di permettere al software utilizzato dal responsabile delle procedure di
ETL e dei caricamenti dei dati di visualizzare alcuni dati presenti nel CFG. Sarà sufficiente permettere
al software di destinazione di visualizzare i dati contenuti nelle tabelle. Questo è possibile creando
delle viste o delle query e concedendo gli opportuni diritti sull’RDBMS12.
Potrebbe, ad esempio, essere implementata una funzione che ad ogni nuovo inserimento di un
documento invii una e-mail per avvisare il responsabile del caricamento dal data warehouse che è
disponibile nuovo materiale. Oppure potrebbe essere interessante tenere costantemente aggiornati tutti
gli utenti sui nuovi inserimenti. Ancora potrebbe essere programmato uno scadenzario che avvisi gli
utenti che non sono pervenuti documenti che invece dovevano essere già presenti nel CFG.
12
RDBMS (Relational Database Management Systems) Database relazionale.
4. Architettura fisica*
Nelle seguenti sezioni verranno illustrate le architetture software e hardware utilizzate per realizzare il
sistema e i motivi per i quali sono state scelti particolari ambienti piuttosto che altri. Verranno inoltre
illustrati alcuni meccanismi sottostanti alle tecnologie e al software impiegato.
4.1 Tipo di licenze del software utilizzato
Si parla di sistemi Open Source quando la loro produzione è garantita da una comunità di sviluppatori
che ne rilasciano le successive versioni in formato sorgente e con licenze non restrittive di utilizzo. I
maggiori vantaggi dell'adozione di tale software in questo contesto consistono nei seguenti punti:
• risparmio sui costi delle licenze;
• garanzia di evoluzione continua del prodotto;
• ottimo livello di qualità;
• possibilità di personalizzare le caratteristiche del software per adattarlo alle proprie necessità;
• scelte di progetto del software indipendenti dalle politiche di una società commerciale;
• contributo di numerosi sviluppatori indipendenti.
Negli ultimi tempi il fenomeno del software Open Source ha riscosso notevoli consensi anche nella
Pubblica Amministrazione.
Nel comunicato stampa del 29 ottobre 2003, disponibile sul sito del “Ministero per l’innovazione e le
tecnologie”, riguardante la “Direttiva Stanca per l'Open Source” (pubblicata in Gazzetta Ufficiale n. 31
del 7-2-2004) è riportato: “[...] La "Direttiva Stanca per l'open source" dispone che le Pubbliche
amministrazioni acquisiscano programmi informatici sulla base di valutazione comparativa tecnica ed
economica tra le diverse soluzioni disponibili sul mercato, tenendo conto della rispondenza alle
proprie esigenze, ma anche della possibilità di poter sviluppare programmi informatici specifici e del
riuso da parte di altre amministrazione dei programmi informatici sviluppati ad hoc.
Tra le valutazione di tipo tecnico ed economico vanno contemperati anche il costo totale di possesso
delle singole soluzioni e del costo di uscita, ma anche del potenziale interesse di altre amministrazioni
al riuso dei programmi informatici. [...]”.
La direttiva dispone alcuni criteri generali per quanto riguarda la comparazione delle diverse soluzioni:
“[...] Le Pubbliche amministrazioni nell'acquisto dei programmi informatici dovranno privilegiare le
soluzioni che:
o assicurino l'interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della
Pubblica amministrazione, salvo che ricorrano peculiari ed eccezionali esigenze di sicurezza e
di segreto;
o rendano i sistemi informatici non dipendenti da un unico fornitore o da un'unica tecnologia
proprietaria;
o garantiscano la disponibilità del codice sorgente per l'ispezione e la tracciabilità da parte
delle Pubbliche amministrazioni;
o esportino dati e documenti in più formati, di cui almeno uno di tipo aperto. [...]”.
*
A cura di Francesco Altarocca
Viene, inoltre dato particolare risalto al riuso del codice: “[...] Per favorire il riuso dei programmi
informatici di proprietà delle amministrazioni, nei capitolati e nelle specifiche di progetto dovrà
essere previsto che i programmi sviluppati ad hoc siano facilmente esportabili su altre piattaforme.
Inoltre nei contratti di acquisizione di programmi informatici sviluppati per conto e a spese delle
amministrazioni, le stesse includono clausole che vincolano il fornitore a mettere a disposizione
servizi che consentano il riuso delle applicazioni. [...]”.
Viste le precedenti indicazioni e viste le considerazioni fatte prima nel paragrafo 3.5 Note sulla
integrabilità con altri sistemi e sviluppi futuri) è stato preferito privilegiare, qualora fosse possibile,
l'utilizzo di software Open Source.
4.2 Le piattaforme utilizzate
Di seguito sono riportate delle indicazioni di massima sulle piattaforme hardware che preferibilmente
si dovrebbero utilizzare per garantire il necessario livello di performance e di sicurezza.
Ciononostante, è possibile utilizzare sistemi molto più economici tenendo presente i rischi di
affidabilità e ovviamente le minori performance risultanti. É altresì indicato l'utilizzo di sistemi
software sui quali il CFG si appoggia per svolgere al meglio i propri compiti.
4.2.1 La piattaforma hardware
La piattaforma minima per la gestione e la creazione del CFG è stata individuata in un PC Pentium III
con un processore da 1,5 Ghz e una dotazione di RAM non inferiore a 512 Mb, un controller Wide
SCSI II, scheda di rete 10/100 Mbit e due dischi fissi di dimensioni appropriate (120 GByte ogni
disco). L'impostazione si deve basare su almeno due dischi rigidi in modo tale da consentire
l'implementazione di un sistema di fault tollerance ridondante (mirroring) per ridurre il rischio di
perdita dei dati. Per aumentare il grado di sicurezza e per evitare danni irreparabili è opportuno
collegare la macchina server ad un gruppo di continuità ed eseguire backup periodici.
4.2.2 La piattaforma software
Riguardo al software da utilizzare come sistema operativo della postazione server, è stato ritenuto
opportuno utilizzare Windows 2000 Professional. La suite dei prodotti Windows 2000, infatti, offre
una elevata compatibilità con l'hardware che è stato impiegato. Le considerazioni che hanno portato
alla scelta di questo sistema operativo sono: un'interfaccia per l'utente di rapido e semplice utilizzo,
una buona stabilità e un elevato livello di sicurezza per i dati (grazie all'utilizzo di un file-system
journaling13 di ultima generazione) e la presenza di un server FTP integrato nel sistema (non c'è quindi
bisogno di installare prodotti supplementari).
13
NTFS (file system di Windows 2000) è un journaling file system, ciò significa che memorizza tutte le modifiche fatte.
Questo tipo di approccio risulta estremamente utile quando, ad esempio, manca improvvisamente l’alimentazione. Il
sistema può in questo modo risalire ai cambiamenti effettuati e in molti casi recuperare dati corrotti.
4.2.3 Note sulle piattaforme hardware/software
Le raccomandazioni date sopra sono indicative, infatti, le stesse prestazioni, lo stesso grado di
affidabilità (se non superiore), ecc., si sarebbero potute ottenere scegliendo sistemi proprietari come a
titolo di esempio AIX di IBM (presente in Istituto) oppure piattaforme software altrettanto valide come
Linux, OpenBSD o netBSD. Questi sistemi, infatti, garantiscono un alto grado di affidabilità e di
performance ma il prezzo da pagare per ottenere tutto ciò (in termini di know how e quindi di un
maggiore sforzo nelle attività di assistenza e manutenzione) è superiore per gli scopi che il CFG si
prefigge in questa fase. Nulla vieta, comunque, di utilizzare tali piattaforme quando si presenti la
necessità di migliori performance e altissima affidabilità. In tal senso, l'analisi e lo sviluppo sono stati
eseguiti con particolare attenzione alla portabilità proprio per consentire future espansioni e/o
migrazioni.
4.3 Scelte implementative
Viste le considerazioni esposte e le scelte di massima che sono state fatte nelle sezioni precedenti, di
seguito saranno riportati i criteri per la selezione dei principali ambienti che sono risultati necessari.
Memorizzazione dei documenti e file-system: fra le varie opzioni software presenti nell'Istituto,
(Unix-Aix, Linux, Windows 2000), è stato scelto l'impiego di Windows 2000 perchè possiede un client
FTP integrato, è un prodotto dall'aspetto gradevole, standard, facile da usare e familiare per l'utente.
Memorizzazione delle informazioni di catalogazione nel database: per quel che concerne la
gestione delle informazioni inserite nel catalogo e l'interazione del RDBMS (Relational DataBase
Management System) con gli altri moduli del sistema, le opzioni a disposizione sono: Oracle, Access,
SQL Open Source (per es. MySQL o PostgreSQL). La scelta di quest'ultimo sottoinsieme è senza
dubbio più vantaggiosa data la semplicità di utilizzo, la leggerezza e le qualità in termini di
performance che lo caratterizzano a scapito di una riduzione delle funzionalità che un RDBMS come
Oracle mette a disposizione. Il fatto che MySql non possieda le caratteristiche di alcuni tra i più noti
RDBMS non inficia minimamente la qualità del prodotto derivato in quanto queste non risultano
critiche e sono quindi superflue per i compiti che si devono svolgere.
Integrazione del catalogo e interfaccia utente (operazioni di upload/download dei file): per
interfacciare l'utente con il database, attraverso l'impiego di maschere dinamiche, è stato scelto di
utilizzare il Web Server a fronte di Access, Oracle oppure di uno strumento come Visual Basic.
L'utilizzo di questa tecnologia, permette un facile fruizione dei contenuti immagazzinati sui server
attraverso un browser Web (applicativo di larga diffusione in grado di offrire un buon grado di
sicurezza e disponibile su tutte le postazioni di lavoro all'interno dell'Istituto).
Tutto ciò elimina anche il problema del deployment dell'applicazione per il primo e per i successivi
rilasci. Per deployment si intendono le attività di installazione e configurazione del software al fine di
consentire il corretto funzionamento del sistema. In genere, infatti, è necessario installare il software
client sviluppato sui sistemi ospiti per fruire dei servizi erogati dal sistema.
Come linguaggio di scripting, necessario per generare contenuti dinamici e interfacciare il database, ne
è stato utilizzato, come spiegato nella sezione 3.3.1 (I linguaggi di scripting e il PHP), il PHP. Questo
linguaggio possiede caratteristiche di performance buone, è di facile apprendimento ed utilizzo e
consente una integrazione agevole con i database. Il supporto e la documentazione di PHP risultano
essere di ottimo livello anche se tali servizi non sono erogati da una azienda ma da una nutrita schiera
di sviluppatori di tutto il mondo.
La scelta, invece, diventa quasi obbligata quando si parla di caricare una grossa quantità di dati (anche
centinaia di Mb) sul server. La preferenza qui è ricaduta su un applet Java firmata (che “gira” nel
browser previa autorizzazione da parte dell'utente) e un server FTP integrato in Windows 2000.
L'applet deve essere necessariamente firmata altrimenti non potrebbe essere eseguita sul browser. Il
motivo di questa necessità è dettato da problematiche inerenti la sicurezza e serve a garantire
l'attendibilità del fornitore del programma. Nella sezione successiva verranno illustrati i meccanismi di
funzionamento dell’applet in dettaglio.
Riepilogando le scelte illustrate nei paragrafi precedenti, i moduli che compongono il sistema sono:
• sistema operativo Microsoft Windows 2000;
• server HTTP (Apache);
• server FTP (Windows 2000);
• linguaggio di scripting (PHP);
• linguaggio di programmazione per l’applet firmata (Java);
• RDBMS (MySQL).
L'utilizzo di questi sistemi software, come spiegato sopra, è stato preferito per diversi motivi; le
caratteristiche che hanno svolto un ruolo determinante per la scelta sono: la portabilità, la robustezza e
il supporto.
4.4 Il meccanismo di upload dei file
Il protocollo HTTP (Hyper Text Markup Language 1.0 - RFC 1945) basilare nelle applicazioni Web, è
stato sviluppato per rivolgere richieste al server Web e per ricevere risposte, tipicamente pagine html o
documenti di testo.
L’implementazione dei protocolli nei server Web non comporta problemi quando si fa il download di
documenti di grandi dimensioni dal server Web al browser. Se invece si devono caricare documenti si
hanno problemi di prestazione sul server, qualora essi superino una certa dimensione. Per risolvere
questo tipo di difficoltà è stato impiegato il protocollo FTP il cui scopo è quello di trasferire file di
qualsiasi dimensione tra due computer collegati da una rete TCP/IP.
La pagina per l’immissione di un nuovo documento nell’archivio, ha al suo interno un programma
scritto in Java (applet14) che è un client FTP ossia un programma in grado di trasferire file sul server.
Questo meccanismo consente alle pagine di superare alcuni limiti architetturali. Di fatto esso consente
alle pagine Web di eseguire operazioni che non erano previste quando sono stati progettati i vari
protocolli alla base di questa architettura. La applet (ovvero il client FTP Java15), quando il pulsante
per l’upload viene premuto, controlla che nella casella di testo contente il nome del file ci sia un nome
di file valido, lo invia alla applet e comincia l’upload. Nel processo di trasferimento del file la applet si
occupa anche di informare l’utente, attraverso dei meccanismi di comunicazione tra Java e Javascript,
facendo comparire sulla barra di stato la percentuale di processo portato a termine. A conclusione del
trasferimento del file, vengono eseguiti altri controlli per verificare che sia avvenuto in maniera
14
Il client FTP (File Transfer Protocol - RFC 959) implementa solo alcuni dei numerosi comandi specificati nel protocollo.
Infatti è stato sufficiente sviluppare un client che fosse in grado di gestire il login sul server FTP e il comando PUT che
consente di inviare un documento dal client al server.
15
Si sarebbe potuto utilizzare, ad esempio, ActiveX di Microsoft ma, si è preferito Java perché utilizzabile anche su altre
piattaforme.
corretta. Se non si sono verificati problemi le informazioni supplementari vengono inserite nella
tabella dei documenti e l’utente viene informato dell’esito positivo dell’operazione.
Molti sono gli “attori” di questo processo: l’applet Java, il Javascript e il modello DOM (Document
Object Model), il PHP, il server FTP e il database server. Oltre a tutti questi componenti è necessario
utilizzare anche un certificato. Questo serve essenzialmente per ragioni di sicurezza. Infatti non deve
essere possibile per un programma scaricare file dal computer ospite, vedere il contenuto di un disco, o
comunque eseguire operazioni potenzialmente dannose per l’utente.
Java a tal proposito offre diverse linee di difesa tra le quali ricordiamo:
• è fortemente tipato16, esegue controlli sui limiti degli array e non consente l’uso di puntatori;
• possiede un bytecode verifier che effettua numerosi controlli prima di mandare in esecuzione il
codice;
• utilizza il class loader che non permette la sostituzione di alcune classi di sistema;
• fa uso del security manager che si occupa di stabilire limiti di un programma ossia cosa può
fare.
Al fine di garantire l’autenticità di un programma, ossia che l’applicazione sia stata scritta dal suo
autore e che non sia stata “manipolata” da altri, si usa la firma elettronica. L’applet è quindi firmata
con un apposito certificato.
I certificati possono essere creati in proprio oppure possono essere ottenuti, dietro pagamento di un
compenso, dalle Certification Authority. Queste organizzazioni rilasciano un certificato digitale che
attesta la corrispondenza biunivoca tra la chiave pubblica17 contenuta nel certificato e le persona fisica
o la società.
Sintetizzando, per caricare un file sul server e registrare l’inserimento sul database sono necessarie
diverse interazioni fra l’utente e il sistema e fra i diversi sotto-sistemi del CFG:
• preliminarmente bisogna installare il certificato sul proprio browser Web;
• accettare di caricare l’applet firmata sul proprio browser (quando si carica la pagina per
l’upload);
• compilare la form con tutti i dati necessari (compreso il nome del file da caricare);
• verificare che il nome del file sia corretto;
• passare il nome del file all’applet (attraverso un meccanismo di comunicazione da
Javascript a Java);
• collegarsi al server FTP (in questa fase viene mascherato il fatto che bisogna autenticarsi,
questa fase è eseguita automaticamente dall’applet Java);
• scaricare il file sul server (mentre viene scaricato il file sulla barra compare la percentuale
di completamento grazie a meccanismi di comunicazione da Java a Javascript);
• se tutte le operazioni sono andate a buon fine allora l’applet “notifica” il successo alla
“pagina” Web che provvede a registrare il file sul database.
16
Un linguaggio è tipato se è previsto un meccanismo di controllo dei tipi delle variabili. Si dice, invece, che un linguaggio
è fortemente tipato se il tipo di tutte le variabili è determinato a tempo di compilazione, altrimenti e detto dinamicamente
tipato.
17
Il protocollo di crittografia a “chiave pubblica” utilizza una coppia di chiavi legate fra loro: una pubblica (nota a tutti) e
una privata (nota solo al proprietario). Le due chiavi vengono utilizzate per codificare/decodificare un messaggio: ciò che
viene codificato con una chiave può essere letto con l’altra. Il meccanismo è il seguente: il mittente cifra con la propria
chiave privata il programma, il destinatario, attraverso la chiave pubblica riesce a decodificare il messaggio. Operando in
questo modo si è sicuri che il mittente sia chi dice di essere (solo lui infatti possiede la chiave privata) e che il programma
non sia stato alterato.
4.4 La robustezza, la sicurezza e il meccanismo di autenticazione
Si è cercato di raggiungere un buon livello di robustezza adottando software consolidati e utilizzando
tecnologie “proprie” per ogni sottofunzione del sistema. Questa scelta ha permesso di ottenere un
software stabile.
Le scelte operate per garantire un sufficiente livello di sicurezza del sistema dipendono dagli strumenti
utilizzati per la realizzazione del sistema. Essendo stato scelto un sistema basato su browser Web, per
il livello di presentazione, è risultato sufficiente gestire l'autenticazione dell'utente direttamente
mediante i meccanismi messi a disposizione dal fornitore del servizio HTTP stesso (Basic
authentication). Esistono diversi altri metodi di autenticazione, come ad esempio il digest
authentication18, ma è stato preferito, per compatibilità con la maggior parte dei server Web, utilizzare
il Basic authentication. Per minimizzare il rischio di attacchi o di malfunzionamenti sono stati aperti i
servizi strettamente necessari alle funzioni da svolgere. Ogni altro servizio utilizzato (RDBMS o FTP)
richiede comunque un’autenticazione da parte dell'utente. Per questi ultimi la richiesta delle
credenziali per la concessione delle autorizzazioni è impostata in modo automatico (dagli script PHP) a
seconda dei privilegi concessi dall'amministratore.
Nella Tabella 4.1 è riportata la struttura del sito con le relative autorizzazioni.
Directory
/
/Sispa
/Sispa/utente
/Sispa/sys_adm
Tabella 4.1: Autorizzazione per ogni tipologia di utente
Sys_adm Utenti Sispa Utente esterno Utente sconosciuto
X
X
X
X
X
X
X
X
X
X
4.5 Registrazione degli eventi e generazione di report sull'utilizzo del
servizio
Il CFG utilizza i meccanismi di registrazione degli eventi di Apache che si occupa di tenere traccia di
ogni singola richiesta proveniente dai client. Tutte le informazioni sono registrate in un file chiamato
log. Attraverso delle procedure sviluppate ad hoc questi dati vengono elaborati per fornire
informazioni sul servizio e su eventuali problemi.
18
Il digest authentication (RFC 2069) è un protocollo di autenticazione, nel protocollo HTTP versione 1.1, che utilizza un
meccanismo di cifratura di username e password chiamato message digest (riassunto del messaggio) che permette di evitare
di inviare le informazioni in chiaro. Il message digest è una funzione di hashing facile da calcolare ma difficile da invertire:
risalire al messaggio originale è molto oneroso dal punto di vista computazionale.
5. Manuale dell'utente*
5.1 Introduzione
Al “Catalogo dei File Grezzi con meta-dati di base'' di SISPA si accede utilizzando un qualsiasi
browser Web (Microsoft Internet Explorer o Netscape Navigator)1 all'indirizzo http://bengala51.istat.it.
In Figura 5.1 è riprodotta la pagina principale di CFG.
Figura 5.1: Pagina principale
5.2 Accesso al servizio
L'accesso al servizio da parte dell'utente è subordinato alla creazione di un account personale che
permette di operare all'interno del sistema secondo i privilegi che l'amministratore del sistema ha
concesso. Per entrare nel sistema è sufficiente fare clic sul pulsante login posto sulla barra in alto.
Verrà richiesto all'utente di inserire il nome utente e la password, forniti dall'amministratore del
*
1
A cura di Gaetano Sberno
Per inserire documenti è indispensabile Microsoft Internet Explorer 5.0 o superiore
sistema. A seconda della tipologia di utenza che l'amministratore ha creato, l'utente può essere abilitato
ad eseguire alcuni tipi di azione. Sono previste tre tipologie di utenza: amministrativa, interna e
esterna. L'utenza amministrativa non ha alcuna limitazione per quanto riguarda le operazioni che può
effettuare. L'utente interno al sistema può inserire documenti, prelevarli e fare ricerche. All'ultima
tipologia di utenza, quella esterna, sono concesse: la ricerca, la visualizzazione delle informazioni e il
download dei documenti inseriti. Di seguito sono riportate le procedure, previste all’interno del CFG,
dettagliate per tipo di operazione.
5.3 L'utente esterno
L'utente esterno è titolare di un numero minore di diritti di accesso. Tutte le operazioni che questa
tipologia di utente può effettuare possono essere svolte anche dagli utenti appartenenti alle altre due
categorie. Di seguito sono descritte le operazioni che possono svolgere gli utenti esterni.
5.3.1 Cambiare la password
Per cambiare la password è necessario fare clic sull'etichetta Mod. Password contenuta nella sezione
Tools. Comparirà una maschera nel pannello principale contenente i seguenti campi:
• Vecchia Password;
• Nuova Password;
• Conferma.
Nel campo Vecchia Password occorre inserire la vecchia password, nei campi Nuova Password e
Conferma si deve inserire la nuova password. Una volta inserite le informazioni, premere il tasto
Cambia Password e attendere il messaggio di conferma: “Password aggiornata correttamente''. Al
completamento della procedura può accadere che il browser chieda di inserire nuovamente la
password. È consigliabile modificare la propria password al primo accesso al sistema.
5.3.2 Scaricare e ricercare documenti
Per scaricare, ricercare e visualizzare i documenti inseriti nel catalogo, sono disponibili diverse
modalità di accesso raggiungibili dalla sezione Download:
• Navigatore;
• Ricerca;
• Lista.
Il Navigatore organizza i documenti in una struttura gerarchica: il primo livello di gerarchia ripartisce
l'insieme dei documenti contenuti nel CFG per anno di riferimento delle statistiche. Il secondo livello
di gerarchia distingue i documenti all'interno di ogni anno, in base al titolo dell'indagine.
La navigazione tra i documenti avviene facendo clic sull'anno visualizzato e sull'indagine. Una volta
arrivati all'ultimo livello della gerarchia, riconoscibile dalla presenza di una icona che mostra un
documento (invece di una cartellina), selezionato un documento, si visualizzano le informazioni
disponibili nel file specificato. Per prelevare il file è sufficiente premere il tasto destro del mouse
sull'icona al centro della pagina e selezionare “Salva oggetto con nome”.
Un altro modo per accedere ai dati contenuti in CFG è quello messo a disposizione dal modulo di
Ricerca. Facendo clic su Ricerca, nel pannello di sinistra, verrà visualizzata una pagina con un casella
nella quale occorre inserire il testo cercato. Le parole inserite nella casella saranno cercate non solo
nella denominazione dell'indagine, ma anche nell'anno e nella tipologia di file inserito (dati, tracciati,
...). Se, ad esempio, si fosse interessati ai dati dei “Bilanci consuntivi degli enti di diritto allo studio
universitario” , relativi all'anno 1999, si dovrebbe inserire: “dati bilanci univ 1999”. È inoltre possibile
inserire il numero di codice PSN dell'indagine riportato nel “Programma Statistico Nazionale”. Una
volta inserite le parole, premendo il pulsante Ricerca, si accede ai risultati. Facendo clic su uno dei
risultati ottenuti, si accede alla scheda relativa al documento che è identica a quella visualizzata dal
navigatore. Da qui è possibile scaricare il file come spiegato sopra.
La Lista, invece, visualizza l'elenco completo dei documenti che sono stati inseriti in CFG. Le indagini
elencate seguono il seguente ordine:
1. Nome dell'indagine (lessicografico crescente);
2. Anno (numerico decrescente).
È sufficiente fare clic sul documento di interesse per visualizzarne la scheda completa e per prelevarlo.
5.4 L'utente interno
L'utente interno, oltre ad eseguire tutte le operazioni concesse all'utente esterno, può inserire nuovi
documenti e modificare le informazioni dei documenti inseriti.
5.4.1 Configurazione e prerequisiti per il caricamento dei documenti
Per inserire documenti in CFG è necessario eseguire le seguenti operazioni:
• Scaricare il Plug-in Java ed installarlo sulla macchina che servirà per caricare i file in CFG;
• Scaricare il certificato ed installarlo nel browser.
Tali procedure verranno illustrate in dettaglio di seguito.
È inoltre necessario utilizzare Internet Explorer 5.5 o superiore o Netscape Navigator 6.0 o superiore.
5.4.2 Scaricare ed installare il Java Runtime Environment
Fare clic su Aiuto e successivamente sul link qui nella sezione “Scaricare ed installare il Java Runtime
Environment” per avviare il download del Java Runtime Environment 1.3.1_03. Alla richiesta: “Che
cosa si desidera fare di questo file?”, selezionare “Salva l'applicazione sul disco”, premere il pulsante
Ok e salvare il file in una cartella. Terminato il download del file, lanciare l'eseguibile, comparirà il
contratto di licenza, premere il tasto Ok e continuare. Selezionare la cartella nella quale verrà installato
il Plug-in (è consigliabile lasciare la scelta di default) e premere il tasto Avanti. Selezionare l'opzione
“Microsoft Internet Explorer” e premere il pulsante Avanti per continuare. Il programma chiederà di
riavviare la macchina. Confermare.
5.4.3 Scaricare ed installare il certificato per il corretto funzionamento
dell'applet
Fare clic sul pulsante Aiuto e successivamente sul link qui nella sezione “Scaricare ed installare il
certificato per il corretto funzionamento dell'applet” per avviare il download del certificato. Alla
richiesta: “Che cosa si desidera fare di questo file?”, selezionare “Apri file dal percorso corrente” e
premere il pulsante Ok. Comparirà una schermata: premere il pulsante Installa certificato. Premere il
pulsante Avanti per proseguire. Selezionare “Selezionare automaticamente l'archivio certificati
secondo il tipo di certificato” e premere il pulsante Avanti. Premere il pulsante Fine per terminare
l'installazione.
Nota per l'esecuzione dell'applet:
Premere, dal menù avvio, il tasto Start->Impostazioni->Pannello di controllo, aprire il Java Plug-in,
comparirà una schermata: selezionare la scheda “Proxy'', selezionare l'opzione “Usa impostazioni
browser” (se già selezionato lasciare invariato). Selezionare il pulsante Applica se sono state apportate
modifiche, altrimenti chiudere il tool di configurazione.
5.4.4 Inserire un documento
Per accedere all'inserimento fare clic sul link sul pulsante Nuovo file dalla sezione “Gestione file”.
Comparirà la seguente maschera visibile in Figura 5.2.
A questo punto verrà visualizzato un messaggio “Avviso sulla sicurezza di Java Plug-in” il quale
informerà l'utente che la pagina contiene un'applet firmata (il programma che consente di caricare il
file sul server). È possibile rispondere con “Concedi per questa sessione”: nel qual caso ogni volta che
si immetterà un nuovo documento questo messaggio comparirà nuovamente, altrimenti è possibile
rispondere “Concedi sempre”: in questo caso non verrà più richiesto di confermare l'esecuzione
dell'applet2.
A questo punto è necessario inserire le informazioni richieste nella maschera3:
• nome dell'indagine;
• anno;
• tipo di file (dati, questionari, tacciati record, ...);
• formato input (verticalizzato, piatto, ...);
• eventuali note;
• nome del file.
2
E’ necessario rispondere nei due modi descritti altrimenti non si possono inserire documenti nel CFG.
Per ottenere ulteriori informazioni sul significato dei campi fare clic sull’icona contenente un punto interrogativo posto
nella form in basso a sinistra.
3
Figura 5.2: Maschera per l'inserimento di un nuovo documento
Premendo il tasto Inserisci documento si avvierà la procedura di caricamento del file sul Server. Se per
qualsiasi motivo le informazioni inserite nella maschera non dovessero essere corrette, l'utente verrà
avvisato dell'errore riscontrato mediante una finesta pop-up. Qualora, invece, le informazioni risultino
corrette4, sulla barra di stato (in basso), verrà visualizzato lo stato del download in percentuale e solo
alla fine di questa attività l'utente verrà informato dell'esito della procedura di inserimento. È
comunque consigliabile verificare, dopo l'upload del documento, le informazioni immesse e l'integrità
del file scaricando il documento appena caricato e controllando le informazioni presenti nel database.
5.4.5 Visualizzare la lista dei file archiviati
Facendo clic sul link Lista File dalla sezione “Gestione file” si accede alla lista di tutti i documenti che
sono stati archiviati in CFG. È possibile ordinare la lista, facendo clic sulle frecce accanto ai nomi
delle colonne, secondo i seguenti criteri:
• nome dell'indagine;
• anno di riferimento dell'indagine;
• data di archiviazione.
4
Per quanto sia possibile verificare l’esattezza delle informazioni inserite
Una volta visualizzata la lista, è possibile cancellare il documento inserito facendo clic sull'icona con
la croce rossa nella riga corrispondente al documento che si vuole eliminare. Comparirà un messaggio
“pop-up” che chiederà conferma della cancellazione che si sta effettuando. È possibile modificare
alcune informazioni facendo clic sull'icona contenente una matita come spiegato in dettaglio nella
prossima sezione.
5.4.6 Modifica delle informazioni relative ad un documento archiviato
Una volta entrati nella sezione per la modifica delle informazioni del documento, verrà visualizzata
una maschera simile a quella disponibile per l'inserimento dei nuovi documenti. Ora è possibile
modificare le informazioni contenute nella maschera e, facendo clic sul tasto Modifica Documento,
registrare le modifiche in modo permanente. Attendere come di consueto il messaggio di conferma
dell'avvenuta modifica.
6. Manuale dell'amministratore*
6.1 Le attività di manutenzione dell’amministratore
Il CFG è stato realizzato, come spiegato nei capitoli precedenti, per essere semplice da gestire. Non si
rendono pertanto necessari né interventi frequenti né particolari attività di manutenzione. Le uniche
procedure atte a garantire un buon livello di servizio e la sicurezza delle informazioni contenute sono
riportate di seguito.
6.1.1 Attività ordinarie
Il backup di un sistema è una delle attività che deve essere svolta frequentemente, ad esempio
utilizzando il tool visuale di Microsoft Backup. Attraverso tale software è possibile eseguire un backup
completo del sistema o aggiornarne uno fatto precedentemente (backup incrementale).
L'accuratezza delle politiche di backup e la frequenza di aggiornamento delle copie di sicurezza
devono essere direttamente proporzionali alla criticità dei dati inseriti e alla frequenza con la quale i
file vengono immessi nel catalogo. Se il sistema, una volta entrato a regime, richiedesse una frequente
attività di backup si potrebbe prendere in considerazione l’idea di sviluppare una procedura automatica
per le archiviazioni di sicurezza.
Le altre operazioni che devono essere eseguite con particolare frequenza, sono quelle che permettono
alla macchina (o alle macchine) sul quale “gira” il CFG di operare in buona efficienza. É quindi
opportuno ogni tanto: deframmentare il file-system, sostituire i file di log quando diventano di grandi
dimensioni, aggiornare i driver delle periferiche e così via.
Inoltre, è opportuno monitorare con una certa frequenza l’intensità di utilizzo del sistema. Questa
operazione può essere espletata visualizzando le statistiche presenti nella sezione “Utility” del pannello
laterale (6.2.3).
6.1.2 Attività straordinarie
Sebbene gli strumenti utilizzati per la realizzazione di questo sistema siano stabili e testati in modo
adeguato, può capitare che alcuni di essi presentino qualche piccolo errore (bug). In questi casi è
opportuno, per garantire la sicurezza, l’integrità dei dati e il corretto funzionamento del software,
aggiornare il componente. Bisogna, infatti, seguire le indicazioni che vengono rilasciate sui siti Web
dei relativi prodotti software le quali illustrano in dettaglio le operazioni per “migrare” da una versione
alla successiva.
In particolare occorre prestare attenzione agli aggiornamenti rilasciati per il sistema operativo perchè
fornisce la base, e quindi i presupposti, affinché l’intero sistema possa funzionare correttamente.
*
A cura di Gaetano Sberno
6.2 Struttura delle directory sul server
Gli accessi al sistema, e quindi all’albero delle cartelle della Figura 4.1, sono regolati dal meccanismo
di autenticazione di base di Apache. Le autorizzazioni vengono modificate agendo su specifici file
contenuti nelle directory stesse (i file .htaccess) nei quali sono indicati il tipo di autenticazione che è
utilizzato e il file dal quale viene prelevata la lista di utenti abilitati all'accesso.
Il processo di aggiornamento delle liste si esegue attraverso uno script PHP lanciato da un utente
sys_adm ogni volta che viene aggiornato o aggiunto un utente oppure quando l'utente cambia la
password. La procedura di nome aggiorna_utenti_apache(), contenuta nello script utenti.php, si
occupa proprio di aggiornare le liste e utilizza il tool messo a disposizione da Apache per creare gli
utenti. I file contenenti i permessi si trovano in ../Apache/user, hanno una struttura abbastanza standard
in ambiente Unix e contengono il nome dell'utente e la relativa password criptata. I file in questione
sono tre: all, sys_adm e utente con ovvi contenuti.
Ogni accesso al sistema è intercettato e registrato nel file di log di Apache (nella cartella
../Apache/logs). Le informazioni che vi sono contenute vengono poi utilizzate per produrre alcune
statistiche sull'utilizzo che gli utenti fanno del CFG e viene utilizzato, inoltre, per rilevare anomalie e
malfunzionamenti.
Nella cartella ../files (protetta mediante autenticazione) sono salvati tutti i documenti inseriti dagli
utenti. I file vengono salvati in una singola directory e sono fatti precedere dal time-stamp (momento
in cui sono salvati) per evitare conflitti di nomi.
Un'altra cartella molto importante è quella che contiene il DBMS e il database, aggiornato e
interrogato dagli script PHP, che si trova in c:\mysql.
All'avvio della macchina “partono” automaticamente Apache e MySlq configurati come servizi al
momento dell'installazione dei prodotti e il server FTP integrato in Windows 2000.
Il servizio ftp è sempre attivo e espletato dal modulo interno a Windows 2000. La root directory è
../Apache/sispa/files e l'accesso è consentito ad un solo utente per semplicità di gestione.
Per quanto riguarda il DBMS gli accessi sono gestiti dal motore di MySQL. Sono stati definiti due
utenti: root (l'amministratore del sistema di MySQL), e un altro utente generico utente_sispa al quale
sono consentiti l'aggiornamento e l'inserimento d'informazioni nella base di dati.
6.2.1 L'utente amministratore
L'utente amministratore può eseguire le operazioni consentite all'utente esterno e all'utente interno.
Inoltre all'amministratore è consentito gestire gli utenti e i permessi di accesso. Tutto quello che è stato
detto nel Capitolo 5, quindi, rimane valido anche per l'utente amministratore. Di seguito verranno
illustrate le procedure per la gestione degli utenti e per il monitoraggio del servizio.
6.2.2 La gestione degli utenti
La gestione degli utenti è una tra le operazioni più delicate. L'amministratore deve prestare particolare
attenzione in questa attività al fine di garantire una corretta e sicura utilizzazione dell'intero sistema. Di
seguito sono elencate alcune regole di buon comportamento per la gestione degli utenti del sistema:
• concedere le autorizzazioni strettamente necessarie;
• inserire username che descrivano l'utente;
• non disabilitare tutte le utenze amministrative (altrimenti non si potrebbe più accedere al
sistema e bisognerebbe cambiare i diritti di accesso alle directory manualmente);
• non cancellare mai un utente, al limite si può disabilitare (in questo modo si riesce a tenere
traccia della storia del sistema).
Figura 6.1 Maschera per l'inserimento di un nuovo utente
Inserire un nuovo utente
Per inserire un nuovo utente è necessario fare clic sul pulsante Nuovo Utente contenuto nella sezione
“Gestione Utenti” nel pannello laterale. Comparirà la maschera visibile in Figura 6.1
Una volta inserite le informazioni, premere il tasto Crea Utente ed attendere la pagina di conferma.
Visualizzare la lista degli utenti
Per visualizzare la lista completa degli utenti è necessario fare clic sul pulsante Lista Utenti contenuto
nella sezione “Gestione Utenti nel” pannello laterale. Comparirà la maschera visibile in Figura 6.2.
Figura 6.2 Lista degli utenti del sistema
Da qui è possibile visualizzare la lista degli utenti creati e le loro caratteristiche (adilitato/disabilitato,
tipo di utenza, username...). Facendo clic sull'icona sotto la colonna “Mod.” è possibile visualizzare la
scheda relativa all'utente e modificare alcuni parametri. La maschera della modifica è simile a quella
per l'inserimento di un nuovo utente: una volta effettuate le modifiche è necessario fare clic sul
pulsante Aggiorna Utente e attendere la conferma della modifica.
6.2.3 Utility
Questa sezione consente all'amministratore di tenere sotto controllo alcuni aspetti del sistema.
Statistiche sui Download
Le informazioni raccolte dai file di log di Apache vengono elaborate, attraverso apposite procedure, e
presentate all'utente sotto forma di tabella. Di seguito sono riportate le informazioni presenti nelle
statistiche sui Download:
File per utente e codice - per ogni utente sono visualizzati i file scaricati i byte trasferiti e altre
informazioni su i codici di ritorno;
Download per Host - per ogni Host/indirizzo IP sono visualizzati i file scaricati;
Download per utente - per ogni utente sono visualizzati i file scaricati;
Download per file - viene visualizzato il numero di volte che il file è stato scaricato (per ogni
file);
Download per codice - vengono visualizzati il numero di file per codice di ritorno del server
Web;
Totali - vengono visualizzati il numero di file totale e il numero di byte totali trasferiti.
In fondo alla pagina è riportata la tabella dei codici del server Web.
Statistiche sugli Upload
Le informazioni raccolte dal database sono elaborate e presentate all'utente sotto forma di tabella. Di
seguito vengono riportate le informazioni presenti nelle statistiche sugli Upload:
• Aggregazione per Indagine e Anno - per ogni indagine e anno è visualizzato il numero di file
presenti nel catalogo;
• Aggregazione per Indagine - per ogni indagine viene visualizzato il numero di file presenti nel
catalogo;
• Aggregazione per Anno - per ogni anno viene visualizzato il numero di file presenti nel
catalogo.
7 Bibliografia
[1] “Core PHP programming”, L. Atkinson, Prentice Hall, 2001
[2] “Web Application Development with PHP 4.0”, T. Ratschiller, T. Gerken, New Riders, 2000
[3] “Computer Networks (Third Edition)”, Andrew S. Tanembaum, Prentice Hall, 1998
[4] “Basi di dati e basi di conoscenza”, J. D. Ullman, Jackson, 1991
[5] “Java 2. I fondamenti”, Gary Cornell, Cay S. Horstmann, McGraw Hill, 1999
[6] “Java 2. Tecniche avanzate”, Gary Cornell, Cay S. Horstmann, McGraw Hill, 2002
[7] “Speciale: ASP vs JSP vs PHP”, Autori vari, Dev n°93 ed. Infomedia, 2002
[8] “Data Warehouse. Teoria e pratica della progettazione”, Matteo Golfarelli, Stefano Rizzi, McGraw,
2002
7.1 RFC (Request for Comments): Standard utilizzati in CFG
HyperText Markup Language 2.0 (HTML) - RFC 1866
File Transfer Protocol (FTP) - RFC 959
Hyper Text Markup Language 1.0 (HTTP) - RFC 1945
Hyper Text Markup Language 1.1 (HTTP) - RFC 2068
Multi-Purpose Internet Mail Extensions (MIME) - RFC 2045
An Extension to HTTP: Digest Access Authentication - RFC 2069
7.2 Siti internet (al 23/3/2005)
http://w3c.org/ sito del World Wide Web Consortium
http://www.rfc-editor.org/ Request for Comments
http://www.php.net/ sito ufficiale di PHP
http://www.apache.org/ sito ufficiale di Apache Software Foundation
http://www.mysql.com/ sito ufficiale di MySQL
http://java.sun.com/ sito ufficiale di Java
http://cesare.dsi.uniroma1.it/~reti/Reti1_html/welcome.html Corso Sistemi di Elaborazione: Reti I
(Università di Roma “La Sapienza” Dip. SMFN, corso di Laurea in Informatica)
http://cesare.dsi.uniroma1.it/~reti/Reti2_html/welcome.html Corso Sistemi di Elaborazione: Reti II
(Università di Roma “La Sapienza” Dip. SMFN, corso di Laurea in Informatica)
http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ sito di Javascript (Netscape)