Quando usar o Spring Integration vs. Camel?

Como usuário experiente do Spring, eu estava assumindo que o Spring Integration faria mais sentido em um projeto recente que requer alguns recursos de mensagens (JMS) ( mais detalhes ). Depois de alguns dias trabalhando com o Spring Integration, ainda parece haver muita sobrecarga de configuração, dada a quantidade de canais que você precisa configurar para implementar algumas comunicações de solicitação-resposta (ouvindo em diferentes filas JMS).

Portanto, eu estava procurando algumas informações básicas sobre como o Camel é diferente da Spring Integration, mas parece que as informações disponíveis são bastante sobressalentes, descobri:

• http://java.dzone.com/articles/spring-integration-and-apache (comparação muito neutra entre a implementação de um cenário de integração do mundo real no Spring Integration vs. Camel, de dezembro de 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparando o Camel com outras soluções, outubro de 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, outubro de 2008)

A pergunta é: que experiências você fez ao usar uma pilha sobre a outra? Em quais cenários você recomendaria ao Camel o Spring Integration não possui suporte? Onde você vê os prós e os contras de cada um? Qualquer recomendação de projetos do mundo real é muito apreciada.

Escolhemos Camel em vez de Spring-Integration, porque a API fluente é muito boa. Na verdade, nós o usamos em projetos do Spring e usamos o Spring para configurar parte dele. As APIs de programação são claras e há um grande conjunto de componentes sensíveis.

Fizemos um tiroteio em pequena escala e, basicamente, naquele momento, para nossa exigência, Camel venceu. Nós o usamos principalmente para transferir arquivos de dados internos de / para terceiros, o que geralmente requer conversões de formato enviando-o usando ftp / sftp / ... ou anexando-o a um email e enviando-o.

Encontramos o ciclo de edição, compilação e depuração reduzido. Usando groovy para experimentar a configuração de rotas são adicionados bônus.

O Spring-Integration também é um ótimo produto, e tenho certeza de que também atenderia às nossas necessidades.

Eu só recomendo o Spring Integration se você já possui um projeto do Spring e precisa adicionar alguma integração "básica" usando File, FTP, JMS, JDBC e assim por diante.

O Apache Camel tem duas vantagens principais:

1. Muitas, muitas outras tecnologias são suportadas.
2. Além disso, um (bom) DSL XML, existem APIs fluentes para Java, Groovy e Scala.

Como o Apache Camel tem uma integração muito boa com o Spring, eu até o usaria em vez do Spring Integration na maioria dos projetos do Spring.

Se você precisar de mais detalhes, pode ler minhas experiências no meu blog: Spoiled for Choice: qual framework de integração usar - Spring Integration, Mule ESB ou Apache Camel?

Recentemente, conduzi um tiroteio Camel vs Spring Integration com o objetivo de integrar o Apache Kafka . Apesar de ser um desenvolvedor ávido do Spring, infelizmente achei minha suspeita com a crescente pilha de projetos do Spring : o Spring é incrível como o IOC-Container para servir de cola para outra estrutura, mas falha ao fornecer alternativas viáveis para essas estruturas . Pode haver exceções a isso, ou seja, tudo a ver com o MVC, de onde o Spring veio e de onde ele faz um ótimo trabalho, mas outras tentativas de fornecer novas funcionalidades sobre os recursos do contêiner ficam aquém por três razões e o caso de uso do SI Kafka confirma todos eles:

• Introdução de um longo DSL difícil de usar DSL para configuração XML.
• Páginas do código de configuração xml para conectar todos os componentes da estrutura.
• Recursos ausentes para fornecer funcionalidade a par com estruturas dedicadas.

Agora, voltando aos resultados do meu tiroteio: o mais importante é que estou impressionado com o conceito geral de rotas entre os pontos finais da Camels . O Kafka se integra perfeitamente a esse conceito e três linhas de configuração são suficientes para colocar tudo em funcionamento. Os problemas encontrados durante o processo são tratados com atenção por ampla documentação da equipe do projeto , além de muitas perguntas sobre o Stackoverflow. Por último, mas não menos importante, existe uma integração abrangente no Spring que não deixa desejos por realizar.

Com o SI, pelo contrário, a documentação para a integração do Kafka é bastante intensa e ainda não consegue explicar claramente como integrar o Kafka. A integração do Kafka é pressionada pela maneira SI de fazer as coisas, o que adiciona complexidade extra. Outra documentação, por exemplo, no Stackoverflow, também é menos abundante e menos útil do que para o Camel.

Minha conclusão: o sapateiro adere ao seu comércio - use o Spring como contêiner e o Camel como estrutura de integração de sistemas.

Realmente depende do que você quer fazer. Se você precisar estender algo para criar sua própria solução de mensagens, o Spring Integration possui o melhor modelo de programação. Se você precisar de algo que ofereça suporte a muitos protocolos sem código personalizado, o Camel está à frente da Spring Integration.

