Entradas etiquetadas con comparativa

Servidores J2EE 7 Certificados (Junio 2015)

Hace ya un tiempo razonable desde la salida de la especificación 7 de J2EE. ¿Serán muchos los servidores que se hayan certificado? La verdad es que no. Me ha sorprendido que sean tan pocos. También me ha sorprendido la distribución. Pensaba que todos serian proyectos desarrollados por la comunidad, por aquello de que su ciclo de desarrollo suele ser mas rápido. En cambio, solo la mitad son open source. No me entretengo mas, veamos cuantos y cuales son:

GlassFish Server Open Source Edition 4.0

Logo de GlassFish

El servidor del pescado (a estas alturas ya sabreis que no es santo de mi devoción) fue el primero en conseguir la certificación. Cosa lógica, ya que se trata del demostrador tecnológico de Oracle. Así cualquiera. Ha sido probado en Solaris Sparc10 y 11, Windos XP y 2008, MacOS12.10, Ubuntu12.10, OracleLinux 6.3, Fedora 18 y openSUSE 10.2 con JDK 7 Update 21. Cumple con la especificación full profile y la web profile.

Wildfly 8

Logo oficial de WildFly

Logo oficial de WildFly

Wildfly fue concebido para ser J2EE 7 certificado desde el principio, así que no es una sorpresa encontrarlo en la lista. Este ha sido probado en Red Hat Enterprise Linux 6 (lógico también) con JDK 7 Update 45. También cumple con la especificación full profile y la web profile.

TMAX JEUS 8

Hace un par de años ya hablamos de este servidor de aplicaciones coreano. Yo nunca lo he usado (quizás porque no soy coreano) pero parece que en su país es muy popular. No cabe duda que se lo toman en serio si lo han certificado ya. Ha sido probado en Red Hat Linux Fedora 17 con JDK 7 Update 9. Esta certificado full profile.

Cosminexus 10

cosmi

De este también hablamos en el post que comentaba antes. Este servidor de aplicaciones es el otro comercial de la lista, propiedad de Hitachi. No te puedo decir mucho mas: la información que he encontrado (casi todo en su página) hace casi siempre referencia a versiones antiguas. Probado en Windows 7, 8, 8.1, 2008, 2008 R2, 2012, 2012 R2, Red Hat Enterprise Linux Server 5 y 6 y AIX 6.1 y 7.1.

¿Cambiara esto pronto? Pues yo espero que para final de año se hayan añadido bastantes servidores a la lista: WebSphere, JBoss y TomEE no creo que tarden mucho. Otros ya veremos. Hagan sus apuestas. Por mi parte, intentare acordarme cuando llegue el final de año y repasare la lista.

Los servidores mas usados en 2015 segun Plumbr

Hace un par de años ya te hablé de Plumbr, la herramienta de detección de memory leaks para aplicaciones java, y de sus estadísticas. Los resultados han cambiado bastante con respecto a años anteriores, pero puede deberse al cambio de rol de la herramienta. Si hace dos años se trataba de una herramienta de desarrollo, ahora es mas una solución de motorización, así que cada vez refleja mas lo que nos podemos encontrar en entornos de producción.

Han analizado 758 instalaciones y han conseguido identificar el proveedor de 554 de ellas. Cosas destacables: Tomcat pasa del 40% al 60% de las instalaciones, Jetty se queda a un tercio de los resultados anteriores y WebLogic dobla su presencia.

La situación actual es esta (pulsa para agrandarla):

 

Utilización de servidores de aplicaciones en 2015. Fuente: Plumbr

Utilización de servidores de aplicaciones en 2015. Fuente: Plumbr

 

Y la evolución temporal esta:

 

Evolución de los servidores de aplicaciones hasta 2015. Fuente: Plumbr

Evolución de los servidores de aplicaciones hasta 2015. Fuente: Plumbr

 

Con respecto a la versión del JDK utilizado, nos encontramos la evolución esperada en términos de adopción de nuevas versiones, y alguna cosa que directamente da miedo. Para empezar, Java7 domina domina el mercado, habiendo tocado techo. Java8 va subiendo y Java6 camino de desaparecer. Como te decía, lo esperado.

La situación actual es esta:

 

Utilización de las versiones del JDK en 2015. Fuente: Plumbr

Utilización de las versiones del JDK en 2015. Fuente: Plumbr

 

Y la evolución temporal esta:

 

Evolución de las versiones del JDK hasta 2015. Fuente: Plumbr

Evolución de las versiones del JDK hasta 2015. Fuente: Plumbr

 

Ya hora lo que me ha dado miedo: mira las versiones de Java7 que se están usando:

 

Utilización de las diferentes versiones de Java7 en 2015. Fuente: Plumbr

Utilización de las diferentes versiones de Java7 en 2015. Fuente: Plumbr

 

Prácticamente nadie utiliza la ultima versión y el 20% de los servidores están utilizando versiones anteriores a la 1.7.0_45, que contienen mas de 100 bugs de seguridad que son perfectamente conocidos y explotables. Por favor, actualiza tu base de servidores siempre que sea posible. Ganaras en tranquilidad. Si no quieres o no puedes mirar continuamente la página de Oracle, puedes suscribirte al blog y yo te avisaré.

Puedes ver los artículos completos aquí y aquí.

Oracle no dará soporte comercial para Glassfish 4

