Sunday, January 5, 2014

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:
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.
share|improve this question
add comment

7 Answers

up vote20down voteaccepted
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.
share|improve this answer
1 
Thanks Peter for sharing your points, did you ever try to use the JMS capabilities of Camel, it seems like the respective components are also quite flexible and have the same richness as Spring Integration? By "small scale shootout" you refer to better performance numbers? –  ngeek Jun 14 '10 at 13:36
 
Shootout : it was mainly developer performance. Our performance needs are not very high. Yes we use a lot of JMS as basis. Both ActiveMQ and JBossMQ are used for messaging. –  Peter Tillemans Jun 14 '10 at 16:12
add comment
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 if 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?
share|improve this answer
add comment
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.
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
share|improve this answer
add comment
Camel has the nice fluent interface but debugging Camel routes is really next to impossible. Having worked on some large projects that used Camel, I would recommend Spring Integration. It just became a chore to debug routes and led to a large project turning into a pile of spaghetti. Granted, Camel has taken pains to integrate with Spring but there is a slight impedance between the terminology used in the Holpe book and the names Camel chose to give to some components.
In short, having worked on a large real-world project with Camel, I would not choose that technology again. I highly recommend that you choose Spring Integration. I personally trust the Spring Framework.
share|improve this answer
1 
You should be careful to recommend something because you don't like the alternative. Debugging messaging applications is hard, wether or not it is unreasonably hard in Camel compared to SI can only be concluded if you've used both on a large project. I have read the Camel source code. And written some of SI. I'm inclined to believe you're right. –  iwein Sep 25 '13 at 7:22
add comment
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:
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.
share|improve this answer
1 
You do have an abstraction over ThreadPools themselves in SI pollers and task executors from Spring. Nothing is preconfigured for you OOTB in SI though. See the task executor configured here:static.springsource.org/spring-integration/docs/2.1.x/reference/… –  cwash May 17 '12 at 14:40
add comment

1 comment:

megan collins said...

It was a great blog. It had all the required information that was needed for a better understanding of the topic.I'm glad you shared this with us, thanks. Here is a referred link same as yours   oracle soa training