I vantaggi di un enterprise service bus

Question

Dove posso trovare alcune informazioni sugli usi e benefici di un enterprise service bus (ESB)?

Sto cercando informazioni su:

1. i tipi di problemi e ESB aiuta a risolvere
2. le alternative a un ESB - e i compromessi nella scelta tra di loro
3. che cosa dovete fare come sviluppatore per costruire sistemi ESB-compatibile

Sto cercando un livello più fine di dettagli che solo Wikipedia o brochure di marketing online da fornitori. Idealmente, un po 'di codice di esempio aiuterebbe a chiarire ciò che è coinvolto in approfittando di un ESB. Informazioni da un punto di vista .NET o Java sarebbe il più utile.

Grazie.

Answer 1

Io suggerirei Per ESB o di non ESB per cominciare, scritto dal creatore di Mule .

Answer 2

ESB di sono un buon modo per implementare Enterprise Integration Patterns .

tipi di problemi che un ESB aiuta a risolvere

• Si dispone di un certo numero di protocolli di desideri normalizzare a un singolo protocollo (ad esempio FTP, e-mail, SOAP, XMPP, ecc per un sistema di messaggistica) ad esempio, ActiveMQ. Ciò consente di separare l'implementazione di servizi da protocollo.
• Si desidera un modo coerente per agganciare i servizi in questa architettura in modo che possano ascoltare i messaggi, messaggi di processo e di generare messaggi (Message Endpoint, Adattatori Canale ecc.).
• Si consiglia un contenitore riusciti a distribuire queste varie componenti in (ad esempio ServiceMix, Mule)
• Si consiglia un numero di componenti predefiniti e adattatori in vari protocolli (per esempio ServiceMix, mulo e Camel hanno un sacco di componenti predefiniti).
• È possibile richiedere flussi di lavoro in esecuzione lunghi. Business Process Management è spesso qualcosa che viene fornito insieme a un ESB (Apache ODE si inserisce in una serie di ESB Open Source).

Alternative a un ESB

Le alternative in realtà dipende dal problema che si sta cercando di risolvere.

• Per fornire servizi distribuiti, le persone spesso usano server applicativi che espongono i servizi via un certo punto a punto il protocollo RPC (come EJB oltre RMI o servizi Web su HTTP). Quindi, piuttosto che mettere un messaggio su un 'bus', un client chiama direttamente un server.
• Per rispondere a specifici protocolli, si può solo creare un client che risponde a quel protocollo per esempio scrivere un'applicazione che ascolto per i messaggi di posta elettronica utilizzando JavaMail o uno che ascolta XMPP utilizzando Smack. Se il problema è limitato a uno o due protocolli non può essere la pena di portare in una piena ESB.

Quello che dovete fare come sviluppatore per costruire sistemi ESB-compatibile

Questo dipenderà dalla ESB selezionato, anche se dato che la maggior parte di quelli buoni sono progettati per chiamare in ogni sorta di protocolli e POJO di accoglienza, non c'è molto si dovrebbe bisogno di fare costruire sistemi compatibili ESB . Vale la pena di provare a rendere il codice asincrono.

Per esempio, Apache Camel ha probabilmente la configurazione più succinta, ecco una esercitazione .

Answer 3

Tre vantaggi chiave:

• Un bus fornisce un modo per i punti finali per collegare tra loro senza dover comunicare direttamente l'uno all'altro. E ' semplifica le comunicazioni per i punti finali come hanno solo a conformarsi ad un'interfaccia di comunicazione standard, il bus. (Questo è con qualsiasi autobus tecnica, non solo gli ESB)
• Un ESB fornisce un unico luogo per ottenere alcuni parametri chiave del punto finale:. Frequenza, disponibilità e prestazioni
• Un ESB tende a fornire più di un'interfaccia di comunicazione. Tuttavia, uno sviluppatore ha bisogno solo di scegliere il più facile da ottenere e ricevere i dati dal bus.

Tuttavia, assicurarsi che quelli fornirà valore di business per la situazione. Avere un ESB è l'aggiunta di un ulteriore complessità alla vostra impresa. Idealmente, non si dovrebbe scegliere questo sulla base di alcune applicazioni, ma l'intera organizzazione. Ci dovrebbe essere solo una la produzione di ESB di cluster per l'organizzazione.

Alternative:

• Basta collegare le cose tra di loro direttamente, soprattutto se i protocolli di comunicazione sono gli stessi. Questo è un bene per semplici applicazioni cluster e non richiede troppo pensare. Tuttavia, come il tuo numero di applicazioni crescere, mantenendo le interconnessioni diventa difficile.
• Un'altra alternativa è un'implementazione MQ. Questo vi fornirà un modo di trasmettere i dati in giro senza dover interconnessioni complesse, ma poi si è costretti ad utilizzare un solo canale di comunicazione. Fortunatamente per Java, hanno lo standard JMS.

