Bare Bones MicroServices Camel

Photo by Dakota Corbin on Unsplash


The purpose of this article is to help you get through some very quick and concise examples of microservices using Camel.
This might also be called a “bare bones” approach.

Before we start, I’ll try to clarify some potential confusion.
This may take more time than reviewing the code itself 🙁
Skip through, accordingly. The meat is in the bottom half.

Micro Service, Maximum Confusion:

Microservices are best characterized by what they are not. Which leads to confusion, because a microservice which is not anything, also fails to exist. So it has to be something. Stay with me here.

As soon as a microservice becomes something, the arguments begin. “I’ll use REST,” so someone blogs “Microservices suck because REST sucks.” Then you have to explain to the hater that microservices don’t require REST, which may only confuse him, because most, in fact, may use REST APIs. And so on, through every decision point. Exhausting.

It was tempting to name this blog “Haters Guide to Camel Microservices” but that would only serve my own frustrations with the human side of this puzzle.

Microservices Defined In This Context

In this context, I will approach microservices as an attempt to eliminate the ball and chain of required infrastructure. No hosting Tomcat or service bus … or …. whatever might be getting your dander up. It can be a long list. Every technology has it’s own haters. Go to any conference. Embarrassing, at least for the technology agnostic.

The approach here will be to eliminate everything possible – the bare bones approach – because that makes Camel microservices easiest to learn.  This is actually a big win, because it is easier to learn how to add stuff back in, than learn what can be taken away after it is added. Or, so it was for me.

Next, a Spring Boot project will make up the second service. By adding the absolute minimum Camel code to this, you will quickly see the delta. Not much to see.

Debating Society Disclaimer

Given the impressive debating society around all things microservices… Please do not use these two projects as part of this debate.  These example projects are learning tools only, and have no merit, other than a place to pick up how to information quickly.

Why So Difficult To Find a Bare Bones Example?

The last piece of confusion to resolve is this:
If Camel requires nothing more than a bare bones setup, why is there almost no prominent online example of same? Excepting for unit test projects, which might only confuse the novice? Even Claus Isben’s own Spring Boot Example seems to include layers of opinionated infrastructure, which can obfuscate how bare bones a Camel service might be.

You won’t have to think hard to answer this question. No one really believes you would ever want to deploy a bare bones service. “You’re at least going to need this and this and this.” Great for teaching this and this and this, not so great for learning the essential minimum.

About the Routes

All routes in this set of examples try to do as little as possible, other than prove that they are running.

It is assumed that you would  or have learned about Camel routes elsewhere, and would insert your desired routes herein. One such modification would be to provide a serviceable camel endpoint such as REST or file or jms or  … which neither of these services has 🙂

Two of Quadzillion Deployment Methods Provided For:

So many options! But not here. I run both projects with either of

  1. Shell script (java -jar etc)
  2. Dockerfile

What is not included? It is assumed that the reader either has his favorite microservice vendor – i.e. AWS – or he is being assaulted daily by many vendors who would like to be his favorite. Nearly any could such platform could be consumed, with 1 or 2 above, and a little extra account metadata.

Each project renames the jar which maven produces to make it easier to point the shell script or Dockerfile. This is done using <finalname> in the pom.xml.

Series Advertisement: Jammazwan

“Jammazwan” is Hindi for “camel keeper”.
This blog is part of that series.

Me, a jammazwan? another Camel Keeper: TL DR?     about:
pete jammazwanPhotoSmall jamzVid1

If you are impatient or in a hurry, the 2 minute video might explain Jammazwan in the shortest amount of time.

Bare Bones Camel MicroService:

Github: BareBonesCamelMicroService

Little more than a main and a route. Just to show you how skinny it can get. Too skinny to be representative of a real service.


This is pretty much the only code in the project. Of these 24 lines, only 3 make this a Camel microservice:

Main main = new Main();
main.addRouteBuilder(new MyRoutes());;

The rest of this code is just imports, a main(), and the RouteBuilder with a 1 line route, which you would expect in anything Camel, microservice or not.

Note that I also had to add the maven-shade-plugin to the pom.
I left some sample shell scripts to launch it as either a  straight jar, or a docker image. Adjust scripts as needed to match your own file placements.

Other than that, the project is nearly empty. And now you know how to create the skinniest microservice imaginable.

Note also that no port is exposed in the Dockerfile, as this service has no endpoints.

Bare Bones, except adding Spring Boot

Github: SpringBootBareBonesCamelMicroService

What would be the absolute minimum number of steps required to use Spring Boot as it comes right out of the box?
This project answers that question.

