Apache Camel Runtimes

This blog discusses various runtimes for Apache Camel. But before I do, I need to tell you that you don’t need a runtime. Camel is a modular integration framework, you can cherry-pick and only use a few parts in your application. It’s thus perfectly fine to just use the Camel core library and a few components.

So, why do I need a runtime?

Runtimes are mainly used for convenience. Runtimes comes with a lot of batteries included that make it easier to configure and manage Camel integrations than coding everything by hand. Often people who don’t use a runtime, find themselves recreating functionality that can be found in most of the runtimes.

Most common functionality of runtimes are deployment, logging, configuration, scaling, and managing the lifecycle of an integration. In a lot of integration software, there is only one runtime to run integration. For Camel, there are many choices. So, what options do we have?

The Runtimes

Karaf

Apache Karaf was the first runtime used by the Apache project. Karaf is a OSGi based runtime which provides a container onto which various components and applications can be deployed. Some of its functionalities are hot deployment, dynamic configuration, logging and an extensive shell.

Hot deployment means that you can create an integration with an XML that contains the Camel routes, and save this XML in the deploy folder. Camel Karaf commands allowing you to view, start, stop and get info, about the Camel contexts and routes running in the Karaf instance. One of the advantages is that you can combine Camel with other Java software. The downside is that you need OSGi support or provide the support for it yourself.

Support for Apache Karaf

Originally, a lot of people used Camel and Karaf through ServiceMix which packs Camel together with the message broker Apache ActiveMQ and the webservices framework Apache CXF. As ServiceMix isn’t actively maintained it’s now better to just use a vanilla Karaf container.

WildFly (Jboss Application Server)

WildFly is an application server developed by Red Hat. The application server hosts Java applications, including Camel. The WildFly-Camel subsystem allows you to add Camel Routes as part of the WildFly configuration. Routes can thus be deployed as part of Java EE applications.

Java EE components can access the Camel Core API and various Camel Component APIs. In practice, you build your Camel application with Java, use some specific WildFly configuration and then pack it as .war file. Like Karaf, WildFly supports hot deployment by dropping it into a deploy directory.

WildFly Camel User Guide

Main

With the introduction of Camel 3, the main runtime was introduced. This is a module to run Camel standalone. The main module is technically not a real runtime in the sense that you install it and then run integrations. It’s used by extending classes in your Java code. Those classes can then use the application.properties. With more than 100 properties, main is a flexible and extensive way to configure without writing a lot of code.

# https://camel.apache.org/components/next/others/main.html
camel.main.name = MyCoolCamel

# allows source:line precise logging
camel.main.sourceLocationEnabled=true

# application properties
hi = Hello

Main

Spring Boot

Camel with Spring Boot gives a few advantages that comes with the convention over configuration framework. Some are:

• Runs in a Spring Boot available servlet (Tomcat, Jetty or Undertow).
• Autoconfiguration of Spring and Camel.
• Auto startup of the Camel context and available through beans throughout the application.
• Many Camel starters for Spring Boot.

Camel supports Spring Boot, including an opinionated autoconfiguration of the Camel context and starters for many Camel components. The auto-configuration of the Camel context detects Camel routes available in the Spring context and registers the key Camel utilities (like producer template, consumer template, and the type converter) as Spring beans. This approach is very container friendly, resulting in a very lean server environment that can be easily replicated on demand.

Apache Camel Spring Boot starters

Quarkus

Quarkus is a Java Framework sponsored by Red Hat. Quarkus is designed for building lightweight, container-native, and cloud-native applications.

Camel Quarkus aims to bring Camel integrations patterns and component together with the Quarkus runtime. Camel 3.0 was also specifically designed to be modular and friendly to compile natively. The combination of Quarkus and Camel make them excellent for Microservices on Kubernetes, but it can also run on premise when needed. This leads to fast startup times, a small memory footprint and container-native software (built-in health checks and observability).

To leverage the potential of Quarkus (like native compilation), the Camel Quarkus project provides Quarkus extensions for many of the Camel components.

