Je commence à me pencher sur 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?
Je commence à me pencher sur 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?
Réponses:
Tomcat n'est qu'un conteneur de servlets, c'est-à-dire qu'il implémente uniquement les servlets et la spécification JSP. Glassfish et JBoss sont des serveurs Java EE complets (y compris des trucs comme EJB, JMS, ...), Glassfish étant l'implémentation de référence de la dernière pile Java EE 6, mais JBoss en 2010 ne la supportait pas encore complètement.
Tomcat est simplement un serveur HTTP et un conteneur de servlet Java. JBoss et GlassFish sont des serveurs d'applications Java EE à part entière, y compris un conteneur EJB et toutes les autres fonctionnalités de cette pile. D'un autre côté, Tomcat a une empreinte mémoire plus légère (~ 60-70 Mo), tandis que ces serveurs Java EE pèsent des centaines de mégaoctets. 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.
Cependant, pour les applications qui nécessitent une pile Java EE complète (ou au moins plus de pièces qui pourraient facilement être boulonnées sur Tomcat) ... JBoss et GlassFish sont deux des offres open source les plus populaires (la troisième est Apache Geronimo , sur lequel 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 est loin derrière GlassFish dans la mise en œuvre des spécifications Java EE actuelles. De plus, 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 simple, alors que la plupart des tâches d'administration dans JBoss se font avec une ligne de commande et un éditeur de texte. GlassFish vient directement de Sun / Oracle, avec tous les avantages que cela peut offrir. JBoss n'est PAS sous le contrôle de Sun / Oracle, avec tous les avantages QUI peuvent 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 servlets (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 saveurs:
Aucun support commercial disponible (uniquement support communautaire)
JBoss - géré par RedHat Il s'agit d'un support de pile complète pour JavaEE et il s'agit d'un conteneur Java EE certifié. Cela inclut Tomcat en tant que conteneur Web en interne. Cela a également deux saveurs:
Glassfish - Run by Oracle Il s'agit également d'un conteneur Java EE certifié à pile complète. Celui-ci possède son propre conteneur Web (pas Tomcat). Cela vient d'Oracle lui-même, donc toutes les nouvelles spécifications seront d'abord testées et mises en œuvre avec Glassfish. Ainsi, il prendrait toujours en charge les dernières spécifications. Je ne connais pas ses modèles de support.
jboss et glassfish incluent un conteneur de servlet (comme tomcat), mais les deux serveurs d'applications (jboss et glassfish) fournissent également un conteneur de bean (et quelques autres choses aussi j'imagine)
JBoss et Glassfish sont essentiellement des serveurs d'applications Java EE complets, tandis que Tomcat n'est qu'un conteneur de servlets. La principale différence entre JBoss, Glassfish mais aussi WebSphere, WebLogic et ainsi de suite par rapport à Tomcat mais aussi Jetty, réside dans les fonctionnalités qu'offre un serveur d'application complet. Lorsque vous disposiez d'un serveur d'application Java EE à pile complète, vous pouvez bénéficier de toute l'implémentation du fournisseur de votre choix, et vous pouvez bénéficier d'EJB, JTA, CDI (JAVA EE 6+), JPA, JSF, JSP / Servlet bien sûr etc. Avec Tomcat d'autre part, vous ne pouvez bénéficier que de JSP / Servlet. Cependant, aujourd'hui, avec un framework avancé tel que Spring et Guice, bon nombre des principaux avantages de l'utilisation d'un serveur d'applications à pile complète peuvent être atténués, et avec l'hypothèse d'un de ces frameworks viril avec Spring Ecosystem,
Il semble un peu décourageant d'utiliser Tomcat lorsque vous lisez ces réponses. Cependant, ce que la plupart ne mentionnent pas, c'est que vous pouvez obtenir des cas d'utilisation identiques ou presque identiques avec tomcat, mais cela vous oblige à ajouter les bibliothèques nécessaires (via Maven ou tout autre système d'inclusion que vous utilisez).
J'ai exécuté tomcat avec JPA, EJB avec de très petits efforts de configuration.
JBoss et Tomcat sont tous deux des serveurs d'applications de servlet Java, mais JBoss est beaucoup plus. La différence substantielle entre les deux est que JBoss fournit une pile Java Enterprise Edition (Java EE) 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 pile Java EE qui comprend 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 seul conteneur de serverlet qu'il ne prend pas en charge pour l'application Java d'entreprise (JEE). JBoss et Glassfish prennent en charge l'application JEE mais Glassfish bien plus lourd que le serveur JBOSS: Référence Slide