Here’s a screenshot of how I generated it. Spring makes useable for anyone to use:


So far, no camel code whatsoever, other than naming a dependency in the pom.xml (lower right). A 30 second operation, start to finish.

Look below, and you’ll see exactly what was added after downloading. Notice that the three highlighted lines are literally same as those in the BareBones example above. The route is the same, and the primary difference is the different wrapper to run those three lines from above, only in the boot application.


As with the previous project, the jar name was adjusted in the pom, and shell scripts and Dockerfile were added for deployment/running.

I’m hoping by now you would agree, there isn’t that much work to a Camel microservice, if you want to go bare bones. And repeating from above, any cloud vendor would be happy to take it from there. You can repeat this entire process in less time than it takes to read this blog, once the process is familiar.

Now That You Have Learned The Minimum:

You may now add back in whichever pieces of infrastructure technology that don’t get your dander up. I’m sure you have your own favorite list.

Most will make the right choice, and head towards something like Claus Isben’s adaptation of Spring Boot. If you do that now, you would at least be well informed. It’s not quite as well documented, but now you know the essential minimums.

Or, better yet, take full advantage of fabric8 and/or Openshift!

Go for it!

Camel CXF – X__project Supplement



This blog should be interesting only to someone actively attempting to get their first camel-cxf project working. It is a companion piece to a progression of 4 example projects, and the docs on each.

  1. Code first CXF – simple.
  2. WSDL first CXF – simple.
  3. Code first CXF – complex objects.
  4. WSDL first CXF – complex objects.

It is notable that none of the previous Camel example projects required anything close to this kind of documentation, or explanation.

Main Points:

If you are impatient, like me, you may find that getting to number 4, above, is needlessly difficult, the first time. Especially aggravating, given that number 4 is the only variant that commercial/corporate applications might accept.

Then, when you get it all done, you might wonder what the fuss was about. Maybe this blog and these projects will get you there without spending much time.

The idea is to be able to blast through each of these very quickly, picking up additional steps/dependencies with each one.

The Sequence:

  1. Code first simple – basic dependencies, server, testing, tooling.
  2. WSDL first simple – add WSDL first steps, code.
  3. Code first complex – adds objects for input and output, processing, and testing variants.
  4. WSDL first complex – adds a merge with your own entity code.

Again, once you know the above steps you’ll wonder what all the fuss was about. Until then I found lots of ways to guess wrong and waste lots of time.

Specific to WSDL-First:

If you are new to SOAP and WSDL first in general, there may be some confusion about the generated code step. Since there may be some options, here is what I found successful.

  • Just running mvn compile is enough to generate the wsdl2java step. It’s will place it wherever you told it to in your pom, or in this case target/generated/src/main/java.
  • Wasn’t sure if I should be making this a legit source folder? Or copy the code to my src/main/java? I chose the latter, see next step.
  • When you copy it to your source folder, there still may be plenty of changes you have to make by hand. For example, your complex input and output object entities may already be in your codebase, and the wsdl2java generates you new entities. So in that case, you would have to merge the generated into the previous entities and then modify the rest of the generated code to point to those, and not the generated. You then delete the generated.
  • You may also have to comment out your wsdl2java plugin code in the pom.xml as soon as you have copied over and modified any generated code. This may or may not be obvious, but will make itself quite obvious if it becomes an issue.

Consuming WSDL from CodeFirst

One possible source of confusion can be quickly clarified by acknowledging a cheat that was used on the two WsdlFirst projects.

One of the most significant challenges to a WSDL first project of any type is the creation of the initial WSDL. This file is a complex 5 part file with many cross-referencing parts. Not for sissies like me, putting together silly example projects.

What was done on these example projects was to create the WSDL using the code first project, which creates a wsdl and publishes it to the browser as part of it’s functionality set.

This WSDL was then hand copied to the correct folder in the WsdlFirst projects.

A side benefit was that the WsdlFirstComplex and CodeFirstComplex projects could then also share entity classes, but that is just a side effect. In this case, the shared entities were placed in the jammazwan.shared project. Both WsdlFirst and CodeFirst projects share the same test code, using this approach.

Running Your Test as a Server (WTH?)

Problem: Jammazwan example projects are for learning Camel, not production deployments. Server and deployment code is intentionally excluded so you can isolate only what you are learning. So what happens in a case like this, where we actually need a running server to test with during development?

Solution: A quick, and ugly, manual hack is provided in our test code. I cringe, but it works great for the learning process.

