Quelle est la différence entre Tomcat, JBoss et Glassfish?

Je commence à regarder Enterprise Java et le livre que je suis en train de suivre mentionne qu’il utilisera JBoss. Netbeans est livré avec Glassfish. J’ai utilisé Tomcat dans le passé.

Quelles sont les différences entre ces trois programmes?

Tomcat n’est qu’un conteneur de servlets, c’est-à-dire qu’il n’implémente que les servlets et les spécifications JSP. Glassfish et JBoss sont des serveurs Java EE complets (y compris des produits tels que EJB, JMS, …), Glassfish étant l’implémentation de référence de la dernière stack Java EE 6, mais JBoss ne l’a pas encore totalement supporté en 2010.

Tomcat est simplement un serveur HTTP et un conteneur de servlet Java. JBoss et GlassFish sont des serveurs d’application Java EE complets, comprenant un conteneur EJB et toutes les autres fonctionnalités de cette stack. D’un autre côté, Tomcat a une empreinte mémoire plus faible (~ 60-70 Mo), alors que les serveurs Java EE pèsent des centaines de Mo. Tomcat est très populaire pour les applications Web simples ou les applications utilisant des frameworks tels que Spring qui ne nécessitent pas de serveur Java EE complet. L’administration d’un serveur Tomcat est sans doute plus facile, car il y a moins de pièces mobiles.

Toutefois, pour les applications qui nécessitent une stack Java EE complète (ou au moins plusieurs éléments pouvant être facilement associés à Tomcat) … JBoss et GlassFish sont deux des offres open source les plus populaires (la troisième est Apache Geronimo). , sur laquelle la version gratuite d’IBM WebSphere est construite). JBoss a une communauté d’utilisateurs plus grande et plus profonde et une base de code plus mature. Cependant, JBoss accuse un retard important sur GlassFish dans la mise en œuvre des spécifications Java EE actuelles. En outre, pour ceux qui préfèrent un système d’administration basé sur une interface graphique, la console d’administration de GlassFish est extrêmement lisse, alors que la plupart des tâches d’administration sont effectuées avec un éditeur de texte et de ligne de commande. GlassFish vient directement de Sun / Oracle, avec tous les avantages qu’il peut offrir. JBoss n’est PAS sous le contrôle de Sun / Oracle, avec tous les avantages que peut offrir.

Vous devez utiliser GlassFish pour les applications d’entreprise Java EE . Quelques points à considérer:

Un serveur Web signifie: gérer les requêtes HTTP (généralement à partir de navigateurs).

Un conteneur de servlet (par exemple, Tomcat ) signifie: il peut gérer les servlets et JSP.

Un serveur d’applications (par exemple GlassFish ) signifie: * Il peut gérer les applications Java EE (généralement à la fois servlet / JSP et EJB).


Tomcat – est géré par la communauté Apache – Open source et a deux versions Tomcat – Profil Web – poids léger qui est uniquement un conteneur de servlets et ne prend pas en charge les fonctionnalités Java EE comme EJB, JMS, etc. Tomcat EE – Il s’agit d’un conteneur Java EE certifié. Cela prend en charge toutes les technologies Java EE.

Aucun support commercial disponible (uniquement support communautaire)

JBoss – Exécuter par RedHat Ceci est un support de stack complet pour JavaEE et il s’agit d’un conteneur Java EE certifié. Cela inclut Tomcat en tant que conteneur Web en interne. Cette version dispose également de deux versions communautaires appelées Application Server (AS). Seule la communauté s’applique à Enterprise Application Server (EAP). Pour cela, vous pouvez disposer d’une licence basée sur un abonnement (basée sur le nombre de cœurs présents sur vos serveurs).

Glassfish – Exécution par Oracle Il s’agit également d’un conteneur Java EE certifié complet. Cela a son propre conteneur Web (pas Tomcat). Cela vient d’Oracle lui-même, donc toutes les nouvelles spécifications seront testées et implémentées avec Glassfish en premier. Donc, il prend toujours en charge les dernières spécifications. Je ne connais pas ses modèles de support.

jboss et glassfish incluent un conteneur de servlets (comme tomcat), mais les deux serveurs d’applications (jboss et glassfish) fournissent également un conteneur de beans (et quelques autres choses que j’imagine)

JBoss et Glassfish sont essentiellement des serveurs d’application Java EE complets, alors que Tomcat n’est qu’un conteneur Servlet. La principale différence entre JBoss, Glassfish, mais aussi WebSphere, WebLogic, etc., concernant Tomcat mais aussi Jetty, réside dans les fonctionnalités offertes par un serveur d’applications complet. Lorsque vous disposiez d’un serveur d’application Java EE complet, vous pouvez bénéficier de toute l’implémentation du fournisseur de votre choix, et vous pouvez bien sûr utiliser EJB, JTA, CDI (JAVA EE 6+), JPA, JSF, JSP / Servlet. etc. Avec Tomcat, vous ne pouvez bénéficier que de JSP / Servlet. Cependant, avec le Framework avancé tel que Spring et Guice, beaucoup des principaux avantages de l’utilisation d’un serveur d’application à stack complète peuvent être atténués, et avec l’hypothèse de ce cadre avec Spring Ecosystem, vous pouvez bénéficier de nombreux avantages. projet que dans mon expérience de travail laissez-moi laisser l’utilisation d’un serveur d’application de stack complète en faveur du serveur d’application léger comme tomcat.

JBoss et Tomcat sont tous les deux des serveurs d’applications Java, mais JBoss est bien plus que cela. La différence substantielle entre les deux est que JBoss fournit une stack Java EE (Java Enterprise Edition) complète, y compris Enterprise JavaBeans et de nombreuses autres technologies utiles aux développeurs travaillant sur des applications Java d’entreprise.

Tomcat est beaucoup plus limité. Une façon de penser est que JBoss est une stack Java EE qui inclut un conteneur de servlets et un serveur Web, tandis que Tomcat, pour la plupart, est un conteneur de servlets et un serveur Web.

Apache tomcat est juste un conteneur de serveur uniquement qu’il ne prend pas en charge pour l’application Enterprise Java (JEE). JBoss et Glassfish supportent l’application JEE mais Glassfish est beaucoup plus lourd que le serveur JBOSS: Reference Slide

Il semble un peu décourageant d’utiliser Tomcat lorsque vous lisez ces réponses. Cependant, ce que vous ne parvenez pas à mentionner, c’est que vous pouvez accéder à des cas d’utilisation identiques ou presque identiques avec tomcat, mais cela nécessite que vous ajoutiez les bibliothèques nécessaires (via Maven ou tout autre système inclus).

J’ai utilisé tomcat avec JPA, EJB avec de très petits efforts de configuration.