Grande parte da confusão entre "passagem de mensagem" e "baseado em evento" tem a ver com detalhes arquitetônicos versus de implementação. Eu já vi (e escrevi) sistemas orientados a eventos que realmente usam mensagens fornecidas pelo SO para sua implementação. Acho que você está realmente se referindo a idéias arquitetônicas.
Como muitas pessoas já apontaram "passagem de mensagem" e "baseado em evento", não são realmente bons termos suficientes para evitar ambiguidade.
Quais são os méritos relativos de um sistema de "transmissão de mensagens" versus um sistema "baseado em eventos".
Passagem de mensagem
Vou começar supondo que, quando você diz um sistema de "transmissão de mensagens", está falando de um sistema em que um objeto passa uma mensagem para outro objeto específico. Quando penso em um sistema baseado nesse paradigma, geralmente penso em um sistema em que um objeto que detecta algo sabe quem precisa ser informado sobre algo. (Não estou especificando como ele sabe, apenas o que sabe.)
Esse tipo de arquitetura é muito bom para sistemas em que os produtores e consumidores são bem conhecidos. O produtor de uma mensagem sabe quem deve recebê-la ou o consumidor deve saber de quem receber a mensagem.
Se você estiver escrevendo um aplicativo bancário, é de se esperar que você realmente queira saber para quem está enviando suas transações e de quem elas são originárias.
Baseado em evento
O outro sistema em que acredito que você está pensando quando diz que um sistema "baseado em eventos" é aquele em que um objeto gera um "evento" sem saber quem (se alguém) responderá a ele.
Esse tipo de arquitetura orientada a eventos é muito bom para sistemas em que o produtor não se importa com quem consome o evento ou onde o consumidor realmente não se importa com quem produziu o evento.
Em geral, esses sistemas são ótimos onde você não conhece o relacionamento entre consumidores e produtores e espera que o relacionamento seja dinâmico.
Um sistema em que usei isso foi um sistema em que o aplicativo era realmente composto de módulos configurados dinamicamente (plug-ins) carregados em tempo de execução. Quando um módulo era carregado, ele se registrava para os eventos importantes. O resultado foi um sistema no qual foi muito fácil estender a funcionalidade.
Por exemplo, digamos que a condição A gerou um EA de evento que normalmente causava a resposta RA. O objeto que causou a resposta RA simplesmente se registrou para receber o evento EA e agiu sobre ele quando chegou. Agora, digamos que queremos adicionar uma nova resposta ao EA, chamada RA_1. Para fazer isso, simplesmente adicionamos um novo objeto que procura o EA e gera a resposta RA_1.
Aqui estão alguns exemplos (usando sua terminologia):
- "passagem de mensagem" : seu chefe diz para você preencher sua folha de ponto.
- "orientado a eventos" : a secretária do departamento envia um e-mail a todos, lembrando-os de que suas folhas de ponto estão vencidas hoje.