Nos encantan los acrónimos, lo usamos para todo, pero en muchas ocasiones es difícil entender el significado, más aún si no lo hemos escuchado en nuestra vida. También puede ser complicado si no estamos en contexto, «¿quizá esté post vaya a hablar de Electricity Supply Board o de Educación Secundaria Básica…?». Pero no, vamos a hablar de un elemento software muy utilizado y extendido.
ESB
Un Enterprise Service Bus (ESB) se trata de una infraestructura software que actúa como capa intermedia (middleware) para comunicar los diferentes sistemas de una empresa, tanto sistemas internos de la misma como otros fuera del ámbito de ésta. Para llevar a cabo estas comunicaciones se basa principalmente en el uso de tecnologías web para enlazar los distintos puntos.
ESB
Aunque a priori un ESB no ofrece una funcionalidad que pueda ser considerada como estrictamente necesaria en una empresa, lo cierto es que facilita enormemente las tareas de integración entre diferentes sistemas que en muchos casos «hablan» lenguajes, estándares y formatos de información distintos.
Una de las funciones del ESB será recibir mensajes en diferentes estándares y transformarlos a otros distintos para que sea posible el entendimiento entre los extremos.
También puede encargarse de gestionar la carga de los sistemas a través del uso de colas y el tratamiento asíncrono de la información, lo que en muchas ocasiones mejorará el rendimiento y disponibilidad de las otras plataformas. Esto lo veremos más claro con un ejemplo (así dejamos de hablar de humo 😀 ):
Ejemplo
Si tenemos un sistema central en la empresa (A) con el cuál el resto de plataformas se conectan (B, C y D), su servidor debería de ser capaz de asimilar toda la información que el resto de sistemas generan. De lo contrario se saturaría y sufriría continuos cortes en el servicio, con los problemas que ello conlleva: empleados que no pueden trabajar por la lentitud de las aplicaciones, continuas quejas de las empresas externas que nos solicitan información, e incluso poner en riesgo el rendimiento y disponibilidad de otros sistemas.
Además los sistemas B, C y D deben ser capaces de enviar la información en el estándar y «lenguaje» (lo que A llama teléfono para B es phone) del sistema A.
Ejemplo punto a punto
Si en lugar de una arquitectura que envía la información punto a punto se utilizase un ESB, éste podría encargarse de tratar la información que la aplicación B, C y D y reenviarla de manera escalonada al sistema central A. De esta manera evitaríamos un sobredimensionamiento de A que, con total seguridad, fuera de los picos de trabajo estaría siendo desaprovechado. Con esto mejoraríamos el rendimiento del mismo y con ello el del resto de sistemas.
Al utilizar el ESB, ninguno de los sistemas que se conectan con A necesitan conocer nada de estándares o el tipo de información que maneja, dejando este cometido al ESB que se encargaría de traducir adecuadamente la información.
Ejemplo de ESB
Conclusiones
Ahora bien, con el ejemplo surge una duda importante y podrás decirnos:
Sí, ya no está la carga en el sistema A y ahora está en el ESB, éste se saturará de la misma manera que lo haría el A. Entonces, ¿qué he ganado con esto?
Bueno, es cierto que ahora la carga estará en el ESB, pero la finalidad de éste no es más que transportar información, no la trata y no la almacena, por esto los mensajes no requieren demasiado tiempo para ser reenviados y difícilmente lo saturaremos.
En el ejemplo se puede apreciar fácilmente dos de las ventajas que ofrece una arquitectura compuesta por un middleware respecto a una arquitectura monolítica (conexiones punto a punto). Otra posible ventaja que no se aprecia en este ejemplo es que el ESB también sería capaz de agregar servicios de los distintos sistemas. Un rápido ejemplo:
Si el sistema A necesitase mandar la información a B, C y D, no sería necesario que mandase la información a los tres puntos, si no que solo lo mandaría al ESB. Esto ofrece ventajas a la hora de gestión de los errores, reduce el tiempo de respuesta y con todo ello mejoraría el rendimiento de A.
Finalmente ofrece una gran ventaja, que no he mencionado antes, de cara a posibles cambios que se puedan producir en la arquitectura puesto que abstrae de las modificaciones que los sistemas pueden sufrir. Volviendo al ejemplo de antes:
Si B y C necesitan enviar información al sistema A y éste sufriera algún cambio con el paso del tiempo (como cambio en la tecnología de comunicación, seguridad, etc) solo sería necesario adaptar la comunicación entre el ESB y A. De esta manera se evita tener que adaptar las comunicaciones en dos sistemas y hacerlo solo en uno, el ESB. Evidentemente, este aspecto es más notable cuantos más sistemas se conecten a la plataforma A, pudiendo ser un gran ahorro de tiempo (y dinero).
En el siguiente tutorial hablaremos ya de un software de ESB concreto, Mule ESB. Hasta entonces, cualquier duda os podéis poner en contacto con nosotros.