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

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

Quindi, invece di generare un evento e chiunque sia stato iscritto all'evento che lo riceve, il mittente definisce qualche ID del destinatario o dei destinatari previsti o del gruppo logico dei destinatari e quindi invia il messaggio direttamente a loro o passa attraverso un broker di messaggi (anche se il sistema operativo può 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 di eventi di C #, ma è comunque possibile creare il proprio modello pub / sub che viene eseguito su thread diversi.

Questo è mele e arance:

Un sistema Event Driven può passare messaggi (i messaggi in questo contesto sono dati immutabili non condivisi impliciti) man mano che gli eventi vengono generati. Questo è un progetto puramente architettonico.

Un sistema Message Passing può essere guidato da eventi che attiva i messaggi da creare e passare. Questo è un progetto puramente di implementazione.

I due non si escludono a vicenda. Puoi implementare un design event driven in Erlang che è un ambiente che passa .

Gran parte della confusione tra "message passing" e "event based" ha a che fare con i dettagli architettonici e di implementazione. Ho visto (e scritto) sistemi basati su eventi che effettivamente usano i messaggi forniti dal SO per la loro implementazione. Immagino che tu ti stia davvero riferendo alle idee architettoniche.

Come molte persone hanno già sottolineato che "message passing" e "event based" non sono termini veramente validi per evitare ambiguità.

What are the relative merits of a "message passing" system vs an "event based" system.

Passaggio del messaggio

Comincerò a indovinare che quando si dice un sistema di "passaggio di messaggi", si sta parlando di un sistema che un oggetto spende un messaggio su 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 informato su qualcosa. (Non sto specificando come lo sa, solo che lo sa.)

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

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

Basato sugli eventi

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

Questo tipo di architettura basata sugli eventi è molto buona per i sistemi in cui il produttore non si cura di chi consuma l'evento o dove il consumatore non si preoccupa veramente di chi ha prodotto l'evento.

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

Un sistema in cui ho usato questo era un sistema in cui l'applicazione era in realtà composta da moduli configurati dinamicamente (plug-in) caricati in fase di esecuzione. Quando un modulo è stato caricato, si registrerebbe per gli eventi a cui importava. Il risultato è stato un sistema in cui è stato molto semplice estendere la funzionalità.

Per esempio, diciamo condizione EA di evento sollevato 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 la 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 dei tempi.
• "event driven" : il segretario del dipartimento invia un'email a tutti ricordano loro che i loro fogli orari sono dovuti oggi.

In SOA hai il concetto di messaggi Comando e messaggi Evento . C'è bisogno di entrambi.

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

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

Per ulteriori informazioni, visita attentamente il sito del mio service bus qui: link

Secondo la mia esperienza, la più grande differenza tra i due è che i messaggi in un sistema che trasmette messaggi sono oggetti di prima classe, mentre gli eventi nei sistemi basati su eventi sono molto più semplici. I messaggi tendono a trasportare informazioni e tali informazioni possono essere trasformate, memorizzate, recuperate e ritrasmesse. Gli eventi tendono a trasportare informazioni più piccole e più mirate che vengono immediatamente consumate e poi scartate. Tendono ad essere inviati da una fonte di eventi direttamente a uno o più sink di eventi, mentre i messaggi sono più spesso indirizzati tra più ricevitori, e possono essere convertiti / tradotti / spostati o elaborati in altro modo in qualsiasi punto lungo il percorso. Usano tecnologie simili (bus, code, filtri, ecc.) Ma sono animali davvero disparati.

Da un punto di vista pratico, i messaggi sono tipicamente implementati come un blocco di memoria che viene copiato dallo spazio indirizzo del mittente allo spazio indirizzo del destinatario (o altrimenti viene imposto come oggetto immutabile) in modo da guadagnare sicurezza nel thread immediatamente.

In alcuni casi di passaggio di messaggi il mittente deve specificare il destinatario, ma in alcuni altri casi puoi semplicemente postare un messaggio in una casella di posta e chiunque può ascoltare i messaggi in quella casella di posta, quindi c'è una certa flessibilità nell'accoppiamento stretto loro sono. Naturalmente, puoi avere una casella di posta in cui il contratto è "posterò un messaggio per questa casella di posta quando questo evento accade".

Nel 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 contabili, cercando di capire quale oggetto ha dimenticato di annullare la registrazione del gestore di eventi. Significa che il target non può essere garbage collection fino a quando il proprietario dell'evento non viene raccolto, anche se il target non sta più facendo nulla di utile.

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

L'interpretazione più semplice dei sistemi di trasmissione dei messaggi e di eventi:

• Utilizza messaggi in coda Coda: 1 produttore - > 1 consumatore
• Utilizza argomenti basato su eventi (pub / sub): 1 produttore - > N consumatori

Entrambi i pattern possono sfruttare un broker di messaggi, come RabbitMQ.