Armando una Plataforma SOA con Apache

http://www.apache.org/

Hoy me voy a desviar del tópico Java EE 6 de los post anteriores para meterme un poco en el mundo SOA (arquitecturas orientadas a servicios). Me desvío pero no demasiado porque me quedo en el mundo Java. Y si hablamos de Java, uno de los líderes indiscutidos del open source es la Apache Software Foundation.

SOA fue un estilo de arquitectura muy popular hace unos años, uno de los términos en boga como hasta hace nada Twitter, las bases de datos NoSQL o la nube. Como pasó y sigue pasando con muchos conceptos fue malinterpretado por gerentes, líderes de proyecto, arquitectos y programadores. Tras muchos proyectos fracasados, tras muchas empresas que dejaron a sus ESBs abandonados en algún servidor perdido con cuatro o cinco servicios desplegados (poco tiempo después de que se anunciaban los marketineros casos de éxito), nos paramos un segundo a pensar y nos preguntamos: ¿Sirve SOA?

No voy a discutir sobre eso ahora, pero hay varios debates muy buenos que pueden leer si les interesa: SOA is Dead?, Debate: Is SOA Dead?,  Is SOA Dead as a Term but Alive as a Concept?, Does BPM-in-the-Cloud Require RESTful Services?

SOA sí sirve, pero no como un producto de moda y sí como lo que es: un estilo de arquitectura. El software sufre hoy el aceleramiento exponencial que sufre el ser humano del siglo XXI y que la misma industria de software potenció (pero más la industria del hardware). SOA como un concepto necesitaba un tiempo de maduración. Entender SOA como una filosofía, como un nuevo paradigma, como una nueva forma de concebir el desarrollo de software, lleva tiempo. Por eso, cuando SOA se lanzó la década pasada, a toda velocidad, se mezcló demasiado con Web Services.

Por todos lados se dice que SOA no es un producto. SOA no es los productos que voy a mencionar en breve de Apache, SOA no es la SOA Platform de JBoss, SOA no es una suite costosa de Oracle. Y es verdad. Vuelvo a repetir: SOA es un estilo de arquitectura. Pero así como a nadie se le ocurriría desarrollar un ERP o un CRM con Assembler, hoy en día nadie pensaría implementar SOA con tan sólo un lenguaje de propósito general (GPL) como es Java, C o Python.

Para cerrar con este extenso preámbulo, imaginemos que decidimos implementar SOA en una empresa y que vamos a usar todos productos Open Source. Una opción podría ser la de JBoss, que mencioné en el párrafo anterior, con su HornetQ, su JBoss ESB, una cucharada de Smooks por aquí, otra de Drools por allá; todo esto vendido por Red Hat como la SOA Platform. Otra opción es la que me da la excusa para escribir este post: la Apache SOA Platform (este nombre lo acabo de inventar).

Apache ActiveMQ

http://activemq.apache.org/

ActiveMQ es la plataforma de mensajería de Apache, un broker de mensajería, orientado al intercambio de mensajes asincrónicos (MOM: Message-Oriented Middleware). Un broker de mensajería permite que distintas aplicaciones y componentes se comuniquen entre sí en tiempo real, desacopladamente, mediante el envío y recepción de mensajes, sin conocer previamente quiénes participan en el proceso.

ActiveMQ provee una implementación de la especificación JMS y un conjunto de funcionalidades adicionales como destinos dinámicos, consumidores retroactivos, grupos de mensajería, políticas de entrega repetitiva y mucho más. Provee APIs clientes para una variedad bien grande de lenguajes y tecnologías (Ajax, C++, Python, PHP, WebSockets y un largo etcétera) y también de protocolos de transporte, como HTTP, UDP, SSL, Multicast, etc.

Una tecnología de este tipo provee alta escabilidad. Los productores y consumidores no necesitan conocerse entre sí, los participantes pueden conectarse y desconectarse dinámicamente y hasta se puede armar una red de brokers capaces de autodescubrirse entre sí, formando distintas topologías.

Apache Camel

http://camel.apache.org/

