Differenza tra un broker di messaggi e un ESB

Ho esaminato diverse domande / articoli su Message Broker ed ESB (anche su StackOverflow). Non hai ancora idea di quale sia la differenza che delimita CLEAR tra un Message Broker e un ESB? Ora qui sto cercando di confrontare i prodotti, Websphere Broker e Mule ESB !!

Innanzitutto, Webshere Broker è (qualsiasi versione) un ESB? I nostri ragazzi del prodotto IBM affermano che si tratta di un ESB! (Non ne sono sorpreso).

Le mie informazioni limitate mi dicono che un Message Broker funziona su un modello HUB-SPOKE. Tuttavia, ESB funziona su un'architettura bus. Cosa diavolo dovrebbe significare? Ho letto che se l'HUB fallisce (non disponibile immagino), allora il broker fallisce completamente. Che non è il caso di un ESB (così dicono quei ragazzi). Quello che non capisco qui è "Cosa succede se il BUS" fallisce?

Ora la solita roba su ESB e Broker è che forniscono routing, trasformazione, orchestrazione ecc. Quindi se entrambi forniscono questo, allora perché dovrei scegliere l'uno rispetto all'altro.

Un'altra area di conflitto riguarda la TRASFORMAZIONE. Gli ESB lo facilitano in modo diverso rispetto ai Message Broker? Mi piacerebbe davvero approfondire questo.

Ora parlando del ridimensionamento ORIZZONTALE. Chi supera chi? O sono entrambi ugualmente scalabili in termini di complessità (o qualsiasi altro fattore). Naturalmente, dal punto di vista dei costi, Webshpere Broker ti addebiterà per ogni casella (figuriamoci per ogni CPU). Credo che anche il MULE ESB commerciale non lo faccia. Lasciando da parte la parte di costo, quali sono le implicazioni del ridimensionamento ESB e del ridimensionamento di Message Broker. Mi capita di sapere che puoi passare al livello di servizio in ESB. È possibile in un Message Broker?

È possibile utilizzare un broker di trasformazione senza un bus di servizio e viceversa. In termini di prodotti specifici, non credo che nessuno sia puramente l'uno o l'altro a causa del modo in cui ciascuno completa l'altro. Alcuni prodotti sono più forti in una zona, altri più forti in un'altra. Forse una scelta deve essere fatta in base alla funzione che meglio copre un singolo problema.

Un broker può disporre di "lego block" integrati migliori per la costruzione di una catena di trasformazione rispetto a un prodotto ESB. Un broker messo in servizio come ESB può essere schiacciato sotto carico e non scalare bene, oppure può mancare un journaling solido e strumenti per gestire le riviste.

Alcuni ESB consentono il rollback degli aggiornamenti del database e la riproduzione delle code in un'applicazione corretta una volta scoperto e corretto un errore grave nella logica. Non credo che la maggior parte dei broker integri quel livello di supporto transazionale. Perché questo funzioni in tutte le tue "transazioni" devi quasi essere eventi aziendali (una vendita, un rinnovo, un cambio di proprietà, ecc.) Piuttosto che qualcosa come "aggiornamenti del database" di RPCish.

Dichiarazione di non responsabilità: sono un consulente IBM e sono specializzato in WebSphere ESB. Questo commento non è lasciato in alcun modo ufficiale.

Un ESB è più un modello o un concetto architettonico che un prodotto - in generale, un modo basato sul servizio di progettare accoppiamento libero. La sua definizione è combattuta e non esattamente incastonata nella pietra. In generale, un ESB è un insieme di servizi non correlati (in senso tecnico): espongono le interfacce e le consumano da altri servizi. Generalmente non esiste un hub e un'architettura a raggio, sebbene ci possa essere.

