Camel Achitecture

The following illustration provides a high-level view of the main concepts that comprise the Camel Architecture:

CamelContext

At the core of Camel is the CamelContext and it is the container that is the runtime of Camel. It is the runtime system that links everything together and provides access to many useful services:

Routing Engine

Camel’s routing engine is what moves messages under the hood. This engine isn’t exposed to the developer, but you should be aware that it’s there and that it does all the heavy lifting, ensuring that messages are routed properly.

Routes

Routes are a core abstraction for Camel. The simplest way to define a route is as a chain of Processors. There are many reasons for using routers in messaging applications. By decoupling clients from servers, and producers from consumers, routes can for example do the following:

• Determine dynamically which server a client will invoke

• Provide a flexible way to integrate additional processing

• Allow for clients and servers to be created independently

• Promote better design practices by connecting different systems

• Allow the clients of servers to be stubbed out (ie. use of mocks) for testing purposes

Every route developed in Camel has a unique identifier that’s used for logging, debugging, monitoring, and starting and stopping routes.

Domain Specific Language (DSL)

To wire processors and endpoints together to form routes, Camel defines a DSL (either Java or XML). Camel provides multiple DSL languages, so you could define the same route by using the XML DSL, like this:

<route>
    <from uri="file:data/inbox"/>
    <filter>
        <xpath>/order[not(@test)]</xpath>
        <to uri="jms:queue:order"/>
    </filter>
</route>

Or, in YAML like this:

- from:
    uri: "file:data/inbox"
    steps:
      - filter:
          xpath: "/order[not(@test)]"
          steps:
            - to: "jms:queue:order"

NOTE: The DSLs provide a nice abstraction for Camel users to build applications with. Under the hood, though, a route is composed of a graph of processors.

Processors

The processor is a core Camel concept that represents a node capable of using, creating, or modifying an incoming exchange.

During routing, exchanges flow from one processor to another; as such, you can think of a route as a graph having specialized processors as the nodes, and lines that connect the output of one processor to the input of another. Processors could be implementations of EIPs, producers for specific components, or your own custom code.

A route initiates with a consumer (i.e. using the from in the DSL) and that populates the initial exchange. At each subsequent processor step, the out message from the prior step is the in message of the next.

In some situations, processors don’t set an out message, so in this situation the in message is reused. At the end of a route, the MEP of the exchange determines whether a reply needs to be sent back to the caller of the route. If the MEP is InOnly, no reply will be sent back.

Endpoint

An endpoint is the Camel abstraction that models the end of a channel through which a system can send or receive messages.

In Camel, you configure endpoints by using URIs, (ie. file:data/inbox?delay=5000), and you also refer to endpoints this way. At application runtime, it will look up an endpoint based on the URI notation.

This illustration shows how an endpoint works together with an exchange, producers, and consumers.