A more realistic solution begins to outline itself in my Camel Microservices blog, though that is a bit off topic for this article.


  • Write your project to test with a normal test, such as template.requestBody(), like any other camel route.
  • Once it’s working, test it in the real world using something like SoapUI. To do this, uncomment the hack line

    Thread.sleep(Long.MAX_VALUE); Ugh.

  • You may now run the test, and the test basically hangs. Whola! Your server is operating. Even if you are wincing in disgust.
  • From your camel-ctx.xml file, copy the url. Such as http://localhost:9876/passThru/
  • Append ‘?wsdl‘ to this line. You now have a wsdl url of http://localhost:9876/passThru/?wsdl
  • Open the wsdl url in your browser. My chrome browser shows the xml from the wsdl file.
  • Now you can take this same wsdl url to your SoapUI tool, and test the actual working server with actual working xml. I won’t cover this here, as it’s assumed you already have this skillset.
  • Now you can kill your running test, which never finished, and comment back out the Thread.sleep(). Your manual dev test is complete.

Remaining Documentation:

Each of the 4 cxf example projects is documented in their respective

The files each focus on a diff between that, and previous artifacts. So 4 isn’t so much of a standalone, as a diff between it’s artifacts, and the previous. Etc. Other x__projects are standalone, not these 4.

  1. Code first CXF – simple –
  2. WSDL first CXF – simple-
  3. Code first CXF – complex objects –
  4. WSDL first CXF – complex objects –


Jammazwan FAQ


  • You said my x_project was complete working software! How do I deploy it?
  • How to import into my IDE?
  • Are goals of example projects contradictory?
  • Why is my x_project written with spring/java configuration?
  • What is an x_project?
  • Why the jammazwan.shared dependency?
  • What is this x… prefix?
  • Generated or not? vs
  • What does jammazwan.maker have to do with any of this?
  • Complex project warnings WTH?
  • Local v Remote JMS, DB, FTP
  • X__Projects vs jammazwan.100? WTH?
  • Uh, this isn’t a comprehensive list of example projects.

You said my x_project was working software! How do I deploy it?

x__projects are designed to isolate routing functionality and protect the user from confusing, deployment related code. They are run with unit tests. “Working,” in this context, is not intended to imply that it is deployable on a server.


The routes you would learn about from these isolated examples may be deployed into any server or service as appropriate. One such approach is outlined in another blog, but there are also vertical stack approaches such as Fuse which are amply documented by Red Hat.

Fabric8 or Openshift are also great deployment options, but again, provide their own learning curves.

How to import into my IDE?

You are encouraged – but not required – to open up your IDE into a new workspace and do all jammazwan work in a fresh workspace. This has nothing to do with jammazwan specifically, but is helpful practice whenever experimenting with new tech.

If you use Eclipse, then Import > General > Existing Projects into Workspace > Next > Browse > … then follow the prompts.

Other IDEs, or even Eclipse as an alternative to above, will import any project which has a pom.xml file. You may follow this normal process to import your jammazwan project into your IDE.

Are goals of example projects contradictory?

Jammazwan example projects are all about:

  • Driving adoption to increase learning speed.
  • Isolation of functionality to increase learning speed.

Isn’t that a contradiction? Don’t you need to pick one, instead?

Yes, it’s a contradiction. Maximizing the tension between the two is where learning gets real. Drive adoption and you create a huge desire to learn more, really fast. Isolate functionality and you make Camel easy to learn. Together, it’s a magical combination.

The tension between the two does create other problems, though. These are great problems to have.

Why is my x_project written with spring/java configuration?

There are so many language and configuration combinations available to the author of a Camel project, there could be no canonical, or even “best” choice.

Instead I opted for what seems to be the most common and powerful configuration choices. The choice of Java for it’s fluent API is the most important, because it is the most powerful.

What is this x__project naming convention?

One of the major challenges of isolating functionality in example projects is that now you have too many of them.

x__project is often used in the docs as a name for

see below: “What is this x… prefix?” if you need more info on this.

Why the jammazwan.shared dependency?

Some, but not all, x__projects require jammazwan.shared as a dependency, as indicated in their respective

X__project design tries to include only what is unique to this example, so you can focus only on what is required to demo the MyCoolCamelComponent feature in isolation. The single shared project includes dumb artifacts that shouldn’t be unique to a single x__project, such as:

  • Beans used as value objects for all example projects
  • pom.xml dependencies of a more general nature
  • .csv and other source files for use as data sources
  • generic utility functions not specific to a single project

So you sometimes have to git clone jammazwan.shared as a sibling first, then run mvn install, before installing your project.

