 |
Lo sviluppo di applicazioni su DataBase, in relazione all'ambito in cui l'applicazione produrrà i suoi frutti, richiede strumenti e modalità di accesso diverse.
Lo svuluppo di applicazioni destinate al mondo internet/intranet, si avvale di programmazione CGI o JAVA. Lo sviluppo di applicazioni in rete locale che non sia una intranet, impone l'utilizzo di strumenti diversi, legati a linguaggi di alto livello.
 |
Il Web è un sitema informativo di rete basato su un'architettura software di tipo client-server, con specifiche tipologie di software Client e di software Server.Il Client (o user agent) è lo strumento a disposizione dell'utente, tipicamente un browser, per la navigazione nel Web.
Il Client assolve le seguenti competenze:
I Browser gestiscono un numero limitato di tipologie d'informazione, tipicamente testo e immagini, per le altre si affidano ad applicazioni esterne (helper) per esempio per il playback di filmati, o a Plug-In, librerie di codice specializzato, che possono essere caricate in memoria all'occorrenza.
I Server sono strumenti software permanentemente in esecuzione su elaboratori, dedicati a specifiche funzioni. I loro compiti si riassumono in:
Nonostante la semplicità dei compiti, la realizzazione di un server richiede:
Il Web essenzialmente si appoggia su tre standard:
Nel tempo si sono ampliate le funzionalità richieste dagli utenti e si è incominciato a parlare di funzionalità estese del Web; accesso a DB, linguaggi script per il Web, Java e altro ancora.
 |
Il Binomio Web-Database si realizza, mediante l'utilizzo delle FORM. Questa estensione del Web prevede:
Il processo realizza lo schema illustrato dalla slide. Ad esempio, supponiamo di trovarci in una situazione assai tipica
Immaginiamo che si voglia presentare all'utente un modulo di ricerca in biblioteca di questo tipo (in una pagina HTML):
Esistono degli appositi tag di HTML destinati a creare simili moduli. è possibile includere:
Il codice HTML che genera il modulo sopra visto è il seguente:
<HTML>
|
Il tag <FORM ... > ha un parametro ACTION che specifica l'oggetto (ossia il programma) a cui il server dovrà consegnare i dati immessi dall'utente. In questo caso, vanno consegnati a un programma il cui nome biblio.cgi.
I tag <INPUT ... > definiscono le parti della form che gestiscono l'interazione con l'utente. In questo caso abbiamo:
Quando l'utente preme il bottone "Submit Query" il client provvede a inviare i dati al server, assieme all'indicazione dell'URL alla quale consegnarli.
I dati vengono inviati come coppie:
NomeDelCampo1=ValoreDelCampo1&NomeDelCampo2=ValoreDelCampo2 ecc.
dove:
NomeDelCampo viene dal parametro NAME;
ValoreDelCampo è la stringa immessa dall'utente in quel campo;
& e sono opportunamente codificate, se ci sono spazi e caratteri speciali.
La forma specifica del messaggio inviato dal client dipende anche da un altro parametro del tag FORM: oltre a ACTION=... c'è anche METHOD=... , che può essere:
GET, assunto implicitamente (come nel nostro esempio);
POST, che deve essere indicato in modo esplicito (questo è praticamente l'unico ambito nel quale è ammesso l'uso di tale comando).
Dunque, possiamo avere:
<FORM ACTION=".....">
<FORM ACTION="....." METHOD="get">
<FORM ACTION="....." METHOD="post">
Nel primo e nel secondo caso, la richiesta inviata dal client consiste nella specifica della URL alla quale vengono "appesi" i dati richiesti (con un punto di domanda):
GET /scripts/biblio.cgi?titolo=congo&autore=crichton&submit=submit HTTP/1.0
User-agent: ...
Accept: ...
...
<----- riga vuota
Nel caso del metodo POST, che in questo contesto è molto diffuso, i dati vengono rinviati nel corpo del messaggio:
POST /scripts/biblio.cgi HTTP/1.0
User-agent: ...
Accept: ...
...
Content-type: application/x-www-form-urlencoded
Content-length: 42
<----- riga vuota
titolo=congo&autore=crichton&submit=submit <----- dati della form
Il primo metodo è molto semplice, ma impone un limite al numero di caratteri che possono essere spediti. Il secondo invece non ha alcun limite, ed è da preferire.
Quando il server riceve la richiesta, da questa è in grado di capire:
Nel nostro esempio il programma biblio.cgi avrà l'incarico di:
Naturalmente, il Server Web dovrà essere configurato per sapere dove trovare i programmi CGI.
 |
