Free license available.

Database Relazionali & Internet

Integrazione Internet DB

a cura di: Alessandro Fiorenzi
Revisori: Prof. F.Pirri, Ing. M. Lunghi, Ing. C. Vestri

Introduzione

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.

Web: Un Modello Client Server

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:

Gestire il flusso e l'interazione tra Client e Server nel protocollo HTTP
Visualizzare il contenuto delle pagine Web richieste e le varie tipologie d'informazione grazie all'interprete dei tag HTML

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:

Rimanere in ascolto di richieste da parte di Client
Soddisfare al meglio ogni richiesta trasmettendo le pagine richieste col minor tempo di attesa possibile

Nonostante la semplicità dei compiti, la realizzazione di un server richiede:

Un accurato esame delle prestazioni, massimizzandone l'efficienza
Deve essere in grado di gestire concorrentemente più richieste.

Il Web essenzialmente si appoggia su tre standard:

Sistema di indirizzamento basato su URL
Linguaggio HTML
Protocollo HTTP

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.

Form:Finestra su i DataBase

Il Binomio Web-Database si realizza, mediante l'utilizzo delle FORM. Questa estensione del Web prevede:

sul client: la possibilità di offrire, nella pagina HTML, dei moduli, detti FORM, per immissione di dati e un meccanismo per l'invio di tali dati al server;

sul server: un meccanismo funzionale per consegnare i dati provenienti dalla form ad una applicazione che li gestisce e rende al client i risultati prodotti da tale applicazione.

Il processo realizza lo schema illustrato dalla slide. Ad esempio, supponiamo di trovarci in una situazione assai tipica

esiste una base dati interessante, ad esempio quella di una biblioteca;
si desidera consultarla via Web.

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:

campi testo;
radio button;
checkbox;
menù a tendina.

Il codice HTML che genera il modulo sopra visto è il seguente:

<HTML>

<HEAD><TITLE> ... </TITLE></HEAD>

</BODY>

<CENTER>

<H1>BIBLIOTECA DEI SOGNI</H1>

<H3>Modulo ricerca dati</H3>

<HR>

<FORM ACTION="http://somewhere.com/scripts/biblio.cgi">

Autore:<INPUT TYPE="text" NAME="autore" MAXLENGTH="64">

<P>

Titolo:<INPUT TYPE="text" NAME="titolo" MAXLENGTH="64">

<P>

<INPUT TYPE="submit"><INPUT TYPE="reset">

</FORM>

<HR>

</BODY>

</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:

due campi per l'immissione di testo;
due pulsanti, rispettivamente per l'invio dei dati e per l'azzeramento dei dati precedentemente immessi.

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;
le coppie sono separate dal carattere & 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:

i valori forniti dall'utente;
a quale programma deve consegnarli.

Nel nostro esempio il programma biblio.cgi avrà l'incarico di:

ricevere i dati dal server Web;
trasformarli in una query da sottomettere al gestore della base dati;
ricevere da quest'ultimo i risultati della query;
provvedere a confezionarli sotto la forma di una pagina HTML generata al volo;
consegnare tale pagina al server che la invia al client.

Naturalmente, il Server Web dovrà essere configurato per sapere dove trovare i programmi CGI.

CGI:Interfaccia Web-DB

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:

Script di shell (UNIX);
Perl, TCL;
C, Pascal, Fortran, Java;
AppleScript (MacOS).

Per la comunicazione dal server Web al programma CGI si utilizzano:

Variabili d'ambiente;
Standard input del programma CGI (solo con il metodo 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 client invia una richiesta contenente:
- identità del programma CGI;
- dati della form;
il server riceve i dati;
il server lancia il programma CGI e gli passa i dati;
il programma CGI estrae dai dati i valori immessi dall'utente;
il programma CGI usa tali valori per portare avanti il suo compito, che può essere ad esempio:
- aprire una connessione con un DBMS (anche remoto) ed effettuare una query;
- lanciare a sua volta un'altra applicazione, chiedendole qualcosa;
il DBMS (o l'applicazione) restituisce dei risultati al programma CGI;
il programma CGI utilizza tali risultati per confezionare al volo una pagina HTML, che restituisce al server;
il server invia tale pagina al client, che la visualizza sullo schermo.

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 .

Applicazioni in Rete Locale e 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:

Driver Nativi: Oracle, Informix, SyBase, O2, SQL Server, ecc..
ODBC
JDBC

Driver Nativi

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.

ODBC & JDBC

ODBC

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.

L'applicazione richiama le funzioni SQL per eseguire una interrogazione SQL e per acquisirne i risultati. il driver ODBC maschera il protocollo di comunicazione del DBMS, il S.O ove il DBMS è installato
Il Driver Manager carica, al momento in cui l'applicazione viene mandata in esecuzione, i driver di cui l'applicazione necessita
Il driver ODBC richiamato esegue le operazioni richieste dall'applicazione, traducendole in modo da adattarsi alla sintassi dello specifico prodotto, e consegna i relativi risultati
La fonte dell'Informazione è il sistema remoto che esegue le transazioni trasmesse dal client

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.

Ultimo Aggiornamento 23 Settembre 1998