Java 何时使用 Spring Integration 与 Camel？

When to use Spring Integration vs. Camel?

提问by ngeek

As a seasoned Spring user I was assuming that Spring Integration would make the most sense in a recent project requiring some (JMS) messaging capabilities (more details). After some days working with Spring Integration it still feels like a lot of configuration overhead given the amount of channels you have to configure to bring some request-response (listening on different JMS queues) communications in place.

作为一个经验丰富的 Spring 用户，我假设 Spring Integration 在最近需要一些 (JMS) 消息传递功能的项目中最有意义（更多详细信息）。在使用 Spring Integration 几天后，考虑到您必须配置的通道数量，以实现一些请求-响应（侦听不同的 JMS 队列）通信，它仍然感觉像很多配置开销。

Therefore I was looking for some background information how Camel is different from Spring Integration, but it seems like information out there are pretty spare, I found:

因此，我正在寻找 Camel 与 Spring Integration 有何不同的一些背景信息，但似乎那里的信息非常少，我发现：

• http://java.dzone.com/articles/spring-integration-and-apache(Very neutral comparison between implementing a real-world integration scenario in Spring Integration vs. Camel, from December 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html(Comparing Camel with other solutions, October 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a(Matt Raible, October 2008)

• http://java.dzone.com/articles/spring-integration-and-apache（2009 年12 月在 Spring Integration 与 Camel 中实现实际集成场景之间的非常中立的比较）
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html（Camel与其他解决方案的比较，2009 年 10 月）
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a（MattRaible，2008 年 10 月）

Question is: what experiences did you make on using the one stack over the other? In which scenarios would you recommend Camel were Spring Integration lacks support? Where do you see pros and cons of each? Any advise from real-world projects are highly appreciated.

问题是：在使用一个堆栈而不是另一个堆栈时，您有什么经验？如果 Spring Integration 缺乏支持，您会在哪些场景中推荐 Camel？你从哪里看出各自的优缺点？任何来自现实世界项目的建议都受到高度赞赏。

采纳答案by Peter Tillemans

We choose Camel over Spring-Integration because the fluent API is really nice. We actually use it in Spring projects and use Spring to configure part of it. The programming API's are clear and there is a large set of sensible components.

我们选择 Camel 而不是 Spring-Integration，因为 fluent API 非常好。我们实际上在Spring项目中使用它，并使用Spring来配置它的一部分。编程 API 很清楚，并且有大量合理的组件。

We did a small scale shootout and basically at that time for our requirement Camel won. We use it mainly to transfer internal datafiles to/from external parties which usually requires format conversions sending it using ftp/sftp/... or attaching it to an email and sending it out.

我们进行了一次小规模的枪战，当时基本上满足了我们的要求，Camel 赢了。我们主要使用它来向/从外部各方传输内部数据文件，这通常需要使用 ftp/sftp/... 发送它或将其附加到电子邮件并发送出去。

We found the edit-compile-debug cycle reduced. Using groovy to experiment setting up routes are added bonuses.

我们发现编辑-编译-调试周期减少了。使用 groovy 来试验设置路由是额外的好处。

Spring-Integration is a great product too, and I am quite sure it would satisfy our needs too.

Spring-Integration 也是一个很棒的产品，我很确定它也能满足我们的需求。

回答by iwein

I really depends on what you want to do. If you need to extend something to build your own messaging solution Spring Integration has the better programming model. If you need something that supports many protocols without custom code, Camel is ahead of Spring Integration.

我真的取决于你想做什么。如果你需要扩展一些东西来构建你自己的消息传递解决方案，Spring Integration 有更好的编程模型。如果您需要无需自定义代码即可支持多种协议的东西，Camel 领先于 Spring Integration。

Having a small scale shootout is a very good idea, just make sure you're trying to do the type of things that you'd typically be doing in the project.

进行小规模的枪战是一个很好的主意，只要确保您正在尝试做您在项目中通常会做的事情。

--disclaimer: I'm a Spring Integration committer

--disclaimer: 我是 Spring 集成提交者

回答by Oleg Zhurakousky

Actually, I would say FTP has graduated its incubation period. You can do a simple search on SI forums/JIRA to see what new features were implemented and bugs that were fixed. From various chatter it seems like there is already some production usage out of it, so I would suggest to give it a second look and of course communicate your concerns to us via

实际上，我会说 FTP 已经结束了它的潜伏期。您可以在 SI 论坛/JIRA 上进行简单的搜索，以查看实现了哪些新功能以及修复了哪些错误。从各种喋喋不休看来，似乎已经有一些生产用途了，所以我建议再看看它，当然，通过以下方式向我们传达您的担忧

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

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

Cheers Oleg

干杯奥列格

Disclaimer: I am Spring Integration committer

免责声明：我是 Spring Integration 提交者

回答by Kai W?hner

I only recommend Spring Integration if you already have got a Spring project and you have just to add some "basic" integration using File, FTP, JMS, JDBC, and so on.

如果您已经有一个 Spring 项目，并且您只需使用 File、FTP、JMS、JDBC 等添加一些“基本”集成，我只推荐 Spring Integration。

