Camel’s message model

In Camel, there are two abstractions for modeling messages, both of which we’ll cover in this section.

■ 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

An exchange in  Camel  is  the  message’s  container  during  routing.  An  exchange  also provides support for the various types of interactions between systems, also known as message exchange patterns (MEPs). MEPs are used to differentiate between one-way and request-response messaging styles. The Camel exchange holds a pattern property that can be either

■ InOnly—A one-way message (also known as an Eventmessage). 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.

A  unique ID that  identifies the exchange. Camel will generate a default unique ID, if you don’t explicitly set one.

A  pattern  that  denotes  whether you’re using the InOnlyor InOutmessaging style. When the pattern is InOnly, the exchange  contains  an  in  message.  For InOut, an out message also exists that contains the reply message for the caller.

If an error occurs at any time during routing, an Exceptionwill be set in the exception field.

Similar to  message headers,  but  they  last  for  the  duration  of  the entire  exchange.  Properties  are  used  to  contain  global-level  information, whereas message headers are specific to a particular message. Camel itself will add various properties to the exchange during routing. You, as a developer, can store and retrieve properties at any point during the lifetime of an exchange.

This is the input message, which is mandatory. The in message contains the request message

This is an optional message that only exists if the MEPis InOut. The out message contains the reply message.

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, as illustrated in figure 1.3.

Messages have a body (a payload), headers, and optional attachments, as illustrated in figure 1.4.

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 UIDgenerator.

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. This means that Camel imposes no constraints on the type of the headers. 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.

The body is of type java.lang.Object. That means that a message can store any kind of content. It also means that it’s up to the application designer to make sure that the receiver can understand the content of the message. 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.