framework - Pila Java EE 6 vs. Spring 3

spring framework (16)

Necesito algo ligero, entonces no hay EJB o Seam.

¿Te importaría explicar qué hace que los EJB sean pesados desde EJB3? ¿Te das cuenta de que ya no estamos en 2004? Realmente me gustaría leer su definición de la luz y sus argumentos (y actualizaré mi respuesta con placer porque estoy bastante seguro de que tendría algunas cosas sólidas que decir).

Por otro lado, necesito JPA (Hibernate o alternativa) y JSF con IceFaces.

El perfil web Java EE 6, que incluye JSF 2.0, JPA 2.0, validación de beans, EJB 3.1 Lite, CDI, ... sería perfecto para esto y puede usar GlassFish v3 Web Profile para ejecutar una aplicación creada con el perfil web de Java EE 6 .

¿Crees que esa pila en Spring 3 implementada en Tomcat es una buena opción? ¿O una aplicación web Java EE 6 podría ser mejor?

Bueno, me gusta la idea de ejecutar mi código en una plataforma no propietaria (Java EE) en lugar de en un contenedor patentado (Spring). Y creo que Java EE 6 es lo suficientemente bueno (y esto es un eufemismo, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Tenga en cuenta que yo era un escéptico JSF, pero eché un segundo vistazo y JSF 2.0 con CDI es tan diferente que ni siquiera puedo comparar. Y si no miraste a CDI, déjame decirte que es genial.

Me temo que Java EE 6 es una nueva tecnología, aún no está bien documentada.

Java EE parece bastante bien documentado para mí. Esto suena como reclamo gratuito. Y, créanme o no, empiezo a ver que Spring se complica mientras que Java EE se vuelve más fácil.

Tomcat parece ser más fácil de mantener que Glassfish 3.

¿Probaste algo? ¿Tuviste algún problema en particular? Nuevamente, esto suena como reclamo gratuito.

Estoy comenzando un nuevo proyecto ahora. Tengo que elegir tecnologías. Necesito algo ligero, entonces no hay EJB o Seam. Por otro lado, necesito JPA (Hibernate o alternativa) y JSF con IceFaces.

¿Crees que una pila así en Spring 3 implementada en Tomcat es una buena opción? ¿O una aplicación web Java EE 6 podría ser mejor? Me temo que Java EE 6 es una nueva tecnología, aún no está bien documentada. Tomcat parece ser más fácil de mantener que Glassfish 3.

¿Cual es tu opinion? ¿Tienes alguna experiencia?

¿Por qué todavía hay rumores de que EJB sea un peso pesado en 2010? Parece que las personas no están siendo actualizadas en las tecnologías Java EE. Pruébelo, le sorprenderá gratamente cómo se simplifican las cosas en Java EE 6.

Ahora, después de un tiempo, tengo experiencia con stacks:

Java EE 5 + Seam + GraniteDS + Flex
Spring 3 + Vaadin (en GWT)
Spring 3 + JSF 2.0 (PrimeFaces)

Mis colclusiones son:

Spring 3 es mucho más simple que Seam (casi Java EE 6) y se ejecuta en Tomcat y Jetty. (Jetty for developement con el plugin maven es un juego de azar).
Me encanta Flex (en realidad, fui desarrollador de Flex durante mucho tiempo, por lo que soy parcial) y si necesitas una interfaz completa y puedes comprar FlashBuilder, utiliza esto, pero utiliza este elemento de fondo Spring + GraniteDS o BlazeDs. Si no puede comprar FlashBuilder, no pierda su tiempo.
Vaadin es genial !. El proceso de desarrollo es más simple que Flex, pero puede crear aplicaciones ricas fácilmente sin desorden de HTML. No escribirás una línea JS singe. Solo necesitas CSS (en Flex lo necesitas también). Entonces, si la interfaz de su aplicación se va a comportar como una aplicación de escritorio y no puede (o no quiere) usar Flex - use Vaadin. ¡Advertencia! Vaadin tiene grandes gastos generales JS para el navegador.
Si crea aplicaciones similares a las de un sitio web, use JSF2.0 (con el backend de la primavera como se indicó anteriormente). Tendrás que luchar con HTML (lo odio) y crear una interfaz enriquecida será más difícil que Vaadin (especialmente diseños). Obtendrá HTML ligero para navegadores / compuetrs más lentos. Me gusta PrimeFaces: es fácil y está bien documentado. El segundo lugar es IceFaces
Si crea un sitio web (NO una aplicación web) donde necesita darle vida a HTML (en lugar de crear una aplicación empresarial que encaje en el navegador) use Wicket (si prefiere la actitud basada en componentes) o SpringMVC (si prefiere plantilla basada , push attitude) o simplemente usa Play! marco de referencia. Recuerde que la creación de componentes ricos en datos será mucho más difícil, pero tendrá control sobre cada etiqueta de html (su diseñador de HTML / Gráficos le encantará)

He trabajado tanto en Spring como en Java EE 6. Lo que puedo decir de mi experiencia es que si opta por la antigua JSP o la Flex propietaria, estará seguro si se queda con Spring.

Pero si quiere avanzar con JSF, entonces es hora de cambiar a Java EE 6. Con Java EE 6, se está moviendo a Facelets y bibliotecas de scripts estandarizados y bibliotecas de componentes. No más incompatibilidades de scripts y matrices de biblioteca de componentes.

Con respecto a Spring MVC, es bueno siempre que su proyecto no crezca demasiado. Si se trata de una gran aplicación empresarial, adhiérase a Java EE 6. Porque esa es la única forma en que puede mantener sus propias bibliotecas de componentes y paquetes de recursos de manera ordenada.

Lea el Future Of Enterprise Java de Adam Bien ... Es claro (Java EE con / sin Spring y Vice Versa) , incluidos los comentarios para obtener ambos lados de la moneda. Elegiré Spring por varias razones y el siguiente es una de ellas (reproduciendo uno de los comentarios de la publicación)

''No estoy seguro de qué servidor Java EE 6 estás hablando. Hay Glassfish certificado y TMAX JEUS. Llevará bastante tiempo (leer: años) hasta que las versiones compatibles con Java EE 6 de WebSphere, WebLogic, JBoss, etc. estén en producción y puedan utilizarse para aplicaciones reales. Spring 3 solo necesita Java 1.5 y J2EE 1.4, por lo que puede usarse fácilmente en casi todos los entornos

Mi opinión se basa en algo que los demás no mencionan, a saber, que el código de mi trabajo tiende a vivir durante décadas (literalmente) y, por lo tanto, el mantenimiento es muy importante para nosotros. Mantenimiento de nuestro propio código y de las bibliotecas que utilizamos. Nuestro propio código lo controlamos, pero nos interesa que las bibliotecas que utilizamos sean mantenidas por otros en las décadas mencionadas anteriormente o más.

Para abreviar, he llegado a la conclusión de que la mejor manera de lograrlo es mediante el uso de implementaciones de código abierto de las especificaciones de Sun hasta la JVM en bruto.

De las implementaciones de código abierto Apache Jakarta ha demostrado mantener sus bibliotecas, y recientemente Sun ha trabajado mucho para producir implementaciones de alta calidad para Glassfish v3. En cualquier caso, también tenemos la fuente para todos los módulos, de modo que si todo lo demás falla, podemos mantenerlos nosotros mismos.

Las especificaciones de Sun suelen ser muy estrictas, lo que significa que las implementaciones que se ajustan a la especificación pueden intercambiarse fácilmente. Solo eche un vistazo a los contenedores de servlets.

En este caso particular, sugiero echarle un vistazo a JavaServer Faces simplemente porque es parte de Java EE 6, lo que significa que estará disponible y se mantendrá por un tiempo muy, muy largo. Luego, hemos decidido aumentar con MyFaces Tomahawk, ya que ofrece algunas adiciones útiles, y es un proyecto de jakarta.

No hay nada de malo con JBoss Seam u otros. Es solo que su enfoque es menos hacia el tema de mantenimiento que es tan importante para nosotros.

No he usado JavaEE6.

Sin embargo, todas las versiones anteriores de JavaEE y EJB me han golpeado lo suficiente como para no confiar en él hasta que se establezca como el estándar de facto, no solo como el estándar de jure. En este momento, Spring sigue siendo el estándar de facto.

Si me engañas una vez, la culpa es tuya. Si me engañas dos veces, la culpa es mía. Tómeme tres veces, EJB.

Algunos afirmarán que Spring es propietario. Yo diría que las implementaciones de los proveedores de las especificaciones de JavaEE han sido tan patentadas, si no más.

Pasé por una importante conversión recientemente al mover un montón de aplicaciones Java de JBoss a Weblogic. Todas las aplicaciones de Spring / Hibernate se portaron con cero modificaciones, porque tenían incorporadas todas las bibliotecas que necesitaban. Todas las aplicaciones que usaban JPA, EJB y JSF fueron un desastre a babor. Las diferencias sutiles en las interpretaciones de JPA, EJB y JSF entre los servidores de aplicaciones causaron todo tipo de errores desagradables que demoraron para siempre en corregirse. Incluso algo tan simple como la denominación JNDI era completamente diferente entre los AppServers.

Spring es una implementación. JavaEE es una especificación. Es una diferencia enorme. Preferiría usar una especificación SI la especificación era 100% hermética al aire y no daba lugar a ningún margen de maniobra en la forma en que los proveedores implementan esa especificación. Pero la especificación JavaEE nunca ha sido eso. ¿Tal vez JavaEE6 es más hermético? No lo sé. Cuanto más pueda empaquetar en su WAR, y cuanto menos dependa de las bibliotecas de AppServer, más portátil será su aplicación y, después de todo, es la razón por la que uso Java y no Dot-NET.

Incluso si la especificación fuera hermética, sería bueno poder actualizar el servidor de aplicaciones sin tener que actualizar todas mis pilas de tecnología en todas mis aplicaciones junto con ella. Si quiero actualizar de JBoss 4.2 a JBoss 7.0, tengo que considerar el impacto de la versión más nueva de JSF en todas mis aplicaciones. No tengo que considerar el impacto en mis aplicaciones Spring-MVC (o Struts).

No importa. Java EE 6 es lo suficientemente bueno y debido a los perfiles que tiene, no es "pesado", solo usará el perfil web.

Personalmente, prefiero Spring. Pero me estoy quedando sin argumentos racionales contra Java EE 6 :)

