mensaje impulsado vsevento impulsado enfoques para la integración de aplicaciones

Question

Me preguntaba si hay una clara distinción entre el mensaje impulsada y controlada por eventos de ambientes cuando nos referimos a la SOA o middleware y, en general, en los casos de aplicación y la integración de la empresa.Entiendo que una interfaz de usuario similar a un evento impulsado modelo en el que nuestro sistema intercepta la acción por parte del usuario.

También es claro que de mensajería compatible con los sistemas basados en la publicación/suscripción, síncrono o asíncrono de comunicación, transacciones, etc.

Pero hay una diferencia en el middleware soa/solicitud de integración dentro de contexto?(nivel de la arquitectura).Estoy tratando de consultar fuentes de wikipedia (aquí, y aquí), pero todavía estoy un poco confundido.Cuando se debe a un desarrollador prefiere una solución más que el otro?

Hay ejemplos o casos en los que un enfoque tiene más sentido que el otro?O cualquier integral de los recursos y guías para la implementación de cada uno de ellos?

Muchas gracias por la comprensión.

Answer 1

Respuesta corta "existe una clara distinción" sería "no".

Los términos no son intercambiables, sino que implica la misma arquitectura básica - en concreto de lo que será el desencadenamiento de eventos o mensajes.

El primer artículo de referencia es acerca de la plomería de bajo nivel, la MAMÁ o el pub-sub de "bus" que transporta los mensajes en su nombre.El evento impulsado por la arquitectura es lo que se construye en la parte superior de ese marco.

El término orientado a eventos, mientras que también aplica para el código GUI, no es realmente en el mismo nivel de abstracción.En ese caso, es un patrón en-el-pequeño en comparación con la construcción de la totalidad de la empresa a lo largo de mensaje/evento impulsado por las líneas.

Answer 2

Aquí es un Typesafe/Reactiva punto de vista sobre la cuestión de Jonas Bonér.En el tercer párrafo de este blog:

Con la diferencia de que los mensajes que se dirigen, los eventos no — un mensaje que tiene una clara direccionable destinatario, mientras que un evento acaba de pasar por los otros (0-N) a observarlo.

Answer 3

Esta pregunta se hizo hace mucho tiempo.Creo que es más moderno y claro la respuesta es dada por el Reactivo Manifiesto en Message-Driven (en contraste con Event-Driven):

Un mensaje es un elemento de datos que se envían a un destino específico.Un evento es una señal emitida por un componente al llegar a un determinado estado.En un message-driven sistema direccionable destinatarios de esperar a la llegada de los mensajes y reaccionar a ellos, de lo contrario latente.En un evento impulsado por el sistema de notificación de los oyentes están conectados a las fuentes de eventos que se invoca cuando el evento se emite.Esto significa que un evento impulsado por el sistema se enfoca en direccionable de orígenes de eventos, mientras que un message-driven sistema se concentra en direccionable de los destinatarios.Un mensaje puede contener un codificada como un evento de carga.

Answer 4

Eventos impulsados arquitecturas pueden ser implementados con o sin la aplicación de mensajería.La mensajería es una forma de comunicar los eventos producidos por los productores a los consumidores en un seguro, garantizado manera.Especialmente cuando los productores y los consumidores son verdaderamente disociadas y pueden ser alojados en diferentes servidores / VMs / entornos y no tienen acceso directo a cualquier memoria compartida.

Sin embargo, en casos específicos - cuando el consumidor de que el evento es una función de devolución de llamada registrada dentro de la misma aplicación, o cuando el consumidor necesita para ser ejecutado de forma sincrónica, luego de los eventos de la suscripción puede realizarse sin la mensajería.

Answer 5

Digamos que usted está construyendo un servicio de Pago para un sitio web de comercio electrónico.Cuando se coloca un pedido, la Orden de servicio le pida a su servicio de Pago para autorizar la tarjeta de crédito del cliente.Sólo cuando la tarjeta de crédito ha sido autorizada será el servicio de Pedido de enviar el pedido al almacén para el embalaje y el envío.

Usted necesita llegar a un acuerdo con el equipo que trabaja en el servicio de Pedido de cómo la solicitud de autorización de tarjeta de crédito es enviado desde su servicio a la suya.Hay dos opciones.

• Message-driven:Cuando se coloca un pedido, la Orden de servicio envía una solicitud de autorización a su servicio de Pago.Su servicio procesa la solicitud y devuelve el éxito/fracaso en la Orden de servicio.La solicitud inicial y el resultado podría ser enviado de forma sincrónica o asincrónica.
• Event-driven:Cuando se coloca un pedido, la Orden de servicio publica un NewOrder evento.Su servicio de Pago se suscribe a que tipo de evento, por lo que se desencadena.Su servicio procesa la solicitud y ya sea publica un AuthorizationAccepted o un AuthorizationDeclined evento.El servicio de Pedido, se suscribe a los tipos de eventos.Todos los eventos son asincrónicas.

