MokaByte 85 - Maggio 2004 
Tomcat 5.0
Panoramica d'insieme
di
Giovanni
Puliti
Nel dicembre dell'anno scorso è stato rilasciato il nuovo Tomcat 5.0 che subentra alla versione 4.1 e che introduce alcune interessanti novità. Non molte a dire il vero, visto che il nuovo progetto ha come scopo principale l'uniformazione delle piattaforme precedenti e la compatibilità all'indietro.
In questo articolo faremo una breve presentazione delle caratteristiche più interessanti del nuovo prodotto, rimandando ad altri articoli prossimi futuri la presentazione di argomenti più approfonditi.

Novità ed obiettivi
Il rilascio di una major version di Tomcat corrisponde all'aggiornamento del server con una nuova release delle specifiche Servlet e JSP: in questo caso il server si allinea alla release 2.4 della servlet API e la 2.0 della JSP.
Tomcat 5 introduce il supporto anche per alcune funzionalità proprietarie, come ad esempio il tag -plugin che non inficia però la portabilità delle applicazioni.
Il lavoro fatto dal comitato di sviluppo è stato principalmente quello di portare avanti il lavoro in modo da riunificate i due progetti precedenti, la versione 3 e la 4: sebbene Tomcat 4 è stato infatti presentato al pubblico come una evoluzione del precedente, la continuità fra i due prodotti risiede esclusivamente nel nome.
Il progetto Catalina, che rappresenta il kernel di Tomcat 4, infatti è frutto di una completa reingegnerizzazione del precedente e non ne mantiene praticamente nessun componente.
La versione 3 e la 4 sono profondamente divise sia per quanto riguarda la comunità degli sviluppatori che degli utenti finali.
Molto tempo dopo l'uscita della 4.0 i due gruppi di lavoro iniziarono lo sviluppo congiunto dei connettori Java lato Tomcat: il connettore JK2, quello per il protocollo HTTP ed altri.
L'occasione fu poi presa come spunto per procedere nella realizzazione della release successiva, portando ad un prodotto che di fatto per molte cose unisce il meglio dei due suoi predecessori.
Ad esempio la architettura di Tomcat 3 prevede che il servlet engine possa essere configurato tramite plug-in detti moduli. Questa organizzazione non è presente in Tomcat 4, che invece è basato su una logica completamente diversa. Tomcat 5, benché è stato progettato partendo dal core della 4, reintroduce il sistema dei moduli per il servlet engine, per permettere una maggiore modularità e flessibilità.

 

La servlet 2.4 API
Questa versione rappresenta una evoluzione minore della versione precedente, e di fatto da un punto di vista del programmatore finale tutte le applicazioni scritte per questa versione dovrebbero poter funzionare senza la necessità di particolari modifiche o adattamenti.
Certamente la modifica più importante introdotta con la API 2.4 che ha l'impatto maggiore su Tomcat 5.0 è il supporto per gli XML Schema che prendono il posto del DTD che invece rimarrà per le applicazioni basate su versioni precedenti della API.
La scelta da parte di Sun di usare gli Schema è volta ad offrire una maggiore flessibilità alla struttura e quindi alla capacità di configurazione delle web application.
Il resto delle modifiche alla API sono cose di piccolo conto, bug fixes e chiarimenti nella specifica di aluni metodi e classi; certamente un buon segnale questo per i programmatori che di certo non dovranno lavorare molto per utilizzare il nuovo engine, e che d'altro canto potranno contare su una API ormai stabile e matura.

 

Le JSP 2.0
In questo settore invece le modifiche alla API sono state molte e tante le novità introdotte. Fra tutte forse merita attenzione la possibilità di utilizzare l'Expression Language (EL) in Tomcat 5.0, così come la possibilità di usare Tag Files, funzionalità entrambe introdotte con JSP 2.0.
Particolarmente importante, per quei programmatori che ne fanno uso, il supporto per contenuti basati su XML tramite l'utilizzo dei file .jspx e .tagx
Non entreremo nel dettaglio di queste tecnologie dato che questo esulerebbe dagli scopi di questo articolo.
Tutte queste funzionalità, benché non esclusive di Tomcat 5, erano del tutto assenti nella versione precedente che si fermava alla JSP API versione 1.2.

