Bit - loader

ServiceMix: Un Service Bus para soluciones de integración

   Artículo | Arquitectura Bit - ServiceMix: Un Service Bus para soluciones de integración
Ricardo Ahumada | 12/06/18

Hace unas semanas me tocó hacer un one-to-one con el responable técnico de una empresa portuaria que tenía un reto importante: la integración de las aplicaciones del puerto.

Este reto implicaba la integración de un buen número de aplicaciones de distintas épocas (de legado y nuevas) y diferentes tecnologías. Todas en conjunto aportaban los mecanismos de gestión del puerto (desde cámaras y barreras, a gestión de contendores). Como se puede imaginar, estas aplicaciones necesitan comunicarse e intercambiar datos para enriquecer los servicios del puerto.

 

 

¿Cómo se puede hacer para que aplicaciones de distintas tecnologías; que van desde simples archivos CSV, pasando por colas de mensajería, servicios SOAP y REST, … se comuniquen entre ellas, colaboren, se consuman mutuamente, sin caer en el caos?

Afortunadamente existe una arquitectura ya bastante antigua, la SOA o Arquitectura Orientada a Servicios (que es el germen de los actuales microservicios) y que tiene aparejada una solución de integración: el Service Bus.

Esta solución se adoptó por esta empresa y considero que la experiencia con las tecnologías implicadas son suficientemente interesantes para colocarlas en un artículo y hacer una pequeña reseña.

 

El problema de la integración de aplicaciones

En la plataforma empresarial, es común que múltiples aplicaciones colaboren y proporcionen la funcionalidad de negocio en su conjunto.

 

 

La integración de estas aplicaciones es el problema más recurrente. Se vuelve incluso más complejo con el tiempo a medida que las aplicaciones crecen. Cada aplicación puede requerir y proporcionar datos en su propio formato.

Por ejemplo, si una aplicación (de la que dependen otras aplicaciones) tiene que ser actualizada o reemplazada para responder a una necesidad de negocio concreta; el formato de datos de entrada o de salida de todas las aplicaciones que dependen de esta aplicación maestra se verán afectadas.

Este enfoque muestra el mayor obstáculo que se espera en la Integración en el entorno de una arquitectura fuertemente acoplada.

Aquí es donde un Bus de Servicios Empresarial, ESB (Enterprise Service Bus) entra en escena.

Con un ESB, una aplicación no necesita comunicarse directamente con cada una de las otras aplicaciones; en su lugar, todas las aplicaciones se comunican con el ESB y el ESB maneja el enrutamiento de la información y la conversión del formato de datos.

SOA

Pero, ¿qué son la Arquitectura Orientada a Servicio SOA (Service Oriented Architecture) y los ESB?

SOA es una estructura subyacente de sistemas informáticos que admite la conexión entre varias aplicaciones y el intercambio de datos

Una arquitectura orientada a servicios (SOA) ayuda a que los procesos de negocios sean mejores, más fáciles de volucionar y más económicos de crear. O al menos eso promete.

La creación de procesos de negocio es más rápida y económica porque los servicios existentes se pueden reutilizar más fácilmente, las aplicaciones pueden exponer sus servicios de forma estándar.

En el siguiente esquema se presenta la comparación entre SOA y sistemas monolíticos.

 

 

Como se puede ver, SOA se contrapone a las aplicaciones monolíticas y propone la implementación de servicios que se pueden combinar para generar las funcionalidades necesarias.

Por tanto una arquitectura SOA propone una arquitectura desacoplada (o con acoplamiento débil) que tiene los siguientes beneficios:

  • Aumenta la interoperabilidad intrínseca
  • Incrementa la federación.
  • Aumenta las opciones de trabajar con diferentes proveedores.
  • Aumenta la alineación entre negocios y tecnología
  • Aumenta el retorno de la inversión
  • Aumenta la agilidad organizacional
  • Reduce la carga operativa de TI

Se puede ver más detalle sobre la propuesta de SOA en el Manificiesto SOA.

Las arquitecturas SOA tuvieron su época de gloria en los años 90’s-2000’s y aunque el planteamiento original no tuvo éxito, ahora tenemos herederos direcos de este planteamiento en las arquitecturas de microservicios que están tan de moda hoy en día.

 

Los Enterprise Service Bus

Dentro de la arquitectura SOA nació como componente “broker” en las implementaciones que se intentaron por allá en los años 90 el Service Bus.

Tal como indica Mike Gilpin de Forrester la definición de un Service Bus sería la siguiente:

“An Enterprise Service Bus (ESB) is a software infrastructure that enables SOA by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available.”

( Mike Gilpin, Forrester Research, August 2004)

Es decir un Service Bus es un Componente Middleware que ayuda a integrar las funcionalidades de negocios y las aplicaciones que los generan; identifica mensajes y los enruta entre aplicaciones y servicios; proporciona una abstracción para end-points; permite un acoplamiento flexible y una conexión fácil entre servicios; y está basado en componentes conectables.

El siguiente esquema representa la función de un Service Mix en el entorno de integración de aplicaciones:

 

 

OSGi

Los Service Bus no serían posibles sin una arquitectura de componentes que permitieran el plug-and-play. Estos componentes normalmente siguen el estándar OSGi.

El acrónimo OSGi viene de Open Service Gateway Initiative; aunque ahora OSGi es el nombre para un Sistema de Módulos Dinámicos para Java.

OSGi es un conjunto de especificaciones gestionados por la OSGi-Alliance (fundada en 1999),

OSGi propone construir sistemas a partir de componentes (o bundles) siguiendo la siguiente arquitectura de capas:

 

 