Apache Camel es un framework para construir soluciones de integración y enrutamiento. Con él se pueden definir flujos de integración en múltiples lenguajes como XML, Java, Scala, etc. Básicamente implementa los patrones de integración propuestos en el excelente libro de Gregor Hohpe y Bobby Woolf de la serie de Martin Fowler: Enterprise Integration Patterns. El catálogo de patrones se puede revisar en la página oficial del libro. Estos patrones proveen un marco teórico para la comprensión y uso de Apache Camel.

Entre los patrones más conocidos tenemos: Content-Based Router, Message Filter, Dead Letter Channel o Guaranteed Delivery.

Si les interesa conocer más de Apache Camel, la página de Adictos al Trabajo tiene un excelente tutorial sobre cómo dar los primeros pasos en este framework.

Apache CFX

http://cxf.apache.org/

Apache CXF sirve para construir, exponer y consumir Web Services. Implementa las especificaciones JAX-WS y JAX-RS de Java EE; la primera para exponer fácilmente una funcionalidad hecha en Java como un Web Service SOAP mediante un conjunto de anotaciones, la segunda, idem pero para un servicio REST. En el mundo de JBoss se usa Apache CXF para JAX-WS y en algunos casos se suele usar RESTEasy para lo que es JAX-RS.

Inicialmente este proyecto se llamaba Celtrix y era propietario, hasta que lo adquirió Apache, lo combinó con XFire y allí salió CXF.

CXF se puede desplegar en casi cualquier servidor: un contenedor de Servlet como Tomcat o Jetty, un servidor de aplicaciones como Glassfish, un ESB como ServiceMix, un contenedor OSGi como hoy en día es JBoss 7 o una aplicación standalone con su propia JVM.

Al que le interese ver Apache CXF en acción, le recomiendo este post del blog Enterprise Development Ideas, donde se combina Maven 3, Apache CXF 2.6 y Spring 3.1.1 para armar un servicio SOAP con JAX-WS.

Apache ServiceMix

http://servicemix.apache.org/

Apache ServiceMix es un contenedor flexible que unifica las funcionalidades de ActiveMQ, Camel, CXF, ODE (motor de orquestación de servicios WS-BPEL) y Karaf. Se podría decir que el core de ServiceMix es Apache Karaf, un ESB (Enterprise Service Bus) basado en OSGi. ServiceMix combina las tecnologías antes vistas para proveer la plataforma SOA por excelencia, la que siempre prometió ser la columna vertebral de la empresa, el ESB.

OSGi presenta una gran evolución frente a los ya arcaicos y siempre problemáticos classloaders.

OSGi V.S. Classloaders de Java EE

Mientras que los classloaders de un servidor de aplicaciones típico JavaEE (como JBoss 6 o inferior) se organizan de forma jerárquica, OSGi trata a las librerías Java como si fueran módulos que dependen unos de otros. Este grafo de dependencias que OSGi propone viene a resolver los problemas típicos de classloaders que podemos tener a la hora de actualizar una versión de un framework que usan N aplicaciones desplegadas en un mismo servidor.

El nuevo JBoss 7 viene con OSGi, el nuevo Weblogic 12 también. Lo mismo que el ESB de Apache.

Algunos de los beneficios de usar OSGi frente a una jerarquía de classloaders pueden ser:

• Control absoluto sobre versiones y dependencias: múltiples versiones de una librería conviven felizmente en el mismo contenedor
• Desacoplamiento entre módulos: mediante una Arquitectura Orientada a Servicios interna (dentro del servidor)
• Las clases y dependencias se comparten: para una gestión más eficiente de la memoria
• Agilidad en el desarrollo, testeo y actualización de versiones (hot deploy)
• Olvídese del "si funciona, no lo toques": entienda e inspeccione exactamente qué librerías se están usando en cada parte de su aplicación... ¡en tiempo de ejecución!
• Aísle los cambios en sus componentes: de manera que no impacten al resto del sistema
• Ponga su servidor a dieta: OSGi = modularidad, también en el servidor. ¡Basta de dolorosos slimmings! Utilice sólo las funciones que necesite en su servidor. Cargue a demanda.

OSGi suena ideal para un ESB, ¿no? Y además, todos los que tuvimos que pelearnos alguna vez con una estructura jerárquica de classloaders, sabemos que no escalan; a duras penas logran satisfacer los inmensos y heterogéneos entornos empresariales de hoy.

