approccio basato sui messaggi e sugli eventi per l'integrazione delle applicazioni

Question

Mi chiedevo se esiste una chiara distinzione tra gli ambienti basati sui messaggi e sugli eventi quando facciamo riferimento a SOA o middleware e generalmente nei casi di integrazione di applicazioni e imprese. Comprendo che un'interfaccia utente è simile a un modello basato su eventi in cui il nostro sistema intercetta l'azione dell'utente.

Inoltre è chiaro che la messaggistica supporta i sistemi basati su publish/subscribe, comunicazione sincrono o asincrono, transazioni ecc

Ma c'è una differenza nel contesto di integrazione di middleware/SOA/applicazione? (livello di architettura). Sto cercando di consultare fonti come wikipedia (here e here), ma sono ancora un po 'confuso. Quando uno sviluppatore dovrebbe preferire una soluzione rispetto all'altra?

Esistono esempi o casi in cui un approccio ha più senso dell'altro? O eventuali risorse e guide complete per implementare ciascuna di esse?

Molte grazie per qualsiasi intuizione.

Answer 1

Risposta breve a "c'è una chiara distinzione" sarebbe "no".

I termini non sono abbastanza intercambiabili, ma implicano la stessa architettura di base, in particolare quella che verrà attivata da eventi o messaggi.

Il primo articolo di riferimento riguarda l'impianto idraulico di basso livello, il "bus" MOM o pub-sub che trasporta i messaggi per conto dell'utente. L'architettura basata sugli eventi è ciò che costruisci su quel quadro.

Il termine event-driven, pur applicando anche al codice GUI, non è realmente allo stesso livello di astrazione. In tal caso, è un modello in-the-small rispetto alla costruzione dell'intera azienda lungo linee guidate da messaggi/eventi.

Answer 2

Le architetture basate su eventi possono essere implementate con o senza messaggistica. La messaggistica è un modo per comunicare gli eventi generati dai produttori ai consumatori in modo affidabile e garantito. Soprattutto quando produttori e consumatori sono veramente disaccoppiati e possono essere ospitati su server/VM/ambienti diversi e non hanno accesso diretto a nessuna memoria condivisa.

Tuttavia, in casi specifici, quando il consumatore dell'evento è una funzione/callback registrata all'interno della stessa applicazione o quando il consumatore deve essere eseguito in modo sincrono, la sottoscrizione di eventi può essere implementata senza messaggistica.

Answer 3

Come si legge nell'articolo this, per comprendere la progettazione guidata da eventi, invece di guardare a ciò che presenta dobbiamo osservare ciò che nasconde e questo non è altro che la base della programmazione; il "Call Stack".

Nella progettazione guidata da eventi, la definizione dell'invocazione del metodo passa direttamente dalla finestra. Non c'è più caller e callee. Questo è un bacio addio per chiamare sequenza e ordine. Il sistema non ha bisogno di sapere in quale ordine le cose devono accadere. Pertanto, lo spazio di memoria condiviso , che è un prerequisito di Call Stack, non è necessario.

In un ambiente Stack di chiamate, tuttavia, non solo il chiamante deve sapere cosa succede dopo, ma deve essere in grado di associare una funzionalità al nome di un metodo.

Le applicazioni orientate ai messaggi per impostazione predefinita vengono fornite con la rimozione della memoria condivisa. Publisher e subscriber non hanno bisogno di condividere uno spazio di memoria.D'altra parte, tutte le altre caratteristiche (ad esempio, l'accoppiamento del nome del metodo e così via) non sono necessarie.

Se il passaggio di messaggi è progettato per rispettare gli assiomi dell'architettura basata su eventi, è possibile considerarli identici. Altrimenti c'è un'enorme differenza tra loro.

Answer 4

Se utilizziamo un approccio basato sugli eventi, di solito vogliamo inviare l'oggetto di origine in questo evento - componente che ha pubblicato l'evento. Quindi nel sottoscrittore possiamo ottenere non solo i dati, ma anche sapere chi ha pubblicato questo evento. Per esempio. nello sviluppo mobile riceviamo la vista, che può essere pulsante, immagine o una vista personalizzata. E a seconda del tipo di questa vista, possiamo usare una logica diversa nel sottoscrittore. In questo caso possiamo anche aggiungere qualche back-processing, modificare il componente sorgente - ad es. aggiungi animazione a quella vista sorgente.

Quando utilizziamo un approccio basato sui messaggi, vogliamo pubblicare solo il messaggio con alcuni dati. Non importa per chi ha pubblicato questo messaggio, vogliamo solo ricevere i dati e elaborarli in qualche modo.

Answer 5

Ecco un punto di vista Typesafe/Reactive sulla domanda di Jonas Bonér. Dal terzo paragrafo di this blog post: "La differenza è che i messaggi sono diretti, gli eventi non lo sono - un messaggio ha un destinatario indirizzabile chiaro mentre un evento si verifica per gli altri (0-N) per osservarlo."

Answer 6

Event Driven Architecture e Message Driven Architecture sono due cose diverse e risolvono due problemi diversi.

L'architettura basata su eventi è focalizzata su come il sistema viene attivato per funzionare. La maggior parte dei trigger considerati come eventi nel contesto di EDA sono gli eventi generati con mezzi diversi da tastiera e mouse. È un EDA se questo ci fa pensare esplicitamente al generatore di eventi, al canale di eventi, al motore di elaborazione degli eventi.

Tastiera e mouse sono ovvi generatori di eventi, tuttavia la gestione di questi eventi è già gestita da vari framework o runtime e come architetto non è necessario preoccuparsene. Ci sono altri eventi specifici per determinati domini su cui ci si aspetta che Architect pensi. Esempio: eventi di Supply Chain Management: prelievo, confezionamento, distribuzione, distribuzione, vendita al dettaglio, ecc. Dal punto di vista tecnico per applicazioni di tipo IoT industriale gli eventi sono: lettura RFID, lettura biometrica, dati sensore, scansione codici a barre, eventi generati dal sistema sono gli eventi che devono essere presi in considerazione esplicitamente perché questi eventi guidano la funzionalità del sistema.

Message Driven Architecture obiettivo è quello di integrare i sistemi distribuiti passando messaggio per un modulo all'altro moduli del sistema utilizzando messaggio standard Oriented Middleware.

Answer 7

Questa domanda è stata posta molto tempo fa. Credo che una risposta più moderno e chiaro è dato dalla Reactive Manifesto in Message-Driven (in contrast to Event-Driven):

Un messaggio è un dato che viene inviato a una destinazione specifica. Un evento è un segnale emesso da un componente al raggiungimento di un determinato stato. In un sistema basato sui messaggi, i destinatari attendono l'arrivo di messaggi e reagiscono, altrimenti rimangono inattivi. In un sistema basato su eventi i listener di notifica sono collegati alle origini degli eventi in modo tale che vengano richiamati quando l'evento viene emesso. Ciò significa che un sistema basato sugli eventi si concentra su fonti di eventi indirizzabili mentre un sistema basato sui messaggi si concentra su destinatari indirizzabili. Un messaggio può contenere un evento codificato come suo payload.