G.Morreale
Introduzione:
Spesso sui forum si fà confusione riguardo all'uso di Glassfish o Tomcat, richiedendo se conviene usare uno piuttosto che un altro.
Guardando i log del blog spesso arriva gente che effettua proprio la ricerca "Glassfish VS Tomcat" oppure "Glassfish o Tomcat" oppure ancora "Glassfish contro Tomcat", quindi è chiaro che un newbie che si avvicina al mondo Java EE faccia un pò di confusione circa questa scelta.
La disputa è subito chiarita.. E' un confronto che non ha senso!
Glassfish è un Fuoristrada 4x4, Tomcat è un'utilitaria.
Se devo andare in città e in percorsi da "fuori strada" uso il 4x4 altrimenti se vado solo in città mi muovo con un utilitaria in quanto il suo uso è più agevole.
Tornando sugli aspetti tecnici..
Partiamo dal presupposto che la piattaforma Java EE è composta da diverse e diverse tecnologie: JSP, Servlet, JMS, MDB, EJB, JPA etc etc.(vedi http://java.sun.com/javaee/technologies/ )
Tomcat è in grado di supportare solo una piccola parte di Java EE, essenzialmente quella relativa alle JSP e alle Servlet, motivo per cui Tomcat è definito un Servlet Container.
nota:
Le JSP sono anch'esse delle servlet
Un Application server Java EE come Glassfish invece supporta per intero Java EE.
Glassfish (che nella sua versione commerciale con supporto sun si chiama Sun Application Server) è l'implementazione di riferimento per le tecnologie Java EE.
Ci sono comunque diverse alternative a Glassfish:
Il confronto Glassfish vs uno dei server nell'elenco ha più senso rispetto al titolo dell'articolo!!
Un Application Server è in grado di fare le stesse cose che è in grado di fare Tomcat, in quanto è anche un servlet container, motivo per cui spesso si trovano dei confronti di prestazioni tra le funzionalità comuni di Tomcat e Glassfish
http://raibledesigns.com/rd/entry/glassfish_2_vs_tomcat_6.
oppure
http://www.pneumonoultramicroscopicsilicovolcanoconiosis.org/blog/glassfish-vs-tomcat
)
Conclusione
Io personalmente preferisco applicare il ragionamento dell'esempio del fuoristrada vs utilitaria, nel senso che prendo dal garage l'auto il cui uso è più vicino alle esigenze del progetto.
Non è inoltre da escludere, in un architettura complessa, l'uso di entrambi i tipi di server, ad esempio tomcat per il front-end e glassfish per il back-end.
7 comments:
credo che questo articolo sia di una chiarezza e semplicità straordinaria!
erano giorni che cercavo una cosa del genere!
complimenti davvero bene fatto e, ovviamente, ben scritto ;)
... ora so che cose' veramente JavaEE!
una "metropoli enorme con un sacco di quartieri (serverlet) e periferie (application server) alcuni piccol, alcuni grandi, altri tranquilli, altri malfamati ecc... ecc.. ;D
correggimi se sbaglio la similitudine...
Grazie per i complimenti!!
Riguardo la similitudine una piccola correzione: le periferie sarebbero ad esempio gli EJB(che girano sull'application server).
Sei stato una salvezza, ho capito tutto!
Grazia, mi sarà sicuramente utile per i miei studi all'università!
Chiarissimo!
;D
>ad esempio tomcat per il front-end e glassfish per il back-end.
Scusa ma non mi è chiara ques'affermazione: perchè usare due application server diversi per front-end e back-end?
Essendo strettamente collegati, non si dovrebbe usare sempre un solo application server?
Se a Tomcat o ad un altro servlet container ci aggiungo framework com Spring, a mio avviso si riesce a fare tutto quello che fa un application server come GlassFish o JBoss.
L'idea è quella di partire da un utilitaria per farla diventare un suv all'occorrenza. Quello che non mi piace dell'approccio GlassFish è che ha tutto dentro, anche quello che non mi serve.
Post a Comment