FuseSource

Antes de terminar, es mi obligación revelar la fuente principal de la que saqué el 90% del material que presenté en este post. FuseSource se trata de una empresa dedicada al arduo trabajo de la integración, utilizando estos productos open source de Apache. Al igual que Red Hat vende suscripciones de productos de JBoss, FuseSource vende suscripciones para una plataforma de Middleware basada en ActiveMQ, Camel, CXF y ServiceMix a la que llama Fuse ESB Enterprise y Fuse MQ Enterprise. La info la saqué del webinar de Raúl Kripalani llamado "Integración potente con tecnología Open Source Apache, allá donde lo necesite", el primero realizado en español. Si les interesó este post, probablemente les interese mucho este webinar.

Charla Java EE 6 in Action en CAECE

Introducción a las Principales Tecnologías de Java EE 6

Epidata Consulting los invita a participar de la charla "Java EE 6 in Action", que tendrá lugar el próximo Martes 15 de Mayo, de 19.00 a 20.30hs en la Universidad CAECE, en Av. de Mayo 866, Ciudad Autónoma de Buenos Aires.

El objetivo de la actividad será presentar una introducción a la plataforma actual de Java Enterprise, a través de sus tres especificaciones fundamentales: JPA, como Mapper de objetos a tablas relaciones, EJB, como proveedor de servicios de infraestructura, y CDI, como un ágil y moderno modelo de programación. Montada sobre el lenguaje Java estándar, la plataforma Java EE provee un entorno de desarrollo y ejecución para aplicaciones empresariales. Las nuevas versiones de los servidores de aplicaciones (Glassfish, JBoss, Weblogic) ya implementan esta especificación y las empresas, cada vez más atraídas por los estándares, comienzan a migrar hacia esta nueva plataforma.

La charla será dictada por Adrián Paredes, arquitecto de software de Epidata Consulting.

Temario

• Introducción a Aplicaciones Enterprise y Java EE
• Java Persistence API 2.0 (JPA)
• Enterprise JavaBeans 3.1 (EJB)
• Contexts and Dependency Injection 1.0 (CDI) 

Público destinatario: estudiantes y profesionales interesados en aplicaciones empresariales construidas con Java.

Capacitación gratuita y abierta al público!

¡Inscribite!

Orador

Adrián Paredes es Ingeniero en Informática de la Facultad de Ingeniería de la UBA. Se desempeña como consultor, arquitecto y desarrollador en Epidata Consulting. Cuenta con 4 años de experiencia en proyectos Java EE y actualmente trabaja en proyectos con productos de JBoss y de Oracle.

Detalles

Martes 15 de Mayo de 2012 

19.00 a 20.30hs

Universidad CAECE - Av. de Mayo 866 (CABA)

LINKEDIN: http://linkd.in/Ivlsqu 

FACEBOOK: http://www.facebook.com/events/282237288534513/

PAGINA DE EPI: http://www.epidataconsulting.com/site/pages/noticia/Charla-Java-EE-6-in-Action

Reference Card de Weld

Siguiendo con el tópico del post pasado: CDI (JSR-299), el Contenedor de Contextos e Inyección de Dependencia (Java Contexts and Dependency Injection for the Java EE platform), comparto en esta entrada dos referencias excelentes para aprender CDI y Weld, la implementación de referencia de CDI:

• La primera es la documentación oficial de Weld, que es en verdad muy completa y amena de leer.
• La segunda es la Reference Card de DZone, concisa y maravillosa, muy aconsejable para después de leer la doc oficial.

Una de las cosas que sorprende de Weld es que puede funcionar standalone, sin necesidad de ningún tipo de servidor. Esto es fascinante, ya que en una aplicación Java SE podemos contar con un inyector de dependencias. La documentación aclara que hay contextos que no estarán disponibles, como Session o Request, algo que es lógico. También puede funcionar en un contenedor de Servlets, como Tomcat o Jetty.

La reference card hace referencia a tres arquetipos Maven (ninguno es el que usamos en el post anterior):