Un programma CGI realizza un'interfaccia essenziale fra il Web e le basi di dati, definendo un Gateway fra Server (Common Gateway Interface).
Un programma CGI può essere scritto in qualunque linguaggio:
Per la comunicazione dal server Web al programma CGI si utilizzano:
POST: i dati della form sono inviati mediante pipe).
Molte variabili d'ambiente sono impostate dal server prima di lanciare il programma CGI; le principali sono:
| QUERY_STRING | La lista di coppie campo=valore (usata con il metodo GET) |
| PATH_INFO | Informazioni aggiuntive messe dopo l'URL (usate ad esempio con le clickable map) |
| CONTENT_TYPE | Usata con il metodo POST, indica il tipo MIME delle informazioni che arriveranno (application/x-www-form-urlencoded); |
| CONTENT_LENGTH | Usata con il metodo POST, indica quanti byte arriveranno sullo standard input del programma CGI |
In più ci sono altre variabili per sapere chi è il server, chi è il client, per l'autenticazione, ecc.
L'output del programma CGI deve iniziare con un breve header contenente delle metainformazioni, che istruiscono il server su cosa fare. Poi una riga vuota, quindi l'eventuale pagina HTML.
Le metainformazioni che il server prende in considerazione (tutte le altre sono passate al client) sono:
| Metainformazione | Valori | Significato |
| Content-type: | Tipo/Sottotipo MIME | Tipo dei dati che seguono |
| Location: | URL | File da restituire al client |
| Status: | OK, Error | Esito dell'elaborazione |
Ad esempio, supponendo di usare un linguaggio di programmazione nel quale sia definita un'ipotetica procedura println (String s) che scrive una linea di testo sullo standard output, un programma CGI che genera al volo una semplice pagina HTML potrà contenere al suo interno una sequenza d'istruzioni quale:
println("Status: 200 OK");
println("Content-type: text/html");
println(""); //linea vuota che delimita la fine delle metainformazioni
println("<HTML>");
println("<HEAD>");
...
println("</HEAD>");
println("<BODY>");
...
println("</BODY>");
println("</HTML>");
Viceversa, se il programma CGI vuole effettuare una URL redirection il codice eseguito potrà essere:
println("Status: 200 OK");
println("Location: /docs/index.html");
println(""); //linea vuota che delimita la fine delle metainformazioni
Dunque, la tipica catena di eventi è la seguente:
Il meccanismo delle CGI richiede un Server Web molto efficiente, per evitare rallentamenti, ma assicura un elevato livello di sicurezza, a dispetto di sistemi che utilizzano Java per interconnettersi ad un DB. Infatti, L'applet java che gira sul client s'interconnette direttamente al DB scavalcando il Server Web, questo naturalmente aumenta le performance, ma va a scapito della sicurezza del DB in quanto è l'applet che lavora direttamente sul DB .
 |
Lo sviluppo di applicazioni su database che non si appoggiano su una Internet o intranet, pone un serio problema di interoperabilità, problema che è stato risolto con i seguenti stumenti:
 |
Si possono sviluppare applicazioni che operano su una vastità di DB di produttori diversi, disponendo di driver nativi per l'accesso al DB di ogni specifico produttore, diversamente non sarà possibile l'interoperazione fra DB. Naturalmente ogni produttore avrà definito con suoi nomi, e con specifica sintassi, operazioni simili o uguali a quelle di altri produttori. Tutto ciò comporta aggravi di costi nello sviluppo di applicazioni. Infatti, dovendo operare su DB dei produttori A e B che implementano, per esempio, la SELECT con due sintassi diverse, nei programmi dovrei usare l'una o l'altra a seconda del DB con cui voglio lavorare. Naturalmente i driver nativi sono molto performanti.
 |
