Tomcat: cos’è, come funziona e primo utilizzo

Anche se Internet si è diffusa presso il grande pubblico da poco più di dieci anni, esiste ormai da oltre trent’anni e in linea generale ha sempre funzionato secondo lo stesso criterio; in pratica, essa si basa sulla circolazione di informazioni tra terminali attraverso un "protocollo" (come per esempio il noto HTTP, (Hipetext Tranfer Protocol) seguendo il classico schema:

1. Richiesta da parte dell’utente tramite client (input).
2. Risposta da parte del server (output).

Inizialmente, per soddisfare le richieste inviate dagli utenti, venivano messi a disposizione contenuti "statici", niente di molto differente dalle comuni pagine di un libro.

Ben presto si presentò la necessità di produrre "dinamicamente" contenuti e di "automatizzare" i processi di comunicazione tra client e server. Per rendere chiaro il concetto espresso, basti pensare ai meccanismi che regolano i motori di ricerca interni dei siti web e i moduli per il "feedback" da compilarsi tramite form; in entrambi i casi, un’azione operata dall’utente tramite il proprio client genera delle reazioni/risposte da parte del server:

1. Trasmissione in output di contenuti capaci di soddisfare la richiesta sulla base dei parametri forniti (parole chiave).
2. Trasmissione e recapito dei messaggi inviati dagli utenti attraverso un "metodo" (Get o Post).

Come potete bene immaginare, gestire servizi del genere tramite contenuti "statici" non sarebbe faticoso, sarebbe praticamente impossibile.

La tecnologia Server Side CGI (Common Gatway Interface), si presentò come una risposta valida all’esigenza di superare i limiti imposti dalla "staticità" dei contenuti, in pratica, il compito di produrre output capaci di soddisfare "dinamicamente" e "automaticamente" le richieste dei client fu affidato ad un applicazione.

Senza addentrarci in particolari che esulano dagli argomenti attinenti a questa Guida, possiamo dire che le "Web Applications" basate su CGI funzionano in linea generale come qualsiasi altro programma, cioè generano comportamenti sulla base dei parametri indicati dall’utente.

Le CGI, soffrono però di alcuni svantaggi che caratterizzano molti programmi:

1. Pesano sul processore quando vengono eseguite.
2. Possono produrre output negativi (indesiderati o meno) a carico delle risorse che sono deputate a gestire o del sistema stesso.

Per quanto riguarda la prima problematica, questa diventa particolarmente rilevante per quanto riguarda le applicazioni orientate al Web che devono fare i conti con la possibilità di un alto "traffico" derivante da periodi di alta concentrazione degli utenti; aumentando le richieste, aumentano le esecuzioni simultanee dei processi e così anche il "carico di lavoro" sui processori, ciò causa non di rado rallentamenti e disservizi del sistema.

La seconda problematica non è meno grave: le applicazioni consentono non soltanto di gestire e generare risorse, ma anche di modificarle o addirittura di eliminarle in modo permanente. Così, non di rado, utenti tanto capaci quanto malintenzionati sono in grado di eseguire codice "malevolo" destinato ad intervenire negativamente sui contenuti, alterandoli o rendendoli indisponibili attraverso cancellazioni di dati o interruzioni di servizi indotte artificialmente.

Per risolvere questi problemi, la Sun Microsystem ideò le Servlet, cioè delle classi realizzate in linguaggio Java dotate di forma definita e richiamate con il compito specifico di generare dinamicamente in output i contenuti. Grazie alle Servlet, da una parte vengono superati molti i problemi di sicurezza propri delle applicazioni CGI, dall’altra il "carico di lavoro" dei processori è limitato dalla presenza di un Servlet Engine caricato in memoria che si occupa della gestione e dell’instradamento dei processi generati in seguito agli input degli utenti. Tomcat è appunto un Sevlet Engine sviluppato secondo le specifiche richieste per l’esecuzione delle Servlet in Java.

Come funziona Tomcat

Come anticipato nell’Introduzione, Tomcat è un Servlet Engine (chiamato anche Servlet Container o Servlet/JSP); è cioè un software capace di gestire "Web applications" scritte secondo le specifiche da utilizzare per il linguaggio Java della Sun Microsystem.

A ben vedere Tomcat, un programma open source della Apache Software Foundation nato in seno al cosiddetto "Progetto Jakarta", possiede molti tratti in comune con il suo "fratello maggiore": Apache. In effetti questo Servlet Engine è in tutto è per tutto un Web server in quanto interpreta le richieste provenienti dai browser dei client e provvede a generare dinamicamente i relativi output. Rispetto ad Apache, Tomcat ha però delle caratteristiche particolari che descriveremo in questo capitolo.

Digitando le URL, visualizziamo delle determinate "zone" controllate da un Web server, ogni "zona" in Tomcat prende il nome di Contesto e ogni Contesto fa capo oggetti definiti validi sia per il loro ambito di azione che per gli utenti che ad esso accedono. I Contesti non vengono generati sulla base di chiamate, ma "esistono" dal momento in cui parte il processo di Tomcat e come quest’ultimo "attendono" di rispondere alle richieste degli utenti senza mai arrestarsi.

Ad ogni utente viene affidato dal Web server un Contenitore "personale" detto Sessione caratterizzato dalle risorse a cui quel determinato utente ha la possibilità di accedere. All’interno di questa sessione e per tutta la durata del suo collegamento alle risorse gestite da Tomcat, l’utente potrà effettuare delle richieste sotto forma di input da soddisfare tramite risposte generate dinamicamente in output. Le richieste a loro modo sono dei Contenitori particolari, in quanto esistono solo nel lasso di tempo che separa l’invio della domanda e la fornitura della relativa risposta.

Chi conosce bene i meccanismi che regolano i Web server non avrà di certo notato consistenti novità nel criterio di gestione input/output appena descritto, per quanto riguarda i metodi possiamo invece osservare sostanziali particolarità: all’atto della richiesta, classicamente la digitazione di una URL tramite protocollo di comunicazione HTTP, viene lanciata l’istanza di un oggetto chiamato Request o Req, questo input porta il Servlet Engine ad istanziare un oggetto chiamato Response o Res come reazione "naturale" alla richiesta del client. Req e Res dovranno quindi essere dirottati verso il Contesto contenente le risorse utili a concludere la transizione in atto.

Oltre a Req e Res, Tomcat provvederà ad istanziare un ulteriore oggetto, Ses, riferito al Contenitore di Sessione, con il compito di identificare univocamente il richiedente e di controllare che la sua Sessione sia "aperta".

Ora entrano in gioco le Servlet a cui abbiamo fatto precedentemente riferimento nell’Introduzione, esse dovranno rendere "consistente" Res. In pratica il Contesto a cui appartengono le risorse necessarie per la soddisfazione della richiesta dovrà indirizzare queste ultime alla "Web application" Java necessaria al completamento della transizione. Nel momento in cui verrà generato l’output avremo tre esiti possibili:

1. La Servlet esaudisce la richiesta e lascia a Tomcat il compito di consegnare l’output al client (per esempio, sotto forma di ipertesto HTML).
2. La risorsa necessaria alla soddisfazione della richiesta non è presente nel Contesto utilizzato, dovrà quindi essere ricercata in un ulteriore Contesto esterno, questo compito verrà quindi affidato a Tomcat che riavvierà la procedura di input/output.
3. La richiesta può essere soddisfatta all’interno del Contesto ma non tramite la risorsa richiesta, dovrà quindi essere generato un Forward per il reindirizzamento verso la risorsa adeguata.

Installare JDK su Windows

Per poter creare un ambiente di sviluppo ottimale attraverso il quale sfruttare pienamente le potenzialità di Tomcat, dobbiamo innanzitutto procurarci la distribuzione ufficiale messa a disposizione dalla casa produttrice Sun per il linguaggio Java, cioè il J2SE SDK (Java 2 Standard Edition Software Development Kit), nota semplicemente come JDK. Grazie a questo strumento di sviluppo avremo a disposizione:

• Il compilatore di Java, cioè "javac.exe".
• "java.exe", la "virtual machine" per l’esecuzione dei programmi compilati.
• Tutte le librerie necessarie al funzionamento dell’ambiente di sviluppo.

Esistono, due distribuzioni principali del J2SE SDK: la gloriosa 1.4.2. e la più recente 5.0 (ad oggi giunta al quarto update); l’ultima versione ha incontrato alla sua uscita un discreto successo presso gli sviluppatori quindi per gli esempi riportati in questa guida potremo utilizzarla tranquillamente come riferimento.

JDK è un software freeware, quindi reperibile ed utilizzabile gratuitamente rispettando le clausole della "licenza d’uso". Scarichiamo la versione JDK 5.0 Update 4 da questo link.

Una volta letti i termini (Terms of Use) imposti dalla licenza esposti nella pagina web dell’area "Download" dovremo accettarli per poter procedere con lo scaricamento, per far questo spunteremo il radiobutton corrispondente ad "Accept" e cliccheremo su "Continue". Verremo ora trasferiti su una pagina in cui sono presenti le varie distribuzioni della JDK 5.0 destinate ai diversi sistemi operativi.

Per quanto riguarda Windows abbiamo due possibilità: "Windows Online Installation" e "Windows off line Installation": nel primo caso dovremo scaricare un piccolo eseguibile ("jdk-1_5_0_04-windows-i586-p-iftw.exe", 221.27 KB) che una volta avviato provvederà al download del software e a lanciare il "Wizard" d’installazione; nel secondo caso scaricheremo l’intero pacchetto d’installazione manuale ("jdk-1_5_0_04-windows-i586-p.exe", 56.71 MB) e noi dovremo provvedere all’avvio del setup.

In realtà, tranne qualche automatismo in più nel caso della prima opzione, non vi sono sostanziali differenze pratiche che incidano sul risultato finale. Per questa guida, abbiamo deciso di mostrare la procedura da utilizzare nell’installazione "off line", la maggior parte di coloro che leggono probabilmente non posseggono una connessione a banda larga, quindi sarà per loro più semplice procurarsi l’installer completo reperendolo su Cd rom o Dvd allegato a qualche rivista specializzata o facendoselo scaricare e masterizzare da qualche amico più "fortunato".

Una volta reperito il pacchetto d’installazione, per poter cominciare sarà bene chiudere tutti i programmi in esecuzione, in particolare i browser web che spesso agiscono in collegamento con l’ambiente Java; questo accorgimento diminuirà i rischi d’insuccesso dell’installazione e la probabilità di dover riavviare il sistema ad operazioni concluse.

JDK s’installa come la maggior parte degli applicativi destinati all’ambiente Windows, quindi, una volta esaurite le procedure preliminari, inizieremo con il classico doppio click sul file di setup scaricato in precedenza.

Ci apparirà una colorata schermata di benvenuto recante il famoso logo di Java che rappresenta una tazza di caffè fumante stilizzata, passeranno quindi alcuni secondi durante i quali l’installer rileverà la versione di Windows presente nella nostra macchina.

Il passaggio successivo sarà quello di accettare la licenza d’uso, come abbiamo detto JDK è un software freeware per il quale la casa madre concede il libero utilizzo previa accettazione di determinate condizioni; leggiamo quindi le clausole della licenza, spuntiamo la casella di accettazione e clicchiamo su [Next >].

Ci apparirà una schermata attraverso la quale potremo scegliere quali "features" di JDK installare e il percorso in cui vogliamo che il programma venga installato. Se siamo alle prime armi selezioniamo pure il "pacchetto completo", in questo modo potremo osservare a pieno tutte le funzionalità del Kit Java; per quanto riguarda la path d’installazione potremo lasciare invariata quella indicata di default dal programma ("C:\Programmi\Java\jdk1.5.0_04") o sceglierne una noi, ad esempio: "C:\Java\jdk1.5.0_04".

Ora comincerà la fase d’installazione vera e propria e il "Wizard" compierà autonomamente il suo corso fino alla sua ultima richiesta, cioè l’installazione dell’ambiente di runtime di J2SE (J2SE Runtime Enviroment) che consente di eseguire applicazioni realizzate utilizzando il linguaggio di programmazione Java.

Rispondiamo affermativamente alla richiesta cliccando su [Next >]; a questo punto ci verrà chiesto di selezionare i browser a cui associare la "Plug – In" di Java, selezioniamoli pure tutti.

Un volta cliccato per l’ultima volta su [Next >], l’installazione volgerà al termine e se tutto è andato per il meglio visualizzeremo un messaggio destinato a confermare che l’installazione è avvenuta con successo. Andiamo quindi su [Finish] e riavviamo il sistema qualora ci venga richiesto.

Installare JDK su Linux

Per quanto riguarda l’installazione di SDK in ambiente Linux, abbiamo la possibilità di scegliere tra due differenti tipologie di procedura: quella basata su un file binario auto-estraente e quella basata sul sistema Rpm.

Nel primo caso l’installazione risulterà leggermente più complessa, ma ci potremo avvalere di una procedura praticamente "universale", valida indipendentemente dalla distribuzione di Linux che stiamo utilizzando. Nel secondo caso, utilizzeremo un sistema più semplice, maggiormente automatizzato e basato su una tecnologia per la gestione delle installazioni chiamato Rpm, o RedHat Package Manager, molto diffuso presso le più conosciute versioni del Pinguino come Fedora (costola di Red Hat) e Mandriva (più nota al grande pubblico con il suo vecchio nome, Mandrake, recentemente modificato).

Dal sito ufficiale della Sun, casa madre di Java, cliccando per esempio su questo link, potremo accedere ad una pagina che mette a disposizione gratuitamente entrambe le versioni di SDK disponibili per Linux: la versione binaria viene indicata come "Linux self-extracting file" ("jdk-1_5_0_04-linux-i586.bin", 46.51 MB), mentre il pacchetto Rpm ha il nome di "Linux RPM in self-extracting file" ("jdk-1_5_0_04-linux-i586-rpm.bin", 44.78 MB). Naturalmente, come nel caso di Windows, anche per questo capitolo ci stiamo riferendo alle più recenti versioni di SDK disponibili al momento.

Cominciamo quindi col descrivere la procedura d’installazione basata sui file binari. Una volta scaricato l’auto-estraente, sarà necessario renderlo eseguibile, per far questo avvieremo la Shell di Linux e digiteremo la seguente riga di comando facendola seguire da un [Invio]:

chmod +x jdk-1_5_0_04-linux-i586.bin

Il comando chmod, nient’altro che un’abbreviazione di change modes, introduce l’opzione x (dall’inglese execute, "esegui") e setta sul file passato come parametro all’istruzione il "permesso" di esecuzione.

Ora, utilizzando il comando mv (abbreviazione di move), potremo posizionare il file d’installazione nella directory in cui intendiamo far risiedere SDK, per esempio "/usr/local/" se impersoniamo il root. L’istruzione da utilizzare sarà quindi:

mv jdk-1_5_0_04-linux-i586.bin /path/...

Un volta posizionato il "Linux self-extracting file" nella cartella prescelta, accederemo ad essa tramite la riga di comando:

cd /path/...

ed eseguiremo l’auto-estrante digitando

./mv jdk-1_5_0_04-linux-i586.bin

il punto "." che segue lo slash "/" all’inizio dell’istruzione, indicherà che l’esecuzione dovrà avvenire nella directory corrente. Verrà quindi creata una cartella, di default chiamata "j2sdk1.5.0_04", che conterrà tutti i file necessari per SDK.

Passiamo ora al sistema basato su Rpm, per il quale lavoreremo come utente di root. Una volta scaricato "jdk-1_5_0_04-linux-i586-rpm.bin", sarà sufficiente lanciare la riga di comando:

sh jdk-1_5_0_04-linux-i586-rpm.bin

Ora per permettere al sistema di eseguire applicazioni Java digiteremo:

export PATH=$PATH:/path/java/jdk -1.5.0_04/bin

e

export JAVA_HOME=/path/java/ jdk -1.5.0_04/

Controlliamo il successo dell’installazione con un

java -version

e attendiamo la risposta positiva del sistema.

Installare Tomcat su Windows

Nonostante il fatto che Tomcat, come quasi tutti i prodotti Open Source della Apache Software Foundation, sia stato originariamente pensato per ambienti Unix/Linux, fortunatamente non è stata ignorata la possibilità di implementare questo programma anche per Windows. Così avremo la possibilità di testarne gratuitamente e liberamente le potenzialità anche se non possediamo molta o alcuna dimestichezza col Pinguino. di implementare questo programma anche per Windows. Così avremo la possibilità di testarne gratuitamente e liberamente le potenzialità anche se non possediamo molta o alcuna dimestichezza col Pinguino.

Per installare Tomcat su Windows dobbiamo innanzitutto procurarci una distribuzione di questo software, andiamo quindi a colpo sicuro e colleghiamoci al sito ufficiale del "progetto Jakarta". Nella sezione "Downloads" troveremo tutte le versioni disponibili di Tomcat; per l’esempio descritto in questo capitolo abbiamo utilizzato il pacchetto di installazione "jakarta-tomcat-5.5.9.exe" disponibile su questo link.

Installare Tomcat è molto semplice, una volta reperito l’installer della versione 5.5.9, appena 4,29 MB, per cominciare sarà sufficiente un doppio click sul file di setup, ci verrà quindi mostrata una schermata di benvenuto che rappresenta il punto d’inizio della procedura d’installazione; cliccando su [Next >] verremo spostati sulla schermata contenete la licenza d’uso (License Agreeement) del software, dovremo leggerla con attenzione e poi cliccare su [I Agree] (letteralmente: "Sono d’accordo").

Una volta accettata la licenza d’uso ci verrà proposto di personalizzare la nostra installazione, potremmo quindi indicare al setup se desideriamo che nel nostro computer venga installato soltanto Tomcat oppure se preferiamo includere nella procedura anche:

1. la documentazione a corredo;
2. la creazione degli "Start Menu Items", utili per accedere più velocemente alle operazioni di configurazione, avvio e spegnimento del programma;
3. gli esempi di "Web Applications";
4. Webapps.

Installiamo pure il pacchetto completo selezionando tutte le opzioni disponibili o scegliendo "Full" dal menu a tendina indicato dalla richiesta "Select the type of install".

Ora clicchiamo su [Next >] e scegliamo la directory di destinazione del programma; di default il "Wizard" propone "C:\Programmi\Apache Software Foundation\Tomcat 5.5", ma noi potremo modificare tranquillamente l’impostazione, per esempio in "C:\ Apache Software Foundation\Tomcat 5.5", senza che ciò interferisca negativamente sul successo delle nostre operazioni. Una volta indicata la path desiderata clicchiamo pure su [Next >].

Comparirà ora una schermata in cui ci verrà richiesto di impostare: la "porta di ascolto" di Tomcat; la username e la password dell’admin. La "porta", di default viene indicata la 8080 che potremo benissimo lasciare immutata, indica il punto di ascolto in cui Tomcat attenderà gli input provenienti dagli utenti. Username e password sono a nostra assoluta discrezione e ci serviranno anche per loggarci nel "Manager" di Tomcat, argomento del quale tratteremo meglio in seguito. Una volta indicate tutte le voci richieste clicchiamo pure su [Next >].

Ora l’installer di Tomcat rileverà automaticamente la path in cui è installato SDK e tutto quello che dovremo fare sarà semplicemente confermare i vari passaggi del setup cliccando su [Install]. A questo punto comincerà la fase di installazione vera e propria, una procedura completamente automatizzata che non richiederà il nostro intervento se non nel passaggio finale in cui sarà necessario un click conclusivo su [Finish].

Se tutto srà andato per il meglio, Tomcat partirà automaticamente come servizio e potremo controllare il successo della nostra installazione aprendo il nostro browser preferito e digitando l’URL

http://localhost:8080

oppure

http://127.0.0.1:8080

verrà visualizzata una schermata di benvenuto che confermerà l’esito positivo delle nostre operazioni.

Installare Tomcat su Linux

Per terminare il nostro discorso riguardante le installazioni necessarie per la creazione di un ambiente di sviluppo basato su Tomcat, ci rimane soltanto da descrivere la procedura di setup in Linux di questo Servlet Engine.

Innanzitutto dovremo procuraci il software necessario, per far questo ci recheremo nella sezione "Download" del progetto Jakarta Tomcat e attraverso questo link raggiungeremo una pagina in cui potremo scaricare l’archivio compresso "5.5.9 tar.gz" contenente tutto il necessario per la nostra installazione.

Terminato il download del programma (appena 5.1 MB), dovremo innanzitutto spostare l’archivio compresso nella directory che abbiamo scelto per l’installazione, per esempio la cartella "/usr/local". Per far questo utilizzeremo il comando mv che abbiamo già sfruttato per l’installazione di SDK sul Pinguino; apriamo quindi la Shell di Linux e digitiamo la seguente riga di comando:

mv jakarta-tomcat-5.5.9.tar.gz /usr/local/

A questo punto sarà necessario decomprimere il file ".gz" e scompattare l’archivio ".tar" contenuto al suo interno, per raggiungere questo scopo potremo utilizzare un’unica riga di comando basata sul comando tar a cui passeremo come opzioni gli argomenti "-xvfz" in questo modo:

tar -xvfz jakarta-tomcat-5.5.9.tar.gz

Verrà creata una cartella contenente ogni file necessrio per il funzionamento del nostro Servlet Engine compresi tutti i file di configurazione.

Ora, terminata la fase d’installazione, sarà necessario dedicare qualche secondo alla configurazione di Tomcat. Dovremo infatti infatti impostare due variabili d’ambiente presenti nel file "profile" interno alla directory "/etc". In questo modo il Servlet Engine sarà in grado di individuare la posizione di SDK nel file system di Linux.

Con un qualsiasi editor di testo potremo digitare e salvare le seguenti istruzioni:

JAVA_HOME=/path per SDK export JAVA_HOME

e

TOMCAT_HOME=/path per Tomcat export TOMCAT_HOME

Il prossimo passaggio sarà quello di accedere alla directory "/bin" di Tomcat utilizzando il classico comando si spostamento cd:

cd jakarta-tomcat-5.5.9/bin

Una volta raggiunta la posizione indicata da Shell, potremo dare a Tomcat il comando di "startup":

./startup.sh

Per sinceraci riguardo al successo delle operazioni appena compiute sarà ora sufficiente avviare il nostro browser preferito e digitare l’URL della pagina di benvenuto di Tomcat:

http://127.0.0.1:8080

Come avrete avuto modo di notare, la procedura di installazione non presenta fasi particolarmente ostiche, l’unica vera difficoltà che potremmo incontrare potrebbe essere quella relativa alle indicazioni da dare a Tomcat sui giusti percorsi utilizzabili per reperire le risorse di SDK; per evitare lungaggini e frustrazioni da insuccessi sarà quindi necessario controllare la disposizione delle cartelle di SDK nel nostro file system Linux.

Operazioni di base: avvio, arresto e riavvio di Tomcat

Ora che conosciamo le procedure da seguire per installare sia in Windows che in Linux un ambiente in cui Tomcat possa far girare le applicazioni per la gestione delle quali è stato creato, cominciamo a osservarne il funzionamento attraverso le comuni operazioni di base valide per qualsiasi applicazione: avvio, arresto e riavvio.

Naturalmente, nei sistemi operativi di casa Microsoft avremo a disposizione un’interfaccia grafica per la gestione di Tomcat, mentre per quanto riguarda il Pinguino, descriveremo le stesse operazioni dal punto di vista della Shell attraverso delle righe di comando valide praticamente per tutte le distribuzioni.

In Windows, Tomcat funziona come "servizio in background", rimane cioè in attesa degli input provenienti dall’esterno senza che vi sia la necessità del continuo intervento di un operatore fisico. Una volta terminata l’installazione, Tomcat verrà lanciato ad ogni avvio del sistema e nella barra dei task comparirà un piccolo cerchietto con una freccetta al centro e la piuma dell’Apache Software Foundation in cima. Con un doppio click sul cerchietto potremo accedere ad una semplice interfaccia di configurazione che ci permetterà di agire sulle proprietà del nostro Servlet Engine.

Nel menu "General" di Apache Tomcat Properties, troveremo il nome del servizio (Service Name) che nel nostro caso sarà "Tomcat5". Un po’ più in basso vedremo un menù a tendina dal quale potremo configurare la sua procedura di avvio (Startup Type), avremo infatti tre opzioni tra cui scegliere: "Automatic", di solito imposta di default e responsabile della partenza di Tomcat all’avvio del sistema senza richiesta dell’operatore; "Manual", che se selezionata impedirà a Tomcat di avviarsi senza un’esplicita richiesta dell’operatore una volta stoppato; "Disable", che disabiliterà il servizio fino a nuovo ordine.

Immediatamente dopo lo Startup Type abbiamo la voce Server Status che potrà variare in "Started", se il servizio verrà avviato o "Stopped", se il servizio sarà arrestato; questi due status possono essere gestite tramite i pulsanti "Stop", che serve per interrompere l’attività di Tomcat e, "Start", con il quale potremo avviare e riavviare il servizio.

Analogamente, sarà possibile cliccare con il tasto destro sull’icona posta nella task bar e selezionare le voci "Start Service" o "Stop Service" con le quali ordinare all’Apache Service Manager le relative operazioni di avvio, arresto e riavvio.

Per Linux il discorso si fa, se possibile, ancora più semplice. Le operazioni di avvio e di arresto del processo che fa riferimento a Tomcat sono permesse da due file contenuti nella sotto cartella "/bin" della directory principale del Servlet Engine.

Quindi per avviare o arrestare Tomcat sarà sufficiente portarci nella sotto cartella che li contiene e richiamare da Shell l’esecuzione di questi due file:

./startup.sh

./shutdown.sh

Un’altra soluzione, sempre praticabile da riga di comando, è quella di richiamare direttamente il processo "/etc/rc.d/init.d/tomcat" affiancandogli i necessari argomenti. Quindi per avviare Tomcat digiteremo:

/etc/rc.d/init.d/tomcat start

Per riavviarlo scriveremo:

/etc/rc.d/init.d/tomcat stop

Infine, per riavviarlo lanceremo l’istruzione:

/etc/rc.d/init.d/tomcat restart

Ambito delle applicazioni Web in Tomcat

Dare una definizione esauriente di "applicazione" in campo informatico non è semplice e, il compito non viene certo facilitato limitando l’osservazione alle sole "Web Applications". In ogni caso, molti concetti possono essere chiariti osservando l’ambito e la struttura delle applicazioni sviluppate per poter funzionare sotto la gestione di Tomcat.

Perchè una "Web Application" possa essere eseguita correttamente dal Servlet Engine, è fondamentale posizionare i file da cui è composta mantenendo una struttura precisa che sarà contenuta nella cartella "TOMCAT_ROOT/webapps"; per conseguire questo risultato è possibile utilizzare differenti procedure, ma in questo capitolo descriveremo il sistema meno complesso, basato sul semplice inserimento attraverso il copia/incolla dei file appartenenti all’applicazione nella corretta disposizione richiesta da Tomcat

Il lavoro degli sviluppatori di "Web Applications" destinate a girare grazie a Tomcat, è fortunatamente reso più semplice da una disposizione standardizzata dei file e delle cartelle necessari per il funzionamento delle loro applicazioni; il loro ambito segue infatti un sistema gerarchico consolidato.

Si parte naturalmente da una directory principale, detta anche "radice" o "root directory" che per le "Web Applications" è convenzionalmente webapps. Se immaginiamo lo schema gerarchico delle applicazioni come un "albero", webapps ne sarà appunto la radice e il percorso che porterà ad ogni "ramo" di questa pianta dovrà necessariamente cominciare con il nome (context path) di questa directory.

All’interno della "root directory", avremo i diversi tipi di files, distinguibili grazie alle loro estensioni: comuni ipertesti scritti in codice HTML; file ".jsp" (Java Server Pages) preposti a produrre dinamicamente contenuti; immagini Gif e Jpeg. Il loro scopo è quello di permettere l’interazione dei "client" utilizzati dagli utenti con i contenuti dei server attraverso la mediazione di Tomcat. Non dimentichiamoci infatti, che è di Internet che stiamo parlando e, le "Web Applications", sono finalizzate allo scopo più importante per il quale è stata creata la Rete: consentire lo scambio di informazioni tra terminali sulla base del semplice meccanismo input/output, domanda e risposta.

Addentriamoci ancora oltre nella struttura delle applicazioni per il Web: all’interno di webapps avremo la cartella WEB-INF, destinata a contenere, tra gli altri, file non visualizzabili dai client per motivi inerenti la sicurezza del sistema. Si pensi, per esempio al file di configurazione web.xml, un documento XML (Extensible Markup Language) che permette a Tomcat di eseguire le Servlet per le "Web Applications" descrivendone percorsi, argomenti necessari per l’inizializzazione, nomi/alias… Per questa sua funzione di "consigliere" del Servlet Engine, web.xml è appunto definito come deployment descriptor.

All’interno della sub directory WEB-INF, troveremo altre due importanti sotto cartelle, utili per scopi simili ma secondo procedure diverse. Innanzitutto abbiamo la cartella classes in cui dovranno essere copiati i file dotati di estensione ".class", questi ultimi comprendono Servlet, classi Java e altri file necessari al loro corretto utilizzo. Perchè i file ".class" assolvano il loro compito dovrà essere dichiarato il percorso che porta ad essi; quindi una classe denominata "sitoweb.mysite.package.Servlet" dovrà corrispondere al percorso "/WEB-INF/classes/sitoweb/mysite/package/Servlet.class".

Nel caso in cui le classi Java siano state inserite all’interno di archivi Jar (Java Archive), come ad esempio i driver JDBC (Java Database Connectivity), non dovranno essere posizionate nella sub directory classes, ma nell’altra importante sotto cartella di WEB-INF denominata lib.

Testare Tomcat: dall’HTML alla nostra prima JSP

Ora che abbiamo installato Tomcat sulla nostra macchina e abbiamo descritto i meccanismi fondamentali del suo funzionamento, non ci resta che proporre qualche esempio per consentire al lettore di vederlo all’opera.

Come anticipato in precedenza, è sufficiente digitare nella barra degli indirizzi del nostro browser preferito la URL:

http://localhost:8080

in modo da accertarsi che la procedura d’installazione del Servlet Engine abbia avuto successo. A questo indirizzo verrà infatti visualizzata la "HomePage" di Tomcat recante il messaggio di benvenuto:

If you're seeing this page via a web browser,
it means you've setup Tomcat successfully.
Congratulations!

La "HomePage" corrisponde alla pagina "index.jsp" interna alla cartella "webapps/ROOT" della directory principale di Tomcat, sarà dunque in quella posizione che piazzeremo i nostri codici/esempio

Cominciamo con qualcosa di semplice, per esempio potremmo creare una paginetta ".html" e chiamarla "prova.html". Apriamo la con un qualsiasi editor di testo e scriviamoci un po’ di codice:

<html>
    <head>
        <title>Prova Tomcat</title>
    </head>
<body>

<h1>Prova</h1>

</body>
</html>

Ora apriamo il nostro browser e digitiamo in Url:

http://localhost:8080/prova.html

Verrà stampata a video la parola "Prova". Come avrete avuto modo di notare, il meccanismo input/output attraverso il protocollo di comunicazione HTTP tra client e Web Server funziona correttamente e la nostra richiesta tramite URL viene prontamente soddisfatta. Troppo semplice? Rendiamo allora le cose un po’ più complesse, ma soltanto in apparenza, e scriviamo la nostra prima pagina ".jsp".

Creiamo un’altra pagina chiamata "prova" ma questa volta diamole ".jsp" come estensione; apriamo il nostro nuovo documento con un editor di testo come il NotePad di Windows o Gedit in Linux e scriviamo:

<html>
    <head>
        <title>Prova JSP</title>
    </head>
<body>

<%
    out.println("<h1>La mia prima pagina in JSP</h1>");
    out.println("<h2>Funziona!</h2>");
%>

</body>
</html>

Testiamo la pagina digitando nella barra degli indirizzi del nostro browser l’URL:

http://localhost:8080/prova.jsp

e osserviamo il risultato.

Nel codice appena digitato, salta immediatamente agli occhi una prima particolarità, tutto il codice JSP presente nella pagina "prova.jsp" e racchiuso all’interno dei delimitatori "<%" e "%>" in queste poche righe:

out.println("<h1>La mia prima pagina in JSP</h1>");
out.println("<h2>Funziona!</h2>");

In esse è presente un’istruzione, out.println, che ha la stessa funzione dei costrutti print ed echo in PHP, cioè stampa a video la stringa che le viene passata come parametro.

Per il resto abbiamo soltanto puro HTML; JSP è quindi un linguaggio "Html embedded" e può essere può quindi "immerso" senza controindicazioni nel codice di una normale pagina Web con estensione ".jsp".

Il Manager di Tomcat

Terminiamo la nostra Guida sul Servlet Engine Tomcat con la breve descrizione di uno strumento, il Tomcat Web Application Manager, tanto semplice da utilizzare quanto comodo per il lavoro dello sviluppatore. Fino alle versioni precedenti alla 4.1, il "Manager" di Tomcat non era ancora disponibile e quindi solo recentemente chi affronta la realizzazione delle "Web Applications" e delle JSP seguendo gli standard Sun ha potuto trarne vantaggio.

Per accedere al "Manager" di Tomcat potremo digitare l’URL:

http://localhost:8080

e cliccare sul Link "Tomcat Manager" posto in altro a sinistra all’interno del menu "Administration". Oppure potremo digitare nella barra degli indirizzi del nostro browser preferito l’URL completa:

http://localhost:8080/manager/html

In entrambi i casi riceveremo una richiesta di autenticazione attraverso la quale ci verrà presentato un modulo da completare inserendo il nome utente dell’"admin" e la relativa parola chiave che abbiamo scelto in sede d’installazione.

Una volta inviati al sistema i dati corretti per esaurire la procedura di login, saremo condotti nell’interfaccia grafica del Tomcat Web Application Manager e potremo cominciare ad osservarne le numerose opzioni, che vanno dalla possibilità di consultare la documentazione in linea messa a disposizione dai fautori del progetto Jakarta fino agli utilissimi esempi di codice e ai report in tempo reale sullo stato del Servlet Engine.

Nella prima sezione, denominata semplicemente "Message" troveremo un laconico ma positivo messaggio: "ok", significa che per Tomcat tutto và per il meglio e che non abbiamo commesso errori durante la fase di installazione. Abbiamo poi il menu "Manager" attraverso il quale potremo visualizzare due utilissimi How-to.

Il primo, raggiungibile attraverso il link "HTML Manager Help", è il Tomcat Web Application Manager How To, in esso potremo trovare preziose informazioni e avvertenze riguardanti lo strumento di gestione che stiamo utilizzando; il secondo, a cui accederemo tramite il collegamento denominato "Manager Help", è il Manager App HOW-TO attraverso il quale potremo imparare ad intervenire sulle opzioni avanzate del "Manager".

Infine, sempre all’interno della sezione "Manager", troveremo il link "Server status" che ci permetterà di accedere ad una sezione grazie alla quale controllare i dati relativi ai dati di traffico, ai tempi di esecuzione e alla quantità di richieste e di risposte gestite da Tomcat.

Senza inoltrarci in argomenti che non riguardano specificamente questa Guida, ma piuttosto lo sviluppo di "Web applications", invitiamo comunque il lettore a consultare la sezione chiamata "Applications" con un particolare occhio di riguardo alla risorsa denominata JSP Samples. In essa sarà possibile visualizzare l’esecuzione e il codice sorgente di numerosi esempi di JSP messi a disposizione dalla Apache Software Foundation.