Informazioni su ESB

Question

sebbene comprenda cosa sia l'integrazione di sistema, sono un po 'nuovo a tutti gli approcci più recenti. Sono molto familiare con i servizi Web e JMS, ma mi sento completamente confuso dal concetto di un ESB.

Ho fatto qualche ricerca ma ancora non la capisco. Lavoro molto meglio con l'esempio piuttosto che con la teoria.

Quindi qualcuno può illustrare un esempio semplicistico per dimostrare perché si dovrebbe utilizzare un bus di servizio aziendale contro solo una coda, un servizio Web, il file system o altro?

Vorrei l'esempio per amplificare le capacità dell'ESB che non potrebbero essere ottenute con qualsiasi altro metodo di integrazione convenzionale o almeno non con la stessa efficienza.

Tutte le risposte sono molto apprezzate.

Grazie, Bob

Answer 1

Si tratta di andare a suonare un po 'dura, ma in fondo se avevi bisogno di un ESB, sapresti avevi bisogno di un ESB.

Per la maggior parte dei casi d'uso, l'ESB è una soluzione alla ricerca di un problema. È una pila di software su cui è stata progettata la maggior parte degli scenari. La maggior parte della gente semplicemente non fa abbastanza varietà di elaborazione per giustificarla. La "E" per "Enterprise" è notevole qui.

In un caso semplice:

tail -F server.log | grep SEVERE >> severe.log 

CHE è un esempio banale di un'istanza di uno scenario ESB.

"Ma questa è solo una pipeline di comandi UNIX!"

Sì, esattamente.

La parte "ESB" è il "|" e la ">>"

L'ESB è il tempo di esecuzione entro il quale è possibile collegare insieme i moduli, monitorare il traffico, la progettazione di tutti i tipi di scenari sgargianti come fan-out e si unisce, ecc ecc

ESB sono notevoli per avere un sacco di connettori per leggere un sacco di fonti e scrivere un sacco di destinazioni. Sono noti per la tessitura di grafici e flussi di lavoro più complicati per l'elaborazione utilizzando blocchi logici piuttosto grossolani.

Ma ciò che la maggior parte delle persone in genere fanno è:

input -> DO_STUFF -> output 

Con un ESB ottengono:

ESB[input -> DO_STUFF -> output] 

In natura, la maggior parte delle condutture semplicemente non sono così complicato. Tendono ad avere una logica off che non è riutilizzabile e la gente tende a raggrupparla in un unico modulo logico.

Bene, diamine, puoi farlo con uno script Perl.

Le condotte lunghe negli ESB tendono ad essere più inefficienti di quanto non lo siano. Con un sacco di marshalling di dati in entrata e in uscita di moduli generici (dal momento che raramente si utilizza un payload binario).

Quindi, ad esempio, CSV entra, converte in XML, lo elabora, genera l'XML per l'input in un altro passo come XML, che lo esegue, lo lavora, lo converte in XML per Yet Another step. Risciacquare e ripetere fino a quando la CPU raggiunge il 400% (FTW multi-core).

Poi qualcuno si avvicina con "Ehi, se trascino un drop di questi moduli in una singola routine, saltiamo tutta questa spazzatura XML!", E si finisce con "input -> DO_STUFF -> output" .

Per i sistemi di grandi dimensioni, con molti servizi Web che richiedono un'integrazione casuale e ad hoc, possono andare bene. Se sei in un'azienda che lo fa molto, possono funzionare davvero bene. Quando hai dozzine di condutture, possono aiutare con l'aspetto operativo della loro gestione.

Ma per le pipeline complicate, se si dispone di molti passaggi, forse non è una buona idea al di là del prototipo, soprattutto se è coinvolto un volume reale. Attenzione, potresti non avere alcuna scelta, dipende dai sistemi che stai integrando.

In caso contrario, se si dispone di un'interfaccia singola è necessario alzarsi in piedi, quindi è sufficiente farlo. Fallo in Perl, in Java, in C#, in qualunque cosa. Non correre e spendere circa 100 MB di infrastrutture e complessità che ora devi imparare, gestire e gestire.

