Meriti di un sistema "Message Passing" rispetto a un sistema "Event Based"

La mia domanda viene da una prospettiva in qualche modo non istruita.

Quali sono i meriti relativi di un sistema di " trasmissione di messaggi " rispetto a un sistema " basato su eventi ".

Perché uno dovrebbe scegliere uno sopra l'altro? Quali sono i loro punti di forza e di debolezza?

Vorrei sapere non solo "in teoria", ma anche "in pratica".

MODIFICARE:

Problema specifico :

Voglio costruire un sistema di componenti plug-in che si comportino come servizi su piccola scala (ciascuno eseguendo alcuni piccoli compiti e o fornendo alcune informazioni).

I servizi possono:

• essere stratificato in modo che l'output di un servizio possa fungere da input per un altro
• hanno gerarchie di contenimento in modo che un servizio possa essere contenuto da un altro senza una relazione input-output specifica come menzionato nella frase precedente

L'obiettivo del sistema è tradurre un singolo flusso di eventi di basso livello in un altro sistema in informazioni e funzionalità di livello superiore e inoltre fornire un canale di ritorno all'altro sistema fornendo un'unica serie di eventi.

Posso fornire maggiori dettagli se questo non è abbastanza.

Dopo aver guardato un po 'di più. Questo e questo probabilmente descrive meglio la mia situazione.

Sembra che possa adattarsi bene alla mia situazione: http://akka.io/

Nella mia esperienza, l'unica differenza specifica è che nella maggior parte dei sistemi di trasmissione dei messaggi, il mittente del messaggio è a conoscenza (e spesso dichiara) chi sia il destinatario del messaggio.

Quindi, invece di generare un evento e chiunque sia iscritto all'evento che lo riceve, il mittente definisce un ID del destinatario o dei destinatari previsti o un gruppo logico di destinatari e quindi invia il messaggio direttamente a loro o passa attraverso un broker di messaggi (sebbene il sistema operativo possa essere visto come un broker di messaggi in un sistema basato su eventi).

Ovviamente c'è il caso del threading che Telastyn menziona con l'implementazione degli eventi di C #, ma è ancora possibile creare il proprio pub / modello secondario che viene eseguito su thread diversi.

Sono mele e arance:

Un sistema Event Driven può reagire agli eventi passati come messaggi (i messaggi in questo contesto sono dati immutabili non condivisi impliciti ) quando gli eventi vengono generati. Questo è un design puramente architettonico.

Un sistema di Message Passing può essere guidato da eventi che creano e passano i messaggi. Questo è un progetto puramente attuativo.

Le due cose non si escludono a vicenda.

Esempio: è possibile implementare una progettazione guidata dagli eventi in qualsiasi lingua che può anche essere un ambiente di passaggio messaggi come in Erlang.

Gran parte della confusione tra "passaggio di messaggi" e "basato sugli eventi" ha a che fare con i dettagli architettonici e di implementazione. Ho visto (e scritto) sistemi guidati da eventi che utilizzano effettivamente messaggi forniti dal sistema operativo per la loro implementazione. Immagino che ti riferisci davvero alle idee architettoniche.

Come molte persone hanno già sottolineato "passaggio di messaggi" e "eventi basati" non sono termini abbastanza buoni per evitare ambiguità.

Quali sono i meriti relativi di un sistema di "trasmissione messaggi" rispetto a un sistema "basato su eventi".

Passaggio dei messaggi

Inizierò supponendo che quando dici un sistema di "passaggio di messaggi", stai parlando di un sistema in cui un oggetto spende un messaggio a un altro oggetto specifico. Quando penso a un sistema basato su questo paradigma, penso più in generale a un sistema in cui un oggetto che rileva qualcosa sa chi deve essere raccontato su qualcosa. (Non sto specificando come lo sa, solo che lo sa.)

Questo tipo di architettura è ottimo per i sistemi in cui produttori e consumatori sono noti. O il produttore di un messaggio sa chi deve riceverlo o il consumatore deve sapere da chi ricevere il messaggio.

Se stai scrivendo un'applicazione bancaria, ci si aspetterebbe davvero che tu voglia sapere a chi stai inviando le tue transazioni e da chi provengono.

Basato su eventi

L'altro sistema a cui credo tu stia pensando quando dici che un sistema "basato sugli eventi" è quello in cui un oggetto genera un "evento" senza sapere chi (se qualcuno) risponderà ad esso.