• weld-jsf-servlet-minimal: crea una aplicación web que usa Weld y JSF 2.0 (JSR-314)
• weld-jsf-jee-minimal: crea una aplicación web que usa Weld, EJB 3.1 (JSR-318) y JSF 2.0 (JSR-314), pero sin persistencia
• weld-jsf-jee: crea una aplicación web que usa Weld, EJB 3.1 (JSR-318), JSF 2.0 (JSR-314) y JPA 2.0 (JSR-317) para la persistencia

Comparado con el arquetipo jboss-javaee6-webapp que habíamos visto, la aplicación que crea weld-jsf-jee es un poco más pequeña. Claro, el primero muestra un ejemplo más completo, incluso exponiendo un servicio REST con JAX-RS 1.1 (JSR-311).

Otra de las cosas que sorprende, por lo menos a mí que vengo de trabajar bastante con Seam 2, es que no hace falta ninguna anotación ni configuración extra para que una clase Java normal sea considerada como un Bean para el CDI. La única condición de Weld es que exista un archivo beans.xml en el META-INF del EAR o en el WEB-INF del WAR. En este xml se pueden declarar interceptores, decoradores e implementaciones alternativas de interfaces para cambiar en tiempo de despliegue. El archivo puede estar vacío.

Como en Seam, dependiendo del tipo de componente Java EE que sea (Entidad, EJB, Managed Bean de JSF, Spring Bean), tomara un scope u otro por defecto (si no se le especifica).

Los scopes que CDI provee son:

• @RequestScoped
• @ConversationScoped
• @SessionScoped
• @ApplicationScoped
• @Dependent

Voy a echar en falta el contexto PAGE (o VIEW como se llama en JSF 2.0). Yo lo usaba bastante. No sé si lo provee Seam 3. De todas formas, todo apunta a que se use bastante el scope Conversation, que parece mucho más sencillo de utilizar que en Seam 2.

Es claro que habrá un antes y un después de CDI en el mundo de Java EE. El @Inject es demasiado simple de usar y, como dicen los españoles: mola demasiado.

Para cerrar, les cuento que estaré dando una charla de Java EE 6 que se llamará justamente Java EE 6 In Action. La charla será en la Universidad CAECE el 15 de mayo a las 19hs, con duración estimada de una hora y media. Todavía no fue lanzada la propaganda oficial. Cuando lo esté, supongo que durante esta semana o la próxima, la linkearé en este blog.

Weld y Arquetipo de Maven para JBoss 7

Con este post voy a dar comienzo a una serie de entradas que en este blog etiquetaré como Java EE 6 in Action, y que espejaré, como vengo haciendo últimamente en mi otro blog Tecnologías Java, para facilitar las búsquedas.

Mi objetivo es que juntos nos vayamos adentrando en el mundo de Java EE 6 (JSR-316) de la forma más ágil posible. La especificación de la nueva plataforma empresarial de Java se lanzó en diciembre de 2009. Si bien hace tiempo que ya está disponible la implementación de referencia, Glassfish 3, las empresas todavía no han adoptado completamente este estándar (por lo menos acá en Argentina), y es lógico, ya que sería una pésima estrategia migrar todo el software construido cada vez que hay una nueva actualización.

Pero es razonable esperar que los nuevos desarrollos comiencen a construirse sobre esta plataforma.

I - CDI y Weld

Vamos a comenzar con la especificación estrella, la nueva niña mimada de Java EE: CDI (JSR-299), el Contenedor de Contextos e Inyección de Dependencia (Java Contexts and Dependency Injection for the Java EE platform).

Wallpaper de Weld hecho por la comunidad de JBoss.

CDI fue influenciado por varios frameworks Java de inyección de dependencia como Seam, Guice y Spring. Con tantas herramientas dando vuelta era necesaria una especificación y la JCP se encargó de que CDI fuera más typesafe que Seam, más stateful y menos XML-centric que Spring, y mejor preparado para aplicaciones enterprise que Google Guice.

CDI es un contenedor liviano (aunque el adjetivo "liviano" está empezando a deprecarse) que provee servicios para:

• Manejar el ciclo de vida de objetos stateful, asociados a contextos bien definidos
• Inyección de dependencia typesafe
• Interacción entre objetos mediante notificación de eventos
• Interceptores de objetos para implementar orientación a aspectos (mucho mejor diseñado que los interceptores de EJB 3.0)
• una SPI (service provider interface) para desarrollar extensiones portables

