JBoss vs Tomcat nuevamente [cerrado]


138

Esta parece ser la vieja pregunta (cuál es :)) de qué servidor es mejor entre Tomcat y JBoss, pero aún no he encontrado una respuesta lo suficientemente buena como para resolver mi problema.

Sé que Tomcat es solo un motor de servlet y JBoss ofrece muchas más funcionalidades listas para usar, pero lo que no entiendo es por qué es mejor usar Tomcat en algunas situaciones que jboss. Leí en alguna parte que JBoss tiene una arquitectura conectable y, si es necesario, puede desconectar las características de JBoss para que sea esencialmente un contenedor de servlets tomcat. Si ese es el caso, entonces no es mejor hacerlo en lugar de usar Tomcat, para dejar espacio para volver a enchufar las cosas.

Otra explicación que encuentro a favor de Tomcat es que es liviano, eso significa menos requisitos de memoria o eso también permite una respuesta más rápida. Una vez más, necesito saber que jboss no cargará componentes según los requisitos, es decir, si estoy usando solo servlets, entonces jboss no omitirá el resto de las funciones y se volverá ligero de forma automática.

Esencialmente, mi aplicación no tiene ninguna característica Java EE, pero los argumentos "ligeros" a favor de Tomcat no suenan lo suficientemente convincentes debido a las razones mencionadas anteriormente.

Por favor ayuda.

Editar: Finalmente habíamos decidido usar tomcat en ese entonces y lo hemos estado usando durante más de 6 meses con gran facilidad de uso. De hecho, encontramos un uso práctico en el que podríamos ejecutar fácilmente múltiples instancias de tomcat en la misma máquina servidor para diferentes desarrolladores, lo mismo podría haber sido muy difícil con jboss.

He encontrado que tomcat no tiene problemas para nuestro trabajo y, por lo tanto, puede ser la opción correcta cuando no está utilizando muchas de las funciones de Java EE. PD: Tenga en cuenta que todavía usamos Spring e Hibernate con Tomcat


1
¿Uhh no se integra JBoss con Tomcat?
Navi

44
@Navi: En realidad no. Contiene una versión bifurcada de la base de código de Tomcat, pero es bastante divergente.
skaffman

1
Una aplicación web simple, sin características de j2ee, debería desplegarse fácilmente en cualquier contenedor de servlet compatible. Teniendo en cuenta esto, no debería importar demasiado cuál usa por adelantado. Comenzaría con el más simple de implementar (Tomcat y Jetty me han servido bien en el pasado).
Joel

3
Para su información, a finales de 2011, Tomcat recibió la certificación JavaEE 6 como TomEE para responder a esta antigua pregunta.
David Blevins

1
¡¿Preguntas cerradas con alrededor de 150 mil visitas, 125 votos a favor y 0 votos a favor? !! Sé que estas son las reglas, pero debo decir que tales reglas deben cambiarse un poco.
Muhammed Refaat

Respuestas:


132

Primero los hechos, ninguno es mejor . Como ya mencionó, Tomcat proporciona un contenedor de servlets que admite la especificación de Servlet (Tomcat 7 admite Servlet 3.0). JBoss AS, un servidor de aplicaciones 'completo' es compatible con Java EE 6 (incluido Servlet 3.0) en su versión actual.

Tomcat es bastante ligero y, en caso de que necesite ciertas características de Java EE más allá de la API de Servlet, puede mejorar Tomcat fácilmente al proporcionar las bibliotecas necesarias como parte de su aplicación. Por ejemplo, si necesita funciones JPA, puede incluir Hibernate u OpenEJB y JPA funciona casi de inmediato.

Cómo decidir si usar Tomcat o un Java EEservidor de aplicaciones de pila completa :

Al comenzar su proyecto, debe tener una idea de lo que requiere. Si se encuentra en un entorno empresarial grande, JBoss (o cualquier otro servidor Java EE) podría ser la opción correcta, ya que proporciona soporte integrado para, por ejemplo:

  1. Mensajería JMS para integración asincrónica
  2. Motor de servicios web (JAX-WS y / o JAX-RS)
  3. Capacidades de administración como JMX y una interfaz de administración con script
  4. Seguridad avanzada, p. Ej. Integración inmediata con directorios de terceros
  5. Archivo EAR en lugar de "solo" soporte de archivos WAR
  6. todas las otras características "excelentes" de Java EE que no recuerdo :-)

En mi opinión, Tomcat se adapta muy bien si se trata de aplicaciones centradas en la web y orientadas al usuario. Si entra en juego la integración de backend, se debe considerar (al menos) un servidor de aplicaciones Java EE. Por último, pero no menos importante, migrar un WAR desarrollado para Tomcat a JBoss debería ser un ejercicio de 1 día.

En segundo lugar, también debe tener en cuenta el uso dentro de su entorno. En caso de que su organización ya se ejecute, digamos 1,000 instancias de JBoss, siempre puede ir con eso, independientemente de sus requisitos concretos (considere aspectos como el costo de las operaciones o la capacitación). Por supuesto, esto se aplica al revés.

mi 2 centavo


13

Echa un vistazo a TOMEE

Tiene todas las características que necesita para crear una aplicación Java EE completa.


7

Ciertamente miraría a TomEE ya que la idea detrás es mantener a Tomcat trayendo toda la integración JavaEE 6 que falta por defecto. Ese es un tipo de compromiso muy bueno


6

Estrictamente hablando; Sin funciones Java EE, su aplicación apenas necesita un servidor de aplicaciones ;-)

Como otros han señalado, JBoss tiene una pila Java EE (más o menos) completa, mientras que Tomcat es solo un contenedor web. JBoss se puede configurar para que solo sirva como un contenedor web, entonces solo sería un envoltorio delgado alrededor del contenedor web Tomcat incluido. De esa manera, podría tener un JBoss casi tan liviano, que en realidad sería un delgado "envoltorio" alrededor de Tomcat. Eso sería casi tan ligero.

Si no necesita ninguno de los extras que JBoss tiene para ofrecer, elija el que le resulte más cómodo. ¿Cuál es más fácil de configurar y mantener para usted?


1
¿Qué tan difícil es usar los servicios web y jmx con tomcat? ¿Podría proporcionar algunas buenas referencias / enlaces
Ashish

2

También he leído que para algunos servidores, por ejemplo, uno solo necesita anotar contextos de persistencia, pero en algunos servidores, la inyección debe hacerse manualmente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.