Saturday, October 17, 2009

Apache Camel Alternatives

In part one of my mini series I provided a quick introduction to Apache Camel and in part two, I continued with a simple example illustrating the very basics to get you started (which I extended a bit in part three)

In this posting, I would like to talk about some of the alternatives that I see might be interesting for you to investigate, when considering an open-source enterprise integration framework. Hereby however, things always get a bit fuzzy in my opinion, depending on your business requirements.

On one side, you want to have components which allow you to communicate with other services, but on the other side you also want to have some sort of workflow-capabilities in order to orchestrate your business processes. Furthermore, you may be interested in monitoring and reporting functionality.  From a different view-angle, you may desire a higher-level solution versus a solution that embeds easily into existing code using plain Java APIs. The list could probably be expanded considerably, but I hope you get the picture.

Ergo, depending on your specific business requirements, the following list of frameworks may or may not provide a better choice compared to Apache Camel:    
  • Spring Integration
  • Spring Batch
  • JBPM
  • nexusBPM
  • Drools
  • Hadoop/Cascading
  • Full ESBs such as Service Mix, Mule ESB, OpenESB, JBossESB
Actually, in my opinion the closest alternative to Apache Camel is Spring Integration.

Spring Integration

Before I was even aware of Apache Camel, I learned about Spring Integration at the No Fluff Just Stuff (NFJS) Java conference one year ago. Back then I thought that Spring Integration was the best thing since Nutella. Then a little later I learned about Apache Camel and tried to figure which one to take for a spin. As it turns out, comparative information on Google is rather sparse:
Interestingly, Apache Camel provides a component that allows you to integrate Apache Camel with Spring Integration.

To me a good argument for Apache Camel was the greater availability of components compared to Spring Integration, as well as its adoption by other frameworks such as ActiveMQ and ServiceMix

Spring Batch

If your business requirement is to process large amounts of data, you may also want to look at Spring Batch which is specifically designed for batch processing requirements. There are some pointers on the Spring Batch website for integrating it with Spring Integration. I considered it for one of my past projects, but unfortunately I do not have massively deep experience with it as we ultimately chose JBoss jBPM.


In my opinion another option worth considering is jBPM from JBoss. I used it in one of my past projects. Integrating it back then with Spring was certainly a  bit tricky (especially asynchronous execution of Nodes), but it is doable. Interestingly, starting with version 4.0, JBPM provides native Spring integration. Unfortunately, I did not have any opportunity, yet, to try out JBPM 4.0.  JBPM is certainly much heavier compared to Apache Camel or Spring Integration. I would say that its focus is also slightly a different one. While it provides support for human task management during workflow executions, managing the state of your workflow nodes etc., it totally looses out compared to the available components, which are provided by Apache Camel.


A little bit jBPM on steroids is nexusBPM (An older blog post of mine about it is here). Developed by Intercontinental Hotels Group here in Atlanta, it is open-sourced at Sourceforge and provides a set of useful components in addition to the original JBpm distribution.


You probably would not necessarily think of Drools being a Workflow solution but what originally started out as a rules engine seems to venture increasingly into other areas as well. In fact, at least from a 30k foot view, it pretty much provides similar functionality as JBPM (Workflow, human task management etc.) and also provides a few components such as FTP, mail, executing system commands, etc.

What kind of baffles me is the fact that JBoss is maintaining 2 very similar products...

Cascading and Hadoop

If you need to process large amounts of file-based data, then Cascading might also be an interesting alternative. Cascading uses MapReduce to handle chunks of data. Interestingly, you can also use it for creating workflows. Not too long ago I attended an interesting presentation on that subject at AJUG. The presentation can be found here.

ESB like ServiceMix, Mule, OpenESB

Last in my list of alternative frameworks to Apache Camel is an entire category of solutions: Enterprise Service Buses (ESB). Enterprise Service Buses are basically stand-alone products, and as such, have a much heavier foot-print than for example Apache Camel which is basically just a set of light-weight Java APIs. In fact Apache Service Mix 4.0 is using Apache Camel under the hood in order to provide message routing. Besides Apache ServiceMix, you may also look into these OSS products:
This concludes my VERY high-level overview of frameworks/products that allow you to implement worklow and/or enterprise integration-based solutions. This whole subject could easily be extended into a more comprehensive article. Nevertheless, I hope I was able (within the limits of a blog post) to provide you with some good starting points.

