Since we're on a major migration process of this website, some component documents here are out of sync right now. In the meantime you may want to look at the early version of the new website
https://camel.apache.org/staging/
We would very much like to receive any feedback on the new site, please join the discussion on the Camel user mailing list.
QuickstartTo start using Apache Camel quickly, you can read through some simple examples in this chapter. For readers who would like a more thorough introduction, please skip ahead to Chapter 3. Walk through an Example CodeThis mini-guide takes you through the source code of a simple example. Camel can be configured either by using Spring or directly in Java - which this example does. This example is available in the We start with creating a CamelContext - which is a container for Components, Routes etc: 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: This will start all of the configured routing rules. So after starting the CamelContext, we can fire some objects into camel: What happens?From the ProducerTemplate - we send objects (in this case text) into the CamelContext to the Component test-jms:queue:test.queue. These text objects will be converted automatically into JMS Messages and posted to a JMS Queue named test.queue. When we set up the Route, we configured the FileComponent to listen off the test.queue. The File FileComponent will take messages off the Queue, and save them to a directory named test. Every message will be saved in a file that corresponds to its destination and message id. Finally, we configured our own listener in the Route - to take notifications from the FileComponent and print them out as text. That's it! If you have the time then use 5 more minutes to Walk through another example that demonstrates the Spring DSL (XML based) routing. Walk through another exampleIntroductionContinuing the walk from our first example, we take a closer look at the routing and explain a few pointers - so you won't walk into a bear trap, but can enjoy an after-hours walk to the local pub for a large beer First we take a moment to look at the Enterprise Integration Patterns - the base pattern catalog for integration scenarios. In particular we focus on Pipes and filters - a central pattern. This is used to route messages through a sequence of processing steps, each performing a specific function - much like the Java Servlet Filters. Pipes and filtersIn this sample we want to process a message in a sequence of steps where each steps can perform their specific function. In our example we have a JMS queue for receiving new orders. When an order is received we need to process it in several steps:
This can be created in a route like this: <route> <from uri="jms:queue:order"/> <pipeline> <bean ref="validateOrder"/> <bean ref="registerOrder"/> <bean ref="sendConfirmEmail"/> </pipeline> </route> Pipeline is default In the route above we specify <route> <from uri="jms:queue:order"/> <bean ref="validateOrder"/> <bean ref="registerOrder"/> <bean ref="sendConfirmEmail"/> </route> This is commonly used not to state the pipeline. An example where the pipeline needs to be used, is when using a multicast and "one" of the endpoints to send to (as a logical group) is a pipeline of other endpoints. For example. <route> <from uri="jms:queue:order"/> <multicast> <to uri="log:org.company.log.Category"/> <pipeline> <bean ref="validateOrder"/> <bean ref="registerOrder"/> <bean ref="sendConfirmEmail"/> </pipeline> </multicast> </route> The above sends the order (from <route> <from uri="jms:queue:order"/> <multicast> <to uri="log:org.company.log.Category"/> <bean ref="validateOrder"/> <bean ref="registerOrder"/> <bean ref="sendConfirmEmail"/> </multicast> </route> you would see that multicast would not "flow" the message from one bean to the next, but rather send the order to all 4 endpoints (1x log, 3x bean) in parallel, which is not (for this example) what we want. We need the message to flow to the validateOrder, then to the registerOrder, then the sendConfirmEmail so adding the pipeline, provides this facility. Where as the <bean id="validateOrder" class="com.mycompany.MyOrderValidator"/> Our validator bean is a plain POJO that has no dependencies to Camel what so ever. So you can implement this POJO as you like. Camel uses rather intelligent Bean Binding to invoke your POJO with the payload of the received message. In this example we will not dig into this how this happens. You should return to this topic later when you got some hands on experience with Camel how it can easily bind routing using your existing POJO beans. So what happens in the route above. Well when an order is received from the JMS queue the message is routed like Pipes and filters: Using Camel ComponentsIn the route lets imagine that the registration of the order has to be done by sending data to a TCP socket that could be a big mainframe. As Camel has many Components we will use the camel-mina component that supports TCP connectivity. So we change the route to: <route> <from uri="jms:queue:order"/> <bean ref="validateOrder"/> <to uri="mina:tcp://mainframeip:4444?textline=true"/> <bean ref="sendConfirmEmail"/> </route> What we now have in the route is a What to notice here is that the <route> <from uri="jms:queue:order"/> <to uri="bean:validateOrder"/> <to uri="mina:tcp://mainframeip:4444?textline=true"/> <to uri="bean:sendConfirmEmail"/> </route> As the ConclusionThis example was provided to demonstrate the Spring DSL (XML based) as opposed to the pure Java DSL from the first example. And as well to point about that the This example is also based on the in-only message exchange pattern. What you must understand as well is the in-out message exchange pattern, where the caller expects a response. We will look into this in another example. See also |