Come integrare, in ambiente Linux, un server Web con un server SQL (cenni)
Di Roberto Vergallito
introduzione
Apache è un Web Server, cioè un software che deve essere in grado di ascoltare le richieste dei client (browser) e, se possibile, soddisfarle. Queste richieste riguardano, in genere, l'invio di contenuti statici (per esempio pagine html, immagini ) o dinamici (per esempio pagine html costruite a partire dai dati memorizzati in un DataBase). Il protocollo che definisce le modalità di scambio di documenti ipertestuali attraverso la rete Internet è HTTP ed Apache implementa perciò il lato server di questo protocollo.
Il nome Apache pare che stia per “a patched server” e nonostante il nome indichi un prodotto “corretto” è diventato il webserver più utilizzato al mondo e molti dei più famosi siti, anche commerciali, lo utilizzano per pubblicare i loro siti sul WEB.
È possibile installare Apache su molte piattaforme tra cui anche Windows ma il sistema di riferimento dove è nato e continua a svilupparsi è Linux.
Lo sviluppo di questo progetto (“Apache Project”) è portato avanti da un gruppo di sviluppatori (“Apache Group”). Chiunque può aderire a questa comunità che utilizza Internet come strumento di collaborazione a distanza . L'obiettivo di questo progetto è quello di realizzare una piattaforma robusta, modulare, integrabile con altri prodotti.
La prima release di Apache è stata rilasciata il primo dicembre 1995 e da allora continua ad essere il web server più utilizzato ( si veda http://www.netcraft.com/survey).
Il sito di riferimento per prendere visione del progetto, leggere e scaricare la documantazione, iscriversi alle mailing list, scaricare il prodotto, ecc. è www.apache.org.
La versione di Apache a cui facciamo riferimento è la 2.0.43, se il sistema Linux su cui lavoriamo è recente (diciamo successiva al 1 gennaio 2003) probabilmente procedendo ad una installazione completa del software avremo anche installato Apache versione 2.0.X altrimenti avremo la versione 1.3.X. In quest'ultimo caso vale la pena aggiornare il proprio Web Server alla versione 2.
Determinare se e quale versione è installata
Verifichiamo ora se nel nostro sistema è installato ed è funzionante Apache. Per prima cosa proviamo ad aprire uno browser che saranno stati installati sul nostro PC (Mozilla, Galeon, Netscape, ..) ed accediamo all'URL http://127.0.0.1, cioè alla macchina locale, se la risposta è la pagina di benvenuto di Apache allora vuol dire che qualche versione di Apache sta girando sul nostro PC. Se come risposta otteniamo un messaggio di errore allora vuol dire che Apache potrebbe essere installato ma non attivato oppure non installato. Analizziamo nel dettaglio queste tre possibilità.
Apache installato e funzionante:
Vale la pena capire quale versione è installata, il “nucleo” di apache consiste nei processi “demoni” httpd che saranno installati e, in questo caso, attivi sulla nostra macchina. Attivando il processo httpd con l'opzione -v si ottengono le informazioni sulla versione che stiamo utilizzando. Nel nostro caso il comando “httpd -v” genera questo output:
Server version: Apache/2.0.43 Server built: Feb 21 2003 16:10:13 |
Apache installato e non funzionante:
Se apache non risponde alle richieste dei browser allora potrebbe essere comunque installato sul nostro sistema, nel caso di utilizzo della distribuzione RedHat il comando “rpm -qa | grep httpd” ricerca tutti i pacchetti installati in cui compare la stringa 'httpd' e se Apache è installato potrete ottenere una risposta del genere :
httpd-2.0.40-8 httpd-devel-2.0.40-8 httpd-manual-2.0.40-8 redhat-config-httpd-1.0.1-13 |
Questo vuol dire che Apache è già presente sul sistema e deve solo essere attivato. L'attivazione può avvenire in molti modi, ma i principali sono : automaticamente al boot della macchina oppure manualmente. La partenza in automatico si può avere, per lo meno con RedHat, utilizzando l'utility “chkconfig” specificando l'opzione “-add” ed il nome del servizio da inserire nella lista di quelli attivabili (nel nostro caso httpd), quindi il comando sarà:
chkconfig --add httpd |
Questo comando tuttavia inserisce Apache nella lista dei servizi ma ancora non ne determina la partenza all'avvio. Il comando :
chkconfig httpd on |
farà partire Apache nei runlevel 2,3,4,5.
La seconda possibilità è di attivare apache con il comando:
apachectl start |
inserito nel file /etc/rc.local che va in esecuzione al boot del sistema. Se la partenza di Apache deve avvenire dopo altri servizi potrebbe essere utile adottare quest'ultima possibilità inserendo nel file /etc/rc.local l'attivazione dei servizi nell'ordine desiderato (per esempio nella nostra situazione prima si attiva Tomcat e poi Apache con due istruzioni in sequenza in rc.local)
In genere la configurazione di base di Apache è sufficiente per un suo utilizzo “standard” come web server, noi modificheremo qualcosa per permettere a diversi utenti di utilizzarlo come server web personale senza intralciarsi a vicenda e per permettere l'integrazione di Apache con l'application server Tomcat.
Apache non installato
se le due precedenti verifiche hanno dato esito negativo allora sul nostro sistema non è installata alcuna versione di Apache e dovremo procedere alla sua installazione e configurazione di base.
Ottenere ed installare Apache
Apache è scaricabile sia come sorgente che come eseguibile per diverse piattaforme. Il download può esere effettuato entrando nella sezione “download” del sito del progetto Apache: “www.apache.org”. Nel nostro caso caso abbiamo scelto di scaricare il formato sorgente per Linux. Nonostante l'utilizzo della distribuzione RedHat abbiamo utilizzato un archivio standard in formato “tar” e non il formato “rpm”. In realtà è stata una scelta obbligata perchè il modulo di Apache per integrarlo con Tomcat ( di cui parleremo più avanti) richiedeva la versione 2.0.43 che, in formato RPM, non era ancora disponibile.
Dopo aver scaricato Apache avremo sul nostro sistema il file “httpd-2.0.43.tar.gz” che decomprimeremo in una cartella temporanea con il comado:
tar xvfz httpd-2.0.43.tar.gz |
il risultato di questo comando è la scompattazione dell'archivio in una cartella che si chiamerà “httpd-2.0.43”.
In questa cartella vale la pena di leggere con attenzione sia il file README che il file INSTALL, comunque nel nostro caso l'installazione consiste dei seguenti comandi:
./configure --prefix=/usr/local/apache2 -enable-mods-shared=all make make install |
Il primo comando indica dove installare Apache (/usr/local/apache2) e dice di utilizzare tutti i moduli dinamici che apache mette a disposizione.
Il secondo ed il terzo comando compilano il codice sorgente e lo installano.
Con la distribuzione RedHat versione 8.0 non ci sono stati problemi di compatibilità con altri software e librerie.
Dopo questi comadi in /usr/local/apache2 è installato apache.
Attivazione di apache
Nella cartella bin dell'installazione è presente una shell “apachectl” che permette di attivare e fermare Apache, rispettivamente con i parametri “start” e “ stop”
Per fare in modo che Apache sia attivo alla partenz adel sistema inserire il comado nel file /etc/rc.local (come detto sopra)
Configurazione di base di Apache
Molte distribuzioni mettono a disposizione tool grafici per ottenere con pochi passaggi una configurazione di base ma perfettamente funzionante. Tuttavia spesso è necessario modificare direttamente con un editor di testo il file di configurazione di Apache. Nel nostro caso specifico dovremo accedere a tale file e modificarlo. Infatti sia la possibilità di fornire agli utenti una proprio spazio per pubblicare documenti html, sia la possibilità di integrare Apache e Tomcat non sono definibili attraverso l'interfaccia grafica.
La cartella contenente i file di configurazione si chiama “conf” ed è posta sotto la home directory di Apache (nel nostro caso /usr/local/apache2). Il file principale di configurazione è “httpd.conf” e qui vanno configurati i parametri di funzionamento del server.
Vediamo ora come configurare Apache affinchè sia in grado di distribuire i documenti che gli utenti avranno inserito in una directory all'interno della loro area di lavoro. Ciò è particolarmente interressante in un ambiente scolastico dove non possiamo dare agli studenti il permesso di memorizzare i loro file html nella cartella di default (/usr/local/apache2/htdocs). Nel file “httpd.conf”, in genere, compare una riga (di solito commentata) contenente la direttiva “UserDir public_html”, scommentando tale riga si permetterà ad ogni utente della machina di memorizzare i propri file html in una cartella che si dovrà chiamare “public_html” posta sotto la propria home directory (per esempio /home/studente1/public_html). Chiunque potrà accedere a questi file da un browser specificando l'URL : “http://nome-della-macchina/~studente1/index.html”.
Se si presentano dei problemi devono essere controllati i permessi di accesso alla cartella “public_home” ed alla home directory dell'utente (la home directory e la cartella public_html devono avere il bit 'x' di eseguibilità attivato)
Riprenderemo la configurazione di Apache quando avremo installato Tomcat sulla nostra macchina e dovremo integrarlo con Apache.
Introduzione
PostgreSQL è un sistema di DataBase Open Source, la sua affidibalità è paragonabile, se non superiore secondo molti, a quella dei sistemi commerciali.
Le caratteristiche fondamentale di PostgreSQL possono essere così riassunte:
In alcune scuole superiori l'utilizzo dei DataBase è consolidato sia sul piano didattico che su quello relativo alle attività di segreteria. Spesso si utilizzano DataBase “stand alone” (vedi MS Access) anche se il loro utilizzo in applicazioni commerciali di un certo livello è raro (si pensi anche solo a semplici applicazioni di rete che utilizzano pagine ASP e Servlet in cui molti processi/utenti devono accedere ai dati). Per le scuole l'utilizzo di un DataBase più professionale pone non pochi problemi economici. Infatti questi sistemi utilizzano un'architettura client/server e quindi oltre all'acquisto della licenza del DataBase si deve poi acquistare una licenza per ogni client che si connette.
La soluzione di utilizzare DB Server OpenSource offre il vantaggio di non dover affrontare alcun costo indipendentemente dal numero di client che si connetteranno al DataBase.
Attualmente l'ultima versione disponibile è la 7.3. Il sito di riferimento del progetto è “www.postgresql.org” da cui è possibile scaricare il prodotto sia in formato sorgente che in formato eseguibile.
Architettura del sistema
Come già accennato il sistema si basa su un'architettura client/server. Un processo server (“postmaster”) gestisce i dati, accetta le connnessioni ed esegue le operazioni richieste dai client. I client attraverso le applicazioni “frontend” richiedono la connessione al DataBase e l'esecuzione per la definizione dei dati e la loro manipolazione. Questi client possono essere di svariato genere: applicazioni testuali, grafiche, web server che inviano dati estratti da un DataBase, ecc.
La soluzione tipica consiste nell'avere il server ed i client distribuiti su una rete TCP/IP ma nulla vieta, ad esempio in fase di testing dell'installazione, di installare sulla stessa macchina sia il server che i client.
Installazione lato server
L'installazione e la configurazione di base del sistema non è particolarmente complicata . In questa sede tuttavia ci limiteremo alle operazioni minime per avere una sistema funzionante. Compresa nell'installazione c'è una documentazione completa e chiara in formato html (basta dare un'occhiata nella cartella “/usr/share/doc/postgresqlx.x.x).
Molte distribuzioni contengono già al loro interno PostgreSQL Server che potrebbe essere anche già installato. Se si utilizza una distribuzione RedHat e si è fatta una installazione completa allora PostgreSQL server sarà già installato, in caso contrario o si scaricherà da internet l'ultima versione stabile in formato rpm o sui CD di installazione di Linux si cercherà la versione disponibile (dalla versione 8 di RedHat attraverso l''interfaccia grafica per la gestione dei pacchetti risulta molto semplificata la procedura di installazione dei pacchetti aggiuntivi). Una precauzione da prendere è quella di non aggiornare il server pensando di mantenere i client con la vecchia versione, personalmente ho verificato che, ad esempio, la versione server 7.2.2 è incompatibile con i client 7.0.x.
Sulla macchina server ritengo valga la pena installare sia il lato server che quello client di Postgresql, in questo modo sarà possibile, per esempio, effettuare il testing della nostra applicazione.
Configurazione
Prima di qualunque cosa è necessario inizializzare l'area del DataBase sul disco creando quello che viene definito un “DataBase Cluster”. Un DataBase Cluster è un insieme di DataBase accessibili da un'unica istanza del server. Dopo la fase di inizializzazione questo cluster è costituito da un solo DataBase : “template1”. Il comando per effettuare l'inizializzazione è:
initdb |
Questo comando deve essere eseguito come utente “postgres” (questo utente viene aggiunto al sistema quando si installa Postgres)
Dal punto di vista del filesystem questo cluster corrisponde ad una sola directory dove vengono memorizzati i dati. Le directory tipicamente utilizzate sono : “/usr/local/pgsql/data” oppure “/var/lib/pgsql/data”. L'opzione -D del comando “initdb” permette di specificare questa directory.
Dunque la sequenza di comandi per la fase di inizializzazione potrebbe essere:
root# mkkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root#su postgres postgres$ initdb -D /usr/local/pgsql/data |
Dopo questa fase è necessario specificare che i client si connetteranno al DataBase attraverso TCP/IP (il default sono i socket di Unix) e definire i permessi di accesso.
La prima operazione nella versione 7.2.2 si ottiene scommentando nel file “/usr/local/pgsql/data/postgresql.conf” la riga “tcpip_socket = true”, la seconda richiede invece un'analisi attenta del file “pg_hba.conf” (postgres host base access control file).
Questo file definisce quali host possono accedere a quali database e specifica quali meccanismi di autenticazione utilizzare. Se non ci sono esigenze particolare si può definire che tutti gli utenti della nostra rete locale possono accedere e che sono utenti fidati. Supponendo che la nostra rete abbia indirizzo IP 192.168.0.0 per ottenere ciò inseriremo alla fine del file una riga simile a questa :
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE # host all 192.168.0.0 255.255.0.0 trust |
Altri meccanismi più sofisticati di autenticazione sono comunque disponibili (password, ssl, ecc.)
Attivazione del server
Ora possiamo attivare il server. Una prima possibilità, soprattutto per verificare se la nostra installazione è stata fatta correttamente, è quella di attivarlo manualmente con il comando:
postmaster -D /usr/local/pgsql/data > logfile 2>&1 & |
Questo comando va sempre dato come utente “postgres”.
Se si definisce una variabile di ambiente “PGDATA” come :
export PGDATA=/usr/local/pgsql/data |
si può evitare l'opzione -D del comando precedente.
Esiste un file di shell che permette di eseguire questa ed altre operazioni sul server. Il file è “pg_ctl” e le operazioni che permette sono: start, stop, restart, reload, status. Anche per questo comando vale il discorso sull'opzione -D o sulla variabile “PGDATA”.
Per esempio, sulla mia macchina, il comando:
pg_ctl -D /var/lib/pgsql/data status |
genera il seguente output:
pg_ctl: postmaster is running (pid: 858) Command line was: /usr/bin/postmaster |
Una volta verificato che il processo è partito senza problemi allora conviene attivare PostgreSQL al boot inserendo nel solito file “/etc/rc.local” una riga del tipo:
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data |
Creazione degli utenti
Senza entrare ora nei dettagli della gestione degli utenti (si rimanda alla documentazione di PostgreSQL) basti ora dire che gli utenti del DataBase sono slegati da quelli del sistema.
Come utente postgres si creano gli utenti di PostgreSQL con il comando:
createuser |
il cui output è il seguente (“prova” è il nome dell'utente di Postgres che si vuole creare)
Enter name of user to add: prova Shall the new user be allowed to create databases? (y/n) y Shall the new user be allowed to create more new users? (y/n) n CREATE USER |
Installazione lato client
Lato client come prima cosa dobbiamo verificare che non sia già installato PostgresSQL. Se non lo fosse lo installeremo ad esclusione del RPM del server (se per caso è già installato o lo rimuoviamo o è bene essere sicuri che non parta).
Una volta installato il lato client abbiamo già a disposizione una serie di comandi che ci permetteranno di collegarci al nostro DB Server e di inviargli delle richieste. Teniamo presente che, di norma, gli utenti saranno disposti sulle macchine client e attraverso una rete TCP/IP si collegheranno alla macchina Server su cui saranno memorizzati i loro DataBase. Vediamo ora alcuni comandi fondamentali.
Creazione/Cancellazione dei DataBase
Gli utenti possono creare i loro DataBase con il comando
createdb |
Se non viene specificato nessun nome il DataBase avrà lo stesso nome dell'utente. Un utente che lavora su una macchina client dovrà specificare l'host (opzione -h) dove creare il DB e, probabilmente, il nome del DB.
Quindi ipotizzando che uno studente voglia creare un DB con nome “miodb” sulla macchina server “serverlab” il comando di creazione saà il seguente:
createdb -h serverlab miodb |
L'utente sarà il proprietario di questo DB.
Allo stesso modo il comando “dropdb” permette di cancellare un DB.
Connessione ad un DataBase
il comado “psql” lancia un terminale interattivo che permette di connettersi al DB e di defirne la struttura e/o manipolare i dati attraverso il linguaggio SQL.
La sintassi del comando è la seguente:
psql -h serverlab miodb |
da questo momento si è connessi al DB “miodb” sul server “serverlab” e si può defirne struttura, permessi di accesso, eseguire query, ecc.)
Frontend Grafici per PostgresQL
Esiste la possibilità di utilizzare software OpenSource per avere un programma lato client che ci permetta di interfacciarci al DB per mezzo di un ambiente grafico evoluto.
Uno di questi programmi è “pgaccess” . Questo programma nelle versioni meno recenti di Linux RedHat faceva già parte della distribuzione ed era subito disponibile, ora invece deve essere scaricato da Internet, compilato ed installato. Queste operazioni, per lo meno nella distribuzione Red Hat 8.0, sono molto semplici e non generano alcun problema. L'unico intoppo potrebbe essere non aver installato i moduli delle librerie grafiche Tcl/Tk con versione 8.3 o superiore; in questo caso basta riprendere i CD di installazione di Linux e procedere alla loro installazione e dopo ricompilare pgaccess.
Il sito da cui scaricare pgaccess è http://www.pgaccess.org, il formato è un “tar” compresso che una volta scompattato (comando “tar xvfz ........ ) genera una cartella che contiene tutti i file per la compilazione, configurazione ed installazione ( è presente un README che con molta semplicità e chiarezza spiega cosa fare).
Dopo l'installazione basta aprire un terminale dall'ambiente grafico e lanciare il comando:
pgaccess -h serverlab miodb |
comparirà una finestra che ci permetterà di interagire con il nostro DataBase e che assomiglia molto ad altre applicazioni simili commerciali (frontend di SQLServer, Access, ecc.).
Come abbiamo visto Apache, utilizzando il protocollo http, offre la possibilità di distribuire ai client pagine html statiche. Sempre più spesso, tuttavia, i siti Internet devono offrire contenuti dinamici, cioè pagine il cui contenuto può dipendere da informazioni presenti in un DataBase.
Le possibili soluzioni per generare contenuti dinamici sono molte. Esistono soluzioni commerciali ( es. ASP di Microsoft) e soluzioni basate su Software OpenSource. Tra queste ultime una tra le più rilevanti è senza dubbio l'utilizzo di una categorai di prodotti che viene indicata con il termine di “Application Server”. Questi prodotti lavorano “al fianco” dei server web ed hanno il compito di intervenire e soddisfare le richieste del browser quando queste riguardano pagine dimaniche, cioè pagine che devono essere generate da programmi che, molto probabilmente, accederanno a DataBase. Questi programmi possono essere scritti in linguaggio “Java” e sono “ospitati” dall' Application Server “ che fornisce loro un ambiente di esecuzione.
Ovviamente il prerequisito per l'utilizzo di questi nuovi strumenti è una buona conoscenza delle caratteristiche di Java sia nelle sue funzionalità di “base” che per quanto riguarda le applicazioni “lato server” (realizzazione di JSP, Servlet).
Il nostro obiettivo è però ora vedere come installare e configurare un Application Server e come integrarlo con il Web Server.
Tra i prodotti OpenSource esistono alcuni Application Server di assoluto rilievo utilizzati anche in molte applicazioni commerciali. Tra questi il più famoso ed utilizzato è “Tomcat” sviluppato all'interno del progetto “Jakarta”. Tutte le informazioni su questo progetto sono reperibili sul sito : http://jakarta.apache.org, da cui è possibile anche scaricare i prodotto sia in formato sorgente che binario. Ne esiste anche una versione per Windows che si integra con il Web Server di Microsoft IIS. La versione a cui facciamo riferimento è una delle ultime: la 4.1.18.
Introduzione
Tomcat è un “Application Server” cioè un programma in grado di ospitare (eseguire) applicazioni scritte in Java. L'utilizzo tipico è quello all'interno una applicazione “Web” (es. commercio elettronico, prenotazioni on line, questionari on line, ecc.) in cui non basta la funzionalità tipica di un server web che invia pagine statiche al client. Ad esempio nel caso un utente si colleghi al sito di una libreria e voglia sapere se esistono libri che parlano di un certo argomento pubblicati in un certo periodo dovrà inviare la sua richiesta (tramite una pagina web) al server. Il server non avrà una pagina statica di risposta ma leggera la richiesta (argomento e periodo di pubblicazione), avvierà un programma che interrogherà una Base di Dati, cercherà le informazioni richieste, costruirà la pagina di risposta e la invierà al browser che ha fatto la richiesta. Tomcat è in grado di fare ciò, quindi può essere considerato una sorta di “aiutante” che è in grado di affiancare un web server tradizionale per fornire contenuti dinamici ai client. Tomcat comunque fornisce anche un web server tradizionale che viene attivato di default quando si installa il prodotto. Per non entrare in conflitto con altri web server già installati (Apache, IIS Microsoft, ecc) il web server di Tomcat lavora sulla porta 8080 del TCP.
Scaricare Tomcat
Tomcat può essere scaricato dal sito : http://jakarta.apache.org accedendo alla sezione download. Una volta scaricato il file in formato “tar.gz” basta decomprimerlo con il comando “tar xvfz .......” . La directory dove tipicamente viene decompresso è :”/usr/local” e la directory del prodotto è : “/usr/local/jakarta-tomcat-4.1.18”.
Installazione di Tomcat
Prima di vedere Tomcat all'oper aè necessario solamente definire due variabili di ambiente che il prodotto utilizza: JAVA_HOME e CATALINA_HOME.
JAVA_HOME indica la directory dove è installata la JDK (Java Developement Kit) che Tomcat richiede. Tomcat non ha una JDK sua, dobbiamo averne una installata; è probabile che sulla macchina sia già presente perchè, ad esempio, è installato un ambiente di sviluppo Java (Jbuilder, Sun One Studio, ecc.), in caso contrario basterà andare sul sito Java della Sun (http://java.sun.com) e scaricare una versione aggiornata, ma stabile, della JDK (attualmente siamo alla versione 1.4.1).
CATALINA_HOME invece deve indicare la directory dove abbiamo installato Tomcat.
Quindi per poter avviare Tomcat andremo nel file /etc/rc.local e aggiungeremo queste due righe:
export JAVA_HOME=\usr\local\jdk1.4.1 export CATALINA_HOME=\usr\local\jakarta-tomcat-4.1.18 |
Attivazione del server Tomcat
Ora basterà spostarsi nella sottodirectory “bin” dell'installazione e attivare la shell “startup.sh”. Se non si ricevono messaggi di errore (tipicamente dovuti all'errata definizione delle precedenti variabili di ambiente) Tomcat è attivo ed in attesa di richieste. Per verificarne il corretto funzionamento basterà aprire il nostro browser ed inserire nell'area relativa all'indirizzo il seguente URL : “http://127.0.0.1:8080” oppure : “http://localhost:8080” (come detto precedentemente il server web di Tomcat viene attivato sulla porta 8080 del TCP).
Dalla pagina iniziale è possibile accedere a tutta la documentazione sul prodotto ed agli esempi di utilizzo di Servlet e JSP.
Configurazione di Tomcat per l'utilizzo di Postgres
Questi argomenti richiederebbero una trattazione approfondita ma per mancanza di tempo forniamo qui solo qualche indicazione di massima.
Introduzione
Come abbiamo già detto Tomcat è un Application Server che offre la possibilità di eseguire applicazioni Java lato Server, tecnicamente appartiene a quella categoria di prodotti che si definiscono Servlet Container. In realtà Tomcat può essere utilizzato anche come Web Server, anche se le sue funzionalità non sono paragonabili a quelle di Apache (per esempio non supporta PHP). In una prima fase è senza dubbio vantaggioso sfruttare questa possibilità e costruire le nostre prime applicazioni web in Java utilizzando Tomcat sia come web server che come application server. A questo proposito ricordiamo che dopo l'installazione di Tomcat sulla porta 8080 è già possibile interrogare il server web che risponderà con una pagina di benvenuto e dando la possibilità di vedere la documentazione in linea, di utilizzare l'applicazione web preinstallata relativa al gestore delle applicazioni web e quella relativa al gestore del server stesso.
Accesso a DataBase da Tomcat
La realizzazione di applicazioni Java eseguite all'interno di Tomcat che si interfacciano con Postgres non richiede particolari configurazioni in Tomcat a meno che non si vogliano utilizzare i meccanismi di connection pooling . Per ora però analizziamo il caso più semplice di un'applicazione che gestisce completamente al suo interno la connessione al DB. Come già detto Tomcat non deve fare molto perchè sarà la nostra applicazione Java che dovrà utilizzare il package java.sql per aprire la connessione al DB e effettuare le query SQL. L'unica operazione da fare è copiare il driver JDBC del DataBase che utilizzeremo (PostGres, MySQL, ecc) all'interno della directory di Tomcat destinata a contenere le librerie che tutte le applicazioni web utilizzano. Nel caso di Postgres versione 7.3 copieremo il file pg73j2ee.jar nella sottodirectory common/lib della home directory di Tomcat.
Se non si vuole o non si hanno i permessi per inserire i driver JDBC in questa directory è sempre possibile memorizzarli all'interno della nostra applicazione WEB nella directory WEB-INF/classes/lib.
Nel caso in cui l'applicazione voglia utilizzare un pool di connessioni al DataBase allora la configurazione di Tomcat è più complessa e richiede di modificare il file di configurazione di Tomcat stesso : server.xml. Brevemente possiamo dire che questa tecnica si basa sul principio di lasciare che l'application Server apra un certo di numero di connessioni al DataBase prima che l'applicazioni le utilizzi e le fornisca all'applicazione quando questa, utilizzando il package sql esteso javax.sql, ne fa richiesta.
È possibile integrare ulteriormente Tomcat ed un DataBase configurando Tomcat in modo che gestisca una eventuale accesso ad aree riservate (Realm) ricercando username e password non all'interno del file standard degli utenti users.xml ma all'interno di una tabella del nostro DataBase.