(Como me recordó un comentario, es posible que desee probar RichFaces , así como ICEfaces y / o PrimeFaces , dependiendo de qué componentes necesite).

No lo leí todo, solo para decirle que ahora puede usar EJB3 dentro de una guerra en Java EE 6 para que pueda usar EJB3 en Tomcat (creo).

Puedo ver el uso de Spring si ya lo tienes, pero para el nuevo proyecto, ¿cuál es el punto? Me gustaría ir directamente con Java EE 6 (ejb3, jsf2.0, etc.)

Si el cliente está de acuerdo con Flex, adelante. Use BlazeDS o similar - no mvc. Puede pasar más tiempo en esa parte (intercambiando datos entre el servidor y el cliente) pero tiene control total en ambos lados.

No use Vaadin, a menos que quiera matar su navegador. Además, dedica más tiempo a revisar el código una vez que sus páginas se vuelven más complejas. Además, su modo de pensar tendrá que cambiar por completo y todo lo que sepa sobre el desarrollo de front-end estándar será un desperdicio. El argumento de que no tiene que usar HTML o JS no tiene mucho sentido. Aún debes saberlo aunque no lo uses. Se procesa en HTML y JS finalmente. Luego intenta depurarlo, asegúrate de tener algunos días para cosas simples. Además, no me puedo imaginar desarrollador web que no conozca html / js.

