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.