Pourquoi Jboss est-il "meilleur" que Tomcat?
Je commence actuellement un nouveau développement d'application. L'architecte de l'application insiste sur le fait que nous utilisons JBoss5 parce que c'est "mieux". Quelqu'un at-il une définition plus large de "mieux" (si c'est le cas)?
J'ai de l'expérience en utilisant Tomcat5 et 6 dans des applications à grande échelle avec de grandes charges utilisateur et il gère assez bien (à mon humble avis). Les deux fonctionneraient sur un RedHat6 dans des conditions matérielles identiques (au cas où l'implémentation importerait).
Merci d'avance
Dire que n'importe quel outil ou cadre est simplement "meilleur" est ridicule. Cela dépend toujours de la situation, de l'architecture, etc. Vous ne voulez pas nécessairement utiliser un marteau pour enfoncer une vis.
J'ai écrit JBoss in Action, donc j'aime évidemment la technologie JBoss, mais je serai le premier à dire que JBoss peut être excessif dans de nombreuses situations. Par exemple, pour les deux derniers sites que j'ai développés, il était plus logique de construire avec Grails et de déployer sur une instance Tomcat autonome.
C'est un peu injuste de dire que tout ce que vous obtenez en utilisant JBoss est EJB et JMS. JBoss offre de nombreux services et fonctionnalités, notamment:
- Conteneur de servlet/JSP
- JNDI
- EJB
- JTA
- regroupement
- mise en cache
- JMS
- Gestion des sources de données/des ressources
- Intégration JMX
- Prise en charge OSGi
- services Web
- portails
- Web Beans (Seam)
- Quelques consoles administratives
- un conteneur IoC
- etc.
Ce qui attire de nombreux architectes chez JBoss, c'est sa flexibilité. Il utilise une architecture de plugin qui vous permet d'ajouter et de supprimer des services. Comme d'autres l'ont dit, dans utilise Tomcat comme son conteneur de servlets, vous pouvez donc littéralement réduire JBoss jusqu'à ce qu'il ne soit pratiquement qu'un serveur Tomcat. Quel est l'avantage de faire cela? L'épreuve du futur si vous pensez que vous allez utiliser d'autres fonctionnalités de JBoss.
Ces services dans JBoss sont pré-intégrés et s'efforcent de fournir un modèle de déploiement cohérent qui minimise vos efforts pour écrire la logique ou la configuration d'application pour les intégrer vous-même. Cela étant dit, d'autres cadres comme Spring font également un excellent travail en soutenant des façons uniformes d'intégrer de nombreuses bibliothèques et cadres populaires. Mais comme ils se concentrent sur l'intégration de bibliothèques tierces, l'interopérabilité entre les services dépend de vous. Parce que JBoss construit les services et la plate-forme d'intégration, ils passent du temps à développer (et à fournir un support) pour l'interopérabilité.
Certaines questions à poser lors d'un choix sont:
- Allez-vous utiliser des composants architecturaux JavaEE standard comme EJB?
- BTW, EJB peut être exécuté dans Tomcat autonome en utilisant le conteneur intégré JBoss, donc si EJB est tout ce que vous utilisez, alors vous n'avez toujours pas à utiliser JBoss
- Allez-vous utiliser les services Web, les portails, JMS?
- Envisagez-vous de construire avec Web Beans ou Seam?
- Quelles plateformes de déploiement (Tomcat, JBoss, etc.) votre personnel informatique, de support et de développement utilise-t-il actuellement? Si vous allez utiliser quelque chose de nouveau, vous devrez payer des frais supplémentaires pour apprendre la nouvelle plate-forme.
- Si vous vendez un produit que les clients déploieront, quel impact cela aura-t-il sur l'organisation informatique des clients.
- Allez-vous avoir besoin d'une assistance payante?
- Vous pouvez trouver un support pour Tomcat par le biais de nombreuses sociétés (dont Red Hat je crois).
- Vous devrez comparer les coûts, car je ne pense pas que le support JBoss soit bon marché, bien que je n'aie pas recherché les prix récemment.
- Aurez-vous besoin de faire un clustering sophistiqué?
- JBoss possède de merveilleuses capacités de clustering, et vous obtiendrez probablement un bon support de clustering via Red Hat. Cependant, pour une divulgation complète, je n'ai jamais effectué de clustering complexe avec d'autres cadres pour pouvoir comparer.
- Allez-vous avoir besoin d'une gestion avancée des transactions (transactions distribuées, validations en 2 phases, etc.)
Pour ne pas ressembler à une prise sans vergogne, mais le premier chapitre de JBoss in Action est disponible gratuitement sur le site Web de Manning. Bien que nous ne fassions pas de comparaison directe entre JBoss et d'autres serveurs d'applications et environnements de déploiement dans le chapitre, nous parlons un peu des différences architecturales, qui est pertinent pour votre question.
Je commence actuellement un nouveau développement d'application. L'architecte de l'application insiste sur le fait que nous utilisons JBoss5 car c'est "mieux". Quelqu'un at-il une définition plus large de "mieux" (si c'est le cas)?
Drôle, car JBOSS utilise Tomcat comme moteur servlet/JSP.
Sonne comme "mieux" signifie "prend en charge les EJB et JMS", car Tomcat prêt à l'emploi n'a ni l'un ni l'autre.
Mais ce n'est pas un problème si votre application n'utilise pas d'EJB ou de JMS.
Et si vous en avez besoin, vous pouvez les ajouter à Tomcat avec OpenEJB et RabbitMQ ou ActiveMQ.
Je demanderais à votre application Arch quand ils ont écrit pour la dernière fois autre chose que des diapositives PowerPoint ou des documents UML. La réponse pourrait vous surprendre.
JBoss est un serveur d'applications tandis que Tomcat est un conteneur de servlet
JBoss peut donc être meilleur que Tomcat dans le sens où il le contient, ainsi que d'autres composants. C'est tout.
Si vous n'utilisez pas ces autres composants, vous gaspillez des ressources. Si vous avez besoin de ces autres composants, Tomcat ne suffit pas.
Cela dépend, votre architecte a probablement autre chose en tête.
Je me demande ce qu'il dirait si vous lui demandez directement?
Ce n'est pas mieux, c'est juste plus. JBoss inclut Tomcat.
Comme le souligne @duffymo, JBoss utilise Tomcat pour son conteneur Web, donc mieux n'a pas beaucoup de sens si nous comparons des choses équivalentes (c'est-à-dire Tomcat et la partie conteneur Web de JBoss). Et si vous n'utilisez pas JTA, EJB, JMS, JMX, etc., il n'y a pas de réel avantage à utiliser JBoss, en particulier pendant le développement (Tomcat est plus léger et démarre plus rapidement, cela est souvent apprécié par les équipes de développement).
Il y a des cas où vous pourriez préférer JBoss pour la production (je suppose toujours que vous n'utilisez pas d'EJB, etc.):
- L'équipe de production est formée ou utilisée pour utiliser JBoss dans la production, les outils (déploiement, surveillance, etc.) sont adaptés à JBoss.
- La société a un contrat d'assistance pour JBoss (bien que vous puissiez également obtenir une assistance pour Tomcat).
Mais je ne suis pas sûr que c'est ce que l'architecte de l'application voulait dire. J'essaierais de discuter de ce choix avec l'architecte, peut-être qu'il a une explication rationnelle. Et si vraiment JBoss doit être utilisé en production, vous pouvez toujours utiliser Tomcat ou Jetty pendant le développement.
Si vous utilisez JBoss, vous pouvez payer Jboss.org pour le support. Mais ce n'est pas le cas avec Tomcat.
C'est vrai, cependant RedHat (qui a racheté Jboss.org) vous demandera de passer à l'une de leurs versions prises en charge de JBoss
JBoss est conforme à la spécification J2EE, il prend très bien en charge la spécification J2EE, comme EJB, JTA, JMS, JNDI, etc. Tomcat n'est qu'un conteneur de servlet, bien qu'il supporte également un peu la spécification J2ee. Lorsque vous souhaitez utiliser le composant J2EE, vous devez d'abord considérer JBoss.
Oublié un point, JBoss supporte très bien JMX, surtout dans la version 4. *. J'ai expérimenté un projet, il n'a pas d'interface utilisateur Web, JBoss est utilisé uniquement comme plate-forme et conteneur EJB pour intégrer toutes les applications autonomes sur celui-ci à l'aide de MBean.