Quando sviluppiamo per il Web, con Java, abbiamo a che fare con un Web server e nella maggior parte dei casi si tratta di Tomcat, che rappresenta quasi uno standard.
Non è infrequente commettere l'errore di definire Tomcat come Application Server, visto che la maggior parte delle volte i suoi servizi sono sufficienti a definire l'ambiente di esecuzione di una applicazione Web (sia essa Internet che Intranet). Vedremo in questo articolo il motivo per cui la definizione di Application Server è un errore, e cercheremo di definire le esigenze di sviluppo di un'applicazione, cioè quando realmente c'è la necessità di utilizzare un vero Application Server e non Tomcat.
Chi ha letto la guida su Java 2 Enterprise Edition ha visto, nel capitolo dedicato agli Application Server, che di fatto questi server rappresentano un modo di fornire dei servizi a più alto livello di un semplice Web Server.
Parlando a livello insiemistico, potremmo definire un Web Server come un sottoinsieme di funzionalità di un Application Server. Il set di tecnologie fornito da un AS è molto ampio e lo scopo di tante tecnologie è quello di fornire allo sviluppatore una serie di servizi (middleware) che facilitino compiti tipici di una applicazione enterprise, ossia un'applicazione che ha una serie di sorgenti informative che vanno al di là della semplice base di dati.
Tomcat non è un servizio fully compliant con la specifica JEE, cioè con tutte le tecnologie di cui sopra. Quindi Tomcat non può essere considerato un Application Server: ciò non significa che non sia un servizio valido, anzi, la maggior parte dello sviluppo trae beneficio da un sistema "più leggero". È vero anche che Tomcat va al di là della semplice definizione di Web Server, in quanto ha alcune caratteristiche Enterprise che lo fanno appartire come un AS mancato.
Elenchiamo alcune delle più comuni tecnologie enterprise e vediamo quali sono presenti nell'implementazione di Tomcat.
- JNDI*;
- JAAS;
- SOA*;
- JSP/servlet/JSF;
- JDBC;
- Cluster;
- Datasource*.
Questo set di tecnologie consente, di fatto, di avere un ambiente di esecuzione abbastanza completo, tipico delle applicazioni Web pure, con una semplice sorgente dati relazionale (un DBMS) e la gestione dei pool di connessione attraverso l'uso di datasource (anche se la loro funzionalità pecca abbastanza).
I servizi segnati con l'asterisco sono dei tipici servizi Enterprise (JEE) che funzionano con delle limitazioni relative al fatto che il servizio non è compatibile al 100% con la specifica JEE di Sun. Una cosa che potrebbe accadere è che il porting di quei servizi su un AS compatibile diano problemi.
Per quanto riguarda SOA, cioè la possibilità di creare ed utilizzare Web service, Tomcat lo effettua a livello Web tramite l'utilizzo di servizi di terze parti (il progetto Axis). Un application server, invece, lavora a livello enterprise, cioè utilizzando servizi più efficienti (il pooling di stateless session beans) per fornire un servizio più rapido o comunque più affidabile.
Su questo punto possiamo dire che lo stack del protocollo Web service di Tomcat è limitato e spesso non completamente interoperabile con linguaggi diversi da Java (soprattutto .NET) per un motivo di conversione e uso di alcune classi non supportate (anche la classe java.lang.String può creare problemi di interoperabilità). Lo stack protocollare di un application server è sicuramente più completo e permette una piena compatibilità ed efficienza (nonché rapidità) nel processo di costruzione del WSDL e del suo delivery.
I servizi di middleware e tecnologie elencate sono sufficienti allo sviluppo di una applicazione Web based avanzata e fortemente scalabile (tramite cluster) grazie alla tecnologie citate e alla base di JSE (Java Standard Edition), con cui gestire la logica comune.
Altra cosa che negli ultimi anni ha sfumato la reale esigenza di una tecnologia enterprise è l'utilizzo di middleware per la persistenza come Hibernate o Ibatis (mentre recentemente JPA è la persistenza suggerita nella specifica JEE). Con questi tool, costruiti su tecnologia standard, si ha la possibilità di poter fare a meno di middleware enterprise. In pratica, il middleware enterprise è stato affiancato da servizi di middleware "standard" costruiti in maniera standalone con il supporto di annotazioni e relativa semplificazione nella gestione di codice e configurazione.
D'altra parte, se la gestione della logica non si limita a semplici operazioni su dati relazionali, ma ha la necessità di interfacciarsi con sistemi esterni, deve appoggiarsi a middleware specifico come JMS o ottenere alte performance attraverso l'uso di EJB, allora il set di tecnologie di Tomcat non è sufficiente e abbiamo bisogno di un Application Server 100% compatibile. I servizi più comuni che utilizzeremo sono (da aggiungere a quelli citati in precedenza):
- EJB;
- JMS;
- JCA;
- JTA;
- SOA (JAX-RPC, SAAJ, JAX-WS);
- JPA;
- CORBA/RPC.
Il set completo di tecnologie è molto più ampio e spesso utilizzato in specifici domini applicativi. L'uso di queste tecnologie permette una più semplice gestione di connessioni verso sistemi esterni (tramite connettori JCA, Java Connector Architecture) o per l'utilizzo di middleware già esistente (JTA, per le transazioni multiple, JPA, per la persistenza, JMS, per un approccio asincrono). Sarebbe inutile preoccuparsi di servizi che già sono stati creati e pensati a tali scopi (nonché testati approfonditamente).
Se è bene utilizzare Tomcat, o un AS JEE compatibile, quindi, è una questione relativa al tipo di servizi di cui si fa uso. Di sicuro le risorse utilizzate da Tomcat sono minori rispetto ad un AS, visto che il set di tecnologie di cui si fa carico sono molto meno, quindi, un servizio Web non può che beneficiare di un ambiente di esecuzione meno carico. Un sito Web o una Intranet che non hanno esigenza (nemmeno in futuro, altro aspetto da tenere in considerazione è l'evoluzione dell'applicazione) traggono sicuramente più beneficio dall'utiilizzo di un sistema più leggero e più facile da amministrare.
A parte Tomcat esistono altri Web server java che possono essere utilizzati ma, di sicuro, Tomcat è il più usato in assoluto e non è il caso di soffermarsi sui motivi della sua scelta. Scegliere un Application Server può invece essere un'operazione più complessa in quanto sul mercato esistono diverse ottime soluzioni. Lasciando da parte le soluzioni commerciali (Oracle, Bea Weblogic, IBM Websphere) che generalmente sono scelte più "politiche" che altro, rimangono in piedi i due concorrenti open source che si giocano il resto della parte del mercato: Glassfish 2 e Jboss 5.
Con la versione 5, Jboss ha praticamente raggiunto la piena compatibilità con la specifica JEE 5. La versione precedente lo rendeva meno appetibile rispetto a Glassfish 2 (il primo a essere fully JEE 5 compliant) proprio per questo motivo. Di fatto, la possibilità di sviluppare EJB 3.0 tramite annotations è una caratteristica fondamentale per un application server di ultima generazione.
Ovviamente l'implementazione dei due sistemi è indipendente, e al momento non c'è uno studio comparativo tra essi per poter effettuare una valutazione in termini di performance (qui si gioca più sulle sensazioni relative all'esperienza nel loro utilizzo). L'unica vera differenza è la loro amministrazione.
Glassfish ha un'approccio più user friendly, con un'ottima interfaccia Web dove praticamente può essere fatto tutto in maniera abbastanza intuitiva. L'approccio di Jboss è più "sistemistico" con la configurazione del servizio tramite file di configurazione e hot deploy (presente anche in Glassfish, mediato da interfaccia). Altre piccole differenze esistono, ma sono dettagli abbastanza relativi tenendo in considerazione che il set di funzionalità è definito dalla specifica JEE.
