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:
- La Servlet esaudisce la richiesta e lascia a Tomcat il compito di consegnare l'output al client (per esempio, sotto forma di ipertesto HTML).
- 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.
- 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.