Logo de GlassFishEn este blog se ha hablado bastante acerca de la idoneidad de utilizar Glassfish en entornos de produccion. Durante este ultimo año, Oracle no ha hecho sino promover su utilización en cuanto evento de Java (suyo o ajeno) haya asistido. Se han publicado vídeos sobre casos de éxito, documentación a mansalva… de todo. Muchos, entre los cuales me incluyo, siempre hemos dudado de elegir Glassfish fuera una buena elección. Los que llevamos algún tiempo en esto recordamos que Glassfish era un demostrador tecnológico, una implementación de referencia de SUN. Un servidor de aplicaciones “de juguete”, si se me permite la expresión. Todos nuestros temores se han confirmado.

Coincidiendo con la actualización del roadmap de Java y Glassfish, Oracle ha hecho publico que a partir de Glassfish 4, no ofrecerá soporte comercial para la plataforma. Aquellas organizaciones que tengan contratado soporte para versiones anteriores no tienen de que preocuparse (de momento) pues seguirán disponiendo de él hasta que llegue la EOL del producto.  Podéis ver aquí el anuncio: Java EE and GlassFish Server Roadmap Update. El articulo es relativamente largo (no te pierdas los comentarios), pero de entre todo lo que se puede reseñar me quedo con esto:

Commercial Java EE 7 support will be provided from WebLogic Server

Efectivamente: si quieres un servidor de aplicaciones con soporte, usa WebLogic. Inmediatamente después del anuncio, el mundo java se incendió. javaHispano, un sitio que te recomiendo aunque no seas desarrollador, también se hizo eco de la noticia. Ante la avalancha de criticas, Oracle respondió en uno de sus blogs con otro articulo: 6 Facts About GlassFish Announcement. Básicamente nos dice que somos unos exagerados, que hay otros servidores que tampoco tienen soporte y se siguen usando, que si usabas Glassfish te puedes pasar fácilmente a WebLogic, que WebLogic no es tan caro… Creo que no han entendido cual es el problema: que la gente se siente engañada.

Comparativa de servidores de aplicaciones Java EE 6

He venido observando que muchos de los que entráis en el blog lo hacéis buscando una comparativa de servidores. Hace pocos meses, a través de javaHispano, encontré este post en el blog de Markus Eisele. En la entrada va explicando cuales son las necesidades que tiene y a partir de un listado de servidores de aplicaciones los va descartando hasta identificar aquellos que las cumplen. Lógicamente, si tus requerimientos son distintos también lo serán tus conclusiones. Pero la lista de servidores y características que se ha molestado en hacer seguro que te sirve de punto de partida.

Comparativa de servidores de Markus Eisele

Comparativa de servidores de Markus Eisele

A día de hoy, WildFly aun no se distribuye. Pero si ves que falta algún otro, deja un comentario y lo busco. Mientras mas completo sea el listado, mejor. Y si no recuerdas lo que significan los profiles, puedes volver a leer esta entrada.

Comparativa de rendimiento entre Tomcat y TomEE

Introducción

Hace algún tiempo presente TomEE en un par de entradas. Por si no lo recuerdas, TomEE es un servidor J2EE Web Profile certificado construido encima de Tomcat. Básicamente se trata de un Tomcat con librerías añadidas.

Pues a raíz de esto me preguntaron si todo lo añadido a TomEE le penalizaba a la hora de ejecutar aplicaciones con respecto a Tomcat. ¿La aplicación practica de esto? Por ejemplo, si tengo en una maquina un Tomcat y un TomEE, es importante saber si lo que gano consolidando todas las aplicaciones en el TomEE se pierde por el overhead de este. En general esto es algo que yo no haría: prefiero tener las aplicaciones separadas en varios servidores de aplicaciones en lugar de en uno enorme. Sin embargo, puede haber casos en que resulte útil una consolidación como esta.

Así que me dispuse a comprobarlo. Utilizando una aplicación de prueba, la ejecute en TomEE 1.5.1 y en su Tomcat equivalente 7.0.34. Ambos los configure con el mismo JDK (jdk1.6.0_43) y con la configuración por defecto de memoria. El único cambio ha sido la utilización de JMX para la motorización. Para las pruebas utilice JMeter, un proyecto de la fundación Apache para pruebas de carga.

Resultados

Como en otras ocasiones, los resultados de las pruebas per se e incluso la prueba no tienen valor alguno: lo importante es la comparación entre ambos servidores.

Primero veamos el comportamiento de cada servidor durante la prueba. Primero Tomcat:

Comportamiento de Tomcat durante la prueba

Comportamiento de Tomcat durante la prueba (pulsa para agrandar)

Ahora TomEE:

Comportamiento de TomEE durante la prueba

Comportamiento de TomEE durante la prueba (pulsa para agrandar)

Veamos esto en una tabla comparativa:

Tomcat Tomee
Espacio en disco: 14 M 35 M
Tiempo de arranque: 6069 ms 16408 ms
Heap utilizado 50 – 115 M 50 – 100 M
Non-Heap utilizado 60 M 60 M
CPU utilizado 20 – 60 % 20 – 60 %
Clases cargadas 8079 9683
Hilos lanzados 39 44
Ficheros servidos por segundo 90,58 92,04
Kb servidos por segundo 1641,64 1668,93

Conclusión

Como puede verse, a pesar de que TomEE carga un mayor numero de clases y utiliza mas hilos en su ejecucion, el consumo de CPU y memoria es prácticamente idéntico, así como el comportamiento de la aplicación. Es decir, podemos instalar en TomEE aplicaciones que tradicionalmente irían en un Tomcat sin miedo a la perdida de recursos o rendimiento, con poco de penalización de espacio en disco/backups.

Ir arriba