mensagem dirigida vs. evento abordagens para a integração de aplicações orientada

Question

Eu queria saber se existe uma distinção clara entre ambientes impulsionado mensagens e eventos impulsionado quando nos referimos a SOA ou middleware e, geralmente, em casos de aplicação e integração empresarial. Eu entendo que uma interface se assemelha a um modelo orientado a eventos onde a nossa intercepta sistema de acção por parte do utilizador.

Além disso, é claro que os sistemas de suporte mensagens com base na publicação / assinatura, comunicação síncrono ou assíncrono, transações etc.

Mas há uma diferença no contexto intergration middleware / SOA / aplicação? (Nível de arquitetura). Eu estou tentando consultar fontes, tais wikipedia ( aqui , e aqui ), mas eu ainda estou um pouco confuso. Quando deve um desenvolvedor preferir uma solução sobre o outro?

Existem exemplos ou casos em que uma abordagem faz mais sentido do que o outro? Ou quaisquer recursos abrangentes e guias de implementação de cada um?

Muito obrigado por qualquer insight.

Answer 1

curta resposta à pergunta "há uma clara distinção" seria "não".

Os termos não são completamente intercambiáveis, mas implicam a mesma arquitetura básica -. Especificamente que você estará detonando de eventos ou mensagens

O primeiro artigo que você referência é sobre o encanamento de baixo nível, o MOM ou pub-sub "bus" que transporta as mensagens em seu nome. A arquitetura orientada a eventos é o que você construir em cima desse quadro.

O termo event-driven, ao mesmo tempo, aplicável ao código GUI, não é realmente no mesmo nível de abstração. Nesse caso, é um padrão in-the-pequeno em comparação com a construção de toda a sua empresa ao longo de mensagens / linhas impulsionado evento.

Answer 2

Aqui é um Typesafe / ponto de vista sobre a questão de Jonas Boner Reactive . A partir do terceiro parágrafo do este post :

A diferença é que as mensagens são dirigidas, os eventos não são - uma mensagem tem um destinatário endereçável clara, enquanto um evento só acontecerá para os outros (0-N) para observá-lo

.

Answer 3

Esta pergunta foi feita há muito tempo. Eu acho que uma resposta mais moderna e clara é dada pela Reactive Manifesto em Mensagem-Driven (em contraste com Event-driven) :

A mensagem é um item de dados que são enviados para um destino específico. Um evento é um sinal emitido por um componente ao atingir um determinado estado. Em um sistema orientado por mensagem destinatários endereçáveis ??aguardar a chegada de mensagens e reagir a eles, caso contrário adormecidos. Em um sistema orientado a eventos ouvintes de notificação estão associadas a fontes de eventos, que são invocados quando o evento é emitido. Isto significa que um sistema orientado a eventos se concentra em fontes de eventos endereçáveis ??enquanto um orientados a mensagens concentrados sistema no destinatários endereçável. Uma mensagem pode conter um evento codificado como sua carga útil.

Answer 4

Eventos arquiteturas impulsionada pode ser implementada com ou sem mensagens. Messaging é uma maneira de se comunicar eventos gerados pelos produtores aos consumidores de uma maneira confiável, garantido. Especialmente quando os produtores e os consumidores estão verdadeiramente dissociado e podem ser hospedados em diferentes servidores / VMs / ambientes e não têm acesso direto a qualquer memória compartilhada.

No entanto, em casos específicos -. Quando o consumidor do evento é uma função / callback registrado dentro do mesmo aplicativo em si, ou quando as necessidades de consumo a ser executado de forma síncrona, em seguida, eventos de assinatura pode ser implementado sem mensagens

Answer 5

Vamos dizer que você está construindo um serviço de pagamento para um site de comércio eletrônico. Quando um pedido é feito, o serviço Order irá pedir o seu serviço de pagamento para autorizar o cartão de crédito do cliente. Só quando o cartão de crédito tenha sido autorizada será o serviço Order enviar o pedido para o armazém para embalagem e expedição.

Você precisa concordar com a equipe trabalhando no serviço Order sobre como que o pedido de autorização de cartão de crédito é enviada de seu serviço ao seu. Existem duas opções.

• mensagem-driven : Quando um pedido é feito, o serviço Order envia um pedido de autorização para o seu serviço de pagamento. Seu serviço processa a solicitação e retorna sucesso / insucesso ao serviço Order. O pedido inicial e o resultado poderia ser enviada de forma síncrona ou assíncrona.
• Event-driven : Quando um pedido é feito, o serviço Order publica um evento NewOrder. O seu serviço de pagamento subscreve a esse tipo de evento para que ele é acionado. Seu serviço processa o pedido, e publica um AuthorizationAccepted ou um evento AuthorizationDeclined. O serviço Order subscreve a esses tipos de eventos. Todos os eventos são assíncronos.

