Cos'è un ESB ea cosa serve?

In un lavoro precedente, si parlava molto di "Enterprise Service Bus" (ESB). Ho letto parti di un libro concettuale a riguardo, ma non ho mai capito come lo avresti implementato / integrato in termini concreti. Ho familiarità con SOA / accodamento / servizi di directory / ecc. ma non capisco cosa sia esattamente un ESB.

È una cosa concreta (servizio / server / broker / ecc.) Che ti colleghi ad esso tutte le tue app in modi diversi, o è più solo un modo concettuale per progettare i sistemi?

Eventuali spiegazioni o collegamenti a buoni esempi sarebbero molto apprezzati. Grazie.

È un concetto di astrazione di livello abbastanza alto. Il concetto centrale è che ESB fornisce il middleware e le interfacce che consentono alle aziende di connettere le proprie applicazioni senza scrivere codice.

Ciò potrebbe includere la mediazione per riconciliare protocolli, dati e interazioni incompatibili.

L'idea di un autobus centrale su cui tutto passa offre l'opportunità di ulteriori livelli di astrazione. L'utilizzo di standard di settore per "collegare" altre applicazioni, client e simili a questo bus rende relativamente facile la connessione di nuovi servizi, origini dati e client con esigenze disparate.

Implementazioni effettive

Per quanto riguarda le implementazioni effettive, questo è il dominio delle aziende di supporto aziendale di grandi dimensioni. Sebbene sia molto alla moda, l'obiettivo è un ideale che su un piccolo livello può essere compreso attraverso il confronto con Internet:

Somiglianza con Internet

Un unico grande bus di comunicazione con usi e dati molto diversi, ma tutti in esecuzione su protocolli standardizzati.

Si può, infatti, scrivere un connettore da HTTP a FTP che consentirebbe ai browser di accedere ai siti FTP senza richiamare un client FTP (di solito integrato nel browser ora).

Mashup

I mashup dimostrano un'implementazione interessante: prendi alcuni dati sul percorso dell'autobus dall'autorità di San Francisco, mappa da google e posizioni del sushi bar da yahoo con valutazioni ed esegui una semplice query che ti dà il sushi bar più vicino, ponderandolo in modo da essere disposto a viaggiare un po 'più lontano per un bar migliore.

Tutti servizi completamente diversi, incompatibili da soli, ma utilizzando connettori standard (yahoo pipe, per esempio) possono essere uniti in un insieme coerente e utile.

-Adamo

Dichiarazione di non responsabilità: lavoro per IBM e consulto WebSphere ESB, un prodotto IBM progettato per creare ESB con. Le seguenti sono le mie opinioni e non riflettono necessariamente la posizione di IBM.

Un ESB è cose diverse per persone diverse, sfortunatamente.

Per me, un ESB è una tecnologia qualsiasi che puoi inserire in una SOA (Service-Oriented Architecture), che ti consente di connettere sistemi diversi tra loro. Spesso svolge le funzioni di trasformazione del protocollo, modifica dei messaggi, instradamento, registrazione, funge da gateway di sicurezza e così via. Ad esempio, potresti utilizzare un ESB per esporre un servizio precedentemente disponibile solo come servizio Web anche come servizio basato su JMS.

A questo proposito, le implementazioni ESB (o per essere più precisi, il software venduto per costruire ESB con - come quello su cui consulto) sono spesso tecnologicamente simili a quello che era noto come un broker di messaggistica o di accodamento, sebbene lo scopo sia leggermente diverso , perché (come implicano gli acronimi) è orientato ai servizi piuttosto che a spostare i messaggi da un luogo all'altro. Quanto sia importante la distinzione tecnologicamente è una questione di opinione.

La mia esperienza con ESB commerciale è che si tratta di una tecnologia eccessiva e costosa che crea tanti problemi quanti ne risolve. L'ESB collegherà nuovi sistemi e legacy, i messaggi voleranno sull'autobus e tutto sarà in grado di parlare con tutto il resto senza interruzioni. Aggiungete un po 'di resilienza, orchestrazione e avrete un software applicativo aziendale molto potente.

Il problema nasce quando si tenta di usarli per davvero, il sovraccarico di scrivere per l'autobus, creare le strutture dei messaggi e così via, può superare i vantaggi. Essendo un elemento ad alto costo, l'ESB è visto come la panacea per tutti i problemi tecnologici che non è, viene speso troppo tempo sul bus e non sulle applicazioni / dati da collegare. È spesso il caso che più standard concorrenti combatteranno per la supremazia nella stessa organizzazione portando ai classici silos dominati dalla tecnologia che questi sistemi dovrebbero effettivamente riparare.

