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:
- Richiesta da parte dell'utente tramite client
(input).
- 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:
- Trasmissione in output di contenuti capaci di soddisfare la richiesta
sulla base dei parametri forniti (parole chiave).
- 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:
- Pesano sul processore quando vengono eseguite.
- 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.
(Articolo concesso in esclusiva a
Mrwebmaster.it; ne è vietata la riproduzione senza il consenso
dell'autore e di
Mrwebmaster.it.)