Praticità:

ho dichiarato le possibili alternative. Possono sembrare schifoso in un primo momento, ma non è di dire che non è possibile avviare in questo modo. Io personalmente scrivo cose di cui parlare per il telecomando direttamente senza passare attraverso un ESB per assicurarsi che funzioni senza preoccuparsi troppo di problemi di integrazione.

Se non si dispone di un ESB, vi consiglio di provare mulo per lo sviluppo e WebSphere ESB per il test e la produzione. Io tendo ad usare due prodotti che presumibilmente seguono gli standard per assicurarsi che manteniamo i venditori onesti e per assicurarsi che gli sviluppatori sono conformi alle norme che impediscono involontaria vendor lock-in.

Alla fine, basta rispondere alla seguente domanda:? È il momento di aggiungere il bit di complessità per semplificare altre complessità vostra impresa vale il costo a lungo termine

Answer 4

In aggiunta ai siti che sono stati già menzionati. Si consiglia di leggere questo articolo su " Non utilizzare un ESB a meno che non dovete assolutamente ". E 'stato scritto dal CTO di MuleSource, uno dei più popolari open source ESB di disponibili. Non esattamente una risposta alla tua domanda, più di fare un punto da porsi "Ho bisogno di un ESB"?

Answer 5

C'è un discreta serie di 3 parti oltre a IBM per quanto riguarda ESB che è abbastanza concetto orientato e vendor agnostico (per la maggior parte). Ho trovato un sacco di roba buona su ESB da rovistando sito di IBM. Ci sono anche alcune informazioni decente e video e roba sopra al href="http://www.microsoft.com/biztalk/en/us/esb-guidance.aspx" rel="nofollow noreferrer"> sito BizTalk .

Answer 6

Dai un'occhiata a questo Hanselminutes podcast di . Essa risponde ad alcune domande che si dovrebbe davvero porsi prima di implementare un servizio bus.

Answer 7

Un enterprise service bus (ESB) è un'architettura software per il middleware che fornisce servizi fondamentali per le architetture più complesse. Ad esempio, un ESB incorpora le funzionalità necessarie per implementare un'architettura orientata ai servizi (SOA). In senso generale, un ESB può essere pensato come un meccanismo che gestisce l'accesso ad applicazioni e servizi (in particolare le versioni precedenti) per presentare un unico, semplice e coerente interfaccia per via basata su forme sul Web o client-side utenti finali front-end.

In sostanza, ESB fa per servizi distribuiti eterogenei back-end e le applicazioni e gli utenti eterogenea front-end distribuiti e ai consumatori informazioni Cosa Middleware è davvero suppone fare: nascondere la complessità, semplificare l'accesso, consente agli sviluppatori di utilizzare, forme canoniche generiche di interrogazione , l'accesso e l'interazione, curando i dettagli complessi nei precedenti. La chiave per l'appello di ESB, e forse anche il suo futuro successo, risiede nella sua capacità di supportare l'integrazione dei servizi e l'applicazione incrementale come guidata da esigenze di business, non come disciplinato dalla tecnologia disponibile.

http://searchsoa.techtarget.com/definition/enterprise-service-bus

Enterprise Service Bus (prodotto)

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentazione! WSO2 ESB è un veloce, leggero, 100% open source, e user-friendly ESB distribuito sotto la licenza Apache Software v2.0. WSO2 ESB consente agli amministratori e agli sviluppatori di sistema di configurare facilmente il routing dei messaggi, la mediazione, la trasformazione, la registrazione, pianificazione delle attività, il failover, il bilanciamento del carico, e altro ancora. Supporta i più comunemente usati Enterprise Integration Pattern (PEI) e consente la commutazione di trasporto, gestione degli eventi, la mediazione basata su regole, e la mediazione basato sulle priorità per i requisiti di integrazione avanzata. Il runtime ESB è stato progettato per essere completamente asincrono, non bloccante, e lo streaming basato sul motore di mediazione Apache Synapse.

WSO2 ESB è sviluppato in cima alla rivoluzionaria piattaforma WSO2 Carbon, un framework OSGi-based che fornisce modularità senza soluzione di continuità per il vostro SOA tramite componentizzazione. Esso include molte caratteristiche e componenti opzionali (add-on) è possibile installare nel ESB, e si può facilmente rimuovere le funzioni non necessarie nel proprio ambiente, consentendo in tal modo di personalizzare pienamente e su misura WSO2 ESB per soddisfare le vostre esigenze SOA.

