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

StackOverflow https://stackoverflow.com/questions/1820771

Pregunta

Últimamente he estado leyendo / aprendiendo más sobre Spring, y cómo se 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 sospeché que nuestra solución está sobredimensionada y es MUCHO más compleja de lo necesario. Sorprendentemente, es 2009 y, sin embargo, estamos escribiendo nuestras propias clases de manejo de transacciones y agrupación de subprocesos. Y no es como si fuéramos Amazon, eBay o Google, si sabes a lo que me refiero. Por lo tanto, estoy investigando un "más simple es mejor" opción.

Entonces, esta es mi pregunta: me gustaría escuchar opiniones sobre cómo toma 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 pesado? ¿Es necesario que una aplicación llegue antes de que levantes las manos y te rindas y digas, "OK, Tomcat simplemente no lo está cortando, necesitamos JBoss / WebLogic / WebSphere"?

¿Fue útil?

Solución

No creo que la decisión de utilizar un servidor Java EE completo o no deba basarse en el número 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 a Vanilla Tomcat porque nos dimos cuenta de que de todos modos no estábamos usando ninguna de las funcionalidades Java EE más allá de los servlets básicos. Sin embargo, estamos usando Spring. Entre las funciones básicas de gestión de objetos, manejo de transacciones y JDBC de Spring, no vemos una necesidad imperiosa de EJB. Actualmente utilizamos Struts 2 en lugar del MVC de Spring, pero he escuchado grandes cosas al respecto. En cualquier caso, Spring se integra bien con una serie de marcos web Java.

Otros consejos

Spring no intenta reemplazar ciertas partes avanzadas de la especificación JavaEE, como JMS y JTA. En cambio, se basa en esos, haciéndolos consistentes con la "Spring way", y generalmente haciéndolos más fáciles de usar.

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

Google abre fuentes mucho de su código. Si está escribiendo cosas de bajo nivel usted mismo, en lugar de implementar 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 bastantes otros solo use Tomcat. Los chicos de marketing y ventas de IBM te harán creer diferente, tal vez, pero no hay un límite superior para Tomcat.

Excepto por EJB, no estoy seguro de qué falta Tomcat, y no soy fanático de EJB.

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. Entonces podría tener un cuadro para el front-end, otro para los beans de sesión (lógica de negocios) y otro para la base de datos.

Debería hacer esto por al menos 2 razones:

  1. Rendimiento; Estás descubriendo que una caja para manejar todo está cargando demasiado la caja. Separar las diferentes capas en diferentes cajas le permitirá escalar. Los beans de sesión también pueden equilibrar la carga a un nivel de grano más fino. Tomcat y otros servicios web de ese tipo no tienen agrupación fuera de la caja.
  2. Flexibilidad; Ahora que ha movido la lógica de su negocio a su propio entorno, podría desarrollar un front-end alternativo que usara la misma capa, pero, por ejemplo, era un front-end de cliente grueso, por ejemplo. O tal vez a otros contextos les gustaría hacer uso de los beans de sesión.

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

La única razón para usar un servidor Java EE completo es si necesita transacciones XA distribuidas, si no necesita transacciones XA, puede usar Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Correo.

También se supone que un servidor Java EE implementa 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 separado.

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

Todo se puede agregar a Tomcat, incluidos EJB, CDI, JTA, Bean Validation, JAX-RS, etc.

La pregunta es: ¿quieres 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! Todos siempre agregan un marco web, un contenedor ioc, una orm, un administrador de transacciones, servicios web, etc., etc.

Los servidores ligeros Java EE como TomEE ya incluyen todo eso y hacen que la experiencia completa de tener todas esas cosas se integren mucho mejor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top