Jonathan Anstey

+ Follow
since Sep 10, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonathan Anstey

Congrats to all the winners!

Jeanne, FYI Chuck Lam wrote Hadoop in Action. Camel in Action was written by Claus Ibsen and myself

Twitter: jon_anstey
Author of Camel in Action:

Glad you are already using Apache Camel Questions like this definitely should be posted in the Camel user forum. That way, we can discuss and open up new JIRA issues if needed to address the problems you are seeing.

The quickest way of getting us to fix a problem in Camel is to create a unit test demonstrating the problem and attaching this to a JIRA issue you created. That way, we can quickly try it out and figure out what is wrong. Instructions for doing this are here

Also, if you see an XMPP issue logged in the Camel JIRA, feel free to vote on it. That way, we will know that more people are interested in that particular issue.


I'm glad to have a chance of asking you these questions, as I'm right after quite absorbing lecture about SOA and integration/adoption of some really heavy, big, demanding and very distributed environment. I believe it's a plan for next years. There was listed some options during the lecture for tools to support the apporach. There was a Camel on the list as well. I'm just wondering, which of SOA principles/layers Camel supports for sure, and which it doesn't? If it doesn't any of them, what kind of frameworks/approaches would you recommend to fill the gap and tie it with Camel to have effective SOA - it is OK if you write here: it is in the book? Is domain controlling and business orchestrating coverd by Camel? It probably is, if so, how?

This could be a very long answer as the defintion of what SOA is typically varies based on whom you talk to or what book you are reading Camel is definitely designed from the ground up to be used in SOA style integration projects. It is, after all, all about messaging and SOA is mostly about breaking applications down into services which are accessed using messaging.

One particular thing that Camel does not support out of the box and is typical in enterprise applications is clustering. Camel is just an integration frawework and you will need to do some special set up and deploy it into a container like and ESB or Message broker (ex. ServiceMix & ActiveMQ) that supports clustering to get this.

And last one: What is interesting in your book for guys (let's call them: newbies) working on real SOA?

For new developers, you should definitely read the first part of the book (ch 1 & 2) and then you can dive into accessing various services (JAX-WS web services, JMS providers, DBs, raw TCP, etc) so you can see Camel interacting with real things. Chapter 8 also covers more complex Enterprise Integration Patterns that are very useful when building out integration apps.

Disclaimer: yeah, I'm a Camel guy

Both frameworks are definitely related. They both try and fill the space for a lightweight integration framework that is deployed into something else, like an ESB. They are both not ESBs.

Its hard for me to argue for Spring Integration since I use Camel so much but I have heard from others that a big win for Camel is the number of supported transports and APIs that Camel can talk to. Spring Integration has a much smaller set of connectivity options last time I checked. Also personally, I find Camel DSLs much cleaner and are generally easier to read.

Actually, Camel does provide a Spring Integration component so you can produce and consume from SI endpoints in Camel if you'd like to use both.

Hope this helps!

Camel is the open source integration project at the Apache Software Foundation - Support at Apache is done on a volunteer basis so you are not guaranteed a fix - though we are usually very responsive

FuseSource ( has a distribution of Camel called Fuse Mediation Router. It is the same code as Apache Camel, just that it is supported. What this means is that if you are a customer of FuseSource, you can report bugs or enhancements directly to the team and get them resolved in a timely manner.

Certainly if you have other queries about Fuse, you can ask a question here or in the forums

There are lots of companies using Camel in production today. Probably a lot I *can't* say actually. A few of the ones I am allowed to speak of are listed here (I work for FuseSource).

Also, here are some of the projects/products that are integrating/shipping Camel that I know of:
Apache ServiceMix
Apache ActiveMQ
Apache James
Progress Actional Diagnostics
Open eHealth Integration Platform
Grails Camel Plugin
Play Framework
JBoss Drools


1. My company recently started using Open Message Queue (the Sun implementation of JMS) in its applications. Would we have to switch to ActiveMQ to use the Camel framework?

No, you can use the JMS component to connect to any JMS provider.

Chapter 7 contains more information on how to use the JMS component (also a short intro to JMS is in chapter 2).

2. I was looking into Camel a few weeks ago, and downloaded the install file. It seemed (from the size of the download) to be a huge install. My first impression was that it would be heavyweight to run, sucking up lots of CPU cycles. Is this the case?

The core of Camel is only about 1.5MB. Other than that you only need a few more jars to run Camel. See

The distribution size comes from all the components. You will not need to load all these components into memory unless you are connecting to all the 70+ types of things Camel can connect to. That is pretty unlikely

3. How steep is the learning curve for Camel?

We have found that users have an easy time learning Camel for the most part given its expressive and natural to read DSL (it almost reads as it does). That said, knowing something about Java , Spring and also Apache Maven would help you starting out a lot.


Could you comment briefly on what this is and does, beyond the obvious?
Is it intended to be essentially Camel-centric, or a more generic enhancement / replacement for such tools as junit?

The testing functionality in Camel is still used for creating JUnit tests - so it is not replacing JUnit. It started out mainly for testing Camel applications themselves but can also be used as a test driver for other applications. It has components for receiving and checking to make sure that certain conditions are met in the message (mock & test components). It also has a dataset component useful for generating large amounts of data for load testing.

Testing is covered extensively in chapter 6 and you can also find more information at

Is it intended as a primary vehicle for verifying enhancements / user-created plugins to Camel?

Yeah, you should use the camel-test module for testing Camel applications and/or extensions.

Does it include routines suitable for measuring (or optimizing :P) Camel code performance and/or scalability?

The dataset component is useful for testing how load affects a Camel application (you can see MPS) but certainly you'd have to resort to traditional monitoring & profiling tools to dig deeper.

Camel was mainly designed for use in integartion projects - places where you need to route, transform, enrich, etc messages over different types of transports. It has grown into a very useful tool for doing any kind of messaging really. So if you project needs to send messages of any kind (see list of possibilities here, you should consider using Camel for that rather than coding it yourself.

The book's examples are all hosted in this Google Code project:

But for context and the story behind these examples, you'll need the book of course.