¿Cuándo Spring + Tomcat no es lo suficientemente potente?

Question

He estado leyendo/aprendiendo más sobre Spring últimamente, y cómo uno usaría Spring en combinación con otras herramientas de código abierto como Tomcat e Hibernate. Estoy evaluando si Spring MVC podría ser una posible tecnología de reemplazo para el proyecto en el que trabajo, que usa WebLogic y MUCHO código Java EE personalizado. La cuestión es que siempre he sospechado que nuestra solución está sobrediseñada y es mucho más compleja de lo que debería ser. Sorprendentemente, es 2009 y, sin embargo, estamos escribiendo nuestras propias clases de manejo de transacciones y agrupamiento de hilos. Y no es como si fuéramos Amazon, eBay o Google, si sabes a lo que me refiero. Por lo tanto, estoy investigando una opción "más simple es mejor".

Así que esta es mi pregunta: me gustaría escuchar opiniones sobre cómo tomar la decisión de que un servidor de aplicaciones Java EE completo es necesario, o no. ¿Cómo se "mide" el tamaño/carga/demanda en una aplicación Java EE? ¿Número de usuarios concurrentes? Total de transacciones diarias ¿Qué tan "pesada" necesita una aplicación antes de tirar las manos en señal de rendición y decir: "OK, Tomcat simplemente no está cortando, necesitamos JBoss/WebLogic/WebSphere"?

Answer 1

No creo que la decisión de utilizar un servidor Java EE completo o no se deba basar en la cantidad de usuarios o transacciones. Más bien debería basarse en si necesita la funcionalidad.

En mi proyecto actual, en realidad nos estamos alejando de JBoss para Tomcat vanilla porque de todos modos nos dimos cuenta de que no estábamos utilizando ninguna de las funciones de Java EE más allá de los servlets básicos. Sin embargo, estamos usando Spring. Entre la gestión de objetos básica de Spring, el manejo de transacciones y las capacidades de JDBC, no vemos una necesidad imperiosa de EJB. Actualmente usamos Struts 2 en lugar de MVC de Spring, pero he escuchado cosas buenas sobre eso. En cualquier caso, Spring se integra bien con una serie de frameworks web Java.

Answer 2

Google abre fuentes de gran parte de su código. Si escribe cosas de bajo nivel usted mismo, en lugar de implementar el código que ya está escrito, a menudo está pensando demasiado en el problema.

Volviendo a la pregunta real, Walmart.com, etrade.com, The Weather Channel y quite a few others solo usan Tomcat. Las personas de marketing y ventas de IBM lo harían creer diferente, tal vez, pero no existe un límite máximo para Tomcat.

A excepción de EJB, no estoy seguro de qué es Tomcat y no soy seguidor de EJB.

Answer 3

Spring no intenta reemplazar ciertas partes avanzadas de la especificación JavaEE, como JMS y JTA. En cambio, se basa en ellos, haciéndolos coherentes con la "forma de primavera" y, en general, haciéndolos más fáciles de usar.

Si su aplicación requiere el poder de los gustos de JMS y JTA, entonces puede usarlos fácilmente a través de Spring. No hay problema con eso

Answer 4

Lo que tomcat no ofrece, aparte de los elementos más exóticos de Java EE, son los beans de sesión (también conocidos como EJB). Los beans de sesión le permiten aislar su procesamiento de manera eficiente. Por lo tanto, podría tener una casilla para el frente, otra para los beans de sesión (lógica comercial) y otra para la base de datos.

usted quiere hacer esto por lo menos 2 razones:

1. rendimiento; Está descubriendo que una caja para manejar todo está cargando demasiado la caja. Separar las diferentes capas en diferentes cajas le permitiría escalar. Los beans de sesión también pueden cargar el balance en un nivel de grano más fino. Tomcat y otros servicios web de esa índole no tienen clústers listos para usar.
2. Flexibilidad; Ahora que ha trasladado la lógica de su empresa a su propio entorno, podría desarrollar una interfaz alternativa que utilizara la misma capa, pero digamos que era una interfaz de cliente gruesa, por ejemplo. O tal vez otros contextos desearían utilizar los beans de sesión.

Aunque probablemente debería señalar que si utiliza servicios web para comunicarse con ese nivel medio, también podría estar en Tomcat.

Answer 5

Tal vez esto puede ser de su interés:

http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html

HTH

Answer 6

La única razón para utilizar un servidor completo soplado Java EE se si es necesario transacciones distribuidas XA, si no es necesario En las transacciones XA, puede usar Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail. También se supone que un servidor Java EE debe implementar JMS, pero no tiene sentido ejecutar el servidor JMS en la misma máquina virtual que el resto del servidor de aplicaciones, por lo que si necesita JMS, debe tener un servidor JMS por separado.

Answer 7

Estoy totalmente en desacuerdo con todas las respuestas dadas aquí.

Todo puede ser añadido a Tomcat, incluyendo EJB, CDI, JTA, Bean Validation, JAX-RS, etc.

La pregunta es: ¿Qué quiere esto? ¿Desea ensamblar todas esas dependencias en las versiones correctas y probar que todo funciona en conjunto, cuando otros ya lo han hecho?

Seamos claros: nadie usa solo Tomcat! Todo el mundo siempre agrega un marco web, un contenedor ioc, un orm, un administrador de transacciones, servicios web, etc.

Los servidores livianos Java EE como TomEE ya incluyen todo eso y hacen que la experiencia de pila completa tenga todas esas cosas integradas mucho mejor.