Servidor de aplicaciones JBoss/WildFly

Publicado por pico.dev el , actualizado el .
java programacion software planeta-codigo
Comentarios

WildFly

Para una pequeña (o no tan pequeña) aplicación web desarrollada en la plataforma Java un servidor como Tomcat o Jetty es suficiente. Pero una aplicación grande o un entorno empresarial probablemente empiece a requerir funcionalidades que Tomcat no proporciona de por si. En algunos casos una librería puede suplir esta carencia, este podría ser el caso de Hibernate para la persistencia o Apache Shiro para la seguridad de la aplicación. Sin embargo, cuando sea posible y tenga sentido es buena idea seguir alguna de las especificaciones o APIs que proporciona la plataforma Java EE ya que de esta manera podremos cambiar de implementación sin necesidad de modificar el código de la aplicación y permite integrar dos sistemas diferentes si ambos siguen una determinada especificación. Un ejemplo podría ser el caso de Hibernate con la especificación JPA que proporciona una funcionalidad equivalente (de hecho esta especificación se basa en Hibernate y se puede usar Hibernate como implementación a través de la API que define JPA) o de integración de sistemas con JMS.

Los servidores de aplicaciones se pueden distinguir por la cantidad de especificaciones que implementan, sus versiones, perfiles y la versión de Java EE que cumplen. Por una parte tendríamos los contenedores de servlets y JSP como podrían ser Apache Tomcat y Jetty, estos cumplen con un perfil web e implementan una parte de las especificación que engloba Java EE. Por otra parte están los servidores que cumplen con toda las especificaciones que define Java EE y se les suele denominar full profile o perfil completo. Ejemplos de servidores de aplicaciones full profile son:

  • Glashfish: la implementación de referencia de un servidor de aplicaciones.
  • Weblogic: el servidor de aplicaciones propietario que adquirió Oracle con la compra de la antigua BEA Systems.
  • Apache Geronimo: servidor de aplicaciones proporcionado por la fundación Apache. Las implementaciones de las especificaciones son proporcionadas por muchos de los proyectos de la propia fundación.
  • JBoss/WildFly: servidor de aplicaciones que adquirió RedHat de la comunidad JBoss pero al contrario que Oracle y Weblogic con licencia libre de software libre.

De la plataforma Java EE hay varias versiones que a medida que se van publicando mejoran y amplían las especificaciones que ya estaban disponibles en una versión anterior o se incluyen nuevas especificaciones que han de soportar los servidores de aplicaciones si quieren certificarse como full profile. La última versión al momento de escribir esta entrada es la Java EE 7 publicada en abril de 2013. En la introducción y nuevas características de Java EE comento un poco más, aunque este listado no es completo las especificaciones más destaclables son:

  • JSF (2.2): para desarrollar aplicaciones web sucesor de los JSP.
  • Servlets (3.1) y JSPs (2.3): los servlets son la base a partir de la cual desarrollar aplicaciones web dinámicas y los JSP una forma de servlet en el que la mayor parte de el código HTML, similar a PHP.
  • CDI (1.0): proporciona inyección de dependencias de forma parecida a frameworks como Spring.
  • EJB (3.2): beans gestionados por un contenedor administrando su ciclo de vida y proporcionales funcionalidades como persistencia y transacciones. Suelen usarse para incluir la lógica de negocio de la aplicación.
  • Bean Validation (1.1): funcionalidad que mediante anotaciones permite indicar restricciones sobre los valores que pueden contener los beans.
  • JPA (2.1): especificación que proporciona persistencia en una base de datos.
  • JTA (1.2): especificación que proporciona transaccionalidad.
  • JMS (2.0): especificación que permite a las aplicaciones comunicarse mediante mensajes de forma desacoplada.
  • JAX-RS (2.0): especificación sobre los servicios web basados en el modelo REST sobre el protocolo HTTP.
  • JAX-WS (1.3): especificación sobre servicios web basados en XML.
  • JavaMail (1.5): especificación para el envío de mensajes de correo electrónico.

De entre los servidores de aplicaciones mencionados anteriormente JBoss o WildFly, la versión para la comunidad, es una muy buena opción, arranca tremendamente rápido (unos 10 segundos, no mucho más que un Tomcat que ofrece muchas menos funcionalidades), tiene una licencia de software libre, ofrece soporte empresarial y detrás está una compañía que claramente apuesta por el software libre en su modelo de negocio. En la última versión de JBoss, la 7.1, y 8 de WildFly ya no se producen los errores de conflictos entre librerías que se producían anteriormente con el classpath hell, ya que en vez de seguir un modelo jerárquico como antes sigue un modelo OSGi con JBoss Modules. Ahora se basa en módulos y cada war, ear o jar está aislado del resto. Puede administrarse mediante linea de comandos y a través de una consola web evitándose los conflictos. Para diferenciar más claramente la versión comercial de la ofrecida a la comunidad JBoss ha pasado a llamarse WildFly para la versión de la comunidad y la relación con JBoss será similar a la que tienen RHEL con Fedora y desde hace poco con CentOS.

A continuación unas pocas capturas de pantalla de la página de inicio de WildFly y de la consola de administración:

En las notas de publicación de WildFly 8 pueden consultarse las numerosas e interesantes funcionalidades añadidas. También en el siguiente vídeo se explican muchos de los detalles que incorpora.

En posteriores entradas y siguiendo la serie de entradas de seguridad (I, II, III, IV, V y VI) comentaré como crear certificados para usarlos con el protocolo seguro SSL y como configurar diferentes servidores web y de aplicaciones Java, entre ellos WildFly, para usar SSL y el protocolo HTTPS.