Architettura infrastruttura applicativa sulle imprese può essere intrinsecamente complessa, composta da centinaia di applicazioni completamente differenti semantica. Alcune di queste applicazioni sono su misura, alcuni sono acquistati da terzi, e alcuni possono essere una combinazione di entrambi e può funzionare in diversi ambienti di sistema.

L'integrazione tra queste applicazioni eterogenee è di vitale importanza per l'impresa. Diversi servizi possono essere utilizzando diversi formati di dati e protocolli di comunicazione. luoghi fisici di servizi possono cambiare arbitrariamente. Tutti questi vincoli significano le applicazioni sono ancora strettamente accoppiati. Un ESB può essere utilizzata per allentare questi accoppiamenti tra i diversi servizi e consumatori di servizi.

WSO2 ESB è un ESB a tutti gli effetti, enterprise-ready. E 'costruito sul progetto Apache Synapse, che è costruito utilizzando il progetto Apache Axis2. Tutti i componenti sono costruiti come bundle OSGi.

Answer 8

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

spiego quando utilizzare un ESB, Integration Suite, o semplicemente un quadro di integrazione (come Apache Camel). Ho anche discutere le differenze tra open source e proprietarie ESB.

Answer 9

v'è motivo zero a utilizzare un ESB. Non farlo. Inutile complessità. Perché passare attraverso un intermediario quando si può andare direttamente? La gente ESB vi dirà punto a punto è male, eppure in qualche modo punto a punto da e per l'ESB è buono.

Answer 10

La prima domanda è necessario porsi è perché avete bisogno di un ESB?

ESB di solito è usato in eventi SOA architetture distribuite, che sembrano essere una parola d'ordine caldo al giorno d'oggi. Prima di saltare in ESB permettetemi di ricordarvi di Fowler Prima Legge di Martin di distribuire sistemi:

http://martinfowler.com/bliki/FirstLaw.html

"La mia prima legge di Design Object distribuita:. Non distribuire i vostri oggetti (da p di EAA)

Il relativo capitolo è disponibile online. "

Quando si è costruire un nuovo sistema, l'aspetto più importante è che è a prova di futuro, che significa facile scalabilità e manutenibilità. Se si crea il sistema attorno al concetto di servizi sciolto con contratto statico definito distribuito in un ambiente di rete, è possibile "nascondere" l'architettura che si desidera per quel particolare servizio, perché le interfacce sono ancora lì.

ESB è strettamente legata a asyn sistemi di messaggistica, quindi prima di iniziare saltare in quel tipo di implementazione, sappiate che un'architettura non deve essere omogeneo, cioè tutti i servizi da attuare allo stesso modo, Non tiratevi avviare il più grande errore che distribuisce il sistema fin dall'inizio, si dovrebbe distribuire solo come avete bisogno di scala, non prima della mano. Che cosa è necessario fare in modo, però, è che i servizi dovrebbero essere in grado di essere facilmente distribuito in caso di necessità, senza rompere alcun contratto che significherebbe, modifiche per i clienti di tale servizio.

Per quanto riguarda i benefici di ESB, che sono le stesse di SOA, ESB aggiunge il contesto di messaggi asyn operazioni (eventi).

Answer 11

In primo luogo lasciatemi spiegare SOA . Esso è di costruire un'architettura come un insieme di moduli software riutilizzabili esposti come “Servizi” con interfacce ben definite. I servizi facilitano accoppiamento lasco e abstract suoi dettagli di implementazione da parte dei clienti.

SOA potrebbe finire-up disordinato se ogni componente ha invitato servizi direttamente. Quindi ha seguito i problemi più comuni.

• Come si fa a trovare quali servizi vengono utilizzati e quali no?
• Come si fa a trovare i clienti con un servizio di particolare?
• Come si tira fuori gli aggiornamenti di un servizio o di esporre nuove versioni ai servizi esistenti senza interruzioni?
• Come si fa a sostenere la compatibilità per i clienti più anziani invocano interfacce di servizio anziani
• Come si esegue la registrazione, il controllo, l'applicazione di sicurezza ecc in tutti i servizi per il traffico interno / esterno?

Il ESB è la soluzione per le questioni di cui sopra. ESB ...

• Aiuta porta al fine
• Può far rispettare rigorosamente le policy aziendali
  • es. Sicurezza, Throttling, auditing ecc applicata in modo coerente
• Virtualizza endpoint del servizio
  • Favorire il controllo delle versioni, gli aggiornamenti flessibili, HA / Load Balancing etc.
• Eseguire il routing, la mediazione, trasformazione, etc

Alcuni casi di utilizzo di esempio possono essere trovati qui . Si noti che sono da sito degli sviluppatori di AdroitLogic e rigorosamente accoppiato con UltraESB, ESB di AdroitLogic.