Weld es la implementación de referencia de CDI y, a la vez, el core de Seam 3. Seam 3, de JBoss, pasó a ser un conjunto de módulos que extienden las funcionalidades de CDI a través de la SPI provista por el estándar. No es el único. Hay otras extensiones menos conocidas como CODI, de Apache MyFaces, o CDI Source. Y la buena noticia es que la historia se repite. Las extensiones de CDI van camino a la unificación (probablemente para que el día de mañana formen parte de nuevas especificaciones). La semana pasada, InfoQ publicó una entrevista a Pete Muir, donde cuenta que se está incubando un nuevo proyecto en Apache que ya va por su release 0.1. DeltaSpike, como se llama el proyecto, es una fusión entre Seam 3 y CODI con el fin de tomar lo mejor de ambos mundos. Muir tiene la esperanza de que en el futuro otras extensiones del CDI se quieran unir a la fiesta.

II - Arquetipo de Maven para Weld

Para comenzar, qué mejor que tener a mano un código de ejemplo y que además lo podamos ejecutar.

Si descargamos Weld de la página de Seam, la última versión Final publicada a la fecha en la página es la 1.1.6 (aunque ya existe la 1.1.7, con fixes menores, que se subirá a la página en los próximos días), tendremos un zip con las librerías, más varios ejemplos ubicados en la carpeta "examples". Estos ejemplos se pueden seguir con la excelente documentación oficial de Weld. Si usamos Maven podemos usar las librerías que están subidas en los repositorios públicos.

En lo que queda del post, vamos a utilizar un arquetipo para crear todo un proyecto Weld que ya en sí mismo es un ejemplo que incluye un código bastante lindo para comenzar a inspeccionar. Las instrucciones para usar el arquetipo se pueden revisar aquí. El proyecto que genera funciona perfecto para la versión 6.1.0.Final de JBoss AS, pero yo lo voy a aggiornar un poco para que funcione para la versión 7.1.1.Final, la última publicada a la fecha.

El comando que usé para generar el proyecto fue:

mvn archetype:generate -DarchetypeArtifactId=jboss-javaee6-webapp -DarchetypeGroupId=org.jboss.weld.archetypes -DarchetypeVersion=1.0.1.CR2 -DarchetypeRepository=central

La versión de Maven que usé fue la 3.0.3, simplemente porque ya la tenía instalada en mi máquina.

III - Modificando el Proyecto para que Funcione en JBoss 7.1.1.Final

Paso 1: Descargar el JBoss AS 7.7.1.Final:

El JBoss AS se puede descargar de su página oficial. Se puede decir que JBoss AS 7 tiene cambios radicales con respecto a las versiones anteriores. A partir de la versión 7.1.0 implementa todos los perfiles de la especificación de Java EE 6.

Si quieren conocer más de JBoss AS 7 pueden leer el bloque de conocimiento de Epidata Consulting creado por Marcos Reynoso.

Paso 2: Configurar la variable jboss.home:

Si uno configura la variable de entorno JBOSS_HOME en el sistema operativo este cambio no hay que hacerlo. Como en mi rutina diaria utilizo varias versiones de JBoss, yo prefiero no configurar esta variable, ya que me trae problemas. La alternativa es hardcodear la ruta directamente en el mismo pom.xml.

<!-- To specify the JBoss AS directory the "Maven way", set the jboss.home 
property in an active profile in $HOME/.m2/settings.xml -->
<!-- By default, we assign it to the value of the JBOSS_HOME envrionment 
variable -->
<jboss.home>/opt/jboss/jboss-as-7.1.1.Final</jboss.home>

Paso 3: Nuevo Perfil Maven para JBoss 7:

El proyecto viene con cuatro perfiles Maven:

• default: activo por defecto; funciona para JBoss 6.1.0.Final; por defecto no ejecuta los unit test
• arq-glassfish-embedded: funciona con un Glassfish 3.1 embebido (standalone); sirve para correr los tests hechos con Arquillian
• arq-jbossas-remote: sirve para correr los test hecho con Arquillian en un JBoss 6.1.0.Final remoto
• arq-weld-ee-embedded: funciona con un contenedor Weld embebido; también para correr los tests hechos con Arquillian

