Qual è la differenza tra Tomcat, JBoss e Glassfish?

Sto iniziando a esaminare Enterprise Java e il libro che seguo menziona che utilizzerà JBoss. Netbeans viene spedito con Glassfish. Ho usato Tomcat in passato.

Quali sono le differenze tra questi tre programmi?

Tomcat è solo un contenitore servlet, ovvero implementa solo le servlet e le specifiche JSP. Glassfish e JBoss sono server Java EE completi (inclusi elementi come EJB, JMS, ...), con Glassfish come implementazione di riferimento dell'ultimo stack Java EE 6, ma JBoss nel 2010 non lo supportava ancora del tutto.

Tomcat è semplicemente un server HTTP e un contenitore servlet Java. JBoss e GlassFish sono server di applicazioni Java EE completi, incluso un contenitore EJB e tutte le altre funzionalità di quello stack. D'altra parte, Tomcat ha un ingombro di memoria più leggero (~ 60-70 MB), mentre quei server Java EE pesano a centinaia di mega. Tomcat è molto popolare per semplici applicazioni Web o applicazioni che utilizzano framework come Spring che non richiedono un server Java EE completo. L'amministrazione di un server Tomcat è probabilmente più semplice, poiché ci sono meno parti mobili.

Tuttavia, per le applicazioni che richiedono uno stack Java EE completo (o almeno altri pezzi che potrebbero essere facilmente collegati a Tomcat) ... JBoss e GlassFish sono due delle offerte open source più popolari (la terza è Apache Geronimo , su cui è costruita la versione gratuita di IBM WebSphere). JBoss ha una comunità di utenti più ampia e più profonda e una base di codice più matura. Tuttavia, JBoss è notevolmente indietro rispetto a GlassFish nell'implementazione delle attuali specifiche Java EE. Inoltre, per coloro che preferiscono un sistema di amministrazione basato sulla GUI ... La console di amministrazione di GlassFish è estremamente fluida, mentre la maggior parte dell'amministrazione in JBoss è fatta con un editor di riga di comando e di testo. GlassFish arriva direttamente da Sun / Oracle, con tutti i vantaggi che può offrire. JBoss NON è sotto il controllo di Sun / Oracle, con tutti i vantaggi che può offrire.

È necessario utilizzare GlassFish per le applicazioni enterprise EE Java . Alcune cose da considerare:

Un server Web significa: Gestire le richieste HTTP (di solito dai browser).

Un contenitore servlet (ad es. Tomcat ) significa: può gestire servlet e JSP.

Un Application Server (ad es. GlassFish ) significa: * Può gestire applicazioni Java EE (di solito sia servlet / JSP che EJB).

Tomcat - è gestito dalla comunità Apache - Open source e ha due gusti:

1. Tomcat - Profilo Web - leggero che è solo contenitore servlet e non supporta le funzionalità Java EE come EJB, JMS ecc.
2. Tomcat EE - Questo è un contenitore Java EE certificato, supporta tutte le tecnologie Java EE.

Nessun supporto commerciale disponibile (solo supporto della comunità)

JBoss - Gestito da RedHat Questo è un supporto full-stack per JavaEE ed è un contenitore Java EE certificato. Ciò include Tomcat come contenitore Web internamente. Anche questo ha due gusti:

1. Versione della community denominata Application Server (AS) : questo avrà solo il supporto della community.
2. Enterprise Application Server (EAP) : per questo, è possibile disporre di una licenza basata su abbonamento (basata sul numero di core presenti sui server).

Glassfish - Gestito da Oracle Questo è anche un contenitore EE Java certificato full stack. Questo ha il suo contenitore web (non Tomcat). Questo viene da Oracle stesso, quindi tutte le nuove specifiche saranno testate e implementate prima con Glassfish. Quindi, supporterebbe sempre le ultime specifiche. Non sono a conoscenza dei suoi modelli di supporto.

jboss e glassfish includono un contenitore servlet (come Tomcat), tuttavia i due server applicazioni (jboss e glassfish) forniscono anche un contenitore bean (e immagino anche alcune altre cose)

JBoss e Glassfish sono sostanzialmente server di applicazioni Java EE completo mentre Tomcat è solo un contenitore Servlet. La differenza principale tra JBoss, Glassfish ma anche WebSphere, WebLogic e così via rispetto a Tomcat ma anche a Jetty, stava nella funzionalità che offre un server app completo. Quando disponevi di un server app Java EE full stack puoi beneficiare di tutta l'implementazione del fornitore di tua scelta e puoi beneficiare di EJB, JTA, CDI (JAVA EE 6+), JPA, JSF, JSP / Servlet ovviamente e così via. Con Tomcat invece puoi beneficiare solo di JSP / Servlet. Tuttavia oggi con Advanced Framework come Spring e Guice, molti dei principali vantaggi dell'utilizzo di un server di applicazioni full stack possono essere mitigati e, supponendo che uno di questi framework sia virile con Spring Ecosystem,

Sembra un po 'scoraggiante usare Tomcat quando leggi queste risposte. Tuttavia, ciò che molti non riescono a menzionare è che è possibile arrivare a casi d'uso identici o quasi identici con Tomcat, ma ciò richiede di aggiungere le librerie necessarie (tramite Maven o qualunque sistema di inclusione utilizzato).

Ho eseguito Tomcat con JPA, EJB con sforzi di configurazione molto piccoli.

Sia JBoss che Tomcat sono server di applicazioni servlet Java, ma JBoss è molto di più. La differenza sostanziale tra i due è che JBoss fornisce uno stack Java Enterprise Edition (Java EE) completo, inclusi Enterprise JavaBeans e molte altre tecnologie utili per gli sviluppatori che lavorano su applicazioni Java aziendali.

Tomcat è molto più limitato. Un modo di pensarci è che JBoss è uno stack Java EE che include un contenitore servlet e un server web, mentre Tomcat, per la maggior parte, è un contenitore servlet e un server web.

Apache Tomcat è solo un unico contenitore serverlet che non supporta l'applicazione Java Enterprise (JEE). JBoss e Glassfish supportano l'applicazione JEE ma Glassfish è molto più pesante del server JBOSS: Guida di riferimento