Menu
I've been poring over the Apache Camel docs trying to get a concrete understanding of two of its most basic concepts (endpoints and routes), and although these terms are used everywhere throughout the docs, I can find no reference that actually defines what they are and what they are used for. And although their names are fairly obvious-sounding, and I think I understand what they are, I've now been assigned to a task that has landed me neck-deep in Apache Camel Land, and its absolutely vital that I understand what these mechanisms are.
My guess is that an "endpoint" is just a bean - one that can be configured in a config file like any other - that maps a name to a URI/port combo (this taken from the W3C docs). In the context of Apache Camel, my guess is that endpoints are used to connect components together, so that "routes" (connections/maps) can be formed between them. So when Component A living at Endpoint 1 wants to communicate with Component B living at Endpoint 2, so long as there is a mapping from 1 to 2, Camel will be able to transmit messages between these two.
Please stop me and correct me if I am wrong here!
So now, I've seen examples where it looks like routes can be configured in Java:
from("endpointA").routeId("someMessage").to("endpointB");
And I've seen examples where it looks like routes can be configured in XML:
<route id="">
<from .../>
<to .../>
</route>
Are these two methods for configuring routes, or are they different concepts altogether?
Finally, what is the format of the messages that can be routed between endpoints? If it has to be XML, for example, what is the XSD/schema of these routed messages? If it has to be a Java object, what bounds/restrictions apply to the objects that Camel can send?
581
Contents. A Camel route is where the integration flow is defined. For example to integrate two systems then a Camel route can be coded to specify how these systems are integrated. An example could be to take files from a FTP server and send to a ActiveMQ messaging system.
The SEDA component provides asynchronous SEDA behavior, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread from the producer. Note that queues are only visible within a single CamelContext.
The autoStartup option on the <camelContext> is only used once, so you can manually start Camel later by invoking its start method in Java as shown below. For example when using Spring, you can get hold of the CamelContext via the Spring ApplicationContext : ApplicationContext ac = ... CamelContext camel = ac.
The CamelContext is the runtime system, which holds everything together as depicted in the figure below. The CamelContext provides access to many useful services, the most notable being components, type converters, a registry, endpoints, routes, data formats, and languages. Contains the components used.
It seems like you are getting a decent grasp of the concept. I think it helps to think about endpoints in more abstract terms. The camel documentation is not much help here. Endpoints can be thought of as interfaces to a component. Each component can have 1 or more endpoints configured. It helps me to think about endpoints within the context of a route. A simple route can go from Endpoint A (This could be a JMS Queue, tcp socket, file or any camel component) and go to Endpoint B (which can be any camel component). You can of course have processors in the route too that transform the data.
The two examples of route creation you give are just that, two ways to create a route. They are the examples of the same concept. The first being Java DSL and the second using XML.
The format of the messages is typically XML, and the XML can be any valid XML and does not need to be tied to an XSD. The message can also be any Java object. As long as it is staying in the JVM (ie, not going over a socket) it doesn't need to be serializeable.
57
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
