Here’s my current use case:

  1. Receive a message on a queue
  2. Save the body of the message to a file, where the name is determined by a header value

Easy enough, right? Agreed. But to get something solid and reliable, you’re going to do a lot of plumbing:

  • Setup a message listener that recovers from disconnects
  • Make sure all message consumption is transacted
  • Apply some sort of retry mechanism
  • Put messages you can’t read or deal with onto a deal letter queue
  • Handle all io locking issues that can arise

Enter Camel: With a bit of XML configuration and a simple RouteBuilder class, I can do most of this work in a few simple lines.

Obviously, having read the EIP book will help, but the documentation is stellar. You get examples for all the different patterns, as well as some amazing documentation for all components.

That being said, the full power of Camel (for this guy, and at this moment in time) comes from:

  • How easy it is to add different steps in your route, without breaking anything else.
  • Testability
  • The amount of components you can route from and to.
  • Spring integration
  • Component

In my above use case, I already know that the messages will eventually need to be aggregated before getting writen to file. Check. I already know that eventually, I won’t be writing to file, but most likely to FTP. Check. I won’t have much to do short of changing a bit of code in my route, recompile, re-test and voila, all done!

(I’ve always said — ok, for the last few years — that a good senior programmer knows how to find the tools, api’s and frameworks to make his job easier, but more importantly, allow him/her to concentrate on the core buisness code. This is an example of that.)