Cuando nos planteamos la utilización de un bus de servicios empresariales (ESB) como parte de la adopción de nuestra Arquitectura SOA; normalmente existen 2 aproximaciones principales a la utilización del mismo: utilizar un único ESB como "tubo unificado" de comunicación de todos los servicios empresariales; o montar una topología de varios ESB que solventen problemáticas de integración a nivel departamental o de diversos dominios.
Cada una de las 2 aproximaciones tiene sus ventajas y desventajas:
- Si dejamos que cada departamento implemente su propio ESB; estaremos dando libertad para que cada uno adopte la solución que quiera; no obstante la comunicación entre varios dominios tendrá que ser establecida de manera explícita.
- Por el contrario, si utilizamos un único ESB; el control del mismo será único y todos los departamentos tendrán mayor rigidez a la hora de realizar sus integraciones o desarrollos; y además la comunicacion entre servicios interdepartamentales será casi nativo a la propia topología de un esb único.
En cualquier caso, el utilizar un único ESB no implica una anarquia en la utilización de servicios y la "no existencia" de bordes o límites entre departamentos. Normalmente, una aproximación de ESB único implica la creación de dominios y subdominios que establecen los límites del conjunto de servicios que expongan (tendremos servicios públicos a todos los dominios del ESB y privados para el propio dominio).
Cuando utilizamos registros de servicios, en el caso de ESB unificados, la sincronización entre registros (en caso de que existan varias instancias) es propia de este tipo de topologías. Si hablamos de buses diferentes; tiene que existir un proceso externo de sincronización (cuando sea necesario) o al menos el conocimiento de la existencia de diferentes registros (en un intento de favorecer la publicación y suscripción a servicios empresariales, para así buscar la reutilización como fin último de nuestros registros).
Incluso, cuando tratamos temas como el de la gobernabilidad es muy importante tener constancia de todos los posibles ESB que estemos utilizando (un cambio en un servicio de un ESB debe ser notificado a cualquier consumidor de otro ESB que pueda referenciarlo). Es por ello importante, definir los modelos de gobernabilidad que van a utilizarse, para asegurar siempre la consistencia y el conocimiento de la información que manejan.
A la hora de orquestar servicios con, por ejemplo, un motor BPEL, este necesita tener puntos de acceso a los servicios que utilice en cada uno de los buses de servicios que desee conectarse. Puede ocurrir, por ejemplo, que el motor BPEL esté integrado en el propio ESB (como por ejemplo ocurre en la especificación JBI en algunos casos) y eso facilite la orquestacion de servicios en un mismo ESB (en el caso de utilizar varios ESB, se deberán establecer gateways de comunicación entre ellos).
A raiz de esa comunicación entre buses es importante tener en cuenta la fiabilidad de las comunicaciones, ya que de utilizar buses independientes se deberán establecer métodos de comunicación que aseguren la fiabilidad de los mismos (siempre que sean necesarios y un simple protocolo http, por ejemplo, no sea suficiente).
La administración y la monitorización (BAM) en casos de buses unificados se simplifica ya que las consolas de administración están unificadas y, en el caso del BAM, la explotación de datos es más directa y fácil que cuando tenemos varios ESB’s separados.
Sea como sea, e independientemente de la solución escogida; hay que tener en cuenta siempre estos factores; ya que normalmente cuando nuestra arquitectura SOA crece, es importante tener siempre el control de todos ellos de la manera más simple y fiable posible.
¿Qué creeis? ¿Es mejor una aproximación topológica de un ESB unificado o una topología de diversos ESB’s departamentales? ¿Qué experiencias prácticas teneis al respecto?
[Recuerda que puedes plantear cualquier duda nueva o abrir cualquier tema de discusión en el nuevo Foro de Espacio SOA]
