java tomcat6 jboss5.x

java - ¿Por qué Jboss es "mejor" que Tomcat?



tomcat6 jboss5.x (7)

Actualmente estoy comenzando un nuevo desarrollo de aplicaciones. El arquitecto de la aplicación insiste en que usemos JBoss5 porque es "mejor". ¿Alguien tiene una definición más amplia de "mejor" (si es el caso)?

Tengo experiencia en utilizar Tomcat5 y 6 en aplicaciones a gran escala con grandes cargas de usuario y se maneja bastante bien (en mi humilde opinión). Ambos estarían ejecutando un RedHat6 en condiciones de hardware idénticas (en caso de que la implementación importe).

Gracias por adelantado

Actualmente estoy comenzando un nuevo desarrollo de aplicaciones. El arquitecto de la aplicación insiste en que usemos JBoss5 porque es "mejor". ¿Alguien tiene una definición más amplia de "mejor" (si es el caso)?

Es curioso, porque JBOSS usa Tomcat como su motor servlet / JSP.

Parece que "mejor" significa "admite EJB y JMS", porque Tomcat no tiene ninguno de los dos.

Pero eso no es un problema si su aplicación no usa EJB o JMS.

Y si los necesita, puede agregarlos a Tomcat con OpenEJB y RabbitMQ o ActiveMQ.

Le preguntaría a la aplicación arco cuando fue la última vez que escribieron algo además de diapositivas de Power Point o documentos UML. La respuesta puede sorprenderte.

Como señala @duffymo, JBoss usa Tomcat para su contenedor web, por lo que no tiene mucho sentido que comparemos elementos equivalentes (es decir, Tomcat y la parte del contenedor web de JBoss). Y si no va a utilizar JTA, EJB, JMS, JMX, etc., no hay una ventaja real al usar JBoss, especialmente durante el desarrollo (Tomcat es más ligero y comienza más rápido, esto es apreciado por los equipos de desarrollo).

Sin embargo, en algunos casos podría preferir la producción de JBoss (todavía asumo que no está utilizando EJB, etc.):

  • El equipo de producción está entrenado o utilizado para usar JBoss en producción, las herramientas (implementación, monitoreo, etc.) están diseñadas para JBoss.
  • La compañía tiene un contrato de soporte para JBoss (aunque también puede obtener soporte para Tomcat).

Pero no estoy seguro de que esto sea lo que quiso decir el arquitecto de la aplicación. Trataría de discutir esta elección con el arquitecto, tal vez tiene una explicación racional. Y si realmente se debe usar JBoss en producción, siempre puedes usar Tomcat o Jetty durante el desarrollo.

Decir que cualquier herramienta o marco es simplemente ''mejor'' es ridículo. Siempre depende de la situación, la arquitectura, etc. No necesariamente quiere usar un martillo para manejar un tornillo.

Escribí JBoss en acción, así que obviamente me gusta la tecnología de JBoss, pero seré el primero en decir que JBoss puede ser excesivo en muchas situaciones. Por ejemplo, para los dos últimos sitios que he desarrollado, tiene más sentido construir con Grails y desplegar en una instancia de Tomcat independiente.

Es un poco injusto decir que todo lo que obtienes al usar JBoss es EJB y JMS. JBoss ofrece muchos servicios y características, que incluyen:

  • Contenedor Servlet / JSP
  • JNDI
  • EJB
  • JTA
  • agrupamiento
  • almacenamiento en caché
  • JMS
  • Datasource / gestión de recursos
  • Integración JMX
  • Soporte de OSGi
  • servicios web
  • portales
  • Web Beans (Seam)
  • Algunas consolas administrativas
  • un contenedor IoC
  • etc.

Lo que atrae a muchos arquitectos a JBoss es su flexibilidad. Utiliza una arquitectura de complemento que le permite agregar y eliminar servicios. Como otros han dicho, usa Tomcat como su contenedor Servlet, por lo que literalmente puede reducir JBoss a donde prácticamente no es más que un servidor Tomcat. ¿Cuál es el beneficio de hacer esto? Pruebas futuras si cree que va a utilizar otras funciones de JBoss.

Estos servicios en JBoss vienen preintegrados y se esfuerzan por proporcionar un modelo de implementación coherente que minimice su esfuerzo al escribir la lógica de la aplicación o la configuración para integrarlos usted mismo. Dicho esto, otros marcos como Spring también hacen un gran trabajo al apoyar formas uniformes de integrar muchas bibliotecas y marcos populares. Pero dado que se centran en la integración de bibliotecas de terceros, la interoperabilidad entre servicios depende de usted. Debido a que JBoss está construyendo los servicios y la plataforma de integración, dedican tiempo a desarrollar (y brindar soporte) la interoperabilidad.

Algunas preguntas para hacer al elegir son:

  • ¿Vas a usar componentes arquitectónicos JavaEE estándar como EJB?
    • Por cierto, EJB se puede ejecutar en Tomcat independiente utilizando el contenedor integrado de JBoss, de modo que si EJB es todo lo que estás utilizando, entonces todavía no tienes que usar JBoss
  • ¿Vas a utilizar los servicios web, portales, JMS?
  • ¿Estás buscando construir con Web Beans o Seam?
  • ¿Qué plataformas de implementación (Tomcat, JBoss, etc.) utilizan actualmente su personal de TI, soporte y desarrollo? Si va a utilizar algo nuevo, incurrirá en un costo adicional para conocer la nueva plataforma.
  • Si está vendiendo un producto que los clientes implementarán, qué impacto tendrá en la organización de TI de los clientes.
  • ¿Necesitarás ayuda paga?
    • Puede encontrar soporte para Tomcat a través de muchas compañías (incluida Red Hat, creo).
    • Necesitará comparar los costos, porque no creo que el soporte de JBoss sea barato, aunque últimamente no he buscado precios.
  • ¿Necesitarás hacer un clúster sofisticado?
    • JBoss tiene algunas capacidades maravillosas de clustering, y probablemente obtendrás un buen soporte de clustering a través de Red Hat. Sin embargo, para una revelación completa, nunca he hecho ningún clúster complejo con ningún otro framework para poder comparar.
  • ¿Va a necesitar una gestión avanzada de transacciones (transacciones distribuidas, confirmaciones de dos fases, etc.)?

No parece un enchufe desvergonzado, pero el primer capítulo de JBoss in Action está disponible de forma gratuita en el sitio web de Manning. Aunque no hacemos una comparación directa entre JBoss y otros servidores de aplicaciones y entornos de despliegue en el capítulo, sí hablamos un poco sobre las diferencias arquitectónicas, lo cual es relevante para su pregunta.

JBoss cumple con la especificación J2EE, es compatible con la especificación J2EE muy bien, como EJB, JTA, JMS, JNDI y etc. Tomcat es solo un contenedor de servlets, aunque también admite una especificación J2ee de bit. Cuando desee usar el componente J2EE, debe considerar JBoss primero.

Olvidé un punto, JBoss es compatible con JMX muy bien, especialmente en la versión 4. *. He experimentado un proyecto, no tiene una interfaz de usuario web, JBoss se usa solo como una plataforma y el contenedor EJB para integrar todas las aplicaciones independientes en las que utiliza MBean.

JBoss es un servidor de aplicaciones, mientras que Tomcat es un contenedor de servlets

Entonces, JBoss puede ser mejor que Tomcat en el sentido en que lo contiene, más otros componentes. Eso es.

Si no va a usar esos otros componentes, está desperdiciando recursos. Si necesita esos otros componentes, Tomcat no es suficiente.

Depende, probablemente su Arquitecto tenga algo más en mente.

Me pregunto qué diría si lo preguntas directamente?

No es mejor, es solo más. JBoss incluye a Tomcat.

Si usa JBoss, puede pagar a Jboss.org para obtener asistencia. Pero no es el caso con Tomcat.

Esto es cierto, sin embargo, RedHat (que compró Jboss.org) requerirá que cambie a una de sus versiones compatibles de JBoss.