Una ventaja del evento-enfoque basado en es que otros servicios pueden suscribirse a los diferentes eventos así.Por ejemplo, podría ser un RevenueReporting servicio que se suscribe a AuthorizationAccepted eventos y crea informes para el equipo de Finanzas.

Una desventaja del evento-enfoque basado en es que el sistema como un todo se vuelve un poco más difícil de entender.Por ejemplo, digamos que el equipo que trabaja en el servicio de Pedido le pide que reemplace el AuthorizationDeclined evento con diferentes eventos dependiendo de la razón por la tarjeta de crédito fue rechazada (no hay fondos, cierre de la cuenta, la dirección de facturación incorrecta, etc).Si usted dejar de publicar AuthorizationDeclined eventos, tendrá que romper algún otro servicio que existe?Si usted tiene muchos eventos y servicios, esto puede ser difícil de rastrear.

Answer 6

Como se pone bien en este el artículo, con el fin de entender Evento impulsado por el diseño, en lugar de mirar lo que representa tenemos que observar lo que se esconde y que no es nada más que la muy básicos de programación;la "Pila de llamadas".

En el Caso de diseño orientado a la definición de la invocación del método va a la derecha de la ventana.No hay más llamante y llamado.Que es un beso de despedida a la llamada de la secuencia y el orden.El sistema no necesita saber el orden en el que las cosas tienen que suceder.Por lo tanto, espacio de memoria compartida, que es un requisito previo de la Pila de llamadas, se hace innecesaria.

En una Pila de llamadas ambiente sin embargo, no sólo la persona que llama tiene que saber lo que sucede después, pero tiene que ser capaz de asociar una funcionalidad a un nombre de método.

Mensaje orientado a las aplicaciones por defecto vienen con la eliminación de la memoria compartida.Publicador y el suscriptor no necesitan compartir un espacio de memoria.Por otro lado, todas las demás funciones (es decir,orden, nombre de método de acoplamiento y tal) no son necesidades.

Si el paso de mensajes está diseñado para cumplir con los axiomas de evento impulsado por la arquitectura, pueden ser considerados idénticos.De lo contrario, hay una gran diferencia entre ellos.

Answer 7

Si utilizamos evento impulsado por el enfoque, por lo general, quieren enviar el objeto de origen, en este caso de un componente que ha publicado el evento.Así, en el suscriptor podemos conseguir no sólo los datos, sino también saber que publicó este evento.E. g.en desarrollo de aplicaciones móviles de recibir la Vista, que puede ser un Botón, una Imagen o alguna Vista personalizada.Y dependiendo del tipo de este punto de Vista podemos utilizar una lógica diferente en el suscriptor.En este caso podemos incluso añadir un poco de nuevo-procesamiento, modificar componente de origen - por ejemplo,añadir animación a los de la Vista de origen.

Cuando hacemos uso de message-driven enfoque, queremos publicar el mensaje con algunos datos.No importa para el suscriptor que publicó este mensaje, solo queremos recibir los datos y el proceso de alguna manera.

Answer 8

Evento Impulsado por la Arquitectura y el Mensaje Impulsado la Arquitectura son dos cosas diferentes y resuelve dos problemas diferentes.

Evento Impulsado por la Arquitectura foco está en cómo el sistema se activa la función.La mayoría de los disparadores que se pensó como los eventos en el contexto de la EDA son los eventos generados por otros medios que el teclado y el ratón.Es una EDA si que nos hace pensar de forma explícita sobre el evento generador, canal de eventos, procesamiento de eventos de motor.

El teclado y el Ratón son evidentes generadores de eventos, sin embargo el manejo de estos eventos ya es atendido por varios marcos o tiempos de ejecución y como Arquitecto no necesitamos que preocuparse por ello.Hay otros eventos que son específicos a ciertos dominio es lo que el Arquitecto se espera que pensar.Ejemplo de la Cadena de Suministro Gestión de eventos de selección, empaque, envío, distribución minorista, que vende etc.Desde el punto de vista Técnico Industrial IoT tipo de aplicaciones, los eventos son RFID de Lectura, Bio-métricas de Leer, Sensor de Datos, código de Barras de Exploración, el Sistema de Eventos Generados son los eventos que se necesita para ser atendidos de forma explícita debido a que estos eventos de la unidad de la funcionalidad del sistema.

Mensaje de la Arquitectura dirigida enfoque es integrar los sistemas distribuidos por el paso de mensajes de un módulo a otro de los módulos del sistema, utilizando el estándar de Middleware Orientado a Mensajes.

Answer 9

El Mensaje concepto es abstracto, más concreta tipos de mensajes son para Eventos y Comandos.

Mientras que los mensajes no tienen intención en absoluto, eventos informar acerca de algo que ha ocurrido y ya está completado (en el pasado).Los comandos de desencadenar algo que debería ocurrir (en el futuro).