Revisión de servidores de aplicaciones Java EE 6
AbrahamAntonio Goncalves, líder del París JUG, JavaChampion y autor de varios libros sobre Java EE, ha escrito en su blog una revisión de todos los servidores de aplicaciones con soporte para Java EE, tanto los que soportan la aplicación al completo como los que soportan el web Profile. La revisión incluye servidores que han pasado ya el Java E E6 TCK (Oracle GlassFish Server 3.1.1, Caucho Resin 4.0.17, JBoss Application Server 7, Apache TomEE 1.0.0-beta-1, TMAX JEUS 7, IBM WebSphere Application Server 8.0, Fujitsu Interstage Application Server) como a algunos que no Geronimo 3, JOnAS 5.3, Siwpas.
Para cada servidor de aplicaciones Antonio muestra una ficha describiendo si soportan Java EE 6 y/o el Web Profile 1.0, el vendedor, la licencia, información sobre el vendedor, información sobre dónde descargarlo, el tamaño de la descarga, como arrancarlo, situación de los ficheros de log...
Además de haber creado una ficha para cada uno de los servidores Java EE 6 Antonio ha hecho un pequeño benchmark donde mide dos dimensiones de estos servidores de aplicaciones. Por un lado, el tiempo que tarda en arrancar:
Y por otro, el tamaño que ocupan tanto memoria como en el disco duro:
Como puede verse en los gráficos, el consumo de memoria de estos servidores de aplicaciones cada vez es más bajo. A raíz de esto Antonio hace una reflexión. Hace unos años para desarrollar aplicaciones Java EE uno tenía que instalar una base de datos al estilo de Oracle o MySQL en su equipo para desarrollar aplicaciones, lo que imponía bastante carga computacional al equipo y por tanto hace que perdamos bastante tiempo arrancando, parando y ejecutando consultas en la base de datos en tiempo de desarrollo.
Al día de hoy, para desarrollo muchas veces se emplean bases de datos cargadas en memoria al estilo de Apache Derby o H2, lo cual disminuye los tiempos de desarrollo. Antonio predice que en un futuro cercano los servidores de aplicaciones también estarán corriendo "en memoria" en tiempo de desarrollo, lo cual hará el desarrollo de aplicaciones Java EE más ágil.
¿Estáis de acuerdo con la opinión de Antonio?
Reader Comments (8)
Falta un enlace a la entrada de blog original, donde poder ver el informe completo y los enlaces. En el mismo, se puede leer, por ejemplo, la explicación de por qué Tomcat 7, que no es un servidor Java EE, aparece en las comparativas (como referencia). Lo aviso antes de que salte alguno con que "Tomcat 7 no es...". No, no lo es.
A mi personalmente gran parte de las comparativas me parecen... poco comparables. Comparar el espacio en disco de una instalación, o el tamaño en memoria por defecto... es anecdótico. Y si me apuras, sin homogeneizar los servicios que ponen en marcha todos los servidores al arrancar, comparar el tiempo de arranque es... bueno, anecdótico también.
Sí, sí, ya me conozco las excusas habituales "no pretende ser exhaustivo", "simplemente para hacerse una idea..." pero vamos, quizá algún día nos acerquemos a ser la ciencia que pretendemos que sea, pero de momento ni de lejos.
Lo de correr los servidores en memoria en desarrollo no lo he pillado... ¿te refieres a embebidos como parte del proceso de desarrollo? Por que si no los tienes ahora ejecutándose "en memoria", ya me dirás donde se están ejecutando ;)
Corregido lo del enlace. Y sí, lo de correr el servidor de aplicaciones en memoria sería básicamente hacer lo mismo que hace Derby, comparado frente a, por ejemplo, MySQL.
Creo que la idea de "correr el servidor en memoria", se refiere a que los cambios que se realicen en el desarrollo se apliquen directamente al contenedor, de tal manera que el servidor de aplicaciones se "actualice" sobre la marcha.
Algo similar ya se puede hacer con aplicaciones de NetBeans Platform y Javeleon:
- Se lanza la aplicación de escritorio en ejecución
- Se realizan cambios en el IDE
- Javeleon actualiza los cambios de manera directa e inmediata en la aplicación en ejecución.
No es necesario, en este caso, una nueva fase de stop-build-launch cada vez que se desarrollan modificaciones, o corrigen errores.
Hombre, yo creo que son cosas diferentes. Para poder hacer actualizaciones on-the-fly en las aplicaciones, no hace falta que ejecutes el servidor de aplicaciones dentro del IDE.
Pero volviendo al tema de "en memoria", una cosa eran las BDD que eran procesos externos a tu aplicación con sus instalaciones, comunicación y ahora se ejecutan en el mismo proceso (JVM) que tu aplicación, y otra son los servidores de aplicaciones, que ya se ejecutan en el mismo proceso que tu aplicación. De ahí que me pierda con lo de que se ejecutarán "en memoria"...
Una alternativa, como quedamos con Abraham, es que en vez de tener un servidor de aplicaciones donde haces deploy, ejecutes en desarrollo cada vez todo con un servidor de aplicaciones embebido que sólo monte tu aplicación. Hombre... cómodo es y es algo que ya se usa para los tests automáticos y otros temas (Wembed), pero para eso siguen haciendo falta contenedores ligeros de arrancar y despliegues rápidos... cosa que si tuviéramos entonces no estariamos hablando de esto por que no sería un problema hacer los re-deploys.
La otra alternativa es evitar hacer re-deploys pesados con cosas estilo JRebel y/o tecnologías que no requieran re-deploy para cada cambio (usar .war o .ear en desarrollo ya son ganas) pero eso no tiene nada que ver con ejecutar servidores de aplicaciones "en memoria".
En fin, que esa predicción no me queda nada clara.
les falto hacer de weblogic y como se despega !! por los cielos esas barras
Bueno. no he leido el post original pero creo que hay que decir que, por ejemplo, Glassfish proporciona muchísimas más funcionalidades y una consola mucho más amigable que tomcat. eso influye directamente en su tiempo de carga y en el consumo de memoria posterior.
¿y dónde está el Spring Framework?
A los servidores web de aplicaciones escritas en Java les faltan unas cuantas cosas:
1. Ausencia de modularización. Inversión de Control no es suficiente, falta cachear sólo aquellas librerías (o partes) que se necesitan durante el servicio tras el arranque.
2. Consultar qué librerías (o partes) no se utilizan durante su vida de servicio, con el fin de podarlas o removerlas.
No discutan mas, cámbiense a Ruby y se acabo el tema.....