Miglior gestione della memoria e pool di oggetti
Il grosso lavoro di refactoring che è stato fatto in Tomcat 5 ha portato ad un sensibile miglioramento della gestione della memoria e del ruolo quindi del garbage collector.
Una situazione tipica che si ha con i container di questo tipo è l'elevato numero di oggetti che vengono instanziati ma che tuttavia hanno una vita molto breve (si pensi agli oggetti creati per una request) e che in genere non sono riutilizzati.
Non sempre questo rappresenta un problema, se non in quei casi in cui il server sia molto caricato di lavoro, il garbage collector dovrà effettuare un lavoro più oneroso con conseguente impatto sulle prestazioni.
Apprfondito è stato il lavoro dei progettisti relativamente alla generazione di garbage memory. Ad esempio già nella 4.1 dopo un lungo lavoro di tuning e performance profiling fu scoperto che la pipiline request creava un eccessiva quantità di garbage memory durante il mapping delle request dal connettore verso il container.
Adesso in Tomcat 5.0 è stato introdotto un nuovo sistema di instradamento delle informazioni e mapping delle request tale da generare una quantità minima (o nessuna secondo quanto dichiarato nei documenti ufficiali) di oggetti di scarto.

 

Nuovo motore di deploy
Molto lavoro è stato effettuato per migliorare le procedure di deploy/undeploy/redeploy così come lo start/stop delle applicazioni.
Nella 4.1 la parte di configurazione esterna alla web application è contenuta nel file TOMCAT_HOME/conf/server.xml il quale contiene un singolo elemento <context> all'interno del quale in genere tutto veniva fatto. Ogni modifica a questo file richiede il restart del server.
Invece tutto quello che viene inserito nella directory TOMCAT_HOME/webapps viene letto dinamicamente al momento della modifica.
Questa separazione offre una buona possibilità di scelta al programmatore, ma può portare a confusione o difficile controllo della situazione. Inoltre un unico file di configurazione può portare a maggior confusione all'aumentare della dimensione e della complessità del contenuto (come quando ad esempio ci sono molte applicazioni in deploy).
Per offrire una maggiore pulizia ed ordine ma mantenere al contempo la separazione dei contesti, in Tomcat 5.0 adesso è possibile inserire porzioni di codice XML all'interno di file posizionati in sottodirectory della conf, secondo il seguente
schema

TOMCAT_HOME/conf/[engine-name]/[host-name]

dove engine-name rappresenta il nome dell'engine che si vuole configurare.
Ad esempio nel caso di Catalina e di un hostname www.mokabyte.it si potrebbe scrivere

TOMCAT_HOME/conf/Catalina/www.mokabyte.it/server.xml

Molti dei parametri di configurazione sono stati rinominati o è cambiato il loro significato per fare maggiore chiarezza. Ad esempio l'attributo liveDeploy del tag <Host> è stato rinominato in autoDeploy, mentre l'autoDeploy di Tomcat 4.1 diventa deployOnStartup.

Per un completo elenco dei nomi e dei cambiamenti si faccia riferimento alla documentazione ufficiale nella sezione relativa alla configurazione del server ([CONF]).
Infine da notare che è stato inoltre aggiunto un deployer standalone basato su script Ant

 

