Enterprise Service Bus y Arquitectura Orientada a Servicios

¿Qué son ESB y SOA?

Enterprise Service Bus (ESB) y la Arquitectura Orientada a Servicios (SOA, por sus siglas en inglés) son los pilares de la integración empresarial y los patrones de integración empresarial. Como su nombre indica, normalmente asociamos esta tecnología a las grandes implementaciones empresariales de procesos y servicios de integración. Tradicionalmente, también son tecnologías y enfoques que asociamos con altos costes en términos de licencias o suscripciones y sus servicios correspondientes.

Sin embargo, el predominio de los estándares, en torno a esto, ha llevado a desarrollar una serie de tecnologías de código abierto que reducen drásticamente los costes asociados a las licencias y las suscripciones. La fundación Apache tiene una serie de proyectos en su cartera. También, hay muchos otros proyectos respaldados por los proveedores y apoyados por la comunidad. Esto ha reducido significativamente las barreras de entrada para las organizaciones más pequeñas que desean implementar esta funcionalidad y tecnología.

Propuesta de valor de la capacidad

Asociamos un ESB a los patrones clásicos de integración empresarial. La mayoría de los productos o proyectos se crean para llevarlos a cabo. Esto permite un enfoque estándar de entrega en todas las tecnologías. En general, significa que las soluciones son relativamente portátiles entre las tecnologías. No siempre es necesariamente cierto en la implementación, pero es común que muchas de las piezas de una implementación sean reutilizables.

El valor de un ESB radica en el enfoque de implementación basado en estándares. Es decir, permite extraer la arquitectura y el diseño de las soluciones de la implementación técnica. Los arquitectos pueden centrarse en el diseño de soluciones en cuanto a un conjunto estándar de patrones de integración. La arquitectura orientada a servicios es bien conocida en el mercado, lo que también significa que los recursos están generalmente disponibles en el mercado. Dado que asociamos estas implementaciones con grandes implementaciones empresariales, también las asociamos a servicios muy robustos, fundamentales y expansibles.

La aparición de tecnologías de código abierto en este ámbito significa que las organizaciones más pequeñas pueden aprovechar este enfoque de integración, la solidez y adaptabilidad de un ESB.

Usos habituales o casos de uso

Por lo general, vemos que los ESB se emplean en organizaciones que gestionan integraciones de naturaleza altamente fundamental. Las organizaciones que se conectan a sistemas heredados, servicios SOAP, estructuras de datos XML, procesos asíncronos, transferencia gestionada de archivos o que necesitan una entrega garantizada de mensajes, suelen apoyarse en un ESB para estas capacidades. Los casos de uso que implican la presentación de servicios discretos en una organización como parte de un catálogo de servicios global se benefician mucho de este enfoque.

A menudo, la nueva generación de proyectos de ESB de código abierto, ya sea de la Fundación Apache o respaldada por proveedores, se utiliza en proyectos de migración. Las empresas con altos costes permanentes asociados a servicios de integración muy estables están trasladando activamente sus servicios a plataformas de menor coste. Con la llegada de IPaaS y ESB de menor coste con raíces de código abierto, la propuesta de valor para las costosas implementaciones de ESB, se ha erosionado con rapidez.

Como socio de WSO2, a cada instante, vemos el WSO2 ESB combinado con el producto de API Management de WSO2, líder en el mercado, como alternativa a enfoques más costosos. Tenemos varios clientes que se benefician de este enfoque sólido y con gran capacidad de ampliación a un coste significativamente menor. En muchos casos, solemos dar soporte de principio a fin a toda la solución y reducimos la complejidad inherente en este tipo de implementaciones. Lo denominamos oferta de integración como servicio.

Prácticas de implementación recomendadas

En cuanto a la implementación, hay un camino muy trillado con respecto a la entrega de un ESB. La recopilación de requisitos, el establecimiento de la arquitectura, la arquitectura, los modelos, los esquemas de datos, las normas de la empresa, los mapeos de datos, etc., son actividades comunes como requisito previo en todos los proyectos de integración. Un área en la que podemos ver una diferencia de enfoque es en los papeles dentro de un proyecto. Es habitual que el enfoque de la solución o el patrón de integración que se va a implementar lo decida otra persona que no sea el desarrollador que realiza la integración. Asimismo, puede que veamos una segregación de los papeles en lo que respecta a la entrega de algunas de las piezas de integración, por ejemplo, XSLT para la transformación de datos en esquemas XML puede ser realizado por un desarrollador XML especializado.