If you want to replicate the functionality of your project into your own stand-alone project, you will need to pull some dependencies and code from each.

Another pattern I could have followed would be to create jammazwan.shared as a parent project. This pattern has been horribly abused in recent years, (IMO), creating insanely nested and hard to decipher project structures, so I just avoided it entirely.

What is this x… prefix?

The prefix x__ is used for maintaining sort order in a directory, providing packaging, and is otherwise meaningless. The x stands for example.

A side benefit is that I do a lot of work in a bash shell, so being able to type cd ../xao [tab] saves me a lot of time, and is easier to remember than a lot of project names.

Generated or not? vs

Every project has a which is generated from here, and never hand modified.

Some projects also have a which is entirely created by hand, and contains information which is not in the metadata. Go there first if you have any needs that are not answered in the opening page README.

What does jammazwan.maker have to do with any of this?

All x__projects are created with a generator. Interesting notes about the generator, if you care:

  • Written entirely in Camel
  • Can create, and update, any project.
  • Uses Velocity component
  • Open source, use it for anything you wish.
  • Not in any way documented or supported.

Complex project warnings WTH?

Xab and at least one other project start out by advising you to go away. Kind of silly.

The whole point of x__projects is isolation of just one small thing. These projects break that implicit contract. So instead of learning just one thing you are confronted with way more than you can absorb, possibly doing more harm than good.

I’m still not sure why they are here, but some day I might come up with a better strategy and explanation.

Local v Remote JMS, DB, FTP

to be documented later, if ever.

X__Projects vs jammazwan.100?  WTH?

Is Jammazwan about x__projects or jammazwan.100? Don’t they have different goals in mind?

  • jammazwan is 90% about example projects
  • jammazwan.100 is for advanced work

Uh, this isn’t exactly a comprehensive list of example projects.


Pull requests welcomed.

Jammazwan – Projects for Learning Apache Camel


Camel Keeper: Jammazwan

“Jammazwan” is Hindi for “camel keeper”.

Apache Camel is sponsored and maintained by Red Hat, and a part of it’s Fuse offering.

Me, a jammazwan? another Camel Keeper: TL DR?     about:
pete jammazwanPhotoSmall jamzVid1

If you are impatient or in a hurry, the 2 minute video might get you through faster than reading this blog.

Ease Learning by Driving Adoption

Start with Camel projects that already do something useful. Projects that already work.  Every example project is designed to be IDE ready in 60 seconds. Try one!

Jammazwan lets you learn Camel the same way you probably already learned everything else you work with every day, like Maven or Spring or JEE or Eclipse or IntelliJ or…  Someone gave you projects that already worked, and you gradually expanded your skillset until you became an expert.

Make the Easy Stuff Easy

Once you succeed with Camel, you’ll want to use it for everything that’s easy.  That’s what Camel is about, making things easy, the stuff we have to do every day. And Jammazwan example projects are designed to be easy.

Let adoption be the driver for the learning that has to happen in your organization. Cryptic docs really start making sense once you’ve got projects that you care about, to give you context, and you’re not wrestling with syntax and semantics.

Why Jammazwan?

I wrote Jammazwan projects because my only option was to learn from books or docs or courses or the like.  Author Claus Isben, for example, writes a superb book. But you show me some working code that I start using in projects I need, and I’m off to the races. Only then do I become super-enthusiastic to use a great book or docs, to help me expand my project into a perfect use cases.

Jammazwan projects cover things that you need to do every day.

Then, Jammazwan.100 for Breadth and Depth

Let’s face it. Most of us work in pretty homogenous corporate environments. “We only use camel for …. type of use cases.”  Our skills then rarely expand beyond our daily use cases.

What I needed was a randomized project spec generator to push me past my normal comfort zone and develop Camel coding speed in areas that I don’t get to do every day.

Take a look at jammazwan.100 and jammazwan.100.done.

The areas you know will go fast, but Jammazwan 100 will also push you through unfamiliar areas, so you can get them up to speed, using the kind of reps you get in your daily work.

If You Must Study First

There are some things about learning Apache Camel that would be helpful to know. Before you invest a bunch of time.

Consult this whitepaper-like blog to save you time, by identifying some strategies and tips. Here’s hoping that it saves you a few days, or even weeks of time!


If you are an automation enthusiast, you might look at the code in jammazwan.maker.

You might even want to use it to generate your own Camel projects. But it’s not documented or designed to be user friendly, so it may not be worth the effort.


Ping me if I can help  your shop move it’s development efforts forward with Camel.