Integraciones de sistemas con Enterprise Service Bus 

Esta arquitectura es útil cuando se integran sistemas pasivos, en los que ni el emisor ni el destinatario pueden participar en el reparto del mensaje compartido y es necesario un cartero que asuma íntegramente esta tarea.

¿Cómo funcionan las integraciones de sistemas con Enterprise Service Bus?

Desde hace años, una parte importante de nuestros servicios de middleware se basa en la integración de sistemas con Enterprise ServiceBus (ESB), especialmente con los proyectos Apache ServiceMix y JBoss Fuse.

De forma resumida, el ESB se basa en que un repartidor recoge el mensaje del sistema origen, lo procesa y lo lleva hasta el sistema destino. Los sistemas origen y destino no se conocen entre sí y por lo tanto actúan como entidades autistas, por lo que únicamente el repartidor es quien se encarga de realizar el traspaso de información.

El repartidor contiene toda la lógica para leer el dato del sistema origen, procesarlo y enviarlo al sistema destino.

En este vídeo te mostramos de manera gráfica como funciona un ESB. Sin duda una de las mejores soluciones para unir diferentes sistemas de una forma más ordenada.

Ejemplo de Integración con ESB: El repartidor se encarga de recoger el pedido directamente del vendedor y lo entrega al comprador en mano.

Este caso es una situación muy habitual en la vida real: Supongamos que realizamos un pedido por teléfono a una pizzería, el propietario del establecimiento prepara la pizza y una vez horneada, el repartidor la recoge, arranca la moto, zigzaguea entre las calles de la ciudad y nos la entrega en la puerta de nuestro domicilio.

El vendedor se encarga exclusivamente de confeccionar la pizza, el comprador se la comerá y el repartidor es el responsable de llevar el pedido de origen a destino.

Traducido en el ámbito del software, diríamos que el sistema origen (vendedor) produce un mensaje (pizza), el sistema destino (comprador) consume el mensaje (pizza) y es exclusivamente el agente integrador (repartidor) quien se encarga de llevar el mensaje de origen a destino.

A la hora de abordar la integración de esta forma, esta idea desencadena las siguientes conclusiones :

  • El sistema origen sólo tiene código para generar el mensaje.
  • El sistema destino sólo tiene código para consumir el mensaje.
  • El agente integrado tiene código para leer el mensaje del sistema origen, enrutar y transformar el mensaje entre ambos extremos y escribir el mensaje en el sistema destino.

Aunque no parezca especialmente trascendente, pensad que este corte permite que origen y destino estén aislados, es decir que los equipos de desarrollo de cada parte no necesita saber nada del otro y se concentran exclusivamente a su labor (producir o consumir el mensaje) lo que facilita la confección de software. De forma complementaria, existirá un equipo de desarrollo que programará la lógica de enrutamiento y transformación del dato de origen a destino, el cual si deberá conocer ambos extremos.

Proyectos como Apache ServiceMix, Talend y JBoss Fuse implementan un motor ESB, los cuales fundamentan parte de su arquitectura en la tecnología OSGI (Apache Karaf) y una implementación de los patrones EIP a través de Apache Camel, el cual contiene además componentes para automatizar los procesos de lectura en origen y escritura en destino.

Estos proyectos aportan por lo tanto lógica de enrutamiento del mensaje y conectores de escritura de lectura / escritura (ficheros, SFTP, AS400, Amazon AWS, …) para facilitar que el agente integrador tenga la mayor parte del código ya implementado.

Este principio permite centrar las integraciones en un punto determinado para huir de las integraciones ‘spaguetti’ en las que el código que une los extremos se encuentra repartido en todos los puntos del camino.

Como vemos, utilizar un repartidor es especialmente útil cuando el vendedor se desentiende del reparto y el comprador no puede ir a buscar el pedido. Es decir, este planteamiento es adecuado en integraciones con sistemas que no pueden ni trasladar ni transformar el mensaje, arquitecturas dónde se quiere centralizar la lógica de integración de múltiples sistemas o ya se disponga de un componente de lectura / escritura.

¿Cuando utilizar un motor ESB?

  • Cuando los sistemas origen y destino son pasivos, es decir que no puede enganchar por sí mismos con nada (sistemas legacy).
  • Cuando tenemos equipos de desarrollo especializado sólo en un sistema específico y no queremos / podemos que conozcan la tecnología de otros sistemas.
  • Cuando queremos que existan equipos de desarrollo exclusivamente especializados en la integración, es decir llevar el dato convertido de origen a destino.
  • Cuando la lógica de lectura del mensaje en el sistema origen y la de escritura del mensaje en el sistema destino ya exista entre los componentes ofrecidos en el motor (Apache Camel en el caso de Apache ServiceMix / JBoss Fuse).
  • Cuando no queremos que la lógica de integración esté repartida anárquicamente en diferentes orígenes y destinos, y que esté centralizada en un punto común.

Suscríbete a nuestro boletín

Notas, trucos y consejos sobre integración y desarrollo.

Escribe tu dirección de correo electrónico y revisa a continuación tu email para confirmar la suscripción.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies