Apache Camel: The Definitive Guide to Integrating Applications and Microservices

“Apache Camel is a powerful rule-based routing and mediation engine which provides a Java object-based implementation of the Enterprise Integration Patterns” — James Strachan, creator of Apache Camel

Strachan’s definition captures the essence of Camel: a framework that applies EIPs to orchestrate flows between systems in a simple and maintainable way. Have you ever had to integrate applications that don’t understand each other?

In enterprise environments where multiple applications, protocols, and formats coexist, Camel shines by offering declarative routes, message transformation, and a broad catalogue of components to connect virtually anything, without reinventing the wheel.

The result: more reliable integrations, cleaner code, and faster delivery cycles. In this article, we will explain exactly what Camel is, review its key concepts and components, and share practical examples of implementation in Chakray.

What is Apache Camel, and why use it?

Apache Camel is an open-source integration framework developed and maintained by the Apache Software Foundation. It is based on the Enterprise Integration Patterns (EIP) described in the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Hohpe & Woolf, 2003).

It provides a routing and mediation engine that allows you to define, in different programming languages (Java, XML, Groovy, YAML), how messages are transmitted, transformed, and orchestrated between heterogeneous systems.

Camel simplifies integration thanks to hundreds of pre-built components (HTTP/REST, JMS/ActiveMQ, Kafka, JDBC, FTP/SFTP, etc.) and the direct implementation of most EIPs. The result? Less code duplication, greater consistency and faster delivery, with readable and easy-to-test code.

– You may be interested in the following article: Using HL7 FHIR for clinical information exchange and integration with Red Hat Fuse (Apache Camel) –

Architecture

Key components

The main components are: Camel Context, which is the ‘heart’ that manages the lifecycle of routes and components. In addition to configuration through properties/yaml, bean registration, and the type conversion system. And last but not least, there are the components. These act as connectors to technologies/protocols and expose endpoints identified by URIs (e.g.,kafka:orders?brokers=… o file:/inbox?noop=true).

Camel also has a set of elements that will help us perform the tasks we want to carry out, such as: Routes, which chain endpoints and allow us to enter and exit information from the system. EIP components (choice, split, enrich, etc.) that help us perform transformation and routing tasks. Processors, highly versatile elements that will help us in the implementation of any use case.

Each communication will be associated with an Exchange object that will include its corresponding message (message body + headers). Through this, we can validate the incoming message, enrich it, transform it or, in case of error, perform error management. All this without the need to mix business logic with routing logic. Furthermore, do you need to change the protocol? Often, it is enough to change the endpoint URI.

Routes and programming languages

