Mastering Apache Camel: An advanced guide to Enterprise Integration using Apache Camel

Apache Camel originated in Apache ServiceMix. Apache ServiceMix 3 was powered by the Spring framework and implemented in the JBI specification. The Java Business Integration (JBI) specification proposed a Plug and Play approach for integration problems. JBI was based on WebService concepts and standards. For instance, it directly reuses the Message Exchange Patterns (MEP) concept that comes from WebService Description Language (WSDL).

Camel reuses some of these concepts, for instance, you will see that we have the concept of MEP in Camel.

However, JBI suffered mostly from two issues:

In addition to JBI, another foundation of Camel is the book Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.

This book describes design patterns answering classical problems while dealing with enterprise application integration and message oriented middleware.

The book describes the problems and the patterns to solve them. Camel strives to implement the patterns described in the book to make them easy to use and let the developer concentrate on the task at hand.

This is what Camel is: an open source framework that allows you to integrate systems and that comes with a lot of connectors and Enterprise Integration Patterns (EIP) components out of the box. And if that is not enough, one can extend and implement custom components.

Apache Camel ships with a wide variety of components out of the box; currently, there are more than 100 components available.

We can see:

Thanks to this, Camel brings a very powerful connectivity and mediation framework.

Moreover, it's pretty easy to create new custom components, allowing you to extend Camel if the default components set doesn't match your requirements.

It's also very easy to implement complex integration logic by creating your own processors and reusing your beans. Camel supports beans frameworks (IoC), such as Spring or Blueprint.

As we will see later, most of the EIP need a rule definition to apply a routing logic to a message. The rule is described using an expression.

It means that we have to define expressions or predicates in the Enterprise Integration Patterns. An expression returns any kind of value, whereas a predicate returns true or false only.

Camel supports a lot of different languages to declare expressions or predicates. It doesn't force you to use one, it allows you to use the most appropriate one.

For instance, Camel supports xpath, mvel, ognl, python, ruby, PHP, JavaScript, SpEL (Spring Expression Language), Groovy, and so on as expression languages. It also provides native Camel prebuilt functions and languages that are easy to use such as header, constant, or simple languages.

Camel is payload-agnostic. This means that it can support any kind of message. Depending on the endpoints, it could be required to convert from one format to another. That's why Camel supports different data formats, in a pluggable way. This means that Camel can marshall or unmarshall a message in a given format. For instance, in addition to the standard JVM serialization, Camel natively supports Avro, JSON, protobuf, JAXB, XmlBeans, XStream, JiBX, SOAP, and so on.

Depending on the endpoints and your need, you can explicitly define the data format during the processing of the message. On the other hand, Camel knows the expected format and type of endpoints. Thanks to this, Camel looks for a type converter, allowing to implicitly transform a message from one format to another.

You can also explicitly define the type converter of your choice at some points during the processing of the message. Camel provides a set of ready-to-use type converters, but, as Camel supports a pluggable model, you can extend it by providing your own type converters. It's a simple POJO to implement.

Camel uses a different approach based on URI. The endpoint itself and its configuration are on the URI.

The URI is human readable and provides the details of the endpoint, which is the endpoint component and the endpoint configuration.

As this URI is part of the complete configuration (which defines what we name a route, as we will see later), it's possible to have a complete overview of the integration logic and connectivity in a row. We will cover this in detail in Chapter 2, Core Concepts.

Camel itself is very light. The Camel core is only around 2 MB, and contains everything required to run Camel. As it's based on a pluggable architecture, all Camel components are provided as external modules, allowing you to install only what you need, without installing superfluous and needlessly heavy modules.

As we saw, Camel is based on simple POJO, which means that the Camel core doesn't depend on other frameworks: it's an atomic framework and is ready to use. All other modules (components, DSL, and so on) are built on top of this Camel core.

Moreover, Camel is not tied to one container for deployment. Camel supports a wide range of containers to run. They are as follows:

Camel gives a lot of flexibility, allowing you to embed it into your application or to use an enterprise-ready container.

In any integration project, it's typical that we have some part of the integration logic not yet available. For instance:

As a complete integration framework, Camel provides a very easy way to prototype part of the integration logic. Even if you don't have the actual system to integrate, you can simulate this system (mock), as it allows you to implement your integration logic without waiting for dependencies. The mocking support is directly part of the Camel core and doesn't require any additional dependency.

Along the same lines, testing is also crucial in an integration project. In such a kind of project, a lot of errors can happen and most are unforeseen. Moreover, a small change in an integration process might impact a lot of other processes. Camel provides the tools to easily test your design and integration logic, allowing you to integrate this in a continuous integration platform.

Apache Camel uses the Java Management Extension (JMX) standard and provides a lot of insights into the system using MBeans (Management Beans), providing a detailed view of the following current system:

Moreover, these MBeans provide more insights than metrics. They also provide the operations to manage Camel. For instance, the operations allow you to stop an integration process, to suspend an endpoint, and so on. Using a combination of metrics and operations, you can configure a very agile integration solution.

The Apache Camel community is very active. This means that potential issues are identified very quickly and a fix is available soon after. However, it also means that a lot of ideas and contributions are proposed, giving more and more features to Camel.

Another big advantage of an active community is that you will never be alone; a lot of people are active on the mailing lists who are ready to answer your question and provide advice.

Apache Camel is an enterprise integration solution used in many large organizations with enterprise support available through RedHat or Talend.

This chapter briefly introduced Camel and where it's come from. It mainly introduced Camel's key features. In the next chapter, before dealing with some of these features in detail, we will introduce the Camel core concepts, which will help you easily understand the further chapters.