IMHO è molto meglio usare creare un piccolo numero di interfacce specifiche, tipicamente utilizzando i servizi web solo tra i sistemi che ne hanno bisogno.

È fondamentalmente un modo concettuale per progettare un sistema: le società di software cercano di venderti di più attaccandovi l'adesivo "ESB" e ai gestori piace perché un ESB sembra buono da un "livello superiore".

Un ESB è fondamentalmente un MOM (middleware orientato ai messaggi) con un modello di dati aggiunto e una gestione della definizione della struttura. Hai una definizione di dati comune per tutte le applicazioni e gli adattatori su quel bus (potrebbe essere XML con un XSD condiviso). Tutto ciò che si collega DEVE inviare le sue informazioni che aderiscono a questa definizione di dati. L'ESB supporta il caricamento, la condivisione e il controllo delle versioni di questa definizione di dati comune. Quando si collega un nuovo componente a un ESB, ci si può aspettare più "compatibilità" immediatamente rispetto a quando lo si collega a un MOM. Ogni componente su quel bus è concettualmente trattato come una "risorsa", quindi è stata introdotta un'astrazione aggiuntiva per separare il mittente dal destinatario.

Esempio: supponiamo che tu voglia connettere l'applicazione A con l'applicazione B in un middleware orientato ai messaggi standard, prendiamo JMS. Parli con i tuoi colleghi che lavorano sull'applicazione B, concordi su un argomento, tipo di messaggio e campi e invialo (pseudo codice): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101,4 vol = 100})

Se fai la stessa cosa in un'architettura orientata ai servizi, devi farlo

1. installare software aggiuntivo
2. imparare molti nuovi concetti
3. definire il nuovo componente Java nella GUI di amministrazione di ESB
4. implementare alcune interfacce controllate dall'ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101,4 vol = 100}) - nota che la destinazione viene iniettata dall'ESB

La prima volta è probabilmente un po 'doloroso, ma immagino che ci si possa abituare, proprio come ci si può abituare agli EJB ;-)

Si potrebbe dire che un sistema MOM è "non tipizzato" (struttura dinamica) mentre un ESB è "digitato" (struttura statica). I compromessi tra la messaggistica non elaborata e l'ESB sono simili ad altre scelte non tipizzate / tipizzate:

• RIPOSO vs SAPONE
• XML non convalidato rispetto a XML convalidato con un XSD
• Groovy contro Java
• linguaggio interpretato vs. linguaggio compilato

Per progetti più piccoli è bello eseguire rapidamente l'hash delle funzionalità (ad es. Codice Groovy) ma per progetti più grandi è bene avere un debugger (ad es. Java), per essere avvisati in anticipo quando le cose si interrompono e per avere uno standard per le persone prima che si impegnino nel progetto.

Quindi, se il tuo progetto soffre di troppe persone che interrompono il sistema registrando modifiche non convalidate, passa a una struttura più ampia (ESB invece di MOM). Se i tuoi progetti soffrono di non portare a termine abbastanza cose in tempo, scegli la soluzione più semplice e non tipizzata. Se è entrambe le cose, chiama un consulente (sto scherzando ;-)

Beh, dipende da chi chiedi ... Molti direbbero che è un pezzo di "Middleware" che collega insieme vari pezzi di "logica aziendale" per eliminare il codice dalla messaggistica tra questi moduli. Penso che sia una definizione abbastanza generale, ma sono sicuro che ci sei già arrivato tramite Wikipedia e quant'altro.

Coloro che vogliono che il grande ESB salvi il mondo lo vedono come viene presentato più comunemente, un hub per fare tutto. La maggior parte delle implementazioni ESB si sforza di incapsulare tutte le attività ripetitive che vediamo nel software aziendale. Ciò significa che la maggior parte degli ESB si occupa del trasferimento dei dati, della sicurezza, della registrazione, della traduzione del protocollo, dei sistemi di eventi, dell'esposizione delle API tramite servizi web, ecc.

Penso che sia il più chiaro possibile ... Spero che aiuti.

Dai un'occhiata alla mia presentazione "L' imbarazzo della scelta - Come scegliere l'ESB giusto ".

Spiego quando utilizzare un ESB, una suite di integrazione o solo un framework di integrazione (come Apache Camel). Discuto anche le differenze tra ESB open source e proprietari.

Oltre alla definizione standard che puoi ottenere da Wikipedia . Trovo che sia un ottimo strumento per collegare un gruppo di sistemi legacy su più piattaforme e tecnologie. È anche un buon strumento per la creazione di flussi di lavoro distribuiti e sistemi di gestione dello stato (come la contabilità generale).

Tuttavia, è piuttosto costoso, complesso e scomodo da mantenere ed estendere, il che lo rende una scelta tecnologica scadente come strumento generico per il ridimensionamento delle applicazioni.