¿Por qué un Enterprise Service Bus (ESB)?

Tomado de: Por que un enterprise service bus

Por qué un Enterprise Service Bus (ESB)?
Juan José Vázquez

Se ha hablado mucho en los últimos años sobre los ESB, los web services y el fenómeno SOA en general. Gartner pronosticó que SOA sería usado en más del 80% de los procesos de negocio y aplicaciones críticas que se desarrollen en 2010. Estamos en 2010 y mi percepción es que, al menos en España, aún no hemos llegado a esos porcentajes en lo que se refiere al despliegue de soluciones SOA. Lo que sí es cierto sin embargo es que el ascenso de SOA y los ESB como solución tecnológica parece imparable en la mayoría de organizaciones y sectores.

Cuando una tecnología o un cierto paradigma se pone de moda, como ocurre con SOA, tenemos que mantenernos alerta ante la tentación de aplicarlo sin más en el contexto de mi negocio sin preguntarnos si es realmente lo que necesitamos. SOA implica analizar globalmente las necesidades del negocio para dar una respuesta tecnológica coordinada, reutilizable y que permita por tanto ahorrar en costes de desarrollo. Implica pensar en la evolución tecnológica de mi organización en el medio y largo plazo evaluando cuáles son mis necesidades de negocio actuales y cuáles serán en los próximos 10 o 20 años. Si nuestra única preocupación es el corto plazo, probablemente debamos considerar enfoques de desarrollo más tradicionales, que aunque resulten menos escalables, nos darán una respuesta rápida a los retos de hoy.
Enterprise Application Integration

Dicho esto, hay que hacer notar que la complejidad de las organizaciones es cada vez mayor. Caminamos hacia un modelo de organización sin barreras que se comunica a través de distintos canales de información y datos sobre un conjunto heterogéneo de sistemas de información operacionales que deben permanecer integrados para dar una respuesta conjunta a las demandas del negocio. No obstante, cada departamento o equipo de trabajo debe poder evolucionar tecnológicamente acorde a sus propias necesidades sin limitaciones impuestas por la visión integrada de la organización. Los responsables de sistemas de información deben pues asumir que es necesario mantener intacto el doble compromiso de evolución tecnológica para el negocio y la integración de los sistemas.

No es posible tener un único super-sistema operacional, pero igualmente, los sistemas no pueden permanecer aislados. Necesitan por un lado ser autónomos y por otro lado permanecer federados. Pensemos por ejemplo en el negocio sobre Internet o cloud computing. Es verdad que hoy en día es posible comunicar espacios de trabajo sobre redes WAN o VPN pero cada vez es más necesario poder establecer dichas comunicaciones más allá del firewall por ejemplo con partners o proveedores. Para un administrador de sistemas puede resultar un verdadero reto pasar a través del firewall cualquier protocolo y formato. Ante este escenario, se demandan nuevas soluciones tecnológicas que permitan la ubicuidad del negocio sin comprometer cuestiones como la seguridad o la calidad del servicio (QoS).

La competitividad y los nuevos retos del negocio hacen indispensable la innovación tecnológica. La innovación se traduce en la proliferación de sistemas de información que a menudo degenera en un estado de entropía tecnológica. La respuesta ante dicha entropía no puede ser la renuncia a la innovación sino que debe dar pie a abordar seriamente el problema de la integración de los nuevos sistemas con los sistemas legados, lo que se denomina comúnmente EAI o Enterprise Application Integration.

El EAI es el intercambio sin restricciones de datos y procesos de negocio entre cualquier aplicación y fuente de datos existente en la empresa. A un nivel básico, las arquitecturas de integración inicialmente implementadas en la empresa han sido:

* Punto a Punto: cada par de sistemas se integran atendiendo únicamente a sus requerimientos particulares. FTP, RMI o Remoting han sido protocolos típicamente empleados en llevar a cabo este tipo de integración.
* Base de Datos: a un nivel muy simple, una base de datos puede establecerse como unidad central de intercambio de datos entre sistemas e implementar por tanto un modelo de integración básica.

Estas dos arquitecturas, probablemente por su simplicidad y bajo coste aparente, siguen siendo hoy día la respuesta mayoritaria al problema de la integración en la empresa. Sin embargo, a medida que la complejidad tecnológica aumenta y las integraciones punto a punto se suceden, se evidencia una necesidad de mantenerlas controladas, administradas y gestionar su aprovisionamiento. Para atender a esta necesidad, se han sucedido nuevas respuestas al problema de la integración necesariamente más sofisticadas y ambiciosas:

* Hub-and-Spoke: todos los sistemas se conectan a un punto central o hub como en el caso de Microsoft BizTalk. A diferencia de la integración punto a punto, los sistemas se conectan al hub a través de conectores ligeros muy independientes de la tecnología particular de cada solución. El problema es que este punto central se convierte en extremadamente importante para la organización. Un fallo en el hub podría comprometer todos los procesos de negocio de la empresa.
* Enterprise Message Bus o broker de mensajes: en este caso no hay un punto central sino que los conectores están desacoplados gracias al intercambio de mensajes a través de un broker como el de IBM Websphere MQ (WMQ), Microsoft MSMQ o Apache ActiveMQ.

Enterprise Service Bus

Finalmente, comentaremos la arquitectura que se está imponiendo y que podría decirse resulta la más fiel implementación de SOA: el ESB o Enterprise Service Bus.

Un ESB parte de la idea de desacoplamiento introducido por el broker de mensajes incorporando una definición abierta de la forma de integración entre consumidores y publicadores de servicios. Un ESB usa WSDL y XML, estándares abiertos e interoperables, sobre una capa de transporte, típicamente HTTP. De esta manera los conectores no definen la implementación sino la capa de transporte y una interfaz de servicio. En el caso de un broker de mensajes los consumidores y publicadores de servicios asumen cierto conocimiento sobre los tipos de mensajes intercambiados y la tecnología empleada como es el caso de JMS o MSMQ.

Por consiguiente, un ESB puede distribuirse a lo largo de la organización, no necesitando un punto central de integración, y permitiendo la interoperabilidad entre sistemas implementados en las más diversas tecnologías. Las características básicas que debe presentar un ESB son las siguientes:

* Enrutamiento y redireccionamiento de mensajes.
* Estilo de comunicación síncrono y asíncrono.
* Multiplicidad de tipos de transporte y protocolos de enlace.
* Transformación de contenido y traducción de mensajes.
* Orquestación y coreografía de procesos de negocio.
* Procesamiento de eventos.
* Presencia de adaptadores a múltiples plataformas.
* Herramientas de diseño de la integración, de implementación y despliegue.
* Características de garantia de la calidad del servicio (QoS), como transaccionalidad, seguridad y persistencia.
* Auditoría, registro y métricas.
* Gestión y monitorización.

Como ejemplos de ESBs podemos nombrar Sonic ESB, Oracle Enterprise Service Bus, como ESBs comerciales, y Apache ServiceMix o Mule como implementaciones open source. El caso de ServiceMix es especialmente interesante por su alto grado de adecuación a estándares, sumando a los propios de un ESB como XML y WSDL, otros propios del universo Java como JBI (Java Business Integration) y OSGi.
Conclusión

La necesidad de un ESB surge de la complejidad de las organizaciones que deben coordinar e integrar sus procesos de negocio, sistemas operacionales y datos sin renunciar a la innovación tecnológica imprescindible para ser competitivos. Un ESB es la implementación de SOA, una arquitectura que permite mantener integrados los sistemas, nuevos y legados, en un estilo completamente distribuido e interoperable.