Questo tipo di architettura basata sugli eventi è molto utile per i sistemi in cui il produttore non si preoccupa di chi consuma l'evento o in cui al consumatore non importa davvero chi ha prodotto l'evento.

In generale, questi sistemi sono ottimi dove non si conosce la relazione tra consumatori e produttori e dove ci si aspetta che la relazione sia dinamica.

Un sistema in cui l'ho usato era un sistema in cui l'applicazione era in realtà composta da moduli (plug-in) configurati dinamicamente che venivano caricati in fase di esecuzione. Quando un modulo veniva caricato, si registrava per gli eventi a cui teneva. Il risultato fu un sistema in cui era molto facile estendere la funzionalità.

Ad esempio, supponiamo che la condizione A abbia generato l'evento EA che normalmente ha causato la risposta RA. L'oggetto che ha causato la risposta RA si è semplicemente registrato per ricevere l'evento EA e ha agito su di esso quando è arrivato. Ora, supponiamo di voler aggiungere una nuova risposta a EA, chiamata RA_1. Per fare ciò, aggiungiamo semplicemente un nuovo oggetto che cerca EA e genera una risposta RA_1.

Ecco un paio di esempi (usando la tua terminologia):

• "messaggio che passa" : il tuo capo ti dice di compilare il tuo foglio presenze.
• "event driven" : il segretario del dipartimento invia un'email a tutti ricordando loro che i loro fogli di lavoro sono in scadenza oggi.

In SOA hai il concetto di Messaggi di comando e Messaggi di evento . C'è bisogno di entrambi.

Tuttavia, i messaggi di comando hanno un accoppiamento comportamentale più elevato con l'endpoint del destinatario poiché richiede esplicitamente all'endpoint di eseguire alcune funzioni. Non è necessario che sia legato a un particolare endpoint (questo può essere configurato o determinato in fase di esecuzione).

I messaggi di evento, d'altra parte, non hanno alcun accoppiamento comportamentale tra il mittente / destinatario poiché il mittente non ha idea di cosa farà un destinatario con il messaggio. Non sa nemmeno se qualcuno è iscritto all'evento.

Per ulteriori informazioni siete invitati a consultare il mio sito di bus di servizio qui: http://www.servicebus.co.za

Nella mia esperienza, la più grande differenza tra i due è che i messaggi in un sistema che passa messaggi sono oggetti di prima classe, mentre gli eventi nei sistemi guidati da eventi sono molto più semplici. I messaggi tendono a trasportare informazioni e tali informazioni possono essere trasformate, archiviate, recuperate e rispedite. Gli eventi tendono a trasportare frammenti di informazioni più piccoli e più mirati che vengono immediatamente consumati e quindi eliminati. Tendono ad essere inviati da una fonte di eventi direttamente a uno o più sink di evento, mentre i messaggi vengono più spesso instradati tra più ricevitori e possono essere convertiti / tradotti / spostati o altrimenti elaborati in qualsiasi punto lungo il percorso. Usano tecnologie simili (autobus, code, filtri, ecc.) Ma sono animali davvero disparati.

Da un punto di vista pratico, i messaggi vengono in genere implementati come un blocco di memoria che viene copiato dallo spazio degli indirizzi del mittente nello spazio degli indirizzi del destinatario (o altrimenti imposto come oggetto immutabile) in modo da ottenere immediatamente la sicurezza del thread.

In alcuni casi di passaggio del messaggio, il mittente deve specificare il destinatario, ma in altri casi è possibile solo inviare un messaggio a una cassetta postale e chiunque può ascoltare i messaggi in quella cassetta postale, quindi c'è una certa flessibilità nel modo in cui sono strettamente accoppiati. Naturalmente, puoi avere una cassetta postale in cui il contratto è "Invierò un messaggio a questa cassetta postale quando si verifica questo evento ".

In caso di eventi, stai registrando un delegato o una richiamata con il proprietario dell'evento. Nella programmazione orientata agli oggetti ciò significa che il proprietario dell'evento mantiene un riferimento all'oggetto registrato per ricevere l'evento. Questo a volte può portare a incubi di contabilità, cercando di capire quale oggetto ha dimenticato di annullare la registrazione del gestore dell'evento. Significa che il target non può essere garbage collection finché il proprietario dell'evento non è garbage collection, anche se il target non sta più facendo nulla di utile.

Personalmente sceglierei il messaggio che passa sugli eventi, tranne nei casi in cui gli eventi sono forzati su di te, come la programmazione della GUI di Windows, ecc.