Nosotros agregaremos un perfil nuevo llamado jboss7 que, tras aplicarle los siguientes pasos, quedará de la siguiente forma:

<profile>
 <!-- The default profile skips all tests, though you can tune it to run 
  just unit tests based on a custom pattern -->
 <!-- Seperate profiles are provided for running all tests, including Arquillian 
  tests that execute in the specified container -->
 <id>jboss7</id>
 <dependencies>
  <!-- Java EE 6 API dependency -->
  <!-- This one dependency imports all APIs available for a Java EE 6.0 
   application -->
  <dependency>
   <groupId>org.jboss.spec</groupId>
   <artifactId>jboss-javaee-6.0</artifactId>
   <version>${jboss-javaee6-spec.version}</version>
   <type>pom</type>
   <scope>provided</scope>
  </dependency>
 </dependencies>
 <build>
  <plugins>
   <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4.3</version>
    <configuration>
     <skip>true</skip>
    </configuration>
   </plugin>
   <!-- Optional plugin deploys your war to a local JBoss AS container -->
   <!-- To use, set the JBOSS_HOME environment variable (or jboss.home 
    in $HOME/.m2/settings.xml) and run: mvn package jboss:hard-deploy -->
   <plugin>
    <groupId>org.jboss.as.plugins</groupId>
    <artifactId>jboss-as-maven-plugin</artifactId>
    <version>7.1.1.Final</version>
    <executions>
     <execution>
      <id>add-datasource</id>
      <phase>package</phase>
      <goals>
       <goal>add-resource</goal>
      </goals>
      <configuration>
       <address>subsystem=datasources,data-source=java:jboss/myDs</address>
       <resource>
        <enable-resource>true</enable-resource>
        <properties>
         <jndi-name>java:/jdbc/__default</jndi-name>
         <enabled>true</enabled>
         <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
         <driver-class>org.h2.Driver</driver-class>
         <driver-name>h2</driver-name>
         <user-name>sa</user-name>
         <password>sa</password>
         <pool-name>mypool</pool-name>
         <use-java-context>false</use-java-context>
        </properties>
       </resource>
      </configuration>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>
</profile>

Paso 4: Plugin de JBoss 7 para Maven

Lo primero que le hice al perfil fue agregarle el plugin Maven para JBoss 7: jboss-as-maven-plugin, para poder desplegar la aplicación usando el comando jboss-as:deploy.

Paso 5: Aggiornamiento del DataSource

Todo cambió en JBoss AS 7, incluso la forma de escribir un datasource. El datasource para Hypersonic que viene con el proyecto, ubicado en src/main/resources-jbossas/default-ds.xml sirve para JBoss 6 pero no para JBoss 7. Ya que el jboss-as-maven-plugin permite agregar un recurso (como un datasource) en la misma configuración, no vamos a usar el default-ds.xml. Por eso verán que le agregué el goal add-resource a la configuración del plugin.

Paso 6: Deploy

Simplemente ejecutando:

mvn clean install jboss-as:deploy -Pjboss7

Problema con el Nuevo Classloader

Esto realmente no es un problema. Al desplegar, la aplicación tira una excepción de ClassNotFound:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Priority from [Module "org.jboss.logging:main" from local module loader @199836ed (roots: /jboss-as-7.1.1.Final/modules)]

Esta excepción no impide el correcto funcionamiento de la aplicación. Pero resulta visualmente molesto que en el log aparezca este error. Según este thread del foro de JBoss, esto se debe a un bug en el módulo de JBoss Logger y se arregla agregando manualmente los siguientes módulos al archivos $JBOSS_HOME/modules/org/jboss/logging/main/module.xml:

<!-- added these 2 dependencies -->
<module name="org.apache.log4j"/>
<module name="org.slf4j"/>

Si les interesa conocer más del nuevo manejo de classloader de JBoss 7 pueden leer estos artículos:

• Class Loading in AS 7
• How do I migrate my application from AS5 or AS6 to AS7

Paso 7: Ir a la Aplicación

