Pourquoi Jboss est "meilleur" que Tomcat? [fermé]
je commence actuellement le développement d'une nouvelle application. L'architecte de l'application insiste pour que nous utilisions JBoss5 parce que c'est "mieux". Faire quelqu'un a une définition plus large de "mieux" (si c'est la cas)?
j'ai de l'expérience à l'aide de Tomcat5 et 6 dans les applications à grande échelle avec de grandes charges d'utilisateurs et il se manipule assez bien (IMHO). Les deux devraient être en cours d'exécution sur un RedHat6 dans des conditions matérielles identiques (au cas où la mise en oeuvre question.)
Merci d'avance
7 réponses
dire que n'importe quel outil ou cadre est juste "meilleur" est ridicule. Cela dépend toujours de la situation, de l'architecture, etc. Vous ne voulez pas nécessairement utiliser un marteau pour conduire une vis.
j'ai écrit JBoss en Action, donc j'aime évidemment la technologie JBoss, mais je serai le premier à dire que JBoss peut être exagéré dans de nombreuses situations. Par exemple, pour les deux derniers sites que j'ai développés, il était plus logique de construire avec des Grails et de les déployer sur un Tomcat autonome. instance.
il 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, y compris:
- Servlet / JSP container
- JNDI
- EJB
- JTA
- clusters
- mise en cache
- JMS
- source de données / Gestion des ressources
- intégration JMX
- OSGi support
- web services
- portails
- Web Haricots (Couture)
- quelques consoles administratives
- un conteneur IoC
- etc.
ce qui attire de nombreux architectes à 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 Servlet, de sorte que vous pouvez littéralement whittle JBoss vers le bas à l'endroit où il est pratiquement juste un serveur Tomcat. Qu'est-ce que l' avantage de le faire? Vérification Future 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 en écrivant la logique de l'application ou la configuration pour les intégrer vous-même. Cela étant dit, D'autres cadres comme Spring font aussi un excellent travail de soutenir des façons uniformes d'intégrer de nombreuses bibliothèques populaires et cadres. Mais puisqu'ils se concentrent sur en intégrant des 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 soutien) pour l'interopérabilité.
voici quelques questions à poser au moment de faire un choix:
- allez-vous utiliser les composants standards de L'architecture JavaEE comme EJB?
- BTW, EJB peut être exécuté en Tomcat autonome en utilisant le conteneur JBoss intégré, donc si EJB est tout ce que vous utilisez, alors vous n'avez toujours pas à utiliser JBoss
- allez-vous utiliser des services Web, portails, JMS?
- cherchez-vous à construire avec des fèves ou des coutures?
- 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éployer, quel impact aura - t-il sur l'organisation informatique des clients?
- allez-vous avoir besoin d'une pension alimentaire payée?
- vous pouvez trouver du soutien pour Tomcat par l'intermédiaire de nombreuses entreprises (y compris Red Hat I believe).
- vous aurez besoin de comparer les coûts, parce que je ne pense pas que le support JBoss est bon marché, bien que je n'ai pas regardé les prix vers le haut dernièrement.
- aurez-vous besoin de faire des regroupements sophistiqués?
- JBoss a quelques merveilleux clustering les capacités, et vous obtiendrez probablement un bon soutien de regroupement grâce à Red Hat. Bien que, pour la divulgation complète, je n'ai jamais fait de regroupement complexe avec d'autres cadres pour être en mesure de comparer.
- allez-vous avoir besoin d'une gestion avancée des transactions (transactions distribuées, 2-Phase commits, etc)
ne pas sonner comme une prise éhontée, mais le premier chapitre de JBoss en Action est disponible gratuitement sur le Manning site. Bien que nous ne fassions pas un direct comparaison entre JBoss et d'autres serveurs d'applications et environnements de déploiement dans le chapitre, nous parlons un peu des différences architecturales, ce qui est pertinent à votre question.
je suis en train de lancer une nouvelle application développement. L'application de l'architecte insiste nous utilisons JBoss5 parce que c'est "mieux". Faire n'importe qui a une définition plus large de "mieux" (si c'est la cas)?
drôle, car JBOSS utilise Tomcat comme moteur servlet/JSP.
sonne comme "Meilleur" signifie "supporte EJBs et JMS", parce que Tomcat out of the box n'a ni l'un ni l'autre.
mais ce n'est pas un problème si votre application n'utilise pas EJBs ou JMS.
et si vous en avez besoin, vous pouvez les ajouter à Tomcat avec OpenEJB et RabbitMQ ou ActiveMQ.
je demanderais à votre app arch quand la dernière fois ils ont écrit quelque chose en plus de Power Point diapositives ou des documents UML. La réponse pourrait vous surprendre.
JBoss est un Serveur D'Application alors que Tomcat est un conteneur de Servlet
donc JBoss peut ê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 votre architecte a autre chose en tête.
je me demande ce que aurait-il dit si vous lui demander directement?
comme le souligne @duffymo, JBoss utilise Tomcat pour son conteneur web donc n'a pas beaucoup de sens si nous comparons des choses équivalentes (par exemple Tomcat et la partie conteneur web de JBoss). Et si vous n'allez pas utiliser JTA, EJBs, JMS, JMX, etc, Il n'y a pas d'avantage réel à utiliser JBoss, surtout pendant le développement (Tomcat est plus léger et démarre plus vite, 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 si (je suis toujours en supposant que vous n'êtes pas en utilisant des Ejb, etc):
- l'équipe de production est formée ou utilisée pour utiliser les JBoss dans la production, les outils (déploiement, suivi, etc.) sont adaptés aux JBoss.
- la société a un contrat de support pour JBoss (bien que vous pouvez également obtenir un support pour Tomcat).
mais je ne suis pas sûr que ce soit ce que l'architecte de l'application voulait dire. Je voudrais essayer de discuter de ce choix avec l'architecte, peut-être qu'il a une justification explication. Et si vraiment JBoss doit être utilisé dans la production, vous pouvez toujours utiliser Tomcat ou Jetty pendant le développement.
si vous utilisez JBoss, vous pouvez payer Jboss.org for support. Mais ce n'est pas le cas avec Tomcat.
C'est vrai, cependant RedHat (qui a racheté Jboss.org) vous demandera de changer à l'une de leurs versions prises en charge de JBoss
JBoss est conforme à la spécification J2EE, il supporte très bien la spécification J2EE, comme EJB, JTA,JMS, JNDI, etc. Tomcat n'est qu'un conteneur servlet, bien qu'il supporte également une spécification bit J2ee. Lorsque vous voulez utiliser J2EE component, vous devriez considérer JBoss en premier.
J'ai 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 web, JBoss est utilisé juste comme une plate-forme et un conteneur EJB pour intégrer tous L'application autonome sur elle utilisent MBean.