A route defines the end-to-end flow, for example: from(“jms:input”).process(…).to(“http://api”). The core of Camel is always the same, but it can be written in different programming languages and supported by different frameworks. Therefore, it is extremely versatile.

For example, that same route could be written with Java DSL using Quarkus or Spring, in XML, YAML, or even with Kafka connectors. Therefore, choosing the programming language and framework to be used as a basis is a fundamental aspect when tackling any project.

Below are several key points to keep in mind:

• Java: It is widely known and allows us to be close to the code and perform simple unit tests.
• XML: It allows for a declarative definition that is easy to externalise and version, but it is possibly the most outdated method.
• YAML: Lightweight and simple, although less robust than other languages.
• Kafka Connect: Designed primarily for business logic where Kafka plays a fundamental and very specific role.

However, as we have mentioned, regardless of the programming language, all routes are translated into the same internal Camel model, which ensures consistency and allows EIPs, processors, and components to be mixed seamlessly.

Comparison of DSL in Apache Camel

Next, we will have a closer look at choosing DSL and present a comparison table:

Processors and Message Transformation

A Processor in Camel is a unit of work that operates on the Exchange (body, headers, and properties) to validate, transform, normalise, or enrich the message before continuing with routing. It can be implemented as a Java class (Processor interface) or as a lambda in Java DSL. In addition, it can be invoked directly or through components (e.g., setBody, setHeader, transform, bean), keeping the integration logic separate from the business logic.

Camel incorporates transformation-oriented EIPs, such as Message Translator (which allows you to modify or adapt message content), Content Enricher (which allows you to supplement the message with external data) and Normalizer (which allows you to transform the message into a canonical model). These patterns can be combined with other EIPs (e.g., split/aggregate, choice) to build robust and readable flows.

In terms of formats and tooling, Camel offers utilities for transformation to JSON, XML, CSV, Avro, Protobuf, among others. It allows transformations with XSLT/XQuery or Freemarker. Attribute mapping and serialisation with Jackson or JAXB. And it relies on its Type Converter to automatically convert types (e.g., String ↔ POJO). In practice, a typical flow could deserialise (unmarshal), validate, enrich the message coming from an external call, and then serialise (marshal) it back, all described declaratively in the chosen language.

Enterprise Integration Patterns (EIP)

Camel supports most EIPs and offers ready-to-use implementations such as Content-Based Router (choice/when/otherwise), Splitter, Aggregator, Wire Tap, Dead Letter Channel, and others. The official documentation maintains a complete catalogue of patterns that serves as a practical guide for modelling integration flows.

Most commonly used patterns (brief overview)

• Content-Based Router: routes conditionally based on headers, body, or expressions; in Camel, it is expressed with choice(), when(), otherwise().

Content-Based Router Pattern

• Message Translator: Transforms the structure/format of the message (e.g., JSON↔POJO, XML→canonical model) using process/transform, data formats, or components such as Jackson/JSONata.

Message Translator Pattern

• Splitter/Aggregator: Splits a composite message into parts and then reassembles them using correlation/termination strategies.

Splitter / Aggregator Pattern

• Wire Tap: Sends a copy of the message to another destination without affecting the main flow. This is useful for auditing and/or observability tasks.

Wire Tap

• Dead Letter Channel: Enables the forwarding and management of messages when their processing has failed.
  

Dead Letter Channel Pattern

Components/Endpoints

Camel offers over 300 components for connecting to protocols and systems (HTTP/REST, messaging, databases, file systems, cloud, etc.).

REST/HTTP & API Gateway

The HTTP/REST component in Apache Camel allows you to expose and consume REST APIs with support for configuring multiple parameters, such as SSL/TLS connection, proxies, or custom HTTP headers, among others. In addition, the declarative language of the REST component simplifies the configuration of REST and different servers, such as Jetty, Servlet, Netty, or Undertow. 

Finally, the Rest Open API component allows it to be built using a contract-first approach, which simplifies its declaration and facilitates interoperability across different architectures.

Camel Kafka Connector for streaming

Camel Kafka Connector allows Apache Camel components to be reused as source or sink connectors within the Kafka Connect ecosystem, facilitating the development of reliable data streaming integrations. Version 4.10.x of the connector is compatible with Apache Kafka 3.7.x and leverages Kamelets 4.10.x to define portable and reusable integration flows.

JMS/ActiveMQ and message queues

Apache Camel includes support for JMS through a standard component (camel-jms) that allows integration with any broker compatible with the JMS specification. It also offers specific components for ActiveMQ: camel-activemq for ActiveMQ 5.x (Classic) brokers and camel-activemq6 for ActiveMQ 6.x brokers. In the case of ActiveMQ Artemis or generic JMS brokers, it is recommended to use the standard camel-jms component, which provides greater flexibility and compatibility.

Databases (JDBC) and files (FTP/SFTP)

Camel has different components that enable database operations. Depending on how you want to connect or perform operations, we can choose one or the other. The JDBC component executes SQL statements sent in the message body. The SQL component uses Spring JDBC and defines the query directly in the endpoint URI. On the other hand, the JPA component allows us to perform database operations through Java object handling.

In addition, for file exchange, the FTP/FTPS (based on Commons Net) and SFTP (based on JSCH) protocols enable secure transfer and offer flexible configuration.

Camel vs. ESB: lightweight systems integration

Apache Camel is often confused with an ESB, but it is not. Camel is an integration library/framework that you can embed in your applications (e.g., Spring Boot, Quarkus, or standalone), which promotes independent deployments and reduces the vendor lock-in typical of a centralised platform.

In microservice architectures, Camel fits with the ‘smart endpoints & dumb pipes’ principle described by James Lewis and Martin Fowler: the logic lives in the services and the transport remains simple. This avoids the centralised hubs typical of an ESB and improves the observability of pipelines and the autonomy of teams.

What is an ESB and what is a microservice?

An ESB is a centralised integration platform: it provides its own runtime, console, connectors, visual mapping/transformation, policies and governance. Examples: IBM App Connect Enterprise (ACE), Oracle Service Bus (OSB), Mule Runtime/Anypoint Platform, TIBCO BusinessWorks and webMethods Integration Server.

In contrast, a microservice is a small, autonomous unit that implements a limited business capability, runs in its own process, deploys independently, and communicates with others using lightweight mechanisms (HTTP APIs or messaging).

This approach promotes decentralised governance and data. Here, a lightweight library such as Camel provides routes, processors, and message translators without introducing the coupling of a central bus.

Comparison: Camel vs. ESB

Below is a comparison table summarising the main differences between the two:

Getting started with Apache Camel

Installation and dependencies (Maven/Gradle)

With Maven, add starters according to the runtime:

<dependency>

  <groupId>org.apache.camel</groupId>

  <artifactId>camel-core</artifactId>

</dependency>

For Spring Boot or Quarkus, there are multiple starters or extensions that will help us with development. Camel also offers guides and archetypes to get started. In addition, it has tools such as Camel Kameleon, for generating projects, or Camel Karavan, for more visual development. It also has JBang, a CLI tool especially suited for rapid and very lightweight developments.

Quick start with Spring Boot or Quarkus

• Spring Boot: camel-spring-boot-starter  allows you to auto-configure components and expose routes as beans @Component.
• Quarkus: Camel Quarkus compiles to JVM or native and is certified by Red Hat on OpenShift/RHEL with OpenJDK 21. Ideal for fast cold starts and lower memory footprint.

Your first step-by-step ‘Hello World’ route

1. Create a project with Camel JBang or a Spring Boot/Quarkus starter.
2. Define a simple route:
   from(“timer:hello?period=5s”)
    .setBody().simple(“Hola desde Camel @ ${date:now}”)
     .to(“log:demo”);
3. Run and observe the logs. This route illustrates the routing engine, the use of endpoints, and expressions.

Examples of integrations with Apache Camel in Chakray

In this section, we have compiled implementations of some EIPs used in both Apache Camel and WSO2. The work was carried out by the Chakray Tanzania development team, which documented each pattern step by step, with code, configurations, and tests.

The code review was carried out by Daniel Blanco, Technical Leader at Chakray Spain.

The Canonical Data Model Pattern
By: Japhet Sebastian — Integration Developer

Challenge: Normalisation of JSON messages sent by different systems with different formats.

Solution: The Canonical Data Model integration pattern is applied, which translates each incoming message into a common data model with a standard structure: orderId, customer.name, and items[product, quantity]. In this way, regardless of the source, all messages are normalised before being processed, reducing complexity, coupling, and errors in integration.

The Content Filter Pattern
By: Christopher Masaka — Integration Developer

Challenge: Incoming messages contain large amounts of data and many inactive users. The payload needs to be filtered and simplified to expose only relevant information — for example, users with  active=true — thereby reducing coupling and message size.

Solution: The Content Filter integration pattern is applied. In both WSO2/Synapse and Apache Camel, the system evaluates the message and retains only active users, returning a filtered and simpler JSON. This ensures that consumers work only with useful information, optimising communication between systems.

The Message Translator Pattern
By: Charity Mbise — Integration Developer

Challenge: A clearing system must publish receipts in a proprietary ERP, but it is not possible to modify either system.

Solution: The Message Translator integration pattern is applied, which allows the format of messages between applications with different data models to be adapted. In this case, a REST API is exposed that receives the receipt from the clearing system and automatically translates it into a structure that the ERP understands, ensuring compatibility without the need to change the existing systems.

The Message Router Pattern
By: Abdulaziz Abdi — Software Engineer

Challenge: We need to route each request based on its content—in this case, the person’s age—to decide whether they can vote or not. The input message is not transformed, but the application must respond immediately with a clear message in JSON format.

Solution: The Message Router integration pattern is applied, which allows messages to be directed to different flows based on their content. In both WSO2/Synapse and Apache Camel, the age field of the incoming message is evaluated. If the age is greater than or equal to 18, the business logic directs the message to the route that returns the response ‘Yes, you can vote.’ Otherwise, it is routed to the one that responds ‘No, you cannot vote.’

In this way, using routing components (filter in Synapse or choice() in Camel), a clear and readable flow is constructed that illustrates how the Message Router pattern resolves decision scenarios based on the content of the message.

The Message Router Pattern with Queue
By: Abdulaziz Abdi — Software Engineer

Challenge: Solve the same content routing, but in a decoupled and asynchronous manner. The API must receive the request, instantly confirm to the client, and let further processing run in the background without blocking the response.

Solution: The Message Router pattern is applied in conjunction with message queues. The system places incoming messages in an input queue, ensuring that they can be processed later. Processors then read each message, apply routing logic based on age, and direct them to different destinations. There, the result is simply recorded: ‘Yes, you can vote’ or ‘No, you cannot vote.’

This approach demonstrates how the use of queues allows the reception of the request to be decoupled from its processing, improving the scalability and resilience of the solution.

Conclusion

Apache Camel enables lightweight, portable, pattern-oriented integrations that are well suited to modern microservices-based and cloud-native architectures. Its wealth of EIPs, components, and runtimes dramatically reduces delivery time and facilitates maintenance. For complex scenarios—orchestration, messaging, streaming—the combination of EIPs (Router, Translator, Splitter/Aggregator, Wire Tap) and connectors (HTTP, Kafka, JMS, JDBC, SFTP) provides a robust and scalable foundation.

Take the next step towards more agile and scalable integrations.

Schedule a session with our experts today and discover how we can boost your business through robust integration patterns and frameworks.

Talk to our experts!

Contact our team and discover the cutting-edge technologies that will empower your business.

contact us