Continuing the example shown in part1 we now add a new feature, the Claim Check. This is the Apache Camel / CDI equivalent of another Spring Integration example shown before. This pattern, along with most of the groundwork used in enterprise integration, was first codified in “Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf. This book is a must read for any one working in this area, regardless of the tool.
In this example we add the necessary pieces to store data in an external data store while our original message is route throughout our system. The main motivation is to avoid sending and receiving large amounts of data through JMS or other similar systems that are designed to handle low latency communication. Contrary to Spring Integration, Apache Camel does not offer an out of the box implementation of the the Claim Check pattern. The pattern and how to implemented are described here.
There are talks of introducing one for Apache Camel 3.0, but reading the discussions it becomes evident that providing a flexible general case implementation is complicated. Spring Integration provides an implementation, but many times it’s insufficient, as it becomes evident that it’s necessary to only store parts of the message (most likely binary portions of the message), while keeping most of the message to be processed along the pipeline. The general flow of this pattern can be seen below:
To implement the Claim Check pattern, five different new classes were created. The first two classes provide the actual implementation of the two pieces that make up the Claim Check pattern.
The two pieces are in essence a Content Filter that removes part of the content (and stores it in separate database), and a Content Enricher that will pull the data from database and back into the message. The code is seen below:
The data store provides a very simple abstraction to put, get, and delete objects from the database. This current implementation is using JDBC, but shows the basics of how a data store can be implemented:
The last two new classes,
DataSourceProvider, provide the connections to the database, as well as starting the in memory H2 database. Theses classes are normally not needed, since connections are handled by the application server in most Java EE applications. There were added here to provide similar functionality without an application server. You’re welcome to look at the code, but in future post I’ll explain in more detail how to provide these services from inside CDI.
Wiring it all together
Once we have our classes implementing the functionality, the wiring is very simple:
All it takes is adding one destination before and one after. In Camel, declaring multiple destinations will create a pipeline. This means that the message will be sent to the first destination, then the result of the first destination will be sent to the second destination, and so on. This in contrast to multicast, which will send the same message to all of the destinations.
The first change is the addition of
jms:queue:order. What this does is to check out the data and putting it back on the message once the response arrives. Something similar is done on the server side. First we process the request using the
orderServiceHandler bean, and then put the response in the data store. This particular configuration is using the check in for only the response.
It’s fairly easy to change it to use the claim check for both the request and the response. It’s worth noting that such cases are not common in practice, as normally either the response or the request are large.
In this case, request is also stored. Since our check in method stores the whole object, this will an instance of BeanInvokation. This method contains the parameters and other information need to invoke the service method. Based on your needs, you could of course only extract part of this object, for example one or more of the parameters, while keeping the rest of the message intact.
Side by side comparison with Spring Integration
The following sections compare mostly equivalent Spring Integration XML to their Apache Camel DSL. I have not included the implementation of the extra infrastructure pieces which Apache Camel requires.
Routing to a JMS queue and then retrieing the data from the data store
Listening to a JMS queue and routing messages to a bean and storing the result
From this short tutorial, it’s evident that Apache Camel requires quite a bit extra code to accomplish the same tasks we did with Spring Integration. However, most of it becomes irrelevant if running inside an application server, which is the main target for CDI. The biggest piece that I feel should be provided by Apache Camel is a set of data stores using common data sources such as JDBC, JPA, and some of the more popular NoSQL databases. However, once that hurdle is overcome, Apache Camel shines in the ease in which complex problems can be solved in clear concise and easy to maintain code. So which one is better? A lot of it depends on what framework you’re already using (Spring vs CDI), and if any of the integration platforms provides a particular esoteric feature. But in the end, both tools are very capable and easy to use.
You can find the source code for this example in github.
To check out the code clone the following repository:
git clone https://github.com/aolarte/camel-integration-samples.git
git checkout branches/part2
This example can be run directly from maven. For example :
mvn exec:java -Dexec.mainClass="com.javaprocess.examples.integration.main.Main" -Dexec.args="server client"