Méritos de un sistema de "Transmisión de mensajes" frente a un sistema "Basado en eventos"

Mi pregunta proviene de una perspectiva un tanto inculta.

¿Cuáles son los méritos relativos de un sistema de " transmisión de mensajes " frente a un sistema " basado en eventos "?

¿Por qué uno elegiría uno sobre el otro? Cuales son sus fortalezas y debilidades?

Me gustaría saber no solo "en teoría", sino también "en la práctica".

EDITAR:

Problema específico :

Quiero construir un sistema de componentes conectables que se comporten como servicios a pequeña escala (cada uno realizando una pequeña tarea y / o proporcionando alguna información).

Los servicios pueden:

• estar en capas para que la salida de un servicio pueda actuar como una de las entradas a otro
• tener jerarquías de contención para que un servicio pueda ser contenido por otro sin una relación de entrada-salida específica como se menciona en la oración anterior

El objetivo del sistema es traducir un flujo único de eventos de bajo nivel en otro sistema en información y funcionalidad de nivel superior, y además proporcionar un canal de regreso al otro sistema que proporciona una única serie de eventos.

Puedo proporcionar más detalles si esto no es suficiente.

Después de mirar un poco más. Esto y esto probablemente describe mejor mi situación.

Parece que puede ser una buena opción para mi situación: http://akka.io/

En mi experiencia, la única diferencia específica es que en la mayoría de los sistemas de transmisión de mensajes, el remitente del mensaje sabe (y a menudo declara) quién es el destinatario del mensaje.

Entonces, en lugar de generar un evento y cualquier persona que se haya suscrito al evento que lo recibe, el remitente define alguna identificación del destinatario o grupo lógico de destinatarios y luego envía el mensaje directamente a ellos o pasa por un intermediario de mensajes (aunque el sistema operativo se puede ver como un agente de mensajes en un sistema basado en eventos).

Obviamente, existe el caso de subprocesos que Telastyn menciona con la implementación de eventos de C #, pero aún puede crear su propio modelo de pub / sub que se ejecuta en diferentes subprocesos.

Esto es manzanas y naranjas:

Un sistema controlado por eventos puede reaccionar a los eventos pasados ​​como mensajes (los mensajes en este contexto son datos no compartidos implícitos inmutables ) a medida que se generan los eventos. Este es un diseño puramente arquitectónico.

Un sistema de paso de mensajes puede ser impulsado por eventos que crean y pasan los mensajes. Este es un diseño puramente de implementación.

Los dos no son mutuamente excluyentes.

Ejemplo: puede implementar un diseño controlado por eventos en cualquier idioma, que también puede ser un entorno de paso de mensajes como en Erlang.

Gran parte de la confusión entre "pasar mensajes" y "basado en eventos" tiene que ver con los detalles arquitectónicos versus los de implementación. He visto (y escrito) sistemas controlados por eventos que realmente usan mensajes provistos por el sistema operativo para su implementación. Supongo que realmente te estás refiriendo a ideas arquitectónicas.

Como muchas personas ya han señalado, "pasar mensajes" y "basados ​​en eventos" no son términos realmente buenos para evitar la ambigüedad.

¿Cuáles son los méritos relativos de un sistema de "transmisión de mensajes" frente a un sistema "basado en eventos"?

Paso de mensajes

Comenzaré por adivinar que cuando dices un sistema de "transmisión de mensajes", estás hablando de un sistema en el que un objeto pasa un mensaje a otro objeto específico. Cuando pienso en un sistema basado en este paradigma, generalmente pienso en un sistema en el que un objeto que detecta algo sabe quién necesita que se le informe sobre algo. (No estoy especificando cómo sabe, solo que sabe).

Este tipo de arquitectura es muy buena para sistemas donde los productores y consumidores son bien conocidos. El productor de un mensaje sabe quién debe recibirlo o el consumidor debe saber de quién obtener el mensaje.

Si está escribiendo una solicitud bancaria, uno esperaría que realmente quiera saber a quién está enviando sus transacciones y de quién provienen.

Basado en eventos

El otro sistema en el que creo que está pensando cuando dice que un sistema "basado en eventos" es aquel en el que un objeto genera un "evento" sin saber quién (si alguien) responderá.

