messaggio di evento vs guidato approcci alla integrazione delle applicazioni guidato

Question

Mi chiedevo se esiste una chiara distinzione tra gli ambienti dei messaggi guidato e event driven quando ci riferiamo a SOA o middleware e in generale nei casi di applicazione e integrazione aziendale. Capisco che un'interfaccia utente assomiglia a un modello guidato evento in cui la nostra azione intercetta di sistema da parte 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 strutturale). Sto cercando di consultare fonti come Wikipedia ( qui , e qui ), ma sono ancora un po 'confuso. Quando uno sviluppatore dovrebbe preferire una soluzione piuttosto che l'altro?

Ci sono esempi o casi in cui un approccio rende più senso rispetto agli altri? O qualsiasi risorse complete e guide per l'attuazione di ciascuno?

Molte grazie per avere una visione chiara.

Answer 1

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

I termini non sono del tutto intercambiabili, ma implicano la stessa architettura di base -. In particolare che vi sarà innescando di eventi o messaggi

Il primo articolo si fa riferimento è di circa l'impianto idraulico di basso livello, il MOM o pub-sub "bus" che trasporta i messaggi a vostro nome. L'architettura event-driven è quello che si costruisce in cima a tale quadro.

Il termine event-driven, mentre anche applicando al codice della GUI, in realtà non è allo stesso livello di astrazione. In questo caso, si tratta di un modello in-the-piccolo rispetto a costruire l'intera azienda lungo le linee di messaggio / event-driven.

Answer 2

Ecco un Typesafe / punto reattiva di vista sulla questione da Jonas Boner. Dal terzo comma questo post del blog :

  

La differenza è che i messaggi sono diretti, gli eventi non sono - un messaggio ha un destinatario chiaro indirizzabile, mentre un evento appena accaduto per gli altri (0-n) di osservarlo

.

Answer 3

