When to use Spring Integration vs. Camel?

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.

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:

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

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.

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

Solution 2:

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.

Apache Camel has two main advantages:

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

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

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?

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

Solution 4:

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

Solution 5:

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

1.) The effect that Spring Boot has had on developer productivity for 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.

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.

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

For your consideration,

/Pieter (disclaimer I work at Pivotal)