Este tipo de arquitectura basada en eventos es muy buena para sistemas en los que al productor no le importa quién consume el evento o donde al consumidor realmente no le importa quién produjo el evento.

En general, estos sistemas son excelentes cuando no conoce la relación entre consumidores y productores, y donde espera que la relación sea dinámica.

Un sistema en el que he usado esto fue un sistema en el que la aplicación estaba compuesta de módulos configurados dinámicamente (complementos) que se cargaban en tiempo de ejecución. Cuando se cargaba un módulo, se registraba para los eventos que le interesaban. El resultado fue un sistema en el que era muy fácil ampliar la funcionalidad.

Por ejemplo, digamos que la condición A provocó un evento EA que normalmente causó la respuesta RA. El objeto que causó la respuesta RA simplemente se registró para recibir el evento EA y actuó sobre él cuando llegó. Ahora, supongamos que queremos agregar una nueva respuesta a EA, llamada RA_1. Para hacer esto, simplemente agregamos un nuevo objeto que busca EA y genera la respuesta RA_1.

Aquí hay un par de ejemplos (usando su terminología):

• "pasar mensaje" : su jefe le dice que complete su hoja de tiempo.
• "impulsado por el evento" : la secretaria del departamento envía un correo electrónico a todos para recordarles que sus hojas de tiempo deben presentarse hoy.

En SOA tienes el concepto de mensajes de comando y mensajes de evento . Hay una necesidad de ambos.

Sin embargo, los mensajes de comando tienen un mayor acoplamiento de comportamiento con el punto final del destinatario, ya que está pidiendo explícitamente al punto final que realice alguna función. No es necesario que esté vinculado a un punto final particular (esto se puede configurar o determinar en tiempo de ejecución).

Los mensajes de eventos, por otro lado, no tienen acoplamiento de comportamiento entre el remitente / destinatario ya que el remitente no tiene idea de lo que un destinatario va a hacer con el mensaje. Ni siquiera sabe si alguien está suscrito al evento.

Para obtener más información, puede leer el sitio de mi servicio de autobuses aquí: http://www.servicebus.co.za

En mi experiencia, la mayor diferencia entre los dos es que los mensajes en un sistema de paso de mensajes son objetos de primera clase, mientras que los eventos en sistemas controlados por eventos son mucho más simples. Los mensajes tienden a transportar información, y esa información puede transformarse, almacenarse, recuperarse y reenviarse. Los eventos tienden a transportar fragmentos de información más pequeños y enfocados que se consumen de inmediato y luego se descartan. Tienden a enviarse desde un origen de eventos directamente a uno o más receptores de eventos, mientras que los mensajes se enrutan más a menudo entre varios receptores, y pueden convertirse / traducir / envolver o procesar de otro modo en cualquier punto a lo largo de la ruta. Utilizan tecnologías similares (autobuses, colas, filtros, etc.) pero son bestias realmente dispares.

Desde un punto de vista práctico, los mensajes generalmente se implementan como un bloque de memoria que se copia desde el espacio de direcciones del remitente al espacio de direcciones del receptor (o que se impone como un objeto inmutable) para que pueda obtener seguridad de subprocesos de inmediato.

En algunos casos de envío de mensajes, el remitente debe especificar el receptor, pero en otros casos puede simplemente publicar un mensaje en un buzón, y cualquiera puede escuchar los mensajes en ese buzón, por lo que hay cierta flexibilidad en lo estrechamente unidos que están. Por supuesto, puede tener un buzón donde el contrato es "Publicaré un mensaje en este buzón cuando ocurra este evento ".

En el caso de eventos, está registrando un delegado o una devolución de llamada con el propietario del evento. En la programación orientada a objetos, esto significa que el propietario del evento mantiene una referencia al objeto que se registró para recibir el evento. Esto a veces puede llevar a pesadillas en la contabilidad, tratando de descubrir qué objeto olvidó anular el registro de su controlador de eventos. Significa que el objetivo no puede ser recolectado como basura hasta que el propietario del evento sea recolectado, incluso si el objetivo ya no está haciendo nada útil.

Personalmente, elegiría el mensaje que pasa sobre eventos, excepto en los casos en que los eventos son forzados a usted, como la programación de la GUI de Windows, etc.