Gavin King [1], el padre de Hibernate, recomendó que los desarrolladores actualicen a la plataforma Java EE 6 y señaló que la actual renuencia a actualizar es en realidad infundada.
Después del lanzamiento de Java EE 6, vi mucha resistencia a actualizar a la nueva plataforma. La mayoría de estas objeciones las plantean los usuarios de Tomcat/Jetty y algunos marcos de código abierto (como Hibernate y Spring).
Por supuesto, existen muchos beneficios al elegir tecnología de código abierto no estándar. Además, en EE 6, puede utilizar los marcos de código abierto que le interesen. Servlet 3 y CDI pueden integrar perfectamente marcos de terceros. Así que no hay razón para no utilizar EE 6. Aún así, vi a alguien decir:
Actualizar a EE Application Server es difícil
Esto parece ser una cuestión política para la organización específica más que una cuestión técnica real. Por supuesto, actualizar un servidor como GlassFish o JBoss es una tarea muy trivial. (Actualizar marcos de terceros es aún más doloroso). Algunas organizaciones tienen un proceso muy pesado para actualizar servidores, pero no tanto para actualizar los marcos que se ejecutan dentro de los servidores. Por lo tanto, es más fácil para el equipo de desarrollo actualizar los marcos de terceros.
Creo que lo más importante es desarrollar un proceso mejor y más convincente, en lugar de abandonar Java EE. Existen muchos riesgos asociados con la ejecución de su aplicación en una plataforma de servidor antigua y obsoleta, y el proceso no debería fomentar tales prácticas.
Pero desde una perspectiva práctica, casi todo el mundo está planeando actualizar a Servlet 3 en un futuro próximo. Ya sea que esté utilizando Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle o WebSphere, significa una actualización del servidor. Esta es una gran oportunidad para actualizar al perfil web EE 6, la época dorada.
El servidor de aplicaciones EE es demasiado grande
La objeción es que EE Server contiene muchas funciones que no están (actualmente) disponibles. Los argumentos de los oponentes generalmente implican discutir el tamaño del paquete jar y el espacio en disco ocupado por el motor Servlet + el marco de terceros y el servidor de aplicaciones EE. De hecho, este argumento es problemático:
El uso del disco y el espacio en disco discutidos son en realidad triviales cuando se miden en $, y el paquete de guerra de la aplicación es mucho más importante que el tamaño del paquete de instalación del servidor. El servidor en realidad contiene muchas funciones para minimizar el tamaño de la guerra.
Además, creo que lo más convincente es que Java EE 6 Web Profile no es nada enorme. Una vez que los servidores Web Profile certificados estén en el mercado, podremos encontrar un equilibrio entre grandes servidores de aplicaciones EE y pequeños contenedores de Servlet.
¡Malos J2EE y EJB2!
Con el proceso de estandarización de JCP, este problema ya no existe:
1. ¡Han pasado 8 años desde que apareció EJB2! ¿Sigue siendo tu mejor opción?
2. Se han fusionado buenas especificaciones mediante la estandarización continua de JCP, y algunas de ellas se pueden utilizar con gran certeza. Sin embargo, JCP no tiene un éxito del 100% en la estandarización.
3. Todos los que trabajan en la plataforma EE 6 odian EJB2 y J2EE. Es por eso que la gente se une constantemente al JCP para ayudar a solucionar estos problemas. Por ejemplo, el fundador de Hibernate y autor de este artículo. ¿De verdad quieres darle una lección sobre EJB2? :-)
4. ¡Casi todas las personas que trabajan en Entity Beans ya están jubiladas!
De hecho, Java EE 6 Web Profile es suficiente. Si no prueba Java EE 6 usted mismo, realmente no podrá sentir los beneficios de EE6 para el desarrollo.
¡La portabilidad del servidor de aplicaciones es un misterio!
¿En realidad? ¿Vemos a muchas personas dividir sus aplicaciones e implementarlas en diferentes servidores de aplicaciones? Oh, he visto que eso significa portabilidad sin cambios de aplicaciones 100% impecables, un ideal platónico de portabilidad. Entiendo la debilidad por la verdad absoluta y los ideales platónicos, pero veamos primero los ejemplos.
A continuación se muestra una vista muy típica de un problema de portabilidad:
El 9% del código, el 85% de los metadatos externos son totalmente compatibles en diferentes plataformas de servidor y el 1% y el 15% restantes se pueden dividir adecuadamente.
0 % de código, 80 % de metadatos externos vinculados a una arquitectura de contenedor no estándar de un solo proveedor
Mientras dividía estos puntos, de repente quise cambiar el tema de esta sección de la portabilidad del servidor de aplicaciones es demasiado misteriosa como para que no me importe en absoluto la portabilidad de los contenedores. La idea de un cambio de tema confirma que el problema de la portabilidad del servidor es real y que será de gran utilidad para muchas organizaciones.
Siempre quise ver reseñas reales de EE 6 por parte de mantenedores técnicos que no son EE 6. Algunos de los argumentos mencionados anteriormente no provienen del mundo real, por lo que es difícil desencadenar debates sobre cuestiones técnicas reales del desarrollo de aplicaciones en la plataforma EE. La última ronda de especificaciones del JCP parece haber abandonado el campo anti-EE (¿temporalmente?), pero carece de respaldo fáctico para su éxito.
Nota del editor:
[1] Gavin King: fundador de Hibernate, miembro del Comité de Expertos de EJB3, uno de los miembros principales de JBoss, líder del marco Seam, líder de la especificación JSR-299 (CDI) y autor del libro "Hibernate in Action" .
Fuente: Deberías actualizar a Java EE 6