One of the challenges I have is in sorting out all the integration options. For example, Apache Camel describes itself as integrating very well with Spring. If embarking on a greenfield integration solution (i.e., Camel is not already in place), what questions should I be asking to help determine the best path to take? In other words, what advantages does Spring Integration provide over something like Camel?
Hi, without confusing the answer too much could we expand this to just not Camel but other options such as Mule? From a design standpoint, Spring Integration and Mule seem very similar. Not sure where Camel fits into this.
Sorry to jump in on your question Steve, if this does not fit I could start a new thread, but it seemed to be very similar to the question I was going to ask.
We actually have a chapter on some the alternative technologies such as Mule, ServiceMix, OpenESB, and J2EE. Questions I would ask are about ease of use, maintainability, and extensibility. I have found Spring Integration to be one of the most intuitive approaches. Interestingly, Camel, Mule, and ServiceMix all support Spring as a component model.
Camel, Mule, ServiceMix all support Spring, but none can hope to provide the same experience as Spring Integration, as it's developed by the same people who built Spring itself.
Of all the projects mentioned, the only one I would consider even remotely simialar to Spring Integration is Camel - the others are essentially top heavy servers. Spring Integration and Camel are APIs that make servers irrelevant. Spring Integration, specifically, is a framework that provides leading integration with Spring. The development moves fast, but the Spring Integration project tends to hold itself to a higher bar for quality of implementations. If it's not clean, and built in keeping with Spring standards, it doesn't get shipped. Spring Integration provides a POJO centric model for business logic, letting you provide a clean, natural mapping for your integration flows in the XML definition. It features an almost 1:1 mapping to the Patterns of Enterprise Application Integration book, where key concepts in the book enjoy a simialar priority in the API. For example, a channel is a top level API concept that you'll deal with in almost everything, just as the book encourages. Camel, on the other hand, does not have as natural an API. And, frankly, it has some very clumsy API elements that - I think - speaks to its sort of urban sprawl approach to API design. Spring Integration, for example, has no <try><catch> blocks in its XML!
Thanks, Josh Long
Spring Developer Advocate, SpringSource, a division of VMware
http://blog.springsource.org - http://www.joshlong.com
The best PRO of Spring Integration is its very good integration in the Spring environment :-) IMO this is also the only PRO compared to Camel.
Camel offers several different DSLs, you can use Java, Groovy, Scala or Spring XML. I prefer the programming DSLs instead of XML, but that is a matter of taste. Another advantage of Camel is the numerous number of components (over 100 already, including modern cloud interfaces such as Amazon Web Services or Google App Engine).
Thus, I would use Spring Integration in a Spring project where everything else is Spring stuff (if all required components are available such as HTTP, JMS, and so on), and I would use Camel in all other projects.
As already mentioned in the last post, it does not make sense to compare Apache Camel or Spring Integration to Mule, ServiceMix, et al. If you are not aware of the differences between an integration framework and an Enterprise Service Bus, you maybe should read my blog post about exactly this question: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/