Uma vantagem da abordagem orientada a eventos é que outros serviços podem se inscrever para os vários eventos também. Por exemplo, pode haver um serviço RevenueReporting que se inscreve para eventos AuthorizationAccepted e cria relatórios para a equipe de Finanças.

Uma desvantagem da abordagem orientada a eventos é que o sistema como um todo se torna um pouco mais difícil de entender. Por exemplo, digamos que a equipe de trabalho sobre o serviço Order pede-lhe para substituir o evento AuthorizationDeclined com eventos diferentes dependendo do porque o cartão de crédito foi recusado (sem fundos, conta encerrada, o faturamento endereço incorreto, etc). Se você parar de publicar eventos AuthorizationDeclined, será que quebrar algum outro serviço lá fora? Se você tem muitos eventos e serviços, isso pode ser difícil de rastrear.

Answer 6

Como é colocado bem no este artigo , a fim de compreender design orientado Evento , em vez de olhar para o que ele apresenta temos que observar o que ela esconde e que de nada mais do que o básico da programação; o "Call Stack".

design orientado Em Evento a definição de invocação de método sai direito da janela. Não há mais chamador e chamado. Isto é um beijo de despedida a seqüência de chamada ea ordem. O sistema não precisa de saber em que ordem as coisas têm que acontecer. Conseqüentemente, espaço de memória compartilhada, que é um pré-requisito de Call Stack, torna-se desnecessário.

Em um ambiente de Call Stack no entanto, não só o chamador tem de saber o que acontece em seguida, mas tem que ser capaz de associar uma funcionalidade para um nome de método.

aplicações orientadas mensagem por padrão vem com a remoção de memória compartilhada. Publisher e assinante não precisa compartilhar um espaço de memória. Por outro lado, todas as outras características (fim ou seja, acoplamento nome do método e tal) não são necessidades.

Se a mensagem que passa é projetado de forma a cumprir com os axiomas da arquitetura orientada evento, eles poderiam ser considerados idênticos. Caso contrário, há uma enorme diferença entre eles.

Answer 7

Se usarmos abordagem orientada a eventos, geralmente deseja enviar o objeto de origem neste evento - componente que publicou o evento. Assim, no assinante podemos obter não só os dados, mas também saber que publicou este evento. Por exemplo. em desenvolvimento móvel recebemos a vista, que pode ser Button, imagem ou algum costume View. E, dependendo do tipo deste ponto de vista, podemos usar a lógica diferente no assinante. Neste caso, pode até mesmo adicionar um pouco de processamento de volta, componente de origem Modificar - por exemplo, adicionar animação aos fonte View.

Quando usamos abordagem orientada a mensagem, queremos publicar apenas a mensagem com alguns dados. Não importa para assinantes que publicou esta mensagem, nós só queremos receber os dados e processá-lo de alguma forma.

Answer 8

Event Driven Architecture e Message Driven Architecture são duas coisas e resolve diferentes dois problemas diferentes.

foco Driven Architecture

Event é de como o sistema está sendo acionado para função. Maioria dos gatilhos que são pensados ??como eventos no contexto da EDA são os eventos gerados por outros de teclado e mouse meios. É um EDA se que nos faz pensar explicitamente sobre gerador de evento, canal de evento, motor de processamento de eventos.

Teclado e mouse são geradores de eventos óbvios no entanto manipulação desses eventos já é cuidado por vários enquadramentos ou tempos de execução e, como um arquiteto que não precisamos nos preocupar com isso. Existem outros eventos que são específicos para determinado domínio é o que se espera Architect para se pensar. Exemplo - Abastecimento de eventos Chain Management - pegar, embalagem, expedição, distribuição, varejo, vendidos etc. Do ponto de vista técnico para o tipo de Internet das coisas Industrial de aplicações os eventos são - RFID Ler, Ler Bio-métrica, dados do sensor, código de barras de digitalização, Criação Sistema de Eventos são os eventos que precisa ser tomado cuidado explicitamente porque esses eventos conduzir a funcionalidade do sistema.

Message Driven Architecture foco é integrar os sistemas distribuídos pelo envio de mensagens a partir de um módulo para outro módulos do sistema usando mensagem padrão Oriented Middleware.

Answer 9

O conceito de mensagens é abstrato, tipos mais concretas de mensagem são eventos e comandos.

Enquanto mensagens têm nenhuma intenção especial em tudo, eventos informar sobre algo que aconteceu e já está concluída (no passado). Comandos gatilho algo que deve acontecer (no futuro).