If you are just getting started with Apache Camel, hopefully this post will save you a day or two.

If you are unfamiliar with Apache Camel or one of the other EIP platforms, this EIP thing might be something you would wish to get your head around sooner than later. You really don't want to be coding this kind of work via the NIH pattern.

Fair Warning: I only have a month of full time work with Apache Camel, but I learned enough to offer a solid boost to any Apache Camel novice.

Camel Setups

Camel can run in complex containers and app servers. Fabric8, Karaf, and more. it’s easy to get distracted by this advanced capability. I did get distracted by this. Not recommended.
 
Instead, once I got my workspace and Camel project template set up to run straight Camel in the plain JVM and/or IDE, those distractions went away. Working on the first routes is straightforward. Worry about the advanced environments later.
 

Resources

I explored a lot of resources, but Claus Ibsen’s Camel in Action book remained the best, or at least that was my opinion in January 2014.
 
The Camel email list is also unusually well supported for an open source project. It's site is also quite helpful, again comparing this to other open source sites. The StackOverflow community also finds Camel well supported.
 
I've never used Red Hat support, but others in our java user’s group report tremendous success with Red Hat commercial training and support. Fuse is Red Hat's commercially supported Camel product, and every indication is that the lion's share of Apache Camel's development funding comes from them, as well.
 
You may also find that the Enterprise Integration Patterns book has to be on your bookshelf, like I did, though I rarely read more than a few pages at a time. Dense.
 
If you’re going all pro, something you might do after you get past the novice stage, don’t hesitate to call an advanced shop such as Matt Pavlovich at mediadriver.com. Enterprise server clusters maintaining thousands of routes are not uncommon, and this territory is the province of the pros. I blog about other aspects of this a bit more here
 

High Level First

Your first big challenge might be understanding Camel at a high level. This is because “any to any” is kind of a weird abstraction, for developers like me, who are accustomed to connecting two things together at a time, with a very focused, and concrete API - one API just for that specific use case. You’ll want to allow some space to let this more generic approach soak in, and then when it happens, you might wonder why it wasn’t instantaneous - it all seems so natural.
 

Runtime Failure During Development

If you’re accustomed to a language like Java where failure can be seen in the IDE at compile time, even before you even run things, Camel might be like moving to a dynamic runtime language, and just as nerve wracking. Run. Check [logs or tests or console or …]. Run. Check [logs or tests or console or…] etc. The trick here is to set your environment up where this doesn’t slow you down too much. If you work with dynamic languages and nothing more than a text editor, you already know how to do that. It took some adjustment, for me.
 
Endpoint A and Endpoint B might be connected in a route together, but it might take a little experimentation to see exactly how - semantically. If you’ve ever used Perl or regular expressions, and found it challenging how the subtlest syntax screw ups lead you astray - you might find that same thing true in Camel at times. No big deal, just that you need to allow for time for it.
 
The reason for this is simpler than you might guess - with 150 components and written by a wide array of people from a wide array of backgrounds, it is easy to understand such subtleties in a slightly different way. One person might expect a required slash before the directory as natural, another not. Little things like that can make you think you’re on the wrong track when really you’ve just about got it there. Maybe that’s not the best example, but it gives you an idea.
 

WOW! Lots of Moving Parts

When we use normal code to connect functions through APIs, we think it as quite natural to have lots of configuration, arguments, similar contextual details. In Camel, things are so easy, you start expecting that it will magically bypass some of these same requirements! It typically does. But of course, there are some that require set up configuration, and when that happens you need to learn the very specific way that each component designer takes in arguments and configuration. Mostly it’s pretty consistent, but that just makes it more surprising when it’s not. Nor will strong typing and IDE typeahead support come in and save you. 
 
And with 150 components, of course some of it is documented better than others.
 
One of the biggest challenges I had personally was trying to account for things that Camel would just do automagically for me. Implicit actions are wonderful if you know that they are being done for you, but more of a challenge if you are still looking for a way to make them happen explicitly. "Oh, I see. I don't have to worry about that." Look for the examples to guide you through. Experienced Camelists might be of no use to you in this regard, because they have already internalized the expectations, and have forgotten what they already know.
 

It Works, But Sometimes Not As Expected

Apache Camel does work! Fantastically! Just not always in the way we might expect.

Back to those 150 Camel components - most were probably contributed by some guy that needed that particular one. So you go to use it, and you might have a use case that is similar, but not identical.
 
For example, I ran into some SSH and SCP use cases that were different than what is provided for, and it took me a couple of days to learn that was I was trying to do something that wasn’t supported. I switched my code to run in a different way, abandoned one of the optional platforms that i was trying to deploy to, and presto! Everything works fine.
 
Do allow for some time for this kind of situation. Having other work to do while waiting on the email list is often a good strategy.
 

Semantic/Syntactical Sugar

So many great language and DSL options to write your routes in! Each of course has it’s advantages and disadvantages, this is TMI for this blog.
 
You have to wonder though, how they came up with a design that is so flexible that it accommodated so many entry points with apparent ease.
 

OSGi

A curse and a boon, OSGi is easy for some of us and, well, impossibly difficult for others, as you will find blogged about all over the web. I write more about that in this blog, but the bottom line is that the benefit that it offers your work in Camel is nothing short of earth shattering - that is, if you are accustomed to the challenges of binary hell in a large and diverse organization.
 
Build thousands of routes with hundreds of competing binaries and stick them all in the same container. And don’t even worry about them. They will all work. That’s a pretty cool deal.
 
The trick I found is to get one simple boilerplate maven project to compile it’s binary as an OSGi jar, using the Felix Maven Bundle Plugin. Once you have this done, just use that setup for all subsequent projects, and you can always remain OSGi complaint, even if you never have to deploy to an OSGi container. 
 
 

Summary: You'll Never Go Back

Even if your first few days with Camel are challenging - and they may not be - you’ll probably want to know how so many people re-invented framework after framework for decades - myself included - to attack a problem that Camel seems to do so effortlessly.