Nel
settembre 2005 il gruppo di manutenzione del JCP ha
rilasciato una serie di modifiche alle specifiche delle
Servlet, che sono state riprese e discusse allinizio
di questanno, prima in un articolo di JavaWorld,
e poi su TheServerSide.com. Queste modifiche sono raccolte
sotto il JSR 154.
La questione che viene posta è la seguente: è
corretto che una versione di manutenzione, che avrebbe
dovuto portare piccole migliorie, sia poi cresciuta
fino a diventare una vera e propria versione delle API
per i contenuti dinamici per il Web? In altre parole,
le modifiche apportate valgono così tanto da
giustificare una nuova versione? Per provare a dare
una risposta a questa domanda è opportuno analizzare,
anche sommariamente, quali sono state le variazioni
effettuate.
Un taglio con il passato
Si può dire che le Servlet 2.5 diano un netto
taglio con il passato. Una delle modifiche principali
infatti è relativa allutilizzo delle annotazioni,
una delle funzionalità più recenti del
linguaggio Java (versione 5.0). Come si saprà,
questa permette di aggiungere marcatori al codice Java
che indicano al contenitore di seguire un determinato
comportamento. Le annotazioni non sono codice, ma marcano
il codice in modo che il contenitore alteri il proprio
comportamento di conseguenza. Il linguaggio stesso definisce
pochissime annotazioni, oltre ovviamente al fatto che
questi nuovi elementi sono supportati dalla sintassi.
Le annotazioni che è possibile utilizzare nel
codice sono infatti definite in JSR appositi. Un semplice
esempio di annotazione è illustrato nel listato
seguente, che non è altro che limplementazione
di un semplicissimo Web Service. Le annotazioni utilizzate
sono definite nel JSR 181:
import
javax.jws.WebService;
import javax.jws.WebMethod;
@WebService
public class HelloWorldService {
@WebMethod
public String helloWorld() {
return "Hello World!";
}
}
Caricando questa classe in un contenitore apposito,
che ne riconosca il significato, si ottiene un servizio
Web già pronto, senza la necessità di
codificare parti di codice che supportino SOAP.
In merito alle Servlet, lelenco delle annotazioni
non è ancora disponibili, ma le principali sono
le seguenti:
- @Resource
e @Resources permettono di eliminare il codice JNDI.
Marcando un campo con questa annotazione, il contenitore
si preoccupa di valorizzare la variabile con la risorsa
richiesta, prima che la Servlet venga attivata. @Resources
è come
- @Resource,
con la differenza che permette di gestire un vettore
di risorse.
- @PostConstruct
e @PreDestroy permettono di rendere metodi personalizzati
della Servlet parte del ciclo di vita. Sostanzialmente
consentono di definire metodi init() e destroy() alternativi.
Questi possono essere utilizzati per inizializzare
e distruggere risorse attivate tramite @Resource.
- @EJB,
@PersistenceContext, @PersistenceContexts, @PersistenceUnit
e @PersistenceUnits permettono di operare con EJB3.
In particolare la prima annotazione permette di valorizzare
un campo con un riferimento ad un EJB.
Tante
piccole modifiche
Oltre alla funzionalità più eclatante,
lutilizzo delle annotazioni, le nuove specifiche
includono una serie di modifiche minori:
possibilità di utilizzo di wildcard per il mapping
delle servlet e dei filtri.
Rimozioni di restrizioni per la gesitione degli errori
e per la gestione della sessione. In particolare, le
pagine di errore configurate in web.xml con il tag <error-page>
ora possono chiamare il metodo setStatus().
Chiarificazioni varie, relative alle intestazioni, allencoding
ed alle sessioni.
Ma lappettito vien mangiando, ed ancora adesso,
nella lista dei desiderata, sono presenti molte idee.
Purtroppo, la natura dellintervento sulle specifiche
è di pura revisione, quindi modifiche più
corpose sono state postposte, forse alla versione 3.0
delle specifiche. Bisogna anche notare che molto del
tempo dedicato allo sviluppo del JSR 154 è stato
dedicato ad assicurarsi che le specifiche funzionassero
bene con gli altri elementi di quel grande puzzle che
è Java EE 5.0.
Networking
ad altre prestazioni
Forse lelemento più essenziale che il gruppo
di sviluppo del JSR 154 ha dovuto rimandare alla prossima
versione delle specifiche è lutilizzo del
package NIO, le nuovi API Java per la comunicazione
asincrona.
La presenza della sola comunicazione sincrona è
stata sempre un cruccio per la piattaforma Java, che
le ha impedito di scalare facilmente le applicazioni
al fine di supportare un numero considerevole di utenti.
Il classico approccio un thread una connessione,
proposto nelle prime versioni dei server di rete scritti
in Java, infatti, ha il fastidioso problema di esaurire
presto nel risorse disponibili. Con NIO è possibile
ovviare a questo problema, ma ancora le Servlet non
ne fanno uso. E probabilmente non ne faranno uso fino
a Java EE 6.0.
Gli sviluppatori di Jakarta Tomcat hanno fatto un lavoro
eccellente nellimplementare il proprio Servlet
Contaniner senza utilizzare NIO, ottenendo comunque
performance di tutto rispetto, dato che questo software
open source è integrato in JBoss, che si propone
anche come strumento pronto per la produzione. Purtroppo
ci sono anche casi in cui questo non è sufficiente,
come nel caso della piattaforma di gaming condiviso
brasiliana MegaJogos. Altri containter, come Jetty,
hanno migrato a NIO principalmente per problemi di prestazioni.
Ma questo uso rimane dietro le quinte, perché
le API delle Servlet volutamente, per ora, non presuppongono
luso di NIO.
Conclusioni
La nuova versione delle specifiche delle Servlet è
interessante, ma lallineamento con la versione
5.0 del linguaggio significa anche due cose: in primis
lo sviluppatore può utilizzare tutte le caratteristiche
di questa versione del linguaggio. In altre parole,
lessere in presenza di un contenitore Servlet
2.5 significa automaticamente avere a disposizione la
versione 5.0 di Java. Quindi è possibile utilizzare
annotazioni, generici, boxing/unboxing, cicli migliorati,
ed altro).
Lo svantaggio è che le funzionalità delle
Servlet 2.5 non strettamente legate a caratteristiche
di Java 5.0 non saranno disponibili con runtime più
datati.
Come sempre, la scelta se saltare sul carrozzone delle
nuove specifiche o restare ancorati alle più
comprovate versioni precedenti è una decisione
che solo chi lavora sul proprio specifico progetto può
prendere. Ad ogni modo, sicuramente passerà del
tempo prima che le aziende si allineeranno alle nuove
versioni, e di conseguenza, nolenti o volenti, anche
noi dovremmo comportarci di conseguenza.
|