Apache Camel (Concepts)
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:
Service | Description |
|---|---|
Components | Contains the Camel components that are factory of endpoints |
Endpoints | Camel abstraction that models the end of a channel which can send or receive messages |
Routes | Represents a chain of processors |
Data Formats | List of available data formats |
Languages | Used to wire together endpoints and processors |
Type Converters | Allows for the conversion from one type to another |
Registry | Contains a registry to allow for the lookup of beans |
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.
Producer
A producer is an abstraction that refers to an entity that is capable of transmitting a message to an endpoint. When a message is sent to an endpoint, it is the role of the producer to handle the details of getting the message data compatible with that particular endpoint.
For example, FileProducer will write the message body to a java.io.File format. While, JmsProducer, will map the message to javax.jms.Message before sending it to a JMS destination. This is an important attribute of Camel, since it hides the complexity of interacting with any one particular transports. All you need to do is route a message to an endpoint, and the producer will do all of the heavy lifting.
Consumer
A consumer is a service that receives messages produced by an external system, then wraps them in an exchange, and sends them onward to be processed. Consumers are the source of the exchanges being routed in Camel.
To create a new exchange, a consumer will use the endpoint that wraps the payload being consumed. A processor is then used to initiate the routing of the exchange in Camel via the routing engine.
Camel has two kinds of consumers: event-driven consumers, and polling consumers (or scheduled polling consumers). The differences between these consumers are important, because they help solve different problems.