He visto de casualidad un interesantísimo webcast sobre patrones relativos a arquitecturas basadas en eventos e intercambio de mensajes. El autor del webcast es Ian Cartwright en colaboración con el ínclito Martin Fowler.
Me ha llamado poderosamente la atención la presentación porque llevo un tiempo involucrado en la arquitectura y el desarrollo de una aplicación en la que todos los patrones descritos en la presentación tienen mayor o menor aplicación. Muchos de ellos ya aparecen en la arquitectura actual a pesar de que no les conocía, esa es la mágia de los patrones, se repiten una u otra vez.
En el desarrollo de esta aplicación nos hemos enfrentado a varios de los problemas descritos en la presentación como garantizar el envio de fran número de eventos, el gestionar y mantener las subscripciones a todos esos eventos, y tambiénl evitar la notificación de eventos innecesarios.
Pasar de la arquitectura anterior de la aplicación totalmente basada en un modelo pool, en el que los clientes preguntan por el estado continuamente, a un modelo push en el que los clientes reciben eventos cuando se producen cambios en el estado de la aplicación a supuesto un reto importante. Sobre todo porque los eventos no son independientes entre sí y además pueden llegar de manera desordenada. Pero la ventajas que presenta ahora la arquitectura sobre todo desde el punto de vista de la resilencia, la capacidad para recuperarse de situaciones adversas de red o de errores de comunicación o caidas del servidor o de los perifericos, que ha aumentado espectacularmente. Y este era uno de los objetivos buscados.
Tambien usar un modelo basado en eventos y en mensajes hace que la aplicación sea desplegable de una manera mucho más distribuible, lo que mejora enormementa las posibilidades de escalabilidad.
Se habla mucho de las arquitecturas SOA pero sin duda las arquitecturas EDA (Event Driven Architectures) son el complemento ideal para un motón de escenarios habituales.
En la imagen adjunta os dejo un esquema de la arquitectura en cuestión, en la que el amigo, compañero de trabajo y vecino de blog Gorka Elexgaray, tambien puso su importante grano de arena. Podeís ver como aparece un Event Broker, elemento centrar el toda aplicación guiada por eventos y como la información se intercambia utilizando mensajes. Esto nos permite usar MSMQ como sistema de comunicación lo que nos permite que la arquitectura soporte bastante bien escenarios desconectados y desconexiones no esperadas.
Vaya, curiosamente también estoy haciendo yo algo parecido usando la flexibilidad de MSMQ. Mis eventos son generados ademas por unos trigers en la base de datos. Algo parecido a Notificatión Services, pero mucho más dinámico y no tan orientado a usuarios desconectados, sino a procesos conectados.
Ademas, con MSMQ puedes interrogar las colas directamente con las mmc’s, sin necesidad de realizar complicadas herramientas de administración de las mismas, muy útil para los administradores. Otra caracteristica muy buena es que puedes montar la infraestructura de ruteo de dichos mensajes con herramientas administrativas de Windows y tu desde tus programas, olvidarte de (casi) todo el apartado de transmisión, recuperación y verificación de los mensajes.
Un tema desde luego, interesante.
MSMQ es un gran desconocido, pero la verdad es que es sumamente potente.
Disculpa pero podrias subir una imagen donde se pueda visualizar mejor la descripcion de los eventos porque no se le entiende nada
Seria intersante que pudieras subir la misma imagen pero en mayor resolucion t si puedes algo mas de informacion ya que este tipo de arquitectura es bastante interesante .
Saludos..