¡Hasta la próxima!


domix said...

Excelent post, congrats man. I think that Spring Integration is several light years behind in documentation, components, Camel is stronger.

Saludos desde la Ciudad de México

Unknown said...

thanks for the informative blog post. it is indeed hard to find a comparison like the one you posted. I wonder how Spring Integration 2 will stack up against Camel. BTW, Groovy + Camel is AWESOME.

Unknown said...

I would add smooks to the list. Smooks to JBossESB is the same as Camel to ServiceMix.

Claus Ibsen said...

Great list. I have added it to the Camel articles web page so people can find it in the future.

I guess Apache Synapse is also in the integration world.

Mark Fisher said...

Nice posts Gunnar. It's good to see objective comparisons and the recognition that different frameworks may appeal to people and their projects for different reasons. It is true that Spring Integration doesn't have as many adapters, but the number of adapters has not been our focus, so I'll point out a couple things that do relate to our goals.

I think one key difference between Spring Integration and Camel is in the programming model. I tend to view it as component-centric (SI) vs. route-centric (Camel) where "components" are the Message Channels and Message Endpoints themselves. Our goal has been to maintain a clean separation between code and configuration, while recognizing that some components belong in code (e.g. POJO services) and others belong in configuration (e.g. File poller).

Another key difference is in the extent to which we build on the Spring Framework and collaborate with other Spring projects (Security, WS, Batch, DM, Spring/BlazeDS). One thing you may notice is that we're already supporting Spring 3 features, such as the new TaskScheduler abstraction and SpEL, in our 2.0 milestones.

Gunnar Hillert said...

Thanks Claus for the feedback. Interestingly I have never heard of Apache Synapse but I added it to the list. Just doing a quick read about it, it sounds like it is somewhat between ServiceMix and Camel in terms of functionality.

Gunnar Hillert said...

Hi Anton,

Thanks for the comment.
Smooks ( looks interesting but I always regarded it more as a transformation component, although it seems to have some routing capabilities (Need to look at it as time permits...).

Camel actually provides a component that uses Smooks for parsing EDI data (

Anyway, message transformation (Particular non-XML data e.g. EDI) always seemed a bit under-represented in the OSS world and Smooks appears to be the only serious contender.

Gunnar Hillert said...

Hi Mark,

Thanks for your clarifications! I highly appreciate it. As time permits I plan on taking a closer look at Spring Integration. As I do my explorations basically in my spare time, I haven't had the time, just yet.

breun said...

"To me a good argument for Apache Camel was (...) its adoption by other frameworks such as ActiveMQ and ServiceMix."

While I agree Apache Camel is great, I don't think that is a very good argument, since Camel, ActiveMQ and ServiceMix are all backed by the same company: FUSE.

Claus Ibsen said...

I was told by a reviewer for my book - Camel in Action that there is another integration project called Open Adaptor -

Kai Wähner said...

I just wrote an article, which explains my experiences with Apache Camel and its alternatives Spring Integration and Mule ESB:

Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

Best regards,
Kai Wähner (Twitter: @KaiWaehner)

Anonymous said...

HI Gunnar,

Could you please explain me , about which ESB based on which,

means wso2esb based on apache esb..
like, mule,fuse,jboss,opensource esb based on which...

David Wilson said...

I understand that Drools is Open Source and JESS is not, but how do they compare in other areas like ease of use, performance, level of integration with your code?

Gabriel said...

I don't think you can compare Camel to any BPM framework, or even an ESB. Apache Camel is an integration framework, so, you can only compare it to frameworks like it, such as Spring Framework. MuleESB is far different from Camel or any integration frameworks. Also, I don't need to say about jBPM or any other BPM framework. By the way, you can use Camel along with a BPM framework, like jBPM or Activiti, that makes more sense than compare several technologies with very different focuses.

mule esb enterprise said...

Nice blog !! but I have got one doubt that how can we compare drools and JESS in the other areas. Please explain regarding that. Other part you did an excellent job and also given the amazing explanation regarding Spring integration.