New Camel example to compare with Spring Integration simple example

One of the blogs I follow is from Gunnar Hillert, whom back in 2009 discovered Camel and wrote a nice blog entry. He also did some investigation of Camel alternatives as well. One of the alternatives is Spring Integration. Gunnar have since joined VMWare to be part of the Spring team.

So this morning I read the new blog post by Gunnar, how to create a Spring Integration project in STS tooling, which is posted here. The STS creates a simple out of the box example, that provides the following XML (in screenshot) as the main logic. Take a moment to see if you can figure out what it does. And then compare to the equivalent Camel example below.

Spring Integration - Simple Example created by STS tooling
And here is the Camel example using XML as well:

Apache Camel - The same example as above
Having both screenshots, I guess you can figure out that the example:

  1. reads input from the console
  2. upper case the input
  3. and prints it back on the console

This example will be provided out of the box in the upcoming Apache Camel 2.10, in the examples/camel-example-console directory. You can see the source code here.

You can run it from command line using Maven
mvn compile exec:java

And then press ctrl + c to stop the application.

Running the Camel example from command line
Or you can run it from within your IDE of choice, such as IDEA / Eclipse / FuseIDE by running the CamelConsoleMain class. For example as the screenshot shows below from IDEA.
Running the example from your editor such as IDEA

To create a new Camel project you can use the Camel Maven archetypes. Or use Fuse IDE which has a wizard just like STS to create a new Camel project.

A few notes about Camel. The example uses Spring and XML, however Camel can be used without Spring at all. We could use pure Java and define the Camel route in a Java class. You can also use Scala. And for XML we could also have used OSGi Blueprint.

In the example we use the built-in Simple language to upper case the input. You can chose to use more powerful dynamic languages such as Groovy, OGNL, Mvel, JavaScript etc as well.

With Camel you simply have more choices, and dont have to use XML at all.


Claus Ibsen said...

Hi just a test if I can comment myself. Seems there may be a comment issue on this blogger now.

Anonymous said...

Just trying as anonym to post a comment

Mark Fisher said...


To establish some context here, that template's configuration was designed to serve as a starting point for a certain type of app where the gateway and service-activator would be useful. It's purpose is not to provide an example of the most concise way to echo uppercase to the console - it just happened to use that as the stub implementation.

The most concise way to echo uppercase in Spring Integration would be:

<stdio:inbound-channel-adapter id="echo"/>
<int:logging-channel-adapter channel="echo" expression="payload.toUpperCase()"/>

So, that's quite concise. That said, these debates over the difference of a handful of lines of configuration are just a distraction in my opinion. What we hear from developers who choose Spring Integration is that they do so for the accuracy of its representation of EIP, the depth of its functionality and its proven reliability as an extension of the Spring Framework. Meanwhile, you seem more concerned about the fact that you are distancing yourself from Spring. That's fine, but please don't post blogs that intentionally take our examples out of context.


Claus Ibsen said...


The SI project was said to be a, using Gunners own words "... a very basic Spring Integration flow".
For comparison I wanted to see how a similar Camel example could be created (which turned out to be less lines of code).

Likewise I wanted to show how to run the example, not only from an IDE, but also from a command line using Maven.
The blog post by Gunnar didn't talk about how to run the project outside STS.

Likewise I wanted to show that Camel also offers IDE integration with a wizard to setup a new project. For that Camel uses Maven Archetypes, which the popular IDEs of today integrates out of the box with. Gunnar didn't mention in his blog, whether SI supports maven archetypes, or the project create wizard is an exclusive functionality of STS only.

All in all I wanted to see how you could do what Gunnar did but using Apache Camel instead. Which was my intent with the blog post.
I should have named the title of the blog post something else. I guess the DZone people thought so and named the post something about SI vs Camel project creation. Now before you blame me for getting the blog posted on DZone, then I am not in charge of that. I am on the DZone blogger program, and therefore DZone can pick and chose from my blog posts, and redistribute them as they see fit.

Gunnar Hillert said...

Hi Claus,

