CSC/ECE 517 Spring 2015/ch1a 17 WL
Apache Camel
Overview
Apache Camel is a rule-based routing and mediation engine that provides a Java object-based implementation of the Enterprise Integration Patterns(EIP) using an API (or declarative Java Domain Specific Language) to configure routing and mediation rules. The domain-specific language means that Apache Camel can support type-safe smart completion of routing rules in an integrated development environment using regular Java code without large amounts of XML configuration files, though XML configuration inside Spring is also supported.<ref>http://en.wikipedia.org/wiki/Apache_Camel</ref>
Background
Camel is an integration framework that aims to make your integration projects productive and fun. The Camel project was started in early 2007, but although it’s relatively young, Camel is already a mature open source project, available under the liberal Apache 2 license, and it has a strong community. Camel’s focus is on simplifying integration. We’re confident that by the time you finish reading these pages, you’ll appreciate Camel and add it to your “must have” list of tools. The Apache Camel project was named Camel simply because the name is short and easy to remember. Rumor has it the name may be inspired by the fact that one of the founders once smoked Camel cigarettes. At the Camel website a FAQ entry lists other lighthearted reasons for the name.<ref>http://manning.com/ibsen/chapter1sample.pdf</ref>
In order to understand what Apache Camel is, we need to understand what Enterprise Integration Patterns are.
Let's start with what we presumably already know: The Singleton pattern, the Factory pattern, etc; They are merely ways of organizing your solution to the problem, but they are not solutions themselves. These patterns were analyzed and extracted for the rest of us by the Gang of Four, when they published their book: Design Patterns. They saved some of us tremendous effort in thinking of how to best structure our code.
Much like the Gang of Four, Gregor Hohpe and Bobby Woolf authored the book Enterprise Integration Patterns (EIP) in which they propose and document a set of new patterns and blueprints for how we could best design large component-based systems, where components can be running on the same process or in a different machine.
They basically propose that we structure our system to be message oriented -- where components communicate with each others using messages as inputs and outputs and absolutely nothing else. They show us a complete set of patterns that we may choose from and implement in our different components that will together form the whole system.<ref>http://stackoverflow.com/questions/8845186/what-exactly-is-apache-camel</ref>
Examples
This mini-guide takes you through the source code of a simple example.<ref>http://camel.apache.org/walk-through-an-example.html</ref>
We start with creating a CamelContext - which is a container for Components, Routes etc:
CamelContext context = new DefaultCamelContext();
There is more than one way of adding a Component to the CamelContext. You can add components implicitly - when we set up the routing - as we do here for the FileComponent:
context.addRoutes(new RouteBuilder() { public void configure() { from("test-jms:queue:test.queue").to("file://test"); } });
or explicitly - as we do here when we add the JMS Component:
ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("vm://localhost?broker.persistent=false"); // Note we can explicit name the component context.addComponent("test-jms", JmsComponent.jmsComponentAutoAcknowledge(connectionFactory));
The above works with any JMS provider. If we know we are using ActiveMQ we can use an even simpler form using the activeMQComponent() method while specifying the brokerURL used to connect to ActiveMQ
camelContext.addComponent("activemq", activeMQComponent("vm://localhost?broker.persistent=false"));
In normal use, an external system would be firing messages or events directly into Camel through one if its Components but we are going to use the ProducerTemplate which is a really easy way for testing your configuration:
ProducerTemplate template = context.createProducerTemplate();
Next you must start the camel context. If you are using Spring to configure the camel context this is automatically done for you; though if you are using a pure Java approach then you just need to call the start() method
camelContext.start();
This will start all of the configured routing rules. So after starting the CamelContext, we can fire some objects into camel:
for (int i = 0; i < 10; i++) { template.sendBody("test-jms:queue:test.queue", "Test Message: " + i); }
Conclusion
References
<references/>