Pourquoi Jboss est-il «meilleur» que Tomcat?

Je commence actuellement un nouveau développement d’applications. 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 dans l’utilisation de Tomcat5 et 6 dans les applications à grande échelle avec des charges d’utilisateurs importantes et il se débrouille plutôt bien (IMHO). Les deux fonctionneraient sur un RedHat6 dans des conditions matérielles identiques (dans le cas où l’implémentation est importante).

Merci d’avance

Dire qu’un outil ou un 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 bien 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 le déployer sur une instance autonome de Tomcat.

C’est un peu injuste de dire que tout ce que vous obtenez lorsque vous utilisez JBoss est EJB et JMS. JBoss offre de nombreux services et fonctionnalités, notamment:

  • Conteneur Servlet / JSP
  • JNDI
  • EJB
  • JTA
  • regroupement
  • mise en cache
  • JMS
  • Source de données / gestion des ressources
  • Intégration JMX
  • OSGi support
  • services Web
  • portails
  • Haricots (couture)
  • Quelques consoles administratives
  • un conteneur IoC
  • etc.

Ce qui attire beaucoup d’architectes vers JBoss, c’est sa flexibilité. Il utilise une architecture de plugin qui vous permet d’append et de supprimer des services. Comme d’autres l’ont dit, dans Tomcat est utilisé comme conteneur Servlet, vous pouvez donc littéralement réduire JBoss à un simple serveur Tomcat. Quel est l’avantage de faire cela? Épreuves futures si vous pensez que vous allez utiliser d’autres fonctionnalités de JBoss.

Ces services de JBoss sont pré-intégrés et s’efforcent de fournir un modèle de déploiement cohérent qui minimise vos efforts de rédaction de la logique de l’application ou de la configuration pour les intégrer vous-même. Cela étant dit, d’autres frameworks tels que Spring font également un excellent travail en soutenant des méthodes uniformes d’intégration de nombreuses bibliothèques et frameworks populaires. Mais comme ils se concentrent sur l’intégration de bibliothèques tierces, l’interopérabilité entre les services dépend de vous. JBoss développant les services et la plate-forme d’intégration, ils consacrent du temps à développer (et à fournir une assistance) pour assurer l’interopérabilité.

Voici quelques questions à poser lors du choix:

  • Allez-vous utiliser des composants d’architecture JavaEE standard tels que 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?
  • Cherchez-vous à construire avec Web Beans ou Seam?
  • Quelles plates-formes de déploiement (Tomcat, JBoss, etc.) votre personnel informatique, support et développement utilise-t-il actuellement? Si vous envisagez d’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 vont déployer, quel impact aura-t-il sur l’organisation informatique des clients.
  • Allez-vous avoir besoin d’un soutien payant?
    • Vous pouvez trouver un support pour Tomcat par le biais de nombreuses entresockets (y compris Red Hat, je crois).
    • Vous devrez comparer les coûts, car je ne pense pas que le support JBoss est bon marché, bien que je n’aie pas consulté les prix ces derniers temps.
  • Aurez-vous besoin de faire un clustering sophistiqué?
    • JBoss dispose de nombreuses fonctionnalités de clustering et vous bénéficierez probablement d’un bon support de clustering via Red Hat. Bien que, pour une divulgation complète, je n’ai jamais effectué de clustering complexe avec d’autres frameworks pour pouvoir les comparer.
  • Allez-vous avoir besoin d’une gestion de transaction avancée (transactions dissortingbuées, commits en deux phases, etc.)?

Ne pas sonner comme 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 une 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 sont pertinentes pour votre question.

Je commence actuellement un nouveau développement d’applications. 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)?

C’est drôle, car JBOSS utilise Tomcat comme moteur de servlet / JSP.

Sonner comme “mieux” signifie “prend en charge les EJB et JMS”, car Tomcat sort de la boîte.

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 append à Tomcat avec OpenEJB et RabbitMQ ou ActiveMQ.

Je demanderais à votre application arch lorsque la dernière fois ils ont écrit quelque chose en dehors des diapositives Power Point ou des documents UML. La réponse pourrait vous surprendre.

JBoss est un serveur d’applications alors que Tomcat est un conteneur Servlet

JBoss peut donc être meilleur que Tomcat dans le sens où il le contient, plus 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 probablement de votre architecte.

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 @duffymo le fait remarquer, JBoss utilise Tomcat pour son conteneur Web, donc mieux vaut que nous comparions des choses équivalentes (à savoir Tomcat et la partie conteneur Web de JBoss). Et si vous n’utilisez pas JTA, EJB, JMS, JMX, etc., l’utilisation de JBoss ne présente aucun avantage, en particulier pendant le développement (Tomcat est plus léger et démarre plus rapidement, ce qui 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 habituée à utiliser JBoss en production, les outils (déploiement, surveillance, etc.) sont adaptés à JBoss.
  • La société a un contrat de support pour JBoss (même si vous pouvez également obtenir un support pour Tomcat).

Mais je ne suis pas sûr que c’est ce que l’architecte de l’application voulait dire. J’essayerais de discuter de ce choix avec l’architecte, peut-être qu’il a une explication rationnelle. Et si JBoss doit vraiment ê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 obtenir de l’aide. Mais ce n’est pas le cas avec Tomcat.

Cela est vrai, mais RedHat (qui a acheté Jboss.org) vous demandera de changer pour une de leurs versions sockets en charge de JBoss.

JBoss est compatible avec les spécifications J2EE, il supporte très bien les spécifications J2EE, telles que EJB, JTA, JMS, JNDI, etc. Tomcat est uniquement un conteneur de servlets, bien qu’il prenne également en charge une 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 ne possède pas d’interface utilisateur Web, JBoss est utilisé uniquement en tant que plate-forme et conteneur EJB pour intégrer toute application autonome utilisant MBean.