Come deve essere impacchettato/distribuito un ESB?

Question

Sto cercando di avvolgere la mia mente su Apache Camel, che sembra essere un ESB leggero. Se capisco correttamente Camel/ESB, allora puoi pensare a una Camel Route come un grafico di nodi e spigoli. Ogni nodo è un endpoint sulla rotta (può consumare/produrre messaggi). Ogni spigolo è un percorso tra due endpoint diversi (1 produttore e 1 consumatore).

Supponendo che sia corretto, ho una domanda pratica: quali sono le migliori pratiche che dettano l'implementazione dell'ESB/Camel Route dell'applicazione? Dovrei impacchettarlo come proprio JAR, o è degno di essere il suo EAR completo di EJB, Web Services e altri JAR?

Credo che sto chiedendo come un percorso cammello o ESB devono essere distribuiti/L'architettura dei, come:

my-esb.ear/ 
    ejb1.jar/ 
     MyEJB_1.class 
    ejb2.jar/ 
     MyEJB_2.class 
    webservice.war/ 
     MyWebService.class 

Oppure ...

my-esb.jar/ 
    MyEJB_1.class 
    MyEJB_2.class 
    MyWebService.class 

Answer 1

Dalla mia comprensione ci sono un paio di modi in cui è possibile eseguire Camel.

1. integrato in un'applicazione Java: È possibile incorporare Camel in un'applicazione Java stand alone. In questo scenario si avvierebbe un Camel Context all'interno della propria applicazione che avvierà i percorsi ecc. Questo è ottimo quando l'applicazione deve comunicare con i servizi ecc. Per far funzionare questo, è necessario distribuire i barattoli Camel e di terze parti per i componenti. il classpath.

2. incorporato in una Web Application: Mentre la gente ha già sottolineato questo sembra l'un'opzione popolare. I barattoli di cammelli e i barattoli di terze parti sono racchiusi in un file WAR e essenzialmente distribuiti in un contenitore Web come Tomcat per ospitare i servizi Camel.

3. incorporato in un server di applicazioni: Ho letto qualche articolo su come distribuire Camel ad un application server come JBoss e ho anche letto di persone che implementano per Glassfish. Questo sembra molto simile nel modo in cui viene distribuito a Tomcat. JBoss ha alcuni problemi di caricamento di classe che dovresti affrontare e questo lo rende complicato. Quindi sì, è possibile distribuire su un server applicativo andando sulla rotta WAR.

4. Deploy per OSGi: È possibile effettuare la Camel jar un bundle OSGi in tempi relativamente brevi e distribuire ad un quadro OSGi come Apache Felix. È relativamente semplice convertire il jar in un bundle OSGi appropriato e quindi distribuirlo. L'unico grosso problema qui è che alcune terze parti potrebbero non disporre di bundle compatibili con OSGi da distribuire.

La mia preferenza personale è il percorso OSGi. È facile e leggero e mi consente di ospitare le mie rotte di cammello come servizi permanenti (ad es. Il servizio Window, Unix Deamon) con un footprint molto ridotto.

La cosa che dovresti realizzare ora è che Apache Camel può essere distribuito in vari modi e dipende da te decidere come vuoi farlo. Mi ci è voluto un po 'per capire come distribuire Camel in quanto dovevo giocare con i diversi modelli di implementazione per ottenere un buon feeling. L'unico che non ho toccato è stato distribuire su un Application Server perché ritenevo che la maggior parte di questi server fosse abbastanza pesante.

Per quanto riguarda l'architettura, mi piace mantenere i miei percorsi/applicazioni differenti in vasi diversi. Dal momento che sto usando OSGi mi piace essere in grado di aggiornare un percorso specifico e distribuirlo senza dover ridistribuire tutto. Se hai dispiegato tutto in un barattolo, dovresti abbattere il mondo per ricostruire e ridistribuire il barattolo. Tuttavia questa è una preferenza personale e il tuo chilometraggio potrebbe variare

Spero che questo aiuti un po '.

Answer 2

Questo dipende dalle vostre esigenze. Non esiste una singola risposta di verità che sia migliore.

Camel può adattarsi all'infrastruttura esistente e alla piattaforma di runtime. Quindi impacchetta le tue applicazioni con Camel incorporato nel modo in cui questa piattaforma può farlo e nel modo desiderato.

Ad esempio, per utilizzare cammello in un'applicazione web (WAR) è possibile vedere questo link: http://camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

Answer 3

Si stanno prendendo in considerazione .ear embedding, vedo.

Ti consiglio di pensare due volte a incorporare Camel in un server Java EE completo. È certamente fattibile, ma avrai un po 'di lavoro per collegarli (con commonJ, WorkManager, riferimenti JNDI, ecc.). In particolare, lasciare che Camel gestisca il threading è un grande vantaggio.

Embedding Camel all'interno di un'app web di primavera (.WAR) è il mio preferito per l'implementazione in Jetty o Tomcat. Quindi accedi a un contenitore di servlet decente, a un runtime che può fare alcune cose, ecc.

In realtà, ho utilizzato il download standard di ActiveMQ in alcuni ambienti di produzione con il Camel incorporato, più per scopi di adattatore e non così tanto ESB, ma ancora, potrebbe essere una scelta valida se ActiveMQ è il backbone di messaggistica del tuo ESB.

Answer 4

Come nelle altre risposte, dipende dalle vostre esigenze ma un ESB è solitamente una combinazione di diversi processi di integrazione che non necessariamente condividono lo stesso ciclo di vita.

Se questo è il tuo caso, ti suggerisco di utilizzare un approccio al processo di integrazione con jar. In questo modo puoi avere cicli di sviluppo differenti per ciascuno dei diversi jar e puoi assicurare al tuo cliente che non hai toccato nessuno dei codici tranne quello in quel jar.

Questo non significa che devi andare con la soluzione ear. È possibile impacchettare perfettamente il codice per i diversi processi in un file war senza l'overhead ear.

Answer 5

Permettetemi di rispondere alle vostre domande una per una:

Fornisce un descrittiva, elenco non vaga di fattori generali che dovrebbero essere utilizzati per determinare come distribuire meglio un ESB (sia come singolo EAR con ciascun endpoint che è un JAR incorporato o come un singolo "monolitico" JAR);

Il vaso Embeded o Monolithic non importa. Ciò che conta è l'implementazione in bundle o di guerra. Nel caso di un pacchetto autonomo si potrebbe finire con un archivio di distribuzione molto pesante con un sacco di contenitori per la risoluzione delle dipendenze.

spiega pienamente perché Camel potrebbe non giocare bene con Java EE applicazione server come JBoss o GlassFish

1. Discussione/risorse/porta di gestione di App-Server/contenitore può imporre restrizioni.

2. Conflitto di uso comune Biblioteca Versione

3. Conflitto sul meccanismo classloading

Logicamente, se il vostro contenitore supporta OSGi quindi Camel non dovrebbe affrontare qualsiasi problema.

1. Come Apache Camel è un messaggio Router molto leggero, in modo da poter sicuramente si può confezionare nel vostro orecchio insieme con l'applicazione web come un file diguerra. Se stai usando Maven/Ivy e il tuo contenitore web supporta osgi, allora Bingo! La vita sarà molto più facile.
2. seconda opzione è di distribuire l'applicazione come un fascio
3. e un altro è stand-alone jar Java SE.

Seguire il link qui sotto [Anche se, abbastanza antiquato], quelli vi darà passo-passo in direzione sulle confezioni, at-almeno chiarezza sul meccanismo confezione:

Camel Step By Step

Camel in a Web Application

Camel Real Life Packaging & Deployment in OSGi environment