Introduzione al Servlet Engine Tomcat

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.

• << Lezione Precedente
• Indice Guida
• Lezione Successiva >>