Lo standard ODBC Open DataBase Connectivity è una interfaccia applicativa proposta da Microsoft nel 1991 per costruire applicazioni eterogenee, supportate dalla maggior parte dei prodotti relazionali. Tramite driver ODBC, le applicazioni interagiscono con uno specifico server. ODBC uniforma la sintassi delle varie operazioni, e si fa carico di convertirle in quelle specifiche di ogni produttore, mascherando così i vari problemi di connettività, e rendendo molto agevole la produzione di software,La sua struttura si articola in quattro componenti, la cui cooperazione permette di accedere a Database remoti.
Sinteticamente potremmo dire che ODBC si compone di due parti: una, costruita da Microsoft, per gestisce il colloquio con i programmi applicativi, l’altra che e’ il driver vero e proprio, e’ realizzata dal fornitore del database per gestire l’accesso alla base dati. Grazie a questa soluzione si ottiene una forte uniformita’ nelle tecniche di accesso alla base dati rendendo di fatto l’applicativo indipendente dalla sorgente di dati stessa.
JDBC
L’architettura JDBC funziona allo stesso modo. In particolare, data la somiglianza con quella ODBC, esiste un particolare livello intermedio, chiamato JDBC/ODBC Bridge, che permette di usare un driver ODBC con applicazioni JDBC.
Perché allora, se il JDBC è così simile all’ODBC, non è stato utilizzato quest’ultimo?
Secondo gli sviluppatori della JavaSoft vi sono vari motivi. Intanto, affermano, l’ODBC è molto complesso, ha pochi comandi con molte opzioni, mentre l’architettura Java preferisce basarsi su una serie di metodi semplici e immediati da utilizzare, magari tanti, ma con pochi parametri. Inoltre, esso si basa moltissimo sull’utilizzo di puntatori a void e su altre caratteristiche del C che trovano scarso o nessun riscontro in Java.
Il pesante utilizzo di puntatori multipli o di tecniche basate su deriferimenti, rende troppo difficile importare tale architettura in Java. Comunque sia, le classi JDBC si sono aggiunte alle già svariate classi di Java, diventando ben presto un punto di riferimento fondamentale per chiunque voglia sviluppare applicazioni basate sui dati in questo linguaggio.
Ma quali sono i vantaggi delle classi JDBC?
Innanzitutto esse permettono di scrivere applicazioni Java che possono accedere a qualunque base dati semplicemente utilizzando istruzioni SQL, non solo quelle standard, ma di fatto anche qualunque estensione proprietaria sviluppata. Il tutto continuando ad avvalersi dei molteplici vantaggi del linguaggio Java, come la capacità di girare su qualunque piattaforma, la robustezza garantita dai meccanismi di sicurezza e dalla gestione delle eccezioni, la possibilità di operare in locale come in remoto dato dalle classi RMI. Il meccanismo è così flessibile che se uno sposta i dati da una base dati ad un’altra, deve solo cambiare il driver JDBC e l’applicazione continuerà a funzionare regolarmente con la nuova base dati. L’altro aspetto è che, nonostante il meccanismo del Driver Manager garantisca un’interfaccia comune a tutti i sistemi e le basi dati, la presenza di driver JDBC specifici per ogni base dati supportata garantisce un utilizzo ottimale delle caratteristiche specifiche di quella base dati.
Applet sì, applet no
In effetti, le classi JDBC sono usate principalmente con le applicazioni, ma possono essere impiegate anche in un applet.
In questo caso, tuttavia, risentono delle restrizioni tipiche delle applet scaricate da un sistema remoto. Per esempio, un applet che usa classi JDBC può aprire una connessione con una base dati remota solo se questa si trova sul server dal quale l’applet è stato scaricato. Inoltre, essa non può utilizzare in alcun modo informazioni presenti sul client. Persino il driver JDBC, qualora scaricato dal sistema remoto insieme all’applet, può funzionare solo con connessioni con lo stesso server dal quale è stato scaricato. Ciò significa che il server dovrebbe fungere sia da server Web sia da server dati, il che, spesso, è un po’ eccessivo in termini di carico.
Esistono vari modi di aggirare legalmente il problema, ma tutti si basano su un’opportuna riconfigurazione del server, cosa non sempre così semplice da fare. Un’alternativa potrebbe essere quella di utilizzare le classi RMI per collegare l’applet a un server intermedio il quale, utilizzando le classi JDBC, interagisce direttamente con la base dati. Tuttavia, si tratta di una soluzione che potrebbe creare problemi a livello di prestazioni.