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.
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’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!
Consider the following Camel 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
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 OpenLogicteam offers a full week training course on Camel in addition to our support and professional services capabilities.
You can also view my full presentation on Slideshare: