Claus Ibsen

+ Follow
since Apr 01, 2004
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 Claus Ibsen

OpenESB did create a Service Engine to integrate it with Camel

However the SE seems a bit outdated as at the time it was targeted for Camel 1.5.
Today Camel 2.5 will hit the streets.

It would probably be a good idea to try to get that SE updated.

However Camel is just Java code and a set of JAR files. So if you can invoke Java code from OpenESB.
Then you should also be able to integrate it with Camel without that Service Engine.

I would suggest to get in touch with the OpenESB community and ask them to upgrade the Camel component to leverage Camel 2.5.
And if they need any help they can always get in touch with us at Apache Camel.
Camel supports both synchronous and asynchronous messaging.

For example the Camel Jetty component will leverage the continuations feature from Jetty to be able to deliver back a response on the initial HTTP entry point.
Chapter 10 in the Camel book explains this is much more details and has an example it covers to go along.

The CXF-RS and Restlet component is planned to support this as well, when we upgrade to CXF 2.3 and Restlet 2.0 in those components.

Chapter 13 covers 4 scenarios for deploying Camel in
- standalone
- web application in Apache Tomcat as example server (Spring is covered as well)
- J2EE with JBoss as example server
- OSGi with Apache Karaf as example server

But we try not to limit deployment with Camel. So you can deploy Camel in any container you like whether its IBM WebSphere, WebLogic, Glassfish, Google App Engine, Java WebStart etc., Apache ServiceMix 3.x / 4.x, etc.

The Camel website lists all the EIP patterns in Camel

The Camel book covers many of those patterns, but not all of them. We cover all the patterns people normally uses.
And in chapter 8 we have devoted the entire chapter to cover five of the most complex and advanced patterns such as the Aggregator and Splitter.
The Camel mailing list is where you should take technical issues.

This is more general about the book and Camel in general.

Anyway the book talks about running Camel in chapter 13. And it shows how you can start up Camel, let a route run for some time, or let the route be able to stop when it has finished processed X messages.
And chapter 12 talks about an event notifier which allows you to have notifications when certain events occur.

Such as message completed, failed, etc.

So all together you got some features to help you when to call stop on CamelContext.
What context are you talking about?

CamelContext or some Spring stuff?

if you invoke start() on CamelContext then it will start up, initialize all routes, start all routes and then thereafter return from the start() method.

Camel have made inroads into most common business sectors out there.
We have a survey running now and about 25% of the responses are in the finance or insurance industry.

Camel would match in such a scenario. It integrates with Netty, ibatis and hibernate.
And if it doesnt then its just Java code and its easy to create a new Camel component or just integrate directly from Java code.

Camel is a very flexible and light weight integration framework with EIP and routing.

Here is a list of all the EIPs supported

Which means you can use it to route to those different inhouse trading systems.

And it offers a feature called DataFormat you can use to transform data to well known standards

Again if a format is missing you can build you custom.

And Camel is now being integrated out of the box with many other frameworks such as Smooks, Drools, and whatnot. An ever growing list is here

But the important part is that you are given the time to look out and POC the various pieces you find to fulfill you integration jigsaw
Can you elaborate a bit more what you mean with "mangage efficiently"?

request-response flows is the request-reply MEP pattern you can read about here

A reason to pick SI over Camel would be the Spring name.
Personally I doubt the framework would have had a chance if it was not created by Spring.
Hi John

The good thing is that you have choices.
Although you then have to do your assessment.

In terms of JBI, I see that as legacy now. I suggest only to use JBI if you have experience or have existing JBI components you need to leverage.
There is a good blog here about JBI

Apache ServiceMix is an ESB which ships with Camel out of the box. Camel is the light weight routing engine inside ServiceMix.
Apache ServiceMix is the server (it has start/stop scripts etc.). This is a very good fit. ServiceMix allows you to deploy and run your Camel apps.

I suggest to start out with Camel, its often the most easy to get started with. Do some prototyping. Camel is so agile and flexible
that you can run it inside the server you pick. Whether that is ServiceMix, Tomcat, WebSphere etc.

At Camel we have a link collection you can take a look at, some of the links may talk about this topic

In terms of Mule then I am biased towards Camel and will let the Mule people speak for themselves.
However I suggest to listen to the Basement coders podcast about Camel. Link to this is from the link above.
You got some hints what they see being picked out there in real life.

There is also a FAQs at FuseSource which explains more about this
At Apache there is a user story page where end users can add them to the list that they are using Camel

However most people do not do that. Checking the mailing list for emails and googling for blogs etc often reveal well known companies.

At FuseSource ( we have many big enterprise customers which most of them use Camel in some way.
We do have some which uses AMQ only. Or are using SMX 3.x and JBI only.

If you see some of the case stories from FuseSource

You will see some big companies. And if you get in touch with FuseSource (
they will be able to get more references for big customers.

Also from this press release you can read some info about big customers of FuseSource

Some customers do not want to do use cases and white papers. And therefore we cannot public say they are using Camel.

In Denmark the capital region has selected Camel as their choice as integration platform in their health care infrastructure.
It replaces a big vendor proprietary ESB platform.
The Camel book also explains the NotifyBuilder which you can use in testing, in those async integration scenarios.

Then you can use the notify builder to know when X number of messages has been processed or the likes.

The source code for the book is 95% unit tests so there are plenty of testing examples.

Chapter 10 covers asynchronous routing and the source code shows some unit tests with that.
Chapter 6 covers testing and also integration testing.

Integration testing is of course more complex than unit testing as it often involves real live system you test against.

This is a really good question. I am sure I want to come back to this a couple of times with ideas/views on this.

As a side note we are working on the roadmap for Camel 3.0.

This time we want to do shorter development cycle on 3.0, than we did on 2.0. 2.0 took about 11 months to do.
The goal for 3.0 is to have a drop in upgrade for 2.x. While we take on JDK 1.6 as the new min. supported JDK.
And at the same time we do some internal optimizations.

So the next thing we take to the next level could be, besides Camel 3.0:
- support for asynchronous transactions
- OSGi blueprint drop in replacement for Spring DM (work in progress as we got most work done in 2.x)
- Easier OSGi testing (general make using OSGi with Camel easier)
- Persistent state store for doing JMS request/reply (poor mans state engine for simple human flow tasks)

And an area people have asked about before is human work flows, which is an area to take to the next step.
However I believe this work is happening at Apache ServiceMix / Apache Karaf where there are plans to work with
the Activiti project ( and have it integrate with those projects. Camel works well with ServiceMix / Karaf also.

Also the Apache Hise project ( looks interesting and it already integrates out of the box with Camel.
So the human work flow side definitely looks something that we take to the next level with Camel, so you can leverage both.

And if you look at the current survey on Camel, then people are suggesting to improve monitoring and management of Camel.
In that area we would like to expose a REST API which has the same feature set as the current JMX.

Also it would be great with a Camel plugin into the Apache Karaf shell, which then leverages this REST API to fully manage Camel running in Karaf.

And we at FuseSource is working on a GUI tool for Camel. FuseSource Rider. The tool is 100% web based so you only need a web browser to use it.
The tool allows you to visual browse the Camel routes using the EIP icons. The tool is also a designer tool so you can create new routes using it.
Or modify existing etc. We also plan to include a debugger feature so you can debug Camel routes using the visual GUI. So you can add a breakpoint
on an EIP pattern. Then have the tool stop when a message hit that breakpoint. Then you can view the message (alter it if you need) and then single step
the message in the route to see how its being routed. The tool is going to be GA in Q1 2011. And we will post more details at the
FuseSource ( website in the near future.

The Apache Camel PMC launched a survey intended to get a better understanding of how Camel is used,
what the major issues are in getting started with Camel (and even for experienced users) and what improvements
and new features you would like to see in the next releases.

The survey is anonymous and the results will be made public.
Committers will use the survey results to help finalizing the 3.0 roadmap and prioritizing tasks.
The Camel 3.0 release is planned for early Q1 2011.

So please take the survey ( if you didn't already!

Many thanks,
The Apache Camel PMC