Los elementos de la arquitectura OSGi son los siguientes:

  • Componente o Bundle:
    • Es el conjunto de clases y recursos que tienen dependencias gestionadas.
    • El componente puede ser instalado (implementado) / desinstalado en tiempo de ejecución.
    • Asimismo, puede exportar servicios

Servicio o Interfaz de componente

  • Los servicios son provistos por los bundles que los registran en el contenedor.
  • Los servicios son utilizados por los bundles que los solicitan desde el contenedor.
  • Algunos servicios son servicios estándar proporcionados por el contenedor

Contenedor OSGI o Framework de Componente

  • Es el entorno de tiempo de ejecución para bundles.
  • Gestiona el ciclo de vida de los bundles.
  • Gestiona los Servicios.
  • Provee de servicios estándar

Cuando se crea un bundle, este se integra fácilmente en los componentes del contenedor, tal como se muestra en este diagrama:

 

 

ServiceMix

Apache ServiceMix es un proyecto de código abierto de la Fundación Apache (http://servicemix.apache.org/)

Está escrito en Java y ofrece un Enterprise Service Bus (ESB).

Originalmente se basaba en las API de las especificaciones Java Business Integration (JBI: JSR 208), bajo Apache License.

A partir de la versión 5+ ServiceMix es compatible con OSGI.

Apache ServiceMix es un contenedor flexible de integración de código abierto que unifica las funciones y la funcionalidad de Apache ActiveMQ, Camel, CXF y Karaf para proporcionar un ESB completo y listo para la empresa que funciona con OSGi. ServiceMix es un componente liviano en comparación con otros ESB.

Service Mix provee de las siguientes funcionalidades:

  • Federación, clustering y failover proporcionado por el contenedor
  • Implementación en caliente y administración del ciclo de vida de los objetos de negocio
  • Independencia del vendedor de productos con licencia del vendedor
  • Cumplimiento de la especificación JBI JSR 208
  • Cumplimiento de la especificación OSGi 4.2 a través de Apache Felix
  • Soporte para OSGi Enterprise a través de Apache Aries

ServiceMix consiste de los siguientes componentes:

 

 

  • ActiveMQ:
    • ActiveMQ, otro proyecto de Apache, es el intermediario de mensajes que se usa para intercambiar mensajes entre componentes. Además de esto, ActiveMQ también se puede usar para crear un ESB completamente distribuido.
  • Camel:
    • Es el motor de enrutamiento avanzado que permite la configuración de enrutamiento.
  • CXF:
    • Permite exponer y enrutar POJOs de Java anotados con anotaciones JAX-WS y generar con ellos Web Services.
  • Karaf:
    • Runtime Container OSGi que proporciona capacidades adicionales. Apache Karaf proporciona un contenedor liviano para implementar varios componentes y aplicaciones.

 

Dónde se puede usar ServiceMix?

Organizaciones Boundary-Less

  • Sistemas Múltiples
  • Sin formato de datos canónicos
  • Autónomo, pero Federado
  • Intranet versus Internet
  • Socios de trading

Integración

  • Integración de aplicaciones empresariales

Arquitecturas de integración

  • Soluciones punto a punto
  • Soluciones Hub-and-Spoke
  • Integración de Enterprise Message Bus
  • Integración Enterprise Service Bus

Instalando ServiceMix

Antes de instalar ServiceMix, debemos decidir la distribución que queremos usar. ServiceMix viene en dos sabores:

  • El primero es un paquete estándar de código abierto, generalmente llamado ServiceMix.
  • El segundo tipo popular de distribución de ServiceMix (proporcionado por el proveedor comercial FuseSource) se llama FuseESB.

 

Requerimientos Técnicos:

Para ejecutar Apache ServiceMix en sí mismo, necesitaremos:

  • Java Runtime Environment (JRE) 1.6.x (Java 6) o JRE 1.7.x (Java 7+)
  • Aproximadamente 100 MB de espacio libre en disco para el ensamblaje predeterminado

Si queremos desarrollar nuestras propias aplicaciones de integración y paquetes OSGi, también necesitaremos:

  • Java Developer Kit (JDK) 1.6.x (Java 6) o JDK 1.7.x (Java 7)
  • Apache Maven 3.0.4 o superior

 

Descarga e Instalación:

Descarga una distribución de ServiceMix desde uno de los sitios espejo de Apache.

Descomprime la copia en un directorio deseado (que llamaremos SERVICEMIX_HOME)

 

Sanity Check

Abre una terminal de consola

Navega hasta al directorio SERVICEMIX_HOME

Ejecuta: bin / servicemix

Si todo va bien, se mostrará un log como el siguiente:

 

 

Para parar ServiceMix: shutdown

A partir de aquí podemos seguir explorando ServiceMix para desplegar bundles y servicios OSGi, integrar aplicaciones; generar enrutado con Camel, etc.

 

Reflexiones finales

Tal como hemos visto en esta pequeña reseña, ServiceMix (o alternativamente JBoss Fuse) son una buena opción para abordar necesidades de integración de aplicaciones en contextos complejos.

La ligereza y flexibilidad de ServiceMix y la facilidad con la que se puede implantar lo hacen un Service Bus a tener en cuenta en los contextos que hemos descrito.

Entre los beneficios que lograremos, sobre todo están aquellos que nos permiten desacoplar aplicaciones y lograr la colaboración de las mismas a persar de la diversidad que puedan presentar.

La magia de ServiceMix la crean en realidad sus componentes, Karaf, Camel, Active MQ y CXF.

En conjunto nos presentan una solución sólida y con bastante consistencia para distintos entornos donde es necesario integrar aplicaciones.

 


Cursos relacionados
Nuestro sitio utiliza cookies para análisis. Si no estás seguro de ello, echa un vistazo a nuestra política de privacidad.