As Mark noted, the simple template which I created last year is not targeted for utmost conciseness. The goal is to provide a starting point for users who will most likely be new to Spring Integration. Therefore, I believe it is better to provide a template that is more explicit (slightly more verbose) in order to give new users a better understanding of what is going on.

Also, the SpringSource Tool Suite (STS) templates will generate Maven projects by default. Thus, the resulting projects can not only be executed from within STS, but also via the command-line by simply executing:

$ mvn exec:java

For creating template projects through Maven, I am working on Maven archetype support as well. I hope to have that available very soon. However, we already have an initial version providing template support for Gradle [1]. Ultimately we will have templating support for STS, Maven and Gradle.

I found your statement "With Camel you simply have more choices, and dont have to use XML at all." a bit unfair. We do have Scala[2] and Groovy[3] DSLs being developed for Spring Integration. And in regards to IDE support, Spring Integration is not only supported via STS, but IntelliJ IDEA also provides good Spring Integration support [4].

Furthermore, as far as I know Fuse IDE is not an open and free product. STS on the other hand (including Spring Integration support) will be completely open sourced under the EPL license for the STS 3.0 final release this summer. I hope this provides a bit more context. With Spring Integration you do indeed have choices.

[1] https://github.com/SpringSource/spring-integration-templates/tree/master/si-gradle-plugin
[2] https://github.com/SpringSource/spring-integration-scala
[3] https://github.com/dturanski/spring-integration-groovy-dsl
[4] http://blogs.jetbrains.com/idea/2011/12/intellij-idea-for-spring-integration-20-patterns/

Claus Ibsen said...


Its a bit annoying you post the same comment in multiple places, and not keeping the conversation in one place!

I just wanted to make a quick comment about Fuse IDE. Its a *free* tool, that anybody can download and use as much they want.

Fuse IDE is more than a just Camel editor, and we have included a number of exclusive functionality which we only offer to our subscribers. A trial license can be obtained if you want to try these extra features if you want.

Michał M. said...

Actually the Spring example is more readable and easier to grasp even though it's little longer.

Camels configuration, on the other hand, looks like spaghetti of DSLs thrown without much thought.

PS: I'm not affiliated with any of those projects. And in fact haven't used either in a production environment.

Claus Ibsen said...

Thanks Michael, for your insightful comment.

I think you are being rude to the Camel community by saying there is no thought behind its DSL.

That said, any programming language can be abused and turn code into harder to read situations. As the Camel DSL is elaborate and we do not have an upper cap on how many EIPs you can use, then people can create very long routes, that is harder to read. That is just like any functions in Java etc, that ought to be splitted up into more and smaller functions. The same best practice is advised for the Camel routes. Yes I have seen some examples from people doing this. And my advice has been to split their Camel route into smaller and multiple routes. And link them together using direct/seda endpoints etc.

Likewise for Spring XML files can become very big. And it can be a good idea to split into multiple XML files etc.

However we dont hear from people getting onboard Camel that the DSL has no though behind it. In fact its often the opposite. That the DSL is easy to grasp and get started with. And you can grow as you learn. Eg learn about new EIPs and take onboard them in the DSL.

And people run Camel applications in production that has a few lines of DSL. And its very powerful, such as the FAA giving examples in their CamelOne presentation this year.

There is screenshots from their powerpoint presentations from a previous blog of mine. Link is here: http://www.davsclaus.com/2012/06/camelone-2012-videos-freely-available.html

Anyway as we love feedback, then anyone who has opinions about the project or the DSL etc. Is very welcome to get in touch with the community at our official channels such as the Camel user mailing list. There is links to this at the Camel website.


Michał M. said...

I'm sorry for sounding rude, Claus. It wasn't my intention.

I'm judging from those two examples alone. Try to distance yourself and look at it with unbiased mind.

There are at least 3 types of DSLs in this short example on different levels - XML, URI attribute (with own DSL - strings separated by colons and question marks) and finally there's Expression Language in as well.

Maybe it's my personal taste speaking here, I don't know.