La mensajería basada en eventos es un patrón de diseño que permite a los consumidores de servicios, que están interesados en eventos que ocurren dentro de la periferia de un proveedor de servicios, recibir notificaciones sobre estos eventos a medida que ocurren sin recurrir al mecanismo tradicional ineficiente basado en sondeos . [1]
Es importante diferenciar entre servicios basados en eventos y servicios basados en mensajes (también conocidos como servicios basados en colas) : los servicios basados en eventos (por ejemplo, AWS SNS ) están desacoplados de sus consumidores, mientras que los servicios basados en colas o mensajes (por ejemplo, AWS SQS ) están acoplados a sus consumidores. [2]
La interacción entre un consumidor de servicios y un proveedor de servicios normalmente la inicia el consumidor de servicios, ya que necesita responder a un evento que ocurre dentro de los límites del propio consumidor de servicios, por ejemplo, requerir algunos datos de un recurso externo (es decir, el proveedor de servicios) para realizar un cálculo cuyos resultados deben transmitirse a una interfaz de usuario en respuesta a una acción realizada por el usuario. [3] Sin embargo, hay situaciones en las que el consumidor de servicios necesita esperar a que ocurra un evento dentro de los límites del propio proveedor de servicios. En estas circunstancias, el consumidor de servicios necesita de alguna manera ser informado del evento a medida que ocurre. Una forma es programar al consumidor de servicios para que sondee al proveedor de servicios con intervalos regulares para que pueda verificar si el evento sucedió o no. Este enfoque no solo manifiesta ineficiencia sino también imprevisibilidad conductual. Ineficiencia porque el consumidor de servicios y el proveedor de servicios participan en interacciones improductivas y poco confiables porque podría ser que el evento realmente sucediera más de una vez antes de que el consumidor de servicios pudiera sondear al proveedor de servicios, perdiendo así los eventos anteriores y sus datos relacionados. Aparte de estos problemas, esta técnica también introduce latencia, ya que el intervalo con el que el consumidor del servicio realiza el sondeo es fijo y, por lo tanto, solo obtendría los datos del evento en ese momento y no cuando el evento realmente ocurrió. Todo este escenario se deteriora aún más si varios consumidores de servicios dependen de un proveedor de servicios en particular.
Para abordar este problema, el patrón de diseño de mensajería basada en eventos sugiere un mecanismo de comunicación entre editor y suscriptor que garantiza la notificación oportuna de datos relacionados con eventos al consumidor del servicio, [4] eliminando así las ineficiencias vinculadas con el mecanismo de comunicación tradicional basado en sondeos.
La aplicación del patrón de diseño de mensajería basada en eventos requiere un gestor de eventos con el que el proveedor de servicios registra sus eventos. Los consumidores de servicios registran entonces su interés en algunos o todos los eventos anunciados. Cuando se produce un evento, el proveedor de servicios informa al gestor de eventos, que a su vez notifica instantáneamente a todos los consumidores de servicios registrados. [5] Este mecanismo de comunicación comparte sus raíces con el patrón Observador aplicado tradicionalmente en el mundo orientado a objetos . [5] Este patrón de diseño también toma prestados algunos conceptos de la Arquitectura basada en eventos, ya que la razón fundamental detrás de este patrón de diseño es la respuesta a los eventos. [6]
La implementación real de un mecanismo de comunicación basado en publicador-suscriptor requiere extensiones arquitectónicas para proporcionar un mecanismo de seguimiento y reenvío de mensajes tan complejo. Un producto ESB maduro normalmente debería poder proporcionar dicha funcionalidad. La aplicación de este patrón ayuda a desacoplar aún más [7] a los consumidores de servicios de los proveedores de servicios y aumenta la confiabilidad general de una composición de servicios.