In this article Jean-Baptiste Onofré, author of the book Mastering Apache Camel, we will see how 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 reusesthe 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 JBI, all messages between endpoints are transported in the Normalized Messages Router (NMR).

  In the NMR, a message has a standard XML format. As all messages in the NMR havethe same format, it’s easy to audit messages and the format is predictable.

  However, the JBI XML format has an important drawback for performances: it needs to marshall and unmarshall the messages. Some protocols (such as REST or RMI) are not easy to describe in XML.

  For instance, REST can work in stream mode. It doesn’t make sense to marshall streamsin XML.

  Camel is payload-agnostic. This means that you can transport any kind of messages with Camel (not necessary XML formatted).

• JBI describes a packaging. We distinguish the binding components (responsible for the interaction with the system outside of the NMR and the handling of the messages in the NMR), and the service engines (responsible for transforming the messages inside the NMR).

  However, it’s not possible to directly deploy the endpoints based on these components. JBI requires a service unit (a ZIP file) per endpoint, and for each package in a service assembly (another ZIP file). JBI also splits the description of the endpoint from its configuration.

  It does not result in a very flexible packaging: with definitions and configurations scattered in different files, not easy to maintain. In Camel, the configuration and definition of the endpoints are gatheredin a simple URI. It’s easier to read.

  Moreover, Camel doesn’t force any packaging; the same definition can be packaged in a simple XML file, OSGi bundle, andregular JAR file.

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

It 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.

Components and bean support

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

We can see:

• The connectivity components that allow exposure of endpoints for external systems or communicate with external systems. For instance, the FTP, HTTP, JMX, WebServices, JMS, and a lot more components are connectivity components. Creating an endpoint and the associated configuration for these components is easy, by directly using a URI.
• The internal components applying rules to the messages internally to Camel. These kinds of components apply validation or transformation rules to the inflight message. For instance, validation or XSLT are internal components. 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.

Predicates and expressions

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.

Data format and type conversion

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.

Easy configuration and URI

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.

Lightweight and different deployment topologies

Camel itself is very light. The Camel core is only around 2 MB, and contains everythingrequired 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.

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:

• A J2EE application server such as WebSphere, WebLogic, JBoss, and so on
• A Web container such as Apache Tomcat
• An OSGi container such as Apache Karaf
• A standalone application using frameworks such as Spring

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

Quick prototyping and testing support

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

• The application to integrate with has not yet been purchased or not yet ready
• The remote system to integrate with has a heavy cost, not acceptable during the development phase
• Multiple teams work in parallel, so we may have some kinds of deadlocks between the teams

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.

Management and monitoring using JMX

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:

• The different integration processes with the associated metrics
• The different components and endpoints with the associated metrics

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.

Active community

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.

Summary

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

Resources for Article:

---

Further resources on this subject:

• Getting Started [article]
• A Quick Start Guide to Flume [article]
• Best Practices [article]

---