Que son los ESB o buses de servicios empresariales?. Cuando empezamos viendo las suites de tipo BPM y los conceptos de SOA, dejamos sin tratar el tema de la orquestación y middleware. En este post ahondaremos en los ESB, su utilización y el lugar que ocupan en las implementaciones de arquitecturas empresariales vía SOA o BPM y el porque su nombre es menos conocido hoy en día (lo que no quiere decir en ningún caso que el concepto este en baja o no aplique).

Lo primero que usted debe considerar es que el termino ESB (Enterprise Service Bus) es un termino de marketing que inventaron las empresas que fabrican soluciones puras de middleware para entornos empresariales dentro de los esquemas de arquitecturas. Cuando hablamos de BPMs, nombramos el concepto de Suites de BPM o BPMs. Dado que existen soluciones de BPM que ya incorporan sus propias herramientas de middleware.

Sin embargo una solución de tipo ESB, por ser especifica para la capa intermedia de nuestra arquitectura podría ser mas poderosa y de mejor comportamiento en algunos casos que las herramientas que hoy en día las suites de BPMs incorporan. Por decirlo de otra forma, al ser soluciones creadas para un rol especifico, en general deberían dar mas soluciones a temas que están fuera del alcance SOA y WebService en términos de integración. Veamos mas al respecto…

En la siguiente figura puede observar a nivel practico, como una solución especifica de tipo ESB interactúan con distintas soluciones tales como BPM, o portales (puede hacer click sobre ella para ampliar).

Que podemos decir después de ver esto?. Que las soluciones ESB incluyen mas que SOA y WebService, son orquestadores de servicios (pero en el sentido amplio de la palabra, no solo webService), permiten interactuar de mejor forma y mas rápidamente a las componentes técnicas y de información con aquellas relacionadas a los procesos de negocio de las capas superiores o mas altas como las de tipo presentación o BPM.

En otras palabras, un ESB alineado además con una arquitectura SOA permite mantener la flexibilidad necesaria en sus procesos de negocio a nivel técnico y de codificación. Sin embargo hoy en dia si esta pensando en BPM muchas de las suites de este tipo incorporan componentes del tipo ESB muy poderosas y que se integran transparentemente con su BPM por ser de la misma suite y fabricante.

El aporte de un ESB va mas halla de una herramienta que facilite integraciones del tipo SOAP/HTTP WebServices sobre redes TCP/IP- Habilita middleware de servicios orientados a mensajería como JMS, administra colas y priorisa datas y comunicaciones de contenidos, administrando los estados de estas integraciones entre sistemas distribuidos. ESB aplica y apoya servicios débilmente acoplados, esquemas de eventos y listens, acceso a repositorios sobre múltiples plataformas y repositorios de información.

Ahora según mi experiencia cual es el riesgo en la componentes middleware o ESB si pensamos en soluciones fuera de las provistas por Suites BPM. Y Consideramos al ESB como un protagonistas especifico, real y de distinción propia en la arquitectura?

Principalmente es que se tiende a confundir las capas de middlare con las reglas de negocio, algo similar con lo que me ha tocado ver cuando las webservice compuestos se vuelven muy pesados y terminan siendo mas que compuestos. Esto es, empiezan a manejar parte de la capa de lógica de negocio, que no debería estar alli.

Como puede observar en el diagrama superior, un ESB o la solución de middlaware que usted considera lleva apellido, ese apellido es "Bus de Servicio!" , el riesgo y la posibilidad de agregar lógica de negocio, comprometerá toda su arquitectura, es la capa superior, BPM, la que deberá concentrar sus procesos de negocio, sus reglas de negocio, su lógica de negocio. El rol de un ESB no trata con lógica de negocio, trata con lógica de servicios, esto es resolución de servicios, monitorización de servicios, acceso de servicios, homogeneización de los mismos, Administración de adaptadores, ETLs, y todo este tipo de ámbitos.Pero todo esto lo realiza mediante soluciones del tipo Drag/Drop, o soluciones visuales de integración, el nivel de codificación en la capa ESB es menor, esa es la ventaja de este tipo de Middlewares.

En resumen un ESB no implementa una solución SOA, pero si la da las herramientas para facilitarle ese tipo de arquitecturas y además proveer otros mecanismos de integración, como mensajería, adaptadores hacia repositorios, listener y otros medios de administración de servicios.
Ahora cual seria el camino a seguir, en un escenario empresarial de múltiples plataformas, tecnologías y aplicaciones se queremos llevar todo lo que tenemos a un nivel de arquitectura empresarial flexible y orientada a servicios? (ojo que utilizo el concepto servicio en su amplio espectro no solo webservice, normalmente se confunde este tema).

Bien, dependerá del tamaño y presupuesto que tenga. Personalmente este enfoque de soluciones solo lo he visto en proyectos de banca y compañías de seguros consolidadas. Que cuentan con los presupuestos necesarios.

Personalmente no considero que la solución se inicie seleccionando una tecnología especifica para la empresa, entiendase .Net o J2EE (aunque ordenar la casa en este ámbito es necesario, al menos definir un conjunto finito y pequeño de tecnologías), personalmente me tiendo a inclinar hacia J2EE. La verdad es que la tecnología cambiara, mas allá de lo que usted seleccione hoy en día. Deberá asegurarse que ese cambio que vendrá tarde a temprano, pueda ser soportado en los niveles de procesos de negocio, para ello deberá contar con herramientas de middleware. En ese escenario un ESB resulta una opción precisa. Pero si su escenario tiende a estar mas relacionado a una empresa donde fluyen los procesos y documentos, donde las soluciones tienen componentes fuertes de interacción humana, tales como aprobaciones, altas, bajas, etc. Es decir donde los sistemas son H2S (Human to System) y H2H (Human to Human), mas de que S2S (System to System). Entonces una arquitectura BPM debería ser una opción mejor. Y en esa realidad, una suite BPM de excelencia le podría proveer de un middleware con sabor a ESB sino un ESB hecho y derecho según lo que valga la Suite BPM seleccionada.

En resumen y mi mejor consejo respecto a las ESB, es que los mantenga neutrales, lo mas posible a su negocio, en términos de reglas de negocio, y lógica de procesos. Considere a un ESB como un medio de transporte y coordinador de fuentes de información, mapeador de data, monitorizador de elementos, pero no ponga, y por favor no ponga inteligencia de negocio en el.

Javier Urrutia

(5 votos, promedio: 4.8 de 5)

 Loading ...