Integraciones de sistemas con Enterprise Service Bus 

¿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 Service Bus (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, este corte permite que origen y destino estén aislados, es decir, los equipos de desarrollo de cada parte no necesita saber nada del otro y se concentran exclusivamente en 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

 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.

Los citados 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.

Conclusiones

Con 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?

• Los sistemas origen y destino son pasivos, es decir que no puede enganchar por sí mismos con nada (sistemas legacy).
• Tenemos equipos de desarrollo especializado sólo en un sistema específico y no queremos / podemos que conozcan la tecnología de otros sistemas.
• Queremos que existan equipos de desarrollo exclusivamente especializados en la integración, es decir llevar el dato convertido de origen a destino.
• 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).
• 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.

Te puede interesar:

Servicios Open Source  |  Integración de sistemas