When to use Spring Integration vs. Camel?

Question

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). Af

Answer 1

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.

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.

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

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

Answer 2

Camel act as middleware for application where one can perform data modeling, transformation of message values and choreography of messages.

Answer 3

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 to those 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 reasons and the SI Kafka use case confirms all of them:

• 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.

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 team as well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Spring that leaves no wishes unfulfilled.

With SI on the contrary, the documentation for the Kafka integration is quite intense and still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressed into 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.

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

Answer 4

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.

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.

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

Answer 5

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 does provide additional constructs for this simplifying some of the aspects of working with concurrent code:

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.

Answer 6

It 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.

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