En este artículo explicaremos que es un Bus de Servicios Empresarial o Enterprise Servicie Bus (ESB). Mostrando cuáles son sus principales casos de uso, basándonos en ejemplos reales de la vida profesional. Por último, se presentarán ejemplos de ESB con sus principales características y se explicará la diferencia entre ESB generales y de dominios específicos.
Por @palzuri
Un ESB es un componente fundamental en una arquitectura orientada a servicios. Es posible definirlo como un intermediario o middleware que sirve como capa de abstracción entre proveedores y consumidores de servicios. Un ESB permite bajar el acoplamiento entre los sistemas y lograr una gobernanza de servicios dentro de una arquitectura orientada a servicios (SOA). El término ESB, es usado tanto para el patrón arquitectural como para el componente de software que lo implementa. Si bien, la mayoría de los ESBs nos permiten implementar arquitecturas SOA, orientadas a mensajes y orientadas a eventos, en este artículo nos centraremos en ejemplos y casos de uso en arquitecturas SOA.
A continuación, presentaremos un ejemplo basado en nuestra experiencia, el cual iremos desarrollando para ilustrar distintos conceptos.
Supongamos una empresa X que tiene 4 sistemas, de los cuales uno es el sistema principal que apoya la operación. Los sistemas están desarrollados en tecnologías diferentes y desconectados entre si, pero llega el momento en el cual los mismos se deben integrar para lograr los objetivos del negocio.
Una posible solución es desarrollar integraciones punto a punto, lo cual lo podríamos ver reflejado de la siguiente manera:
Esta solución tiene como principal problema el alto acoplamiento entre las aplicaciones, el cual genera inconvenientes en diferentes atributos de calidad. Cuantas más dependencias tengamos entre aplicaciones, más complejas serán las integraciones y más difícil será el mantenimiento. Dado que los sistemas están escritos en lenguajes diferentes, puede ser que el sistema que expone el servicio pueda respetar algunos estándares (por ejemplo, WSSecurity) que el sistema consumidor no puede respetar. En este caso podemos llegar a tener que definir adaptadores para dichos servicios, incrementando la complejidad de cada integración.
Una mejora de diseño es utilizar un ESB como capa de abstracción entre los proveedores y consumidores de servicios, lo cual lo podríamos ver reflejado en la siguiente imagen:
Como se puede observar, la interacción entre los sistemas se simplifica y las relaciones que existían antes en cada aplicación ahora se encapsulan en el ESB. En esta implementación, se utiliza el ESB como proxy de servicio. La mayoría de los ESBs poseen esta funcionalidad para servicios SOAP o REST, tanto en modalidad sincrónica como asincrónica.
Ahora supongamos que queremos remplazar el sistema principal de la empresa, en este caso si tenemos la arquitectura anterior, podemos tener una convivencia de los sistemas haciendo un reemplazo paulatino de los servicios publicados en el ESB.
Gracias al uso del ESB, los consumidores de los servicios no se ven afectados por el cambio del sistema principal, en otras palabras, el ESB nos viabiliza el uso de estrategias que en otras situaciones no serían posibles.
Estos ejemplos, pueden hacer pensar que un ESB es la mejor solución para todas las organizaciones pero solo el conocimiento del contexto de la organización puede afirmar si se debe incorporar un ESB o no. Es importante considerar que la mayoría de los ESBs brindan un conjunto amplio de funcionalidades, como por ejemplo enrutamiento y transformación de mensajes, orquestaciones y coreografías de servicios, entre otros.
La elección del ESB adecuado puede ser critica para el éxito de la implementación de una arquitectura SOA en la organización, con este fin se debe evaluar:
- Funcionalidades requeridas para la implementación de la arquitectura.
- Costo económico de licencias e implementación del ESB.
- Disponibilidad del mantenimiento o código fuente.
- Funcionalidades requeridas por otras áreas de la organización como son operaciones o seguridad.
En este contexto es muy difícil recomendar un ESB dado que se dispone de muchas opciones como por ejemplo JBoss Fuse ESB, Mule ESB, WSO2, Mirth Connect, entre otros. Se han referenciado ESBs de uso general y especializados por área de negocio. Cuando un ESB se especializa en un área específica, trae todos los conectores y adaptadores específicos para dicha área. Por ejemplo, Mirth Connect trae soporte a través de conectores, puntos de entrada y formatos definidos para estándares de Salud.
En resumen, el uso de un ESB tiene un impacto muy positivo en la arquitectura de software de una organización ya que permite resolver diferentes problemas tecnológicos y/o del negocio. Lo debemos evaluar como una opción, sin olvidar los costos asociados. En la práctica, utilizar un ESB nos ha resultado más efectivo cuando deriva de una solución técnica a necesidades de negocio, las cuales justifican la inversión y viabilizan su ROE (Return on Equity).
Escrito por Pablo Alzuri, Consultor en Seguridad de Aplicaciones GeneXus en GeneXus Consulting.
Podrias explicar un caso de uso mas detallado de como se aplica esto integrado con Genexus, y como se supone el uso de Genexus, como simple conector o implementaria parte del bus ?