Apache Camel has two main advantages:

Apache Camel 有两个主要优点：

1. Many, many more technologies are supported.
2. Besides, a (good) XML DSL, there are fluent APIs for Java, Groovy and Scala.

1. 支持更多的技术。
2. 此外，一个（好的）XML DSL，还有适用于 Java、Groovy 和 Scala 的流畅 API。

Because Apache Camel has very good integration with Spring, I would even use it instead if Spring Integration in most Spring projects.

因为 Apache Camel 与 Spring 的集成非常好，如果在大多数 Spring 项目中使用 Spring Integration，我什至会使用它。

If you need more details, you can read my experiences in my blog post: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

如果您需要更多详细信息，可以在我的博客文章中阅读我的经验：Spoiled for Choice: which Integration Framework to use – Spring Integration、Mule ESB 或 Apache Camel？

回答by Jon

One reason to use Camel over Spring Integration is when you need a more featureful EIP set. Spring Integration doesn't provide abstractions over things such as ThreadPool.

使用 Camel over Spring Integration 的一个原因是当您需要一个功能更强大的 EIP 集时。Spring Integration 不提供对诸如 ThreadPool 之类的东西的抽象。

Camel does provide additional constructs for this simplifying some of the aspects of working with concurrent code:

Camel 确实为此提供了额外的构造，以简化处理并发代码的某些方面：

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

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

If you have no need for this sort of thing and just want to connect file, JMS, FTP endpoints etc... then just use Spring Integration.

如果您不需要这种东西，只想连接文件、JMS、FTP 端点等……那么只需使用 Spring Integration。

回答by Venkata Parvatam

If your current application is in Spring and require features which are supported by Spring Integration of EIP then Spring Integration is the best option else require more third party supports/protocols/file formats etc

如果您当前的应用程序在 Spring 中并且需要 EIP 的 Spring Integration 支持的功能，那么 Spring Integration 是最佳选择，否则需要更多第三方支持/协议/文件格式等

回答by PivotalPieter

Most comparisons of Camel and SI that I've seen don't take the following into account:

我见过的 Camel 和 SI 的大多数比较都没有考虑以下因素：

1.) The effect that Spring Boot has had on developer productivity for Spring Integration

1.) Spring Boot 对 Spring Integration 开发人员生产力的影响

2.) The effect of Spring XD has had on making Spring Integration applications available with no code compilation - also Spring XD sources and sinks are simply Spring Integration channel adapters, when you're looking to extend Spring XD.

2.) Spring XD 的影响使 Spring Integration 应用程序无需代码编译即可使用 - 当您希望扩展 Spring XD 时，Spring XD 源和接收器也只是 Spring Integration 通道适配器。

3.) The effect of Spring XD has had on making unifying Spring Integration, Spring Batch, Spring Data (+Hadoop!) in one stack, effectively bringing batch and stream processing, HDFS/Apache Hadoop support, and much more to Spring Integration.

3.) Spring XD 的作用是将 Spring Integration、Spring Batch、Spring Data (+Hadoop!) 统一在一个堆栈中，有效地为 Spring Integration 带来了批处理和流处理、HDFS/Apache Hadoop 支持等。

4.) The effect of the soon-to-be-released Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

4.) 即将发布的 Spring Integration 4.0 Java DSL 的效果https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

For your consideration,

供您考虑，

/Pieter (disclaimer I work at Pivotal)

/Pieter（免责声明我在 Pivotal 工作）

回答by Fritz Duchardt

I have recently conducted a Camel vs Spring Integration shoot-out with the aim to integrate Apache Kafka. Despite being an avid Spring developer, I sadly found my suspicion with Spring's ever-growing Project stack confirmed: Spring is awesome as IOC-Container to serve as glue for other framework, but it fails at providing viable alternatives tothose frameworks. There might be exceptions to this, namely everything to do with MVC, where Spring came from and where it does a great job, but other attempts to provide new functionality on top of container features fall short for three reasonsand the SI Kafka use caseconfirms all of them:

我最近进行了 Camel 与 Spring Integration 的较量，目的是集成Apache Kafka。尽管我是一名狂热的 Spring 开发人员，但遗憾的是，我发现我对 Spring 不断增长的项目堆栈的怀疑得到证实：Spring 作为 IOC 容器作为其他框架的粘合剂非常棒，但它未能为这些框架提供可行的替代方案。可能有例外，即与 MVC 相关的一切，Spring 来自何处，它在何处做得很好，但其他在容器特性之上提供新功能的尝试由于三个原因而失败，SI Kafka 用例证实了这一点他们都：

• Introduction of a long-winded difficult to use DSL for XML-configuration.
• Pages of xml-configuration code to get all framework components wired-up.
• Missing resources to provide functionality on par with dedicated frameworks.

• 为 XML 配置引入一个冗长难用的 DSL。
• 用于连接所有框架组件的 xml 配置代码页。
• 缺少提供与专用框架相当的功能的资源。