Ter um tiroteio em pequena escala é uma ideia muito boa, apenas verifique se você está tentando fazer o tipo de coisa que normalmente faria no projeto.

--disclaimer: Eu sou um colaborador do Spring Integration

A maioria das comparações de Camel e SI que eu já vi não leva em consideração o seguinte:

1.) O efeito que o Spring Boot teve na produtividade do desenvolvedor para o Spring Integration

2.) O efeito do Spring XD teve a disponibilização dos aplicativos Spring Integration sem compilação de código - também as fontes e sumidouros Spring XD são simplesmente adaptadores de canal do Spring Integration, quando você deseja estender o Spring XD.

3.) O efeito do Spring XD teve na integração unificada do Spring Integration, Spring Batch, Spring Data (+ Hadoop!) Em uma pilha, trazendo efetivamente o processamento em lote e fluxo, o suporte ao HDFS / Apache Hadoop e muito mais ao Spring Integration.

4.) O efeito da DSL Java do Spring Integration 4.0 em breve a ser lançada https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Para sua consideração,

/ Pieter (aviso de isenção de responsabilidade que trabalho na Pivotal)

Estamos usando o Spring Integration para nosso aplicativo e agora estamos pensando em mudar para o Apache Camel, pois encontramos muitos problemas com a estrutura do Spring Integration. Aqui estão algumas questões.

1. O CachingConnectionFactory, fornecido pelo Spring, abre milhares de conexões inativas no IBM MQ e não há garantia de que essas conexões sejam reutilizadas. E ainda essas conexões permanecerão abertas para sempre, o que cria problemas no lado do MQ. Teve que reiniciar o aplicativo toda semana em ambientes inferiores apenas para atualizar as conexões. O Apache Camel também fornece armazenamento em cache e as conexões parecem aumentar / diminuir com base na carga.

2. O Spring não fornece mapeadores para parâmetros de QoS. Mesmo se você ativar a QoS, o modo de entrega e as propriedades de validade / cronograma serão perdidas (vou levantar um problema do JIRA para isso). O Apache Camel lida com isso e os parâmetros de QoS são enviados para aplicativos upstream e não descartados.

No momento, estou trabalhando em problemas com o tratamento de exceções e transações com o Apache Camel que o Spring parecia lidar melhor com o AOP.

Na verdade, eu diria que o FTP concluiu o período de incubação. Você pode fazer uma pesquisa simples nos fóruns da SI / JIRA para ver quais novos recursos foram implementados e os erros corrigidos. De várias conversas, parece que já existe algum uso de produção, então eu sugiro dar uma segunda olhada e, é claro, comunicar suas preocupações conosco via

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

Cheers Oleg

Isenção de responsabilidade: Eu sou o committer da Spring Integration

O Apache Camel é uma estrutura muito boa e muito completa também. Mas se o seu aplicativo usar a primavera, meu conselho pessoal é usar o Spring Integration.

Spring Integration é a estrutura de reclamação EIP de integração do ecossistema Spring-Source. Possui excelente integração com o ecossistema: Spring boot, Batch, XD; até o núcleo usa a mesma abstração a partir do Spring Framework 4. Algumas das abstrações de mensagens foram movidas na estrutura, como prova de que a abstração básica de mensagens do Spring Integration é muito forte. Agora, o framework Spring, por exemplo, usa a abstração de mensagens para o Spring Web, suporte a soquete da web.

Outra coisa boa em um aplicativo Spring com relação à integração do Spring para usar o Apache Camel é que, com a integração do Spring, você pode usar apenas um Contexto do Aplicativo. Lembre-se de que o contexto do camelo é um contexto da primavera. se você tiver a chance de usar uma nova versão do Spring, sugiro usar o Spring Integration Java DSL para configuração. Eu o uso em meus novos projetos e parece mais legível e claro. Espero que esta reflexão possa ajudá-lo nas suas avaliações.

Um motivo para usar o Camel over Spring Integration é quando você precisa de um conjunto EIP mais abrangente. O Spring Integration não fornece abstrações sobre coisas como ThreadPool.

O Camel fornece construções adicionais para simplificar alguns dos aspectos do trabalho com código simultâneo:

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

Se você não precisa desse tipo de coisa e deseja apenas conectar arquivos, JMS, pontos de extremidade FTP etc ..., basta usar o Spring Integration.

O Camel atua como middleware para aplicativos, onde é possível realizar modelagem de dados, transformação de valores de mensagens e coreografia de mensagens.

Se o seu aplicativo atual estiver no Spring e exigir recursos suportados pelo Spring Integration of EIP, o Spring Integration é a melhor opção, caso contrário, precisará de mais suporte / protocolos / formatos de arquivo de terceiros etc.