This is part two of a three-part series on using Drools Expert with Apache Camel. Today’s topic provides a basic overview of Apache Camel. Part one covered Drools Expert, and part three will contain a complete working example.
What is Apache Camel?
Apache Camel is a framework that implements many Enterprise Integration Patterns. Camel allows developers to define “routes” which listen for and process specific events (e.g., data from a network endpoint or a direct call from another Camel route). Routes are composed of a Consumer (a “from” endpoint) followed by a series of Processors (“to” endpoints), as illustrated by the following example. (Note that Processor endpoints do not necessarily have to begin with the element name “to”.)
Route snippet derived from an official Apache Camel example
How Data Flows Through Routes
The route’s Consumer listens for data events and uses each event’s information to create an Exchange object that contains an “in” Message. The message contains a known POJO, which can range from a Java object with simple field accessor methods to more complex objects such as arbitrary byte arrays, InputStreams, or XML DOM objects.
Class Diagram of the Exchange / Message / Body relationship
The Consumer passes its Exchange to the next Processor in the route, which inspects the given “in” Message, executes its business logic, and puts a new POJO in the Exchange’s “out” Message. The next Processor in the chain will then receive an Exchange whose “in” Message is the previous Processor’s “out” Message, repeating the pattern until the route is complete.
Processors inherit outgoing Messages
Generally each Processor’s resulting “out” message is a modification of its given “in” message. Processor business logic can be arbitrary Java code. Typically, a Processor will call other services, send messages to “from” endpoints in other routes directly, or modify the given Message to pass to the next Processor in the route.
The first Processor that follows a Consumer is typically a Message Translator EIP (such as a Camel Type Converter component) that converts the body of the Exchange’s “in” Message from its original format into a Java object with simple field accessor methods. This simplifies the business logic required to understand incoming data within Processors further down the route.
How Does Drools Fit In?
A Drools Expert knowledge session can serve as a Processor in a Camel route. The input to the knowledge session is generally the known incoming POJO within the body of the Exchange’s “in” Message. Rule conditions can be most easily written when this body is a Java object with simple field accessor methods. As such, a Message Translator may be necessary to ensure Drools can inspect incoming data through accessor methods easily. After the rules are applied to the input, the output will generally be a modification of the incoming POJO, which will be used as the body of the next Processor’s “in” Message.
Camel routes can contain conditional statements that cause the next element in the route to be one of many different Processors based on the values within the Exchange they receive. Because the output of the knowledge session’s execution can be the input to a conditional statement, rules can affect a decision about the next endpoint the message should enter.
Condition statement adapted from blog-camel-context-simple.xml
By creating a decision that changes the message’s flow in the route, Drools can act as a Content Based Router EIP if the knowledge session is stateless; and it can act as a Dynamic Router EIP if the knowledge session is stateful.
The next part of this series will describe a working example of using Drools in Camel with downloadable code samples. If you have any questions over this introduction to Apache Camel, feel free to use the comments section below or contact us at email@example.com. Be sure to stay tuned for the next part of this series by following us on Twitter at @CrederaOpen or connecting with us on LinkedIn.