Questa domanda è stato chiesto molto tempo fa. Credo che una risposta più moderno e chiaro è dato dalla reattiva Manifesto Message-Driven (in contrasto con 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 di message-driven destinatari indirizzabili attendono l'arrivo di messaggi e reagiscono a loro, altrimenti dormiente. In un sistema event-driven ascoltatori notifica sono attaccati alle fonti di eventi tale che esse vengano richiamati quando l'evento viene emesso. Ciò significa che un sistema event-driven si concentra sulle origini eventi indirizzabili, mentre un sistema di message-driven si concentra su destinatari indirizzabili. Un messaggio può contenere un evento codificato come il suo carico utile.

Answer 4

Eventi architetture guidate possono essere implementati con o senza la messaggistica. Messaging è un modo per comunicare eventi generati dai produttori ai consumatori in modo affidabile, garantito. Soprattutto quando i produttori ei consumatori sono veramente disaccoppiato e possono essere ospitati su diversi server / VM / ambienti e non hanno accesso diretto a qualsiasi memoria condivisa.

Tuttavia, in casi specifici - quando il consumatore della manifestazione è una funzione / callback registrate all'interno della stessa applicazione in sé, o quando deve essere eseguito in modo sincrono il consumatore, quindi gli eventi-abbonamento può essere implementato senza messaggistica

.

Answer 5

Diciamo che si sta creando un servizio di pagamento per un sito di eCommerce. Quando un ordine viene inserito, il servizio di Ordine sarà chiedere al servizio di pagamento per autorizzare la carta di credito del cliente. Solo quando la carta di credito è stato autorizzato sarà al servizio dell'Ordine inviare l'ordine al magazzino per l'imballaggio e la spedizione.

È necessario concordare con il team che lavora sul servizio dell'Ordine su come la richiesta di autorizzazione di carta di credito vengono inviati dal loro servizio al tuo. Ci sono due opzioni.

• Message-driven : Quando un ordine viene inserito, il servizio dell'Ordine invia una richiesta di autorizzazione per il servizio di pagamento. Il vostro servizio elabora la richiesta e restituisce successo / insuccesso al servizio dell'Ordine. La richiesta iniziale e il risultato potrebbe essere inviati sincrono o asincrono.
• Event-driven : Quando un ordine viene inserito, il servizio Ordine pubblica un evento NewOrder. Il vostro servizio di pagamento sottoscrive che tipo di evento per cui viene attivato. Il vostro servizio elabora la richiesta e sia pubblica un AuthorizationAccepted o di un evento AuthorizationDeclined. Il servizio dell'Ordine sottoscrive questi tipi di eventi. Tutti gli eventi sono asincrone.

Un vantaggio dell'approccio event-driven è che altri servizi potrebbero iscriversi ai vari eventi come bene. Ad esempio, ci potrebbe essere un servizio RevenueReporting che sottoscrive gli eventi AuthorizationAccepted e crea rapporti per la squadra Finanza.

Uno svantaggio dell'approccio event-driven è che il sistema nel suo insieme diventa un po 'più difficile da capire. Per esempio, diciamo che il gruppo di lavoro sul servizio dell'Ordine chiede di sostituire l'evento AuthorizationDeclined con eventi diversi a seconda del motivo della carta di credito è stata rifiutata (senza fondi, conto chiuso, indirizzo di fatturazione errato, ecc). Se si interrompe la pubblicazione di eventi AuthorizationDeclined, sarà che a qualche altro servizio là fuori? Se si dispone di molti eventi e servizi, questo può essere difficile da rintracciare.

Answer 6

Come si è messo bene in questo articolo , al fine di comprendere il disegno guidato evento , invece di guardare a ciò che presenta dobbiamo osservare ciò che nasconde e che è niente di più che la stessa base della programmazione; "Call Stack".

Nel design Evento guidato la definizione di chiamata di metodo va a destra fuori dalla finestra. Non c'è più chiamante e chiamato. Questo è un addio bacio a chiamare sequenza e ordine. Sistema non ha bisogno di sapere in cui le cose devono accadere ordine. Quindi, condiviso spazio di memoria, che è un prerequisito di Call Stack, diventa inutile.

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

Messaggio di applicazioni orientate per impostazione predefinita vengono con la rimozione della memoria condivisa. Publisher e abbonati non hanno bisogno di condividere uno spazio di memoria. D'altro canto, tutte le altre caratteristiche (cioè ordine, accoppiamento nome del metodo e simili) non sono necessità.

Se passaggio di messaggi è progettata per soddisfare i assiomi dell'architettura evento guidato, potrebbero essere considerate identiche. In caso contrario, v'è una grande differenza tra di loro.

Answer 7

Se usiamo approccio event-driven, di solito vogliamo inviare l'oggetto di origine a questo evento - componente che ha pubblicato l'evento. Quindi, in abbonato possiamo ottenere non solo i dati, ma anche di sapere chi ha pubblicato questo evento. Per esempio. in sviluppo mobile che riceviamo la vista, che può essere Bottone, Immagine o qualche personalizzato View. E a seconda del tipo di questa Altri possiamo usare la logica diversa in abbonato. In questo caso possiamo anche aggiungere un po 'di back-elaborazione, modificare componente di origine - per esempio aggiungere animazioni a quelli di origine View.

Quando usiamo approccio message-driven, vogliamo pubblicare solo il messaggio con alcuni dati. Non importa per abbonato che ha pubblicato questo messaggio, vogliamo solo per ricevere i dati e di processo che in qualche modo.

Answer 8

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

Event Driven Architecture attenzione è su come sistema viene attivato per funzionare. La maggior parte dei fattori scatenanti che si pensa come eventi nel contesto di EDA sono gli eventi generati con mezzi diversi dalla tastiera e il mouse. Si tratta di un EDA se questo ci fa pensare esplicitamente di generatore di eventi, il canale evento, motore di elaborazione evento.

Tastiera e mouse sono evidenti generatori di eventi tuttavia gestione di questi eventi è già preso cura da vari quadri o tempi di esecuzione e come architetto che non hanno bisogno di preoccuparsi. Ci sono altri eventi che sono specifiche per certo dominio è ciò che Architect è atteso a cui pensare. Esempio - Supply Chain Management eventi - ritiro, confezione, spedizione, distribuzione, rivenditori, ecc venduti dal punto di vista tecnico per Industrial IoT tipo di applicazioni gli eventi sono - RFID Read, Bio-metrica Leggi, dei dati del sensore, scansione di codici a barre, generata dal sistema Eventi sono gli eventi che devono essere curati in modo esplicito perché questi eventi guidare 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 9

Il concetto del messaggio è astratta, i tipi più concreti di messaggio sono eventi e Command.

Mentre i messaggi non hanno alcuna intenzione di speciale a tutti, gli eventi informare su qualcosa che è accaduto e sta già completato (in passato). I comandi innescare qualcosa che dovrebbe avvenire (in futuro).