A year after v2.1 had been released, Spring Integration v2.2 is out with 3 new components MondoDB, Redis and JPA (even though the first 2 were listed also in v2.1 as message store, now they are available as Inbound and Outbound Channel Adapters), retry and other new features. As a comparison Apache Camel has also released v2.10 during the same period with around 18 new components. JPA support in Camel is available from long time, MongoDB since v2.10 and Redis since my commit couple of days ago. But of course the number of connectors (more than 130 for Camel) is not the most important characteristic for an integration framework (some might argue that). There are many other factors which matter when choosing an open source project for your needs. A quick search on the internet will show you which are the main questions you should ask before deciding which open source project to use
for your enterprise. Here are only couple of them and my biased answers:
1. What is the license? – Apache Camel (like all Apache projects) and Spring Integration both are using Apache License version 2.0 which is one of the most permissive licences. It basically says do whatever you want with the software.
2. Is the project actively developed? – According to ohloh.net for the last 12 months Apache Camel has 2415 commits from 24 committers whereas Spring Integration has 949 commits from 17 committers.
3. How mature is the project? – Both projects have started in 2007 and currently Spring Integration has 234K lines of code and is estimated to 60 years of effort, whereas Apache Camel has 800K lines of code and estimated to 220 years of effort.
4. How big and responsive is the community? – If you are creating a project different than ‘Hello World’, no matter how many books and tutorials there are, sooner or later you will have questions. And this is another area where Camel shines. According to Apache stats, Camel users and developers lists have around 700 subscribers combined who send 45 messages per day in total on average. If you ask a question, the chances are, you will get a response in a matter of minutes. On Spring Integration forums there are 24,355 messages since the start of the project, which on average means 13 messages a day.
5. How long it takes to fix a bug? – Personally for me this is a very important metric about open source projects. Imagine you found a bug in the project, a small bug that makes your day miserable. Then you go the extra mile to fix it, prove it with tests, submit a patch, describe it on the project forum/mailing list, but it never gets reviewed or included in the next release… Looking at the reported/resolved issues ratio for the last 30 days, as of mid January, Camel has resolved 80 out of 90 reported issues, whereas SI resolved 3 out of 19. But I strongly believe this is due to recent holiday season and the graph below will look better for SI later in the year.
6. How good is the documentation? – Both projects have quite extensive documentation, tutorials and plenty of blog posts. There are 3 books published covering Spring Integration – having read all of them, I can say more or less they talk about EIPs and repeat Spring Integration documentation but with better graphics. Camel for now has only one book published – Camel in Action by Claus Ibsen and Jonathan Anstey. There are aslo plenty of blog posts, tutorials and webinars for both projects out there. There is one thing that Spring Integration is missing though – CamelOne conference
7. Is there good tool support? – SpringSource develops Eclipse based Spring Tool Suite(STS) which has visual development tools for SI. IntelliJ IDEA also has SI support, but that is limitted to autocompliting varios endpoint options.
The most popular tool for developing Camel routes is Fuse IDE from FuseSource, which is also Eclipse based tool. There is also another Eclipse based graphical tool for Camel – Talend ESB
8. Can I get a commercial support if I need it? – If you have more money than time, both projects have companies offering commercial support. This is useful when you don’t have much time to spent for asking questions on the mailing lists or browsing the source code. There are also plenty of independent consultants you can reach through the mailing lists. These are only some of the questions you should ask yourself before adding one or the other dependency to your product. The more specific questions you should ask depends on your product portfolio, project stack, team abilities and motivation to learn new technologies.
Disclaimer: I’m Apache Camel committer and I absolutely adore Camel. I’ve also worked on projects where we chose Spring Integration over Apache Camel.
Reference: Spring Integration – Apache Camel comparison from our JCG partner Bilgin Ibryam at the OFBIZian blog.
“How big and responsive is the community?” diagrams isn’t correct. See X and Y axis…
If you want to more (near) real things:
https://sonar.springsource.org/dashboard/index/org.springframework.integration:spring-integration
https://analysis.apache.org/dashboard/index/org.apache.camel:camel
See:Unit test coverage and success, Violation and Blocker( both zero ), Critical, and Major issues numbers.
2013-07-02:
Spring Integration critical bugs: 66
Apache Camel critical bugs: 535 (!)
Spring Integration critical major: 802
Apache Camel critical major: 5441 (!)
Sum:
Spring Integration bugs: 1353
Apache Camel bugs: 7133
The sonar reports doesn’t looks to be a fair comparison. Sonar is oriented to guide you in a single specific project, so you can see the quality changing over the time and tackle the issues that haunts you. The quality profiles are different (see the amount of rules enabled) and in my point of view consider “Empty If Stmt” as critical violations sounds very stupid. Don’t get me wrong, I love sonar and I use it a lot. But the default rules could be a little noisy. The coverage doesn’t explicit means anything. The code coverage of a project is… Read more »