Now, back to the results of my shoot-out: most importantly I am impressed by Camels overall concept of routes between endpoints. Kafka seamlessly integrates with this concept and three lines of configuration are enough to get everything up-and-running. Problems encountered during the process are neatly addressed by ample documentation from the project teamas well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Springthat leaves no wishes unfulfilled.

现在，回到我的枪战结果：最重要的是，Camels 的端点之间路由的整体概念给我留下了深刻的印象。Kafka 与这个概念无缝集成，三行配置足以让一切正常运行。项目团队提供的大量文档以及有关 Stackoverflow 的大量问题巧妙地解决了在此过程中遇到的问题。最后但并非最不重要的一点是，它与 Spring 进行了全面集成，没有遗漏任何愿望。

With SI on the contrary, the documentation for the Kafka integration is quite intenseand still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressedinto the SI-way of doing things, which adds extra complexity. Other documentation, e.g. on Stackoverflow is also less plentiful and less helpful than for Camel.

与SI相反，Kafka集成的文档相当密集，仍然没有解释清楚如何集成Kafka。Kafka 的集成被压入了 SI 的处事方式，这增加了额外的复杂性。其他文档，例如 Stackoverflow 上的文档也没有 Camel 那样丰富和有用。

My conclusion: cobbler stick to your trade - use Spring as a container and Camel as system integration framework.

我的结论是：cobbler 坚持你的交易——使用 Spring 作为容器，使用 Camel 作为系统集成框架。

回答by Valerio Vaudi

Apache Camel is a very good framework and very complete too. But if your application uses spring, my personal advice is to use Spring Integration.

Apache Camel 是一个非常好的框架，也非常完整。但是如果您的应用程序使用 spring，我个人的建议是使用 Spring Integration。

Spring Integration is the integration EIP complaint framework of Spring-Source ecosystem. It has excellent integration with the ecosystem: Spring boot, Batch, XD; even the core uses same abstraction starting from Spring Framework 4. Some of the messaging abstraction were moved in the framework, as proof that the basic messaging abstraction of Spring Integration is very strong. Now Spring framework for instance use the messaging abstraction for Spring Web, web socket support.

Spring Integration 是 Spring-Source 生态的集成 EIP 投诉框架。它与生态系统有很好的整合：Spring boot、Batch、XD；甚至核心使用从 Spring Framework 4 开始的相同抽象。框架中移动了一些消息抽象，以证明 Spring Integration 的基本消息抽象非常强大。现在 Spring 框架例如使用 Spring Web 的消息传递抽象，Web 套接字支持。

Another good thing in a Spring application with Spring integration respect to use Apache Camel is that with Spring integration, you can use only one Application Context. Remember that the Camel Context is a Spring context. if you have the chance of use a new Spring version, I suggest to use Spring Integration Java DSL for configuration. I use it on my new projects, and it feels more readable and clear. I hope that this reflection can help you for the your evaluations.

在 Spring 集成的 Spring 应用程序中使用 Apache Camel 的另一个好处是，通过 Spring 集成，您只能使用一个应用程序上下文。请记住，Camel 上下文是一个 Spring 上下文。如果您有机会使用新的 Spring 版本，我建议使用 Spring Integration Java DSL 进行配置。我在我的新项目中使用它，感觉更易读和清晰。我希望这个反思可以帮助您进行评估。

回答by Selvakumar

We are using Spring Integration for our application and now considering to move to Apache Camel as we encountered lots of issues with Spring Integration framework. Here are couple of issues.

我们正在为我们的应用程序使用 Spring Integration，现在考虑迁移到 Apache Camel，因为我们在 Spring Integration 框架中遇到了很多问题。这里有几个问题。

1. The CachingConnectionFactory which Spring provides opens 1000's of idle connections in IBM MQ and there is no guarantee that these connections are reused. And still these connections will stay open forever which creates troubles on the MQ side. Had to restart the application every week in lower environments just to refresh the connections. Apache Camel also provides Caching and the connections seems to go up/down based on the load.

2. Spring doesn't provide mappers for QoS parameters. Even if you enable QoS, the delivery mode and expiration/timetolive properties will get lost (I am going to raise a JIRA issue for this). Apache Camel handles this and QoS parameters are sent to upstream applications and not dropping it.

1. Spring 提供的 CachingConnectionFactory 在 IBM MQ 中打开了 1000 个空闲连接，并且不能保证这些连接被重用。而且这些连接将永远保持打开状态，这会在 MQ 端造成麻烦。必须每周在较低环境中重新启动应用程序才能刷新连接。Apache Camel 还提供缓存，连接似乎根据负载上升/下降。

2. Spring 不提供 QoS 参数的映射器。即使您启用 QoS，交付模式和到期/生存时间属性也会丢失（我将为此提出 JIRA 问题）。Apache Camel 处理这个问题，QoS 参数被发送到上游应用程序而不是丢弃它。

I am right now working on issues with handling the exceptions and transactions with Apache Camel which Spring seemed to handle better with AOP.

我现在正在处理使用 Apache Camel 处理异常和事务的问题，Spring 似乎可以用 AOP 更好地处理这些问题。