At the work place, I've had to do a lot of integration work on my current project.  Instead of trying to tie everything together on my own, someone recommended taking a look at Apache Camel.  Man, did that have a drastically good effect on my project!

Well, What is it?

It's an integration framework written in Java.  In short, it's meant to make the act of integrating systems together easier.

Enough of the Jibberish -- WTFsck() is an Integration Framework?

Yeah, that line wouldn't have made much sense to me, either, before reading the Camel book.  It's probably best to refer to an example.

Let's say you have some really annoying manual process that you use to tie together two systems.  I had a previous employer who would create ISO images and then had to manually upload them to a partner's site so that they could mass-produce optical media from said image.  Some person, who was not a seasoned FTP user (nor wanted to be) had to have a set of credentials, access to the ISO, and had to babysit the upload.  They also had the ability to break the transfer via FTP options.  In this case, the partner needed us to use a specific set of options.

This is something that Camel could do easily.  Users create "routes" to describe processes like the one above.  These routes can be described in Java, XML, or one of the many DSLs (domain specific languages) that are included.  Here's an example route in XML that could satisfy the above problem:

<route id="publishIso">
  <from uri="file://path/to/iso/finished.iso" />
  <to uri="" />

This route can be embedded inside of a Spring config file. To launch the route, the developer would just have to start a Spring context. This would start Camel, which would read the XML file. It would then sit there and scan the /path/to/iso/ directory for a filed named finished.iso every 500ms (by default, as of the time of this writing). When it finds the file, it will upload it to the specified FTP site.

Simple, eh? All that from a little bit of XML and starting a Spring context (all of less than 6 lines of code in Java).

Go on...

Well, as I stated, you can embed this into a Spring configuration file. Upon starting the context, Camel will start. You can also describe routes using the Java DSL:


The "from" and "to" are described as "Endpoints" in Camel.  Endpoints are created by "Components."  This simple route demonstrates the File2 and FTP Components being used to generate two Endpoints.  There are a TON of useful components, with this being a list of the ones that I use most often:

Are you a Wizard?

No.  But Camel is.

It ties together these Endpoints by passing Messages to and fro.  In addition to being able to directly configure the Endpoints, you can manipulate messages en route.  For instance, Camel supports the notion of having Data Formats so that it can seamlessly marshal/unmarshal a message body between Endpoints.  An example use case might be if you're reading an XML file and you want to call a custom bean that you wrote, passing in the XML as an object.  Camel can use JAXB to populate a POJO before calling your bean, preventing your custom bean from having to know anything about the file itself.

It also handles threading wizardry for you.  Many of these components have multi-thread options, meaning that Camel handles the nasty threading-bits.  It's still incumbent upon the user to make sure that they're applying parallelism in an appropriate way, but Camel reduces this exercise to one of configuration and not implementation; Camel's bits already have this figured out.

Bottom Line?

Camel saved me from having to implement a bunch of custom software to tie together my systems.  I can create an XML config file, a few custom beans if need be, and presto!  I now have Java program that will make several systems play nice, threading, logging, and all.  Camel was a tremendous find, and it's had a tremendous impact on my work.

Kudos to Apache, theCamel project, and it's leader, Claus Ibsen.

- bstempi