Il progetto
al comune di Pisa
Ho sviluppato le seguenti
componenti Java:
·
Applet
·
Applicazione “proxy”
·
Applicazione “server”
·
Applicazione “database”
Le tre applicazioni Java sono demoni che girano su tre macchine differenti
(www-server, firewall e PC con database residente, rispettivamente).
L’applet
viene scaricata dal web-server come pagina html e contiene la form da compilare
per l’accesso alle informazioni le quali passano attraverso le tre applicazioni
fino al database e ritornano al browser del client collegato.
I
collegamenti tra le varie componenti sono state realizzate tramite i socket
Java.
L’accesso al database, locale per l’aplicazione
“database”, avviene tramite JDBC e in particolare tramite il bridge JDBC-ODBC,
essendo il database di tipo MS Access.
Applet
La
scelta di un’applet piuttosto di una semplice pagina html è stata fatta per
poter gestire meglio sia la form che i risultati.
Questi
ultimi sono di due tipi:
1.
Informazioni generali
sul verbale della multa (dati alfanumerici)
2.
Immagine del verbale
della multa (se richiesto)
Dopo
essere stata compilata la form, l’applet avvia una connessione socket con
l’host da cui è stata scaricata, manda i dati e attende i risultati, prima gli
alfanumerici e poi, se richiesto dall’utente, l’immagine.
L’applet
non può collegarsi direttamente al database perché il web-server si trova nella
rete esterna mentre la rete interna, dove risiede il database, è protetta da un
firewall che non lascia entrare niente.
I
motivi per cui l’applet non si collega direttamente all’applicazione “server”
sul firewall sono esposti in www.cli.di.unipi.it/~fratini/Tesi/ProgettoComunePisa.html
nel paragrafo “Restrizioni di sicurezza
sulle applet”.
Applicazione “proxy”
L’applicazione
proxy è necessaria per i motivi sopra speciificati riguardo le restrizioni di
sicurezza sugli applet.
Quest’applicazione
non fa altro che passare i dati ricevuti dall’applet all’applicazione “server”
e ritornare i risultati.
E’
un demone che gira permanentemente sulla SUN che funge da www-server e ascolta
le connessioni via socket da una specificata porta. Per ognuna di esse fa
partire un thread che inizia la cannessione tramite un altro socket su un’altra
porta con l’applicazione “server”.
Applicazione “server”
Anche
questa applicazione è un demone e gira sul PC (S.O. linux) implementato come
firewall.
Ascolta
le connessioni provenienti da parte del “proxy” e in multithread si connette
all’applicazione database e ritorna i risultati.
L’accesso
al database potrebbe avvenire in maniera remota e senza l’implementazione
dell’applicazione “database”, utilizzando dei driver JDBC di tipo 4. I driver
di questo tipo per il database MS Access andrebbero però acquistati (Intersolv,
ecc…) mentre il driver di tipo 1 (accesso ad un data base residente sfruttando
ODBC), denominato bridge JDBC-ODBC, è disponibile con il JDK 1.1.x versione
WindowsNT/95. Inoltre, tali driver, non potrebbero sfruttare ODBC poiché non
supportato da linux.
Applicazione “DataBase”
Questo
demone gira su un PC con Windows NT ubicato nella rete interna del Comune di
Pisa.
Questa
applicazione ascolta le connessioni su una determinata porta, avvia le
connessioni al database residente, fa le query, gestisce i risultati e li
rimanda al “server”.
Il
database era inizialmente un INFORMIX con motore SE versione 5.5 residente su
un NETSTRADA 7000 con S.O. SCO Unix; data però l’incompatibilità del database
con Java e con qualsiasi tipo di middleware e considerato il fatto che i dati
del database sono statici, abbiamo relizzato un report portando i dati sul
database MS Access in questione.
Gestione delle immagini
Le
immagini dei verbali delle multe, che sono in formato Tif, in un box di Cd-Rom
gestito da un ulteriore PC (Windows NT?) ubicato nela rete interna.
Per
essere caricate sul browser dell’utente verranno convertite in formato gif o
jpeg al momento della richiesta tramite un convertitore per linux o solaris.
Il
path per accedere alla singola immagine verrà trovato in un campo del database
sopra citato.
Il
trasferimento dell’immagine verso il browser sarà compito di un thread
(dell’applicazione “server”?).
Non
so ancora se far caricare l’immagine dall’applet prendendola da quache zona
della rete esterna (o dal firewall stesso) dove viene temporaneamente
memorizzata (problemi di sicurezza) oppure vedere se esiste un modo per cui
l’applicazione passa direttamente l’immagine come file all’applet che la
visualizza sul browser dell’utente.