IBM commercializza certamente WebSphere Message Broker e WebSphere ESB come prodotti che semplificano la creazione di un ESB (insieme all'appliance hardware DataPower). Hanno radici tecnologiche diverse, ma hanno alcune sovrapposizioni di scopo. Inoltre, questo non vuol dire che non puoi costruire un ESB con molte altre cose che non sono marchiate come un "prodotto ESB".

Ciò non risponde a tutte le vostre domande, ma si spera che si rivolga alla parte IBM.

La differenza tra un Message Broker e un ESB (Enterprise Service Bus) è principalmente la parola "bus".

Per me, un Message Broker è un processo (generalmente grande) che trasforma i dati da una struttura a un'altra struttura o modifica il contenuto.

Un ESB è un middleware orientato ai messaggi (MOM) più servizi aggiuntivi, uno dei quali potrebbe essere un Message Broker. Quindi un ESB può includere un Message Broker come uno dei suoi componenti. Un bus è composto da più di un processo, altrimenti non lo definirei un "bus". La natura di un bus è che ci sono più componenti che svolgono compiti diversi, ognuno dei quali comunica su una MOM e aderisce a una qualche forma di "formato di dati comune". Un bus consisterebbe in: applicazioni che inviano dati alla MOM, adattatori di database, Message Broker, ponti MOM, ecc.

La separazione è un po 'graduale, ma la più grande differenza tra un'architettura Message Broker e un Bus è quella della granularità . Se il tuo compito è integrare le applicazioni A, B, .., Z e un paio di database, puoi farlo con un grande Message Broker che collega tutti. O con un ESB in cui più piccoli componenti occupano solo piccole attività. Ad esempio un adattatore si collega ad A, un altro a B (ma non esegue la trasformazione), quindi ognuno invia le proprie cose a uno (o più) Message Broker, ognuno dei quali dovrebbe essere mantenuto il più semplice possibile - ad es. No conoscere il modello di dati di "A" o "B". Un buon ESB dovrebbe avere una definizione comune dei dati sul bus, sottraendo la "differenza" delle singole applicazioni.

TRASFORMAZIONE: un ESB non aiuta nella trasformazione, a meno che non venga fornito con un Message Broker. Ma ogni buon ESB dovrebbe includere comunque un Message Broker. Il Message Broker dovrebbe essere l'esperto del tuo bus per le trasformazioni, ma nient'altro.

Ridimensionamento ORIZZONTALE: se hai solo 3 cose da connettere (ora e per sempre), probabilmente non vale la pena di ottenere un ESB in piena regola. Un Message Broker ha il vantaggio di essere solo un grande processo. Puoi configurare tutto lì e avere una posizione centrale per tutti i tuoi dati mappati, filtraggio e routing.

Ma se hai 30 applicazioni da connettere, un Message Broker probabilmente si fermerebbe. Ovviamente puoi acquistare più istanze, eseguire attività ridondanti, ecc. Ma dovresti cambiare la tua strategia per "localizzare" i lavori. L'adattatore di ogni applicazione (che può essere una piccola istanza di Message Broker ciascuno) dovrebbe essere in grado di generare e / o ricevere un modello di dati comune astratto (ad esempio XML con un XSD condiviso). Potrebbe esserci anche un Message Broker centrale per le attività di trasformazione, ma quell'istanza dovrebbe essere ignara del modello di dati A o B. Quindi un ESB dovrebbe spostare l'elaborazione nel componente esperto invece di tenere tutto in una posizione centrale.

Ho appena letto questo articolo di Udi Dahan qualche giorno fa, che potrebbe darti una visione più chiara di ciò che ritengo sia una differenza fondamentale.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

citando:

La regola secondo cui esiste un solo editore per un determinato tipo di evento è una delle cose che differenzia gli autobus dai broker, anche se entrambi consentono ovviamente di avere più abbonati

...

Sfortunatamente, ci sono molte tecnologie in stile broker là fuori che vengono commercializzate sotto il nome di Enterprise Service Bus. Mentre alcuni prodotti hanno la possibilità di essere distribuiti in modo centralizzato e distribuito (a volte chiamato modalità "federata" o "incorporata"), molti non impongono la regola del "singolo endpoint di pubblicazione per tipo di evento".

Senza questo vincolo, è semplicemente troppo facile commettere errori.

Spero che sia d'aiuto.

Un bus di servizio aziendale fornisce tre valori chiave per l'azienda:

1. Instradamento contestuale o basato sul contenuto delle transazioni;
2. Trasformazione da un dominio di messaggi o trasporto a un altro dominio di messaggi o trasporto;
3. connettività di servizio molti-a-molti.

Gli ESB offrono un accoppiamento libero dei servizi, consentono la ricostituzione dei servizi in contesti applicativi completamente diversi rispetto a quando i servizi sono stati inizialmente concepiti o sviluppati e promuovono il riutilizzo delle applicazioni senza la necessità di ricodificare le applicazioni. WebSphere Message Broker (o ora si chiama IBM Integration Bus) è un ottimo esempio di Enterprise Service Bus. Per un esempio di semplicità del codice che porta un grande potere in poche righe, puoi vedere il mio post qui: http://soabus.org/viewtopic.php?f=3&t=13 . Il costrutto fondamentale all'interno del runtime IIB si chiama Logical Message Tree(LMT). Tutto ciò che lo sviluppatore vuole fare è un tipo di operazione sull'LMT. ESQL è il linguaggio più efficiente che uno sviluppatore può utilizzare per eseguire queste operazioni su LMT, sebbene siano supportati molti altri linguaggi (ad esempio Java, PHP, Python, ecc.) Nessun altro prodotto si avvicina all'efficienza e alla facilità di sviluppo di ESB applicazioni rispetto a IBM Integration Bus poiché il 90% della codifica di queste applicazioni viene eseguita trascinando e rilasciando nodi su un pallet. Ciò lascia solo il 10 percento della codifica che deve essere eseguita dallo sviluppatore del flusso di messaggi. A proposito, WebSphere ESB è stato sospeso da IBM e molti dei prodotti concorrenti di IBM Integration Bus non vedono alcun nuovo sviluppo su di essi da diversi anni ormai. Un elenco di varie offerte di prodotti ESB è disponibile su soabus.org.

Da allora IBM non ha mai cambiato i nomi della sua offerta ESB, quindi non vorrei entrare nei nomi o nei fornitori.

ESB consente alle informazioni aziendali di fluire tra diverse applicazioni su più piattaforme hardware e software. ESB è più di un livello middleware che contiene una logica di connettività delle applicazioni e una logica aziendale minima o nulla. Ciò consente alle applicazioni di fare ciò che fa meglio senza preoccuparsi di incorporare alcuna logica di connettività su come interagire con altri N numero di applicazioni che richiedono i dati da esso. L'architettura ESB tenta di risolvere il problema degli spaghetti punto a punto in un'azienda.

ESB e Message Broker sono una sorta di sinonimi tra loro, tuttavia, poiché una delle risposte sopra ha evidenziato che il modello di Message Broker è una porzione del dominio ESB più grande. La lettera "B" in ESB è analoga al bus (hardware) nell'architettura del computer. Il bus sulla scheda madre o in un computer collega vari componenti per il funzionamento del computer. ESB è un bus basato su software che collega vari servizi in un'azienda. Hub and speak è uno dei modelli supportati dall'architettura ESB. Nel mondo monolitico, ogni fornitore ha la propria architettura di implementazione ad alta disponibilità per garantire che ESB sia disponibile. Le offerte recenti di qualsiasi fornitore ESB sono in termini di modello di distribuzione basato su microservizi o ospitato nel proprio cloud noto come iPAAS. In questo modo si garantisce che il bus non si guasterà o si guasterà temporaneamente con l'autoguarigione in base al modello di distribuzione selezionato. Con la distribuzione basata su microservizi o iPAAS, gli ESB dispongono ora di funzionalità di ridimensionamento automatico (orizzontale o verticale) con funzionalità che variano in base al fornitore selezionato.

Per funzionalità di livello molto elevato fornite da ESB, è possibile passare al seguente link => https://en.wikipedia.org/wiki/Enterprise_service_bus