Simplemente no entiendo por qué las personas están probando todas esas abstracciones en lugar de usar Java EE directamente.

Recientemente, una de mis asignaciones de clientes implicó evaluar Spring Stack Vs Custom framework stack Vs a Java EE Standards. Después de un mes de evaluación y creación de prototipos, no solo estaba contento sino que me quedé impresionado con el conjunto de funciones de Java EE 6. Para cualquier nueva arquitectura de proyecto "empresarial" en 2011 y en adelante, iría con Java EE 6 y posibles extensiones como Seam 3 o el próximo proyecto de extensiones Apache JSR299. La arquitectura Java EE 6 está optimizada e incorpora la mejor de muchas ideas de código abierto que han evolucionado en los últimos años.

Considere las siguientes funciones de fábrica: gestión de eventos, contextos y DI, interceptores, decoradores, servicios web RESTful, pruebas integradas con contenedor incrustable, seguridad y muchos más.

La mayoría de mis resultados se publican en mi blog explicando los conceptos clave de Java EE 6 que pueden serle útiles.

Por supuesto, no existe una regla rígida para elegir un marco. Java EE 6 podría estar repleto de "sitios web" más simples que no requieren un rico estado de sesión conversacional. ¡También podrías elegir Grails o jugar! Marco de referencia. Pero para las aplicaciones web conversacionales, no puedo ver un argumento mejor sobre por qué Java EE 6 no es una buena opción.

