Parece que nos hubiéramos olvidado de SOA (Service Oriented Architecture) y de todo lo que supuso… y supone aún. Pero no nos debemos olvidar porque las necesidades de integración de sistemas y de arquitecturas que permitan estructurar el armazón funcional y de información siguen vivas, muy vivas. Un elemento arquitectónico muy importante a que dio lugar el desarrollo de SOA es el Enterprise Service Bus, una pieza de software, un middleware como se le dio en llamar, que se constituía en una especie de conector universal.
Definiciones académicas aparte, el Enterprise Service Bus es un software cuya misión, en esencia, es interconectar sistemas. No proporciona por sí mismo una funcionalidad para el usuario final, sino que hace más fáciles y racionales los intercambios de información y servicios entre diferentes sistemas para proporcionar funcionalidades más amplias o para, por ejemplo, implementar extremo a extremo un proceso de negocio.
El Enterprise Service Bus ofrece mecanismos tecnológicos (Web Services, colas de mensajes, conectores a aplicaciones populares, etc) para implementar servicios de interconexión pero, además, suele ofrecer funcionalidades adicionales como la traducción de datos o adaptación de formatos, la persistencia y transacionalidad de las interacciones o la implementación de pequeños workflows.
En su libro ‘Dynamic SOA and BPM‘, Marc Fiammante agrupa en cuatro las responsabilidades de un Enterprise Service Bus:
- Enrutado de mensajes: Cuando utilizamos un ESB la aplicación que necesita un servicio de otra, no llama directamente a esa otra aplicación sino que lo hace a través del bus y es el bus quien sabe cómo hacer llegar esa invocación a la aplicación destino. Esto constituye un primer nivel de desacoplamiento o independización entre ambas aplicaciones
- Conversión de protocolos de transporte: Es decir, cada aplicación o servicio puede utilizar el protocolo que más le convenga y es el bus el que sabe utilizar en cada interacción el protocolo adecuado y realizar las conversiones oportunas cuando protocolo de peticionario y servidor no son iguales.
- Transformación de formatos de mensajes: El bus realiza, si es necesario, traducciones de formatos de argumentos y contenidos de mensajes con lo que, de nuevo, independiza a las aplicaciones que no tiene por qué usar los mismos formatos.
- Tratamiento de eventos de negocio dispares: con lo que, el mismo servicio ofrecido por una aplicación, puede ser invocado en diferentes contextos de negocio.
Como se puede ver, el Enterprise Service Bus viene a ser, dicho de forma muy sencilla, un facilitador de las interacciones entre aplicaciones, desacoplando sus lógicas, interfaces y liberando a éstas de la esclavitud e ineficiencia que suponen los acuerdos bilaterales de protocolos y formatos de mensajes en las interfaces tradicionales.
Se trata, pues, de una pieza de software injustamente olvidada, puesto que juega un papel esencial en la arquitectura de cualquier empresa con un mapa de sistemas complejo.
2 comentarios