KnowledgeShop

Learn & Share

Apache Camel

  • Camel is an integration framework, not an ESB.
  • Camel is a routing engine builder
  • Camel is based on patterns defined in Enterprise Integration Patterns by Gregor Hohpe and Bobby Wolf

Messaging Model

  • org.apache.camel.Message —The fundamental entity containing the data being carried and routed in Camel
  • org.apache.camel.Exchange — The Camel abstraction for an exchange of messages. This exchange of messages has an “in” message and as a reply, an “out” message

Messages

  • Messages are the entities used by systems to communicate with each other when using messaging channels.
  • Messages flow in one direction from a sender to a receiver
  • Messages have a body (a payload), headers, and optional attachments
  • Messages are uniquely identified with an identifier of type java.lang.String. The identifier’s uniqueness is enforced and guaranteed by the message creator, it’s protocol dependent, and it doesn’t have a guaranteed format. For protocols that don’t define a unique message identification scheme, Camel uses its own UID generator.

  • During routing, messages are contained in an exchange.

  • Headers and Attachments
    • Headers are values associated with the message, such as sender identifiers, hints about content encoding, authentication information, and so on.
    • Headers are name-value pairs; the name is a unique, case-insensitive string, and the value is of type java.lang.Object. Headers are stored as a map within the message.
    • A message can also have optional attachments, which are typically used for the web service and email components.
  • Body
    • The body is of type java.lang.Object, and can store any kind of content.
    • When the sender and receiver use different body formats, Camel provides a number of mechanisms to transform the data into an acceptable format, and in many cases the conversion happens automatically with type converters, behind the scenes.
  • Fault Flag
    • Messages also have a fault flag. Some protocols and specifications, such as WSDL and JBI, distinguish between output and fault messages. They’re both valid responses to invoking an operation, but the latter indicates an unsuccessful outcome. In general, faults aren’t handled by the integration infrastructure. They’re part of the contract between the client and the server and are handled at the application level.

Exchanges

  • An exchange is the message’s container during routing.
  • Message Exchange Patterns (MEPs)
    • A pattern that denotes whether you’re using the InOnly or InOut messaging style.
    • MEPs are used to differentiate between one-way and request-response messaging styles.
    • InOnly — A one-way message (also known as an Event message). For example, JMS messaging is often one-way messaging.
    • InOut — A request-response message. For example, HTTP-based transports are often request reply, where a client requests to retrieve a web page, waiting for the reply from the server.
  • Exchange ID
    • A unique ID that identifies the exchange.
    • If not provided explicitly it will be auto-generated by default.
  • Exception
  • Properties
    • Similar to message headers, but they last for the duration of the entire exchange.
    • Used to contain global-level information, whereas message headers are specific to a particular message.
    • Camel itself adds various properties to the exchange during routing. Developer can store and retrieve properties at any point during the lifetime of an exchange.
  • In message
    • This is the input message, which is mandatory. The in message contains the request message.
  • Out message
    • This is an optional message that only exists if the MEP is InOut. The out message contains the reply message.

Components
  • Routing Engine
    • is what actually moves messages under the hood
    • uses routes as specifications for where messages are routed.
    • Routes are defined using one of Camel’s domain-specific languages (DSLs).
  • Routes
    • Simplest way to define a route is as a chain of processors.
    • Each route has a unique identifier that’s used for logging, debugging, monitoring, and starting and stopping routes.
    • Routes also have exactly one input source for messages, so they’re effectively tied to an input endpoint.
    • To define a route, a DSL is used
Example Route in Java DSL
1
2
3

from("file:data/inbox")
	.filter().xpath("/order[not(@test)]")
	.to("jms:queue:order")
  • Endpoints
    • In Camel, endpoints are configured using URIs. e.g., file:data/inbox?delay=5000.
      • file denotes which Camel component handles that type of endpoint. In this case, the scheme of file selects the FileComponent. The FileComponent then works as a factory creating the FileEndpoint based on the remaining parts of the URI.
      • The context path tells the FileComponent that the starting folder is data/inbox.
      • The option, delay=5000 indicates that files should be polled at a 5 second interval.
  • Processors
    • used to transform and manipulate messages during routing and also to implement all the EIP patterns.
    • The processor represents a node capable of using, creating, or modifying an incoming exchange.
    • During routing, exchanges flow from one processor to another; as such, you can think of a route as a graph having specialized processors as the nodes, and lines that connect the output of one processor to the input of another.
  • Components
    • are the extension points in Camel for adding connectivity to other systems. To expose these systems to the rest of Camel, components provide an endpoint interface.
    • There are over 80 components in the Camel ecosystem that range in function from data transports, to DSLs, data formats, etc.
    • Components are associated with a name that’s used in a URI, and they act as a factory of endpoints. E.g., a FileComponent is referred to by file in a URI, and it creates FileEndpoints.
  • Producers
    • an entity capable of creating and sending a message to an endpoint.
    • When a message needs to be sent to an endpoint, the producer will create an exchange and populate it with data compatible with that particular endpoint. For example,
      • a FileProducer will write the message body to a file.
      • A JmsProducer, on the other hand, will map the Camel message to a javax.jms.Message before sending it to a JMS destination.
    • It hides the complexity of interacting with particular transports. All you need to do is route a message to an endpoint, and the producer does the heavy lifting.
  • Consumers
    • A consumer is the service that receives messages produced by a producer, wraps them in an exchange, and sends them to be processed.
    • Consumers are the source of the exchanges being routed in Camel.
    • To create a new exchange, a consumer will use the endpoint that wraps the payload being consumed.
    • A processor is then used to initiate the routing of the exchange in Camel using the routing engine.
    • Consumer Types
      • Event-driven consumer
      • Polling consumer
Event-driven consumer Polling consumer

Bibliography

  • Books
    • Camel in Action by Claus Ibsen, Jonathan