Recomiendo Spring + Tomcat a menos que puedas esperar el momento para que glassfish v3 y Weld sean más maduros. Actualmente hay algunos problemas con el consumo de memoria / carga de la CPU cuando se ejecuta Glassfish con aplicaciones compatibles con CDI.

Si necesita la pila completa de Java EE, le recomiendo GlassFish 3.1. Comienza muy rápido en comparación con otros contenedores Java EE que implementa parte o la totalidad de Java EE 6 (JBoss 6, WebLogic 10.3.4), la reorganización demora segundos y casi todo se puede hacer por convención sobre configuración, es muy amigable.

Si desea algo "Light", puede personalizar un Apache Tomcat 7.x con las características deseadas. Utilicé mucho con las siguientes bibliotecas: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - solo transacciones locales de recursos JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

He sido desarrollador de Java EE durante los últimos 10 años (sufro las primeras tecnologías EJB, JSF y web), Java EE 6 es muy fácil, bien acoplado y el hardware actual funciona sin problemas, por lo que las razones originales que motivaron Spring ya no son válidas.

Te recomendé Tomcat con Spring porque:

Spring puede crear fondos de respaldo para JSP
Utilizará Spring para persistir el objeto a través de JPA

Es una buena elección elegir Tomcat porque no necesita ningún procesamiento pesado

Todavía preferiría Spring.

Y pasaría JSF. Creo que es una tecnología muerta. Spring MVC sería una mejor alternativa. También lo haría Flex. Piense en términos de contratar primero servicios XML y puede desacoplar por completo el back end de la IU.

La respuesta a sus preguntas depende de los requisitos de su proyecto. Si no necesita las características de Java EE, como las colas de mensajes, las transacciones globales administradas por contenedor, etc., vaya con Tomcat + Spring.

También por experiencia, he encontrado que los proyectos que requieren mucha integración de servicio web, programación y colas de mensajes se hacen mejor usando parte de la pila Java EE. Lo bueno es que al usar Spring todavía puede integrarse con módulos Java EE que se ejecutan en un servidor de aplicaciones.

Java EE 6 es muy diferente de las versiones anteriores, y realmente hace que todo sea mucho más fácil. Java EE 6 combina las mejores ideas de la diversa comunidad Java; por ejemplo, Rod Johnson del framework Spring participó activamente en la creación de Dependency Injection JSR en Java EE 6. Una ventaja del uso de Java EE 6 es que usted está codificando de acuerdo con un estándar, que podría ser importante en algunas organizaciones para el soporte de proveedores, etc.

GlassFish v3 es compatible con Java EE 6 y es bastante liviano y se inicia muy rápido. He estado usando glassfish v3 para mis desarrollos, y es muy fácil de configurar. Viene con una consola de administración muy fácil de usar que te permite administrar gráficamente tu servidor.

Si está utilizando GlassfishV3 y JSF 2, puede aprovechar las funciones de CDI de Java EE 6, que le permiten crear fácilmente conversaciones (por ejemplo, páginas de tipo asistente) en JSF.

Habiendo dicho eso, usar Java EE 6 también requiere que aprendas una nueva API. Dependiendo del margen de tiempo disponible, puede que no sea la mejor opción para usted. Tomcat ha existido durante siglos, y la combinación de tomcat + spring ha sido adoptada por muchos proyectos web, lo que significa que hay una gran cantidad de documentación / foros disponibles.