Session clustering
In Tomcat 5.0 è stato finalmente introdotto in bundle un sistema di clustering della sessione, cosa che mancava del tutto alla versione precedente, fatto eccezione un timido tentativo inserito in una vecchia versione del codice sorgente.
Adesso il sistema è stato completamente riscritto e può essere utilizzato anche come plugin per la versione 4.1 anche se è dichiarato che non verrà rilasciato in bundle con la tale versione.
All'interno della versione 5.0 nel file server.xml ci sono già una serie di istruzioni (commentate alla installazione) che permettono di configurare il clustering delle sessioni.
Maggiori apprendimenti possono essere trovati nel capitolo 10 del libro [TOMDEF]

 

Inoltre
La nuova versione include un nuovo sistema di pooling degli oggetti associati ai custom tag e tag library (detto tag pooling) che consente di riutilizzare oggetti già istanziati nella composizione di pagine JSP complesse e contenenti molti tag custom. Questo aspetto, con l'avvento di JSP 1.1 e delle tag library, sta diventando sempre più importante e cruciale per una buona risponsività delle applicazioni.
Il pooling di tag funziona nello stesso modo del servlet pooling, connection pooling o altro tipo di pooling. In particolare dato che i custom tag spesso non devono mantenere nessuno stato (stateless tags), è conveniente riusarli quando questi hanno terminato il loro compito, ovvero non appena dopo che la pagina è inviata al browser.
Un nuovo strumento è stato aggiunto a Tomcat 5.0, non derivante da nessuna specifica ufficiale JCP, ma proprietaria del server. Si tratta di un sistema di rendering JSP configurabile in maniera modulare a plugin tramite il quale è possibile ottimizzare il processo di generazione dell'HTML dinamico partendo dalle pagine JSP.
Il sistema si chiama "tag plugins" e maggiori informazioni possono essere ricavate presso la mailing list dedicata a Jasper2 l'engine JSP di Tomcat 5.0 ([JASP])

 

Altre modifiche
Nella nuova versione di Tomcat sono state introdotte molte altre modifiche che forse sono di minor interesse per lo sviluppatore di applicazioni web, essendo in questo caso Tomcat uno strumento di lavoro e non l'oggetto del proprio programmare.
Fra queste modifiche si annoverano un maggior supporto per JMX, ed un nuovo, più omogeneo e compatto sistema di build del server partendo dai sorgenti.
Per una maggiori informazioni a tal proposito si può far riferimento a [TOM5].
Infine con la nuova release è stata aggiunta una nuova web application, la Balancer Web App, che consente di effettuare balancing di applicazioni via HTTP e senza l'ausilio di nessuna conoscenza sistemistica o il supporto di costosi balancer hardware.

 

Conclusione
Anche se questo articolo non ha la pretesa di entrare in dettaglio su tutti gli aspetti legati al nuovo servlet-JSP engine, si può intuire l'importanza di questa nuova release.
Il grosso lavoro effettuato sulle performance e gestione della memoria paiono essere al momento probabilmente la novità più interessanti del prodotto.
Mi congedo con i lettori rimandando l'appuntamento ai prossimi articoli sull'argomento dove avremo modo di scoprire nel dettaglio i vari aspetti di Tomcat 5.0 e forse anche di effettuare un po' di test e di pubblicarne i risultati.

 

Bibliografia e risorse
[CONF] - Configurazione
Tomcat 4.1 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html
Tomcat 5.0 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html
[TOM5] - What's New in Tomcat 5 by Jason Brittain http://www.onjava.com/pub/a/onjava/2004/01/28/tomcat5.html
[TOMDEF] - "Tomcat: The Definitive Guide" By Jason Brittain, Ian F. Darwin
http://www.oreilly.com/catalog/tomcat/index.html?CMP=IL7015
[JASP] - Jasper2, framework for tag optimization
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg37186.html

MokaByte® è un marchio registrato da MokaByte s.r.l. 
Java®, Jini® e tutti i nomi derivati sono marchi registrati da Sun Microsystems.
Tutti i diritti riservati. E' vietata la riproduzione anche parziale.
Per comunicazioni inviare una mail a info@mokabyte.it