El enfoque, el grado de segregación de los papeles, etc., depende del tamaño o la escala de la implementación y de la organización en la que se implementa. Algunas organizaciones, por ejemplo, ya tienen un papel definido de custodio de XML o desarrolladores de XML dentro de la organización que definirán los esquemas y construirán XSLT para los patrones de integración implementados. También, gestionarán esas piezas de manera permanente. En otras organizaciones más pequeñas, el desarrollador de la integración proporcionará toda la solución o el proceso de principio a fin. Lo que un comprador debería encontrar es que el enfoque de la entrega sea bastante consistente entre los productos dentro del ESB.

¿En qué se diferencian las tecnologías?

Los compradores o adoptantes de la tecnología ESB deberían encontrar o buscar un soporte consistente para los patrones de integración empresarial bien definidos en los productos que están evaluando. No apoyar estos patrones, pondrá en duda la propuesta de valor de la tecnología. Algunos proveedores del mercado han hecho un gran trabajo en términos de diseño de interfaz de usuario para reducir la complejidad de los patrones. Algunos incluso han cambiado por completo la forma de utilizar el bus de servicio y han trasladado sus productos hacia tecnologías más al estilo IPaaS. En cuyo caso, se apoyan generalmente en la solidez de la tecnología como base de su montón.

La experiencia del usuario, la cobertura del conector SaaS y los conectores tecnológicos basados en cloud son áreas clave de diferenciación. Los cubos de Amazon S3, el almacenamiento Azure Blob, Amazon SQL, Google Pub/Sub, Apache Kafka son ejemplos de tecnologías de conectores en los que los productos ESB pueden intentar diferenciarse. En el mundo de Azure, el bus de servicio es solo un componente de los servicios de integración de Azure. Es una base para proporcionar una entrega de mensajes garantizada con el apoyo de sesiones para agrupar mensajes relacionados. Los patrones de integración empresarial ya no son relevantes en una implementación de integración basada en Azure.

La experiencia del usuario y la flexibilidad en las opciones de implementación es otra área fundamental de interés. WSO2, por ejemplo, se ha esforzado mucho en poder implementar la funcionalidad de ESB como microservicios en contenedores. Lo mismo ocurre con Tibco en el mercado. Aquí es donde podemos ver que los proveedores se adaptan a nuevas formas de implementación de la tecnología de integración.

Consideraciones

La adopción de un ESB debe basarse en la adopción de un enfoque orientado a servicios. Si una organización tiene arquitectónicamente poco interés en los patrones de integración empresarial (EIP, enterprise integration patterns), la elección de esta tecnología será cuestionable. La excepción será cuando la tecnología se haya adaptado de alguna manera para aportar beneficios que hagan que los EIP sean irrelevantes en su implementación. Las organizaciones que adopten un ESB deben buscar la solidez inherente del enfoque y estar dispuestas a adoptar la disciplina que lo acompaña o involucrar a una organización que pueda proporcionar la disciplina como Chakray.

Las organizaciones que son nuevas en la integración o tienen un enfoque de cloud/SaaS, pueden ver a un ESB como un gasto innecesario en cuanto al enfoque de integración. Para estas organizaciones, una solución del estilo IPaaS puede ser una tecnología de integración mejor para implementar y más fácil de adoptar. Para muchas organizaciones que tratan con procesos asíncronos o de larga duración, la necesidad de un almacén de mensajes hace que la tecnología sea una parte inherente de sus necesidades arquitectónicas.

Las tecnologías ESB de código abierto más accesibles, ya sean de código abierto o estén disponibles con una suscripción de soporte del proveedor, son ahora casi el camino de facto para la implementación de ESB. Por lo general, pasar por alto esta opción se considera que es ignorar el valor de su operación informática.

Cómo puede ayudar Chakray

Chakray se fundó originalmente sobre su experiencia con tecnologías de integración de código abierto. Si una organización busca tecnología ESB, le ofreceremos una solución ESB de código abierto respaldada comercialmente o basada en el consumo. Consideramos que esto es fundamental para nuestros valores en cuanto a la entrega de valor a nuestros clientes. No significa que no implementemos sobre otras tecnologías de proveedores propietarios o que recomendemos un ESB de código abierto cuando una tecnología IPaaS sea más apropiada. Nuestro negocio se basa en el principio de hacer lo correcto para nuestros clientes y les ayudamos a tomar decisiones de integración pragmáticas.