Para terminar y ver la aplicación de ejemplo funcionando, abrimos un navegador web y vamos a la URL: http://localhost:8080/jboss-javaee6-webapp/. Si todo salió bien, deberíamos ver nuestro formulario de registración de miembros hecho con JSF 2.

http://localhost:8080/jboss-javaee6-webapp/

Un Vistazo Rápido a Arquillian

A través de la cuenta de twitter de Dan Allen @mojavelinux, me he enterado la excelente noticia de que esta excelente Guía de Introducción de Arquillian está disponible a partir de ahora en español. Por ahí se dice que no se puede empezar a escribir pruebas unitarias con Arquillian sin haber leído antes este tutorial. Y es cierto. Así que ya no tenía excusa para probar el flamante framework de JBoss para pruebas de componentes de contenedores.

Como muy bien explica Pablo Felitti en su blog Enterprise Development Ideas, una de las mayores desventajas de usar componentes que se despliegan en contenedores (como EJB, por ejemplo) es que necesitamos levantar el contenedor mismo para probar, ya que el contenedor maneja el ciclo de vida de sus componentes. Levantar un contenedor de EJB, por ejemplo, nos puede consumir mucho tiempo. Esto hace que las pruebas unitarias resulten tediosas para el programador. Muchas veces esto se soluciona de mala manera clasificando las pruebas unitarias que usan EJBs como pruebas de integración y ejecutándolas en una etapa posterior en el ciclo de vida del desarrollo.

Arquillian puede ser una solución para esto. Arquillian nos permite olvidarnos de los mocks, olvidarnos de las chanchadas que hacemos para probar un componente de forma standalone, fuera de su contenedor, y ejecutar pruebas en el ambiente real. Con Arquillian podemos probar un EJB tal cual es, con sus inyecciones de servicios, con su ciclo de vida, en el mismo contenedor, inyectando el componente en el mismo Unit Test, ya que el Unit Test mismo se ejecutará dentro del contenedor.

Seguí el tutorial paso a paso y todo me funcionó de maravilla. El mismo te enseña a crear un proyecto JavaEE 6 de cero usando:

• Maven (yo en particular usé la versión 3.0.3, que es la que tenía)
• JavaSE 6
• JavaEE 6
• JUnit 4
• CDI como modelo de programación (contenedor de contexto e inyección de dependencia)
• Eclipse (opcional; dado que todo el tutorial se puede seguir con otro IDE y usando Maven si se tiene experiencia)

El tutorial comienza de cero, así que no se preocupen si no tienen estas cosas. Lo único que necesitan tener instalado es Apache Maven y conexión a Internet. Hay una parte de la guía en que configura el proyecto Maven usando una herramienta de configuración de proyectos llamada JBoss Forge. Por mi parte tomé el camino más estándar y manual y usé Maven directamente.

A la hora de ejecutar la prueba unitaria, utiliza contenedores embebidos. Esto es una excelente opción para ejecutar rápidamente el test, aunque es mentira que estamos probando en el ambiente real: el ambiente real es el contenedor mismo. La versión embebida del contenedor puede tener distintos bugs o funcionar de forma diferente en algunos casos. De todas formas, repito, es una opción excelente para empezar y probar rápido. Arquillian también permite configurar otros contenedores no embebidos sin cambiar una sola línea de código. La única diferencia es que hay que tenerlos levantados para poder ejecutar los tests.

Los contenedores embebidos con los que la guía prueba son:

• Weld, la implementación de referencia de CDI
• JBoss 7 (managed)
• Glassfish 3 (embedded)

Los tres se configuran en el pom.xml del proyecto mediante perfiles y Maven solito se encarga de descargarlos y Arquillian de activarlos al ejecutar las pruebas, a través de un adaptador para cada contenedor. Arquillian selecciona el contenedor basándose en el adaptador que está disponible en el classpath. Una prueba con Arquillian debe ser ejecutada en cualquier contenedor que es compatible con el modelo de programación utilizado en la prueba (siempre y cuando exista un adaptador de Arquillian para dicho contenedor). Esto significa que el ejemplo del tutorial sólo puede ser corrido en un contenedor CDI como JBoss 6 (o superior), Weld o Glassfish 3 (o superior).

La buena noticia es que en solo diez minutos, siguiendo los pasos, la prueba me ha salido funcionando para los contenedores embebidos. Aquí copio cómo me ha quedado el pom.xml final:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>org.arquillian.example</groupId>
	<artifactId>arquilian-tutorial</artifactId>
	<version>1.0-SNAPSHOT</version>
	<packaging>jar</packaging>

	<name>arquilian-tutorial</name>
	<url>http://maven.apache.org</url>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
	</properties>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
		</plugins>
	</build>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.jboss.arquillian</groupId>
				<artifactId>arquillian-bom</artifactId>
				<version>1.0.0.CR7</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.8.1</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.jboss.arquillian.junit</groupId>
			<artifactId>arquillian-junit-container</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<profiles>
		<profile>
			<id>arquillian-weld-ee-embedded</id>
			<activation>
				<activeByDefault>true</activeByDefault>
			</activation>
			<dependencies>
				<dependency>
					<groupId>org.jboss.spec</groupId>
					<artifactId>jboss-javaee-6.0</artifactId>
					<version>1.0.0.Final</version>
					<type>pom</type>
					<scope>provided</scope>
				</dependency>
				<dependency>
					<groupId>org.jboss.arquillian.container</groupId>
					<artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
					<version>1.0.0.CR2</version>
					<scope>test</scope>
				</dependency>
				<dependency>
					<groupId>org.jboss.weld</groupId>
					<artifactId>weld-core</artifactId>
					<version>1.1.5.Final</version>
					<scope>test</scope>
				</dependency>
				<dependency>
					<groupId>org.slf4j</groupId>
					<artifactId>slf4j-simple</artifactId>
					<version>1.6.4</version>
					<scope>test</scope>
				</dependency>
			</dependencies>
		</profile>

		<profile>
			<id>arquillian-glassfish-embedded</id>
			<dependencies>
				<dependency>
					<groupId>org.jboss.arquillian.container</groupId>
					<artifactId>arquillian-glassfish-embedded-3.1</artifactId>
					<version>1.0.0.CR2</version>
					<scope>test</scope>
				</dependency>
				<dependency>
					<groupId>org.glassfish.main.extras</groupId>
					<artifactId>glassfish-embedded-all</artifactId>
					<version>3.1.2</version>
					<scope>provided</scope>
				</dependency>
			</dependencies>
		</profile>

		<profile>
			<id>arquillian-jbossas-managed</id>
			<dependencies>
				<dependency>
					<groupId>org.jboss.spec</groupId>
					<artifactId>jboss-javaee-6.0</artifactId>
					<version>1.0.0.Final</version>
					<type>pom</type>
					<scope>provided</scope>
				</dependency>
				<dependency>
					<groupId>org.jboss.as</groupId>
					<artifactId>jboss-as-arquillian-container-managed</artifactId>
					<version>7.0.2.Final</version>
					<scope>test</scope>
				</dependency>
			</dependencies>
		</profile>

	</profiles>

</project>

Si usáramos EJB 3.0, Arquillian podría usarse con un JBoss 5.1 o superior. La configuración es un poco más trabajosa, pero puede funcionar. Si usamos EJB 3.1, con un JBoss 6 o JBoss 7 la configuración es más sencilla.

Otra opción a Arquillian es la que propone Pablo Felitti en este post, donde usa un contenedor embebido de EJB y en la prueba unitaria utiliza la interfaz remota del EJB. En el post, Pablo usa Apache OpenEJB, pero podría usar JBoss Embedded o cualquier otro. Ésta es una excelente opción para cuando se está trabajando con EJB 3.0 (JavaEE 5). Las ventajas que brinda Arquillian frente a este enfoque son:

• No tener que declarar una interfaz remota para el EJB (si no es necesario)
• Poder inyectar el EJB en el test de la misma forma en que se haría desde algún otro componente dentro del mismo contenedor (usando la interfaz local)
• Correr el test dentro del contenedor (en el mismo ambiente) y no en otra máquina virtual standalone remota

Para cerrar y ponerle un poco de humor al post, les comparto este gracioso video, compartido originalmente por Dan Allen en Vimeo, donde Hitler se pone loco porque Arquillian deja al descubierto los bugs de su contenedor.

Hitler reacts to Arquillian uncovering bugs in his container from Dan Allen on Vimeo.