¿Qué es un ESB – Enterprise Service Bus?

Cuando se habla de arquitecturas orientadas a servicios, se habla intrínsicamente de los componentes necesarios para tener una arquitectura SOA. Sin duda alguna, uno de los componentes más importantes de una arquitectura orientada a servicios es el Enterprise Service Bus - ESB.

Conforme las organizaciones van moviéndose hacia las arquitecturas orientadas a servicios, se dan cuenta que están trabajando con un “mix” entre lo nuevo y lo viejo. Un ESB es básicamente la integración de lo nuevo y lo viejo, brindándo un lugar central para los servicios, las aplicaciones, y recursos de TI en general que se desean conectar. En otras palabras, lo que se busca es una infraestructura y un sistema de eventos que me permitan conectar cualquier recurso de TI sin importar la tecnología que utiliza el recurso. Esta infraestructura debería permitir administrar los cambios en los requerimientos sin causar problemas a los servicios ya instalados. Esta infraestructura debe de ser confiable y robusta. Aquí es donde entra el concepto de ESB.

Un ESB no solamente permite combinar y re ensamblar servicios, sino que también debe permitir conectar nuevas aplicaciones, servicios web y cualquier otro tipo de aplicaciones tales como aplicaciones LOB ( Line of Business ), archivos batch, legacy middleware a través de adaptadores; todo esto manteniendo la abstracción del manejo de mensajes a través del patrón publicar-suscribir.

Siendo más concretos, podemos decir que un ESB ofrece las siguientes funcionalidades:

• Transparencia de Ubicación: El ESB ayuda a desligar el consumidor del servicio de la ubicación del proveedor del servicio. El ESB provee una plataforma central para comunicarse con cualquier aplicación requerida sin ligar el recibidor del mensaje con el que envía el mensaje.
• Conversión de Protocolo de Transporte: Un ESB debe de tener la capacidad de integrar de forma transparente a través de diferentes protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP, etc.
• Transformación de Mensaje: El ESB brinda funcionalidad para transformar mensajes desde un formato hasta otro formato basado en estándares tales como XSLT y XPath.
• Ruteo de Mensajes: El ESB determina el destino de los mensajes entrantes.
• Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar información faltante basado en los datos del mensaje de entrada.
• Seguridad: Autenticación, autorización, y funcionalidad de encriptación se proveen a través del ESB para asegurar los mensajes entrantes. Igualmente estas funcionalidades se aplican a mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a consumir.
• Monitoreo y Administración: Un ambiente de monitoreo y administración del ESB es fundamental para configurar el ESB para que sea confiable y tenga un alto desempeño; al mismo tiempo, nos permite monitorear la ejecución de los mensajes y su flujo dentro del ESB.

La siguiente figura nos muestra un “big picture” de lo que es un ESB.

Dadas estas funcionalidades de un ESB, ¿cuándo necesito utilizar un ESB?

Conforme las organizaciones van adoptando servicios, se va creando la necesidad de una arquitectura orientada a servicios. Hay una gran diferencia entre el uso casual de servicios y llevar la organización a correr sobre servicios. Conforme se avanza hacia una arquitectura orientada a servicios, van a surgir muchos contratiempos, entre los cuales podemos enumerar como manejar una gran cantidad de servicios de una manera adecuada evitando la duplicación de funcionalidad, como medir y forzar los SLA´s –Service Level Agreement –, como forzar politicas organizacionales dentro de la colección de servicios que se tiene y a la cual se le van agregando servicios.

Además, en el mundo Microsoft existe WCF, el cual es un framework excelente para comunicaciones distribuidas, pero es solo eso, un framework.

Normalmente, cuando se empiezan a tener una cantidad de servicios que deja de ser pequeña y más bien podríamos considerarla de mediana a grande, se empiezan a tener problemas que no se tenían cuando solamente se manejaban un grupo pequeño de servicios. Entre los problemas que se dan más comúnmente podemos enumerar proliferación de servicios por toda la organización sin control, los cuales utilizan diferentes protocolos y tecnologías para su desarrollo e implementación. No hay governance, las configuraciones no son estándar, no hay versionamiento de servicios, etc. Cuando se empiezan a tener este tipo de problemas, y la organización empieza a dar un paso más serio hacia el uso de servicios como plataforma para sus aplicaciones, se empieza a necesitar más y más una arquitectura orientada a servicios.