Quindi, ancora, se avessi bisogno di un ESB, lo sapresti. Veramente. Avresti tutto il sistema che hai costruito insieme a cose disparate, ti batteresti, parlerai con i colleghi di quanto sia doloroso tutto questo, e ti imbatterai in qualche link a qualche sito con qualche venditore e leggerai un white paper e vai "THAT'S IT!", ma se non lo hai ancora fatto, allora non ti manca nulla.

Answer 2

Come concluso da @WillHartung, gli ESB tendono ad essere utilizzati correttamente in situazioni complesse e di grandi dimensioni. Ed è per questo che è denominato Enterprise Bus.

Ora, per rispondere alla tua domanda in realtà, gli ESB in genere:

• comunicare attraverso diversi protocolli (ad esempio HTTP, Message Queue, etc.), sia per l'input e l'output

• Stabilire una comune Formato messaggio, e spesso tradurre da altri formati nel formato "canonico"

• Fornire trasparenza endpoint (ad esempio, inviare un messaggio al bus e ottenere una risposta indietro, ma non si conosce esplicitamente cosa vice, anche lui collegato al bus, ha gestito la tua richiesta.

• fornire il monitoraggio e la gestione delle funzionalità di

• Facilitare il controllo delle versioni dei servizi e dei messaggi

• far rispettare la sicurezza, in caso di necessità.

Quindi, come potete vedere, è per quando si fa un sacco di comunicazione point-to-point ("just do it") sarebbe un enorme, mucchio ingestibile di spaghetti. In effetti, la maggior parte dei luoghi in cui ho visto SOA è stata implementata, sta sostituendo quella enorme pila di spaghetti che esiste già.

Answer 3

ESB è per i casi in cui il servizio Web, la coda e il file system si trovano tutti nello stesso sistema e devono essere integrati. un ESB prodotto di solito risolve il seguente

1. Security
2. messaggio di routing
3. Orchestration (che è avanzato il routing dei messaggi)
4. protocollo trasformazione
5. Messaggio trasformazione
6. Monitoraggio
7. Eventing

Puoi anche fare tutto questo con altri strumenti e se hai solo bisogno di una o due di queste funzionalità puoi probabilmente fare a meno e ESB (come ha introdotto la complessità aggiuntiva) ma quando hai bisogno di alcuni di loro una soluzione integrata in la forma di un ESB può essere una soluzione migliore.

Answer 4

Un ESB è un bus di servizio aziendale, un backplane di infrastruttura, se si desidera un'architettura orientata ai servizi. Immagina il caos di centinaia di servizi che si riutilizzano felicemente. Come gestire un simile ambiente? Come fornisci un instradamento flessibile e disaccoppiato tra i tuoi servizi? Come si evita l'architettura degli spaghetti point-to-point? Come gestisci le transazioni e la sicurezza in un panorama tecnologico ibrido? Come si traccia dove i messaggi sono in flussi complessi su più sistemi?

Si utilizza un ESB.

Gli ESB in genere consentono di progettare flussi su più sistemi in un linguaggio di configurazione XML, offrendo una serie di adattatori EIS, plug-in di trasformazione e mediazione, ecc. Alcuni offrono un IDE per facilitare la progettazione dei flussi. Alcuni ESB sono molto costosi, altri open source.

Se si desidera avere un'idea di ESB, controllare Mule o WSO2, entrambi buoni prodotti open source, o anche Spring Integration che è una soluzione non cluster ma eccellente per disaccoppiare Java dai punti di interfaccia esterni sottostanti.

Answer 5

Questo ti aiuterà a capire il concetto di ESB.

A Buyers Guide to an Enterprise Service Bus (ESB) Questo fornirà un'idea chiara su ESB.

"Quando si tratta di integrazione di applicazioni, l'Enterprise Service Bus (ESB) è la risposta unanime.La sua architettura di soluzione sfrutta servizi Web, middleware di messaggistica, routing intelligente e trasformazione. Data l'ampiezza della sua funzionalità, . decisione se o meno l'organizzazione sarà implementare un ESB e se sì quale si deve scegliere è fondamentale

Questa sessione fornirà una panoramica dei fattori chiave che hanno bisogno di prendere in considerazione alcuni dei quali comprendono -

La fase tecnologica corretta alla quale è necessario considerare l'opzione di utilizzare un adattamento ESB richiesto di architettura esistente La comunità circostante "