How Camel helps you integrate services without getting the hump

A common problem to overcome in system design is how to easily integrate a bunch of disparate services, using a variety of different standards, technologies or frameworks. That is the problem Camel, available under the Apache framework, aims to solve. Camel is a Java library which aims to be an implementation of the Enterprise Integration Patterns, allowing you to bring your systems together in an object-oriented manner.

Process any kind of data…

The core of Apache Camel is a routing engine, which allows you to define your own routes, determine which sources to accept messages from, in which formats, and then how to process and send these messages to destinations. This agnostic approach is one of Camels key strengths – it makes no assumptions on the types of data you need to process. Furthermore, Camels flexibility extends to the choice of Domain Specific Languages, including Java, Scala and Groovy, with an extensive component language and a comprehensive test kit.

…and send it to many different kinds of endpoints

Camel offers a variety of endpoint types (known as components), such as HTTP, FTP and SOAP. It also offers more specific components for services such as Dropbox, Facebook and Google services. These components can be used as entry or exit points for routes. For example, you could use Camel to read requests from a HTTP endpoint, split the messages based on headers, and send to a file system or a message queue.

A little context

The core of a Camel based system is the ‘Camel Context’, which can be thought of as Camel’s Runtime System, similar to how Spring uses an Application Context. The context can be defined either in the DSL or through XML. Once defined, your system will have to start the context, which will activate the routing rules and endpoints described within.

Replicate many core Enterprise Integration Patterns

As described in the excellent book ‘Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions’ by Gregor Hohpe and Bobby Woolf, applications tend to follow repeating patterns. The book outlines a series of common patterns that they describe as Enterprise Integration Patterns. These patterns largely describe the flow of a message from one system to another, with various transformations along the way. Camel builds in concrete support for most of the core patterns outlined in the book, such as Content-Based Router, Wire Tap and Splitter.

Build your system with ‘Routes’

Defined within the context are a series of ‘Routes’ – a chain of processors between two endpoints. Routes are the bread and butter of a Camel system, they should describe the processing that your system is designed to undertake. A common design exercise would be to map out a route – messages should flow in a logical manner.

Figure 1 – an example of a Camel route using the Dynamic Router EIP

Once your routes are designed, with appropriate components as endpoints, data can begin flowing through your system. Camel models this flow of information with ‘Exchanges’ and ‘Messages’. Exchanges are containers that contain both inbound and outbound messages, and additional information such as properties. Messages represent the entities systems use to communicate with each other, and contain ‘headers’, ‘attachments’ and the ‘body’. Following the principle of being payload agnostic, the message body is a simple object and can contain any kind of content.

Further reading

Camel is incredibly powerful tool to aid in the design of routing-based integration systems. For further information about using it, there is no better source than the book Camel In Action. The Camel website also has a ton of valuable resources.

We’ve put together some examples of some simple routes (and the powerful testing framework), which you can see on Github here.

To discuss further how Camel could be used to integrate services in your organisation, drop us a line.