camel-box-small

Introduction to Enterprise Integration Patterns and Apache Camel

on Nov 8, 18 • by Justin Reock • with No Comments

By combining a component-driven approach with an easy-to-understand syntax, Camel allows developers to federate various applications with minimal code...

Home » Featured, Open Source » Introduction to Enterprise Integration Patterns and Apache Camel

This year at ZendCon & OpenEnterprise, I had the chance to present on one of my favorite technologies, the Apache Camel routing and normalization framework.

In my opinion, Camel is one of the best ways to create sophisticated enterprise integration workflows. By combining a component-driven approach with an easy-to-understand syntax, Camel allows developers to federate various applications with minimal code.

Enterprise Integration Patterns

Camel was designed as a programmatic implementation of Enterprise Integration Patterns (EIP). As an architectural design pattern, EIP defines code-agnostic workflows for common business tasks.

For instance, the “Dynamic Router” pattern defines a messaging workflow in which a characteristic of a message is used to make a decision on where to send that message. Visually, the pattern is defined as such:

Most enterprise developers have written logic like this. In the above image, messages with a green square characteristic are pushed to the “widget inventory”, whereas ones with an orange diamond characteristic are pushed to the “gadget” inventory.

Another EIP is the “Content Enricher” pattern:

In this pattern, we begin with a basic message. We then query some sort of resource, perhaps a database or a file server, and enrich the message with data from that resource. Again, most developers have written similar logic.

So, the goal of EIP is to create a common vocabulary and set of workflow actions that can be combined together to create sophisticated business process.

Apache Camel

So what does any of this have to do with Apache Camel? Well, basically everything!

Camel provides a language that can build these patterns using a basic syntax. It takes a message-driven approach to integration, where messages contain data payloads that can be shuttled around through various endpoints.

The endpoints themselves are implemented using Camel Components, and there are a lot of them!

Camel routes are highly portable. They can be run standalone, deployed in a servlet container, wrapped as OSGI blueprints, and more!

Camel Syntax

Camel’s syntax is inspired by the UNIX pipeline.

In UNIX, we might execute something like ps -fe | grep foo. When we run this command, the output of the ps command becomes the input to the grep command. We “pipe” the output of one command into the input of another command.

Camel chains these actions together in an object called an Exchange, which consists of an input message (called the “In” message), some sort of processor (like a component, for instance) and possibly an output or “Out” message if the processor is meant to provide a synchronous response.

A series of Exchange state changes creates a Camel Route.

The magic here is that these processors can be anything. They can be an integration component, they can be a custom processor, and they can be some sort of data transformer. The sky is the limit!

Camel Route

Consider the following Camel Route:

    <route id="CamelFileXlateRoute">
      <description>Example Camel Route :: FileXlate</description>
      <from uri="file:/tmp/InputFiles" />
      <setBody>
         <simple>This is a message that says '${body}' that came from a filename of ${headers.CamelFileName}</simple>
      </setBody>
      <toD uri="activemq:FileInputQueue-${headers.CamelFileName}" />
    </route>  

This route begins using Camel’s “file” component, which allows the route to interact with a local file system.

In this case, we’re creating a file consumer that will watch a directory called “/tmp/InputFiles.” Any time a new file is created in this directory, the contents of that file will become the first input message on the route.

We then perform a simple transform using the reserved command, which transforms the body of the message. In this case, we’re using one of Camel’s built-in scripting languages, , to provide access to the message contents using the ${} property syntax.

Components tend to append relevant headers to messages that move through them. The file component provides many headers, and a useful one is the CamelFileName header which retains the name of the file that is being processed.

Finally, we send that payload to the Camel “activemq” component, which allows for integration with the ActiveMQ message broker.

So, effectively three small blocks of code, we create a file consumer, transform the message payload, and create a JMS producer which will push the file’s contents as a JMS message to an ActiveMQ broker.

Powerful stuff!

Next steps

There’s a lot to this language and this post barely scratches the surface of what can be achieved using this valuable framework. Stay tuned for supplemental blogs where we will dig deeper into Camel’s capabilities, best practices, and additional patterns and techniques.

In the meantime, if Camel has piqued your interest and you’d like to learn more, feel free to reach out to us! The OpenLogic team at Rogue Wave offers a full week training course on Camel in addition to our support and professional services capabilities.

You can also view my full presenetation on Slideshare:

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top