Quando utilizzare Spring Integration vs. Camel?

Come utente Spring esperto, supponevo che l'integrazione Spring avrebbe avuto più senso in un recente progetto che richiedeva alcune funzionalità di messaggistica (JMS) ( maggiori dettagli ). Dopo alcuni giorni di lavoro con Spring Integration sembra ancora un sacco di sovraccarico di configurazione data la quantità di canali che devi configurare per mettere in atto alcune comunicazioni di richiesta-risposta (ascolto su diverse code JMS).

Quindi stavo cercando alcune informazioni di base sul modo in cui Camel è diverso da Spring Integration, ma sembra che le informazioni disponibili siano piuttosto libere, ho scoperto:

• http://java.dzone.com/articles/spring-integration-and-apache (Confronto molto neutrale tra l'implementazione di uno scenario di integrazione del mondo reale in Spring Integration vs. Camel, da dicembre 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Confronto di Camel con altre soluzioni, ottobre 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, ottobre 2008)

La domanda è: quali esperienze hai fatto usando una pila sopra l'altra? In quali scenari consiglieresti a Camel se l'integrazione di primavera non fosse supportata? Dove vedi pro e contro di ciascuno? Qualsiasi consiglio proveniente da progetti del mondo reale è molto apprezzato.

Scegliamo Camel rispetto a Spring-Integration perché l'API fluente è davvero bella. In realtà lo usiamo nei progetti Spring e utilizziamo Spring per configurarne una parte. Le API di programmazione sono chiare e esiste un ampio set di componenti sensibili.

Abbiamo fatto una sparatoria su piccola scala e praticamente in quel momento per il nostro requisito ha vinto Camel. Lo usiamo principalmente per trasferire file di dati interni da / verso soggetti esterni che di solito richiedono conversioni di formato inviandolo tramite ftp / sftp / ... o allegandolo a un'e-mail e inviandolo.

Abbiamo trovato il ciclo di modifica-compilazione-debug ridotto. L'uso di Groovy per sperimentare la creazione di percorsi è un ulteriore bonus.

Anche l'integrazione primaverile è un ottimo prodotto e sono sicuro che soddisferà anche le nostre esigenze.

Raccomando l'integrazione di primavera solo se hai già un progetto di primavera e devi solo aggiungere un'integrazione "di base" usando File, FTP, JMS, JDBC e così via.

Apache Camel ha due vantaggi principali:

1. Sono supportate molte, molte più tecnologie.
2. Inoltre, un (buon) DSL XML, ci sono API fluide per Java, Groovy e Scala.

Poiché Apache Camel ha un'ottima integrazione con Spring, lo userei persino al posto di Spring Integration nella maggior parte dei progetti Spring.

Se hai bisogno di maggiori dettagli, puoi leggere le mie esperienze nel mio post sul blog: Spoiled for Choice: quale Integration Framework usare: Spring Integration, Mule ESB o Apache Camel?

Di recente ho condotto una sparatoria contro Camel vs Spring Integration con l'obiettivo di integrare Apache Kafka . Pur essendo un avido sviluppatore di Spring, ho purtroppo trovato il mio sospetto con lo stack di progetti sempre crescente di Spring confermato: Spring è fantastico come contenitore IOC per servire da colla per altri framework, ma non riesce a fornire alternative praticabili a tali framework . Potrebbero esserci delle eccezioni a questo, in particolare tutto ciò che riguarda MVC, da dove proviene Spring e dove fa un ottimo lavoro, ma altri tentativi di fornire nuove funzionalità oltre alle funzionalità del contenitore non sono sufficienti per tre motivi e il caso d'uso di SI Kafka conferma tutti loro:

• Introduzione di un DSL difficile da usare a lungo termine per la configurazione XML.
• Pagine di codice di configurazione xml per ottenere tutti i componenti del framework cablati.
• Risorse mancanti per fornire funzionalità alla pari con framework dedicati.

Ora, tornando ai risultati della mia sparatoria: soprattutto sono impressionato dal concetto generale di Camels di percorsi tra endpoint . Kafka si integra perfettamente con questo concetto e tre linee di configurazione sono sufficienti per rendere tutto funzionante. I problemi riscontrati durante il processo vengono risolti in modo accurato da un'ampia documentazione del team di progetto e da molte domande su StackOverflow. Ultimo ma non meno importante, c'è una completa integrazione in Spring che non lascia alcun desiderio insoddisfatto.

Con SI al contrario, la documentazione per l'integrazione di Kafka è piuttosto intensa e non riesce ancora a spiegare chiaramente come integrare Kafka. L'integrazione di Kafka è spinta nel modo di fare le cose, il che aggiunge ulteriore complessità. Altra documentazione, ad esempio su StackOverflow, è anche meno abbondante e meno utile rispetto a Camel.

La mia conclusione: il calzolaio si attacca al tuo mestiere - usa Spring come contenitore e Camel come framework di integrazione del sistema.

Dipende davvero da cosa vuoi fare. Se devi estendere qualcosa per creare la tua soluzione di messaggistica, Spring Integration ha il modello di programmazione migliore. Se hai bisogno di qualcosa che supporti molti protocolli senza codice personalizzato, Camel è in anticipo rispetto a Spring Integration.