Apache Camel extensions for Quarkus

Kafka

Apache Kafka is a distributed event store and stream-processing platform. In a sense this means that Kafka is an integration platform itself. It however focuses very much on messages that are posted on its broker and clients that can pull the data out. It lacks a lot of the integration patterns and components that Camel has.

But what if you can combine the superpowers of Kafka and Camel? This is possible through the Camel Kafka Connector. This project allows you to use all Camel components as Kafka Connect connectors. The basic idea is reusing the available Camel components as Kafka sink and source connectors in a simple way. Kafka is then the runtime.

Camel Kafka Connector

CamelK (Camel on Kubernetes)

One of the biggest projects under the Camel umbrella is CamelK. Though Camel can run with most other runtimes on Kubernetes, the CamelK project allows to run Camel natively on Kubernetes and is specifically designed for serverless and microservice architectures. Because of the specific nature of Kubernetes as cloud-native orchestration engine, it makes sense to have software that is tightly fit to its concepts.

The project also provides special tooling, like the command line tool Kamel, special configuration through Kamelets and ready to run integrations through the Kamelets catalog. Though these functionality makes them a bit further from plain Camel as other runtimes do, it also brings a lot of power for developers to deploy and scale integrations in the cloud.

Apache Camel K

JBang

One of the reasons to use a runtime, is that it removes a lot of the setup. This is an area where JBang excels. Just one download and one command is enough to create, edit and run Java. You can run both binary as directly from source.

Camel Jbang makes it possible to have the same level of ease for Camel integrations. When JBang is installed all you need to do is:

jbang app install camel@apache/camel

And then:

camel --help

Then it can be used for fast prototyping of a Camel integration like running it from source, live reload and download dependencies. At the end you can export it to other runtimes like Camel Main, Camel Spring Boot or Camel Quarkus to run the integrations in production.

Camel JBang

jBPM (KIE-Server)

KIE Server is a component of the Red Hat JBoss BPM Suite and Red Hat Process Automation Manager. It provides a runtime environment for executing business processes and rules that have been authored using the Drools or jBPM frameworks. The name “KIE” stands for “Knowledge Is Everything”, which reflects the importance of knowledge management in the development and execution of business processes.

To make use of the camel-jbpm component in a KIE Server you can just add the following two jars into KIE Server application:

• camel-core
• camel-jbpm

After that Camel routes can be added. Either by creating a file named global-camel-routes in the root of the class path of KIE Server or place the Camel XML in the resources folder of a KJAR file. It will be automatically found and registered on every KJAR deployed to KIE Server.

JBPM

Assimbly

Assimbly is a runtime to run Camel routes and DIL flows. They can be run from Filesystem (hot deployment), Java API, REST API or a graphical user interface.

Assimbly is a modular monolith. This means it can run everything in one jar (or one Docker), but can also run functions separately. More on the architecture can be read here:

Architecture of Assimbly

The idea behind Assimbly is that it uses plain Camel with simplified API’s on top of it. In a sense its concept is comparable of how ElasticSearch relates to the search engine Lucene. ElasticSearch provides a runtime with a REST API. Assimbly uses Apache Camel as engine with (REST) API’s on top of it.

Assimbly Gateway is a reference implementation. It uses Spring Boot to run integrations, but the runtime could also be embedded in a command line tool or other technologies when needed. Besides running Camel routes, it also supports the DIL (Data integration Language) format. This is a format inspired by Dataflows:

Data Integration Language

Open Source Integration Modules | Assimbly

Minho

Minho is an experimental project by the Apache Karaf team (lead by Jean Baptiste Onofre). It doesn’t target Camel specifically, but it’s a very generic runtime to run Java software created with various frameworks. Say for example part of the organization uses OSGi Karaf, other uses war files (made for Wildfly) and yet other use Spring Boot. All these can be mixed together into one or more instances of Minho. This again make all the software ready to run with the same (JSON) configuration on premise, in Docker or on Kubernetes. One could say it is a runtime of runtimes.

https://jbonofre.github.io/karaf5/

Camel website:

Home