sábado, 26 de mayo de 2012

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.

sábado, 5 de mayo de 2012

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!

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)

martes, 1 de mayo de 2012

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:
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.