Avere una sparatoria su piccola scala è un'ottima idea, assicurati solo di provare a fare il tipo di cose che normalmente faresti nel progetto.

--disclaimer: sono un committer di integrazione di primavera

La maggior parte dei confronti di Camel e SI che ho visto non tengono conto di quanto segue:

1.) L'effetto che Spring Boot ha avuto sulla produttività degli sviluppatori per l'integrazione di Spring

2.) L'effetto di Spring XD ha avuto la possibilità di rendere disponibili le applicazioni di Spring Integration senza compilazione di codice - anche le fonti e i sink di Spring XD sono semplicemente adattatori di canali di Spring Integration, quando stai cercando di estendere Spring XD.

3.) L'effetto di Spring XD ha avuto il risultato di unificare l'integrazione di Spring, Spring Batch, Spring Data (+ Hadoop!) In uno stack, portando in modo efficace l'elaborazione batch e stream, il supporto HDFS / Apache Hadoop e molto altro all'integrazione di Spring.

4.) L'effetto del DSL Java di Spring Integration 4.0 di prossima pubblicazione https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Per la tua considerazione,

/ Pieter (disclaimer, lavoro a Pivotal)

Stiamo utilizzando Spring Integration per la nostra applicazione e ora stiamo valutando di passare ad Apache Camel poiché abbiamo riscontrato molti problemi con il framework di integrazione di Spring. Ecco un paio di problemi.

1. La CachingConnectionFactory fornita da Spring apre migliaia di connessioni inattive in IBM MQ e non vi è alcuna garanzia che queste connessioni vengano riutilizzate. E ancora queste connessioni rimarranno aperte per sempre, il che crea problemi sul lato MQ. Ho dovuto riavviare l'applicazione ogni settimana in ambienti inferiori solo per aggiornare le connessioni. Apache Camel fornisce anche la memorizzazione nella cache e le connessioni sembrano aumentare / diminuire in base al carico.

2. Spring non fornisce mappatori per i parametri QoS. Anche se si abilita QoS, la modalità di consegna e le proprietà di scadenza / agenda andranno perse (ho intenzione di sollevare un problema JIRA per questo). Apache Camel gestisce questo e i parametri QoS vengono inviati alle applicazioni a monte e non lo rilasciano.

Attualmente sto lavorando a problemi con la gestione delle eccezioni e delle transazioni con Apache Camel che Spring sembra gestire meglio con AOP.

In realtà, direi che FTP si è laureato nel periodo di incubazione. Puoi fare una semplice ricerca sui forum SI / JIRA per vedere quali nuove funzionalità sono state implementate e quali bug sono stati corretti. Da varie chiacchiere sembra che ci sia già un certo utilizzo della produzione, quindi suggerirei di dare una seconda occhiata e, naturalmente, comunicarci le tue preoccupazioni tramite

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

Saluti Oleg

Disclaimer: sono un committer di integrazione di primavera

Apache Camel è un ottimo framework e anche molto completo. Ma se la tua applicazione utilizza Spring, il mio consiglio personale è di utilizzare Spring Integration.

Spring Integration è il framework di denuncia EIP per l'integrazione dell'ecosistema Spring-Source. Ha un'eccellente integrazione con l'ecosistema: Spring boot, Batch, XD; anche il core usa la stessa astrazione a partire da Spring Framework 4. Alcune astrazioni di messaggistica sono state spostate nel framework, come prova che l'astrazione di messaggistica di base di Spring Integration è molto forte. Ora il framework Spring, ad esempio, usa l'astrazione di messaggistica per Spring Web, supporto per i socket web.

Un'altra cosa positiva in un'applicazione Spring con integrazione Spring rispetto all'uso di Apache Camel è che con l'integrazione Spring è possibile utilizzare solo un contesto applicativo. Ricorda che il contesto del cammello è un contesto primaverile. se hai la possibilità di utilizzare una nuova versione di Spring, ti suggerisco di utilizzare Spring DSL Java Java per la configurazione. Lo uso nei miei nuovi progetti e mi sembra più leggibile e chiaro. Spero che questa riflessione ti possa aiutare per le tue valutazioni.

Uno dei motivi per utilizzare Camel over Spring Integration è quando è necessario un set EIP più funzionale. L'integrazione di primavera non fornisce astrazioni su cose come ThreadPool.

Camel fornisce ulteriori costrutti per questo semplificando alcuni degli aspetti dell'utilizzo del codice simultaneo:

http://camel.apache.org/camel-23-threadpool-configuration.html

Se non hai bisogno di questo genere di cose e vuoi solo connettere file, JMS, endpoint FTP ecc ... quindi usa solo Spring Integration.

Il cammello funge da middleware per l'applicazione in cui è possibile eseguire la modellazione dei dati, la trasformazione dei valori dei messaggi e la coreografia dei messaggi.

Se l'applicazione corrente è in primavera e richiede funzionalità supportate da Spring Integration di EIP, allora Spring Integration è l'opzione migliore altrimenti richiedono più supporti / protocolli / formati di file di terze parti ecc.