...
NOTE: It is important to recognize that this format is only for a generic model of a message. Apache Camel supports a large variety of protocols and endpoint types. Hence, it isn't possible or conceivable to standardize the format of the message body or the message headers.
Output message
This is a temporary holding area for a reply message or for a message that has been transformed. Certain processing nodes can modify the current message by treating the input message as a request, routing it to a producer endpoint, and then receiving a reply back from that endpoint. The reply message from the endpoint will then be inserted into the output message slot in the exchange.
Message Exchange Patterns (MEP)
These are patterns that will impact the interaction between the exchange and endpoints in the route, as follows:
Consumer endpoint — this creates the original exchange and will define the initial value of the MEP. This starting value will indicate whether the consumer endpoint expects to receive a reply (by using the InOut MEP) or not (with the use of the InOnly MEP).
Producer endpoints — the MEP will impact the producer endpoints that our exchange passes through along the route. For example, if the current MEP has been set InOnly, a destination node would not expect to receive a reply from the endpoint. There may be occasions when we need to change the state of the MEP to customize the exchange’s interaction with a producer endpoint.
Message exchange patterns
The use of an Exchange object makes it simple to generalize message processing to different message exchange patterns. As an example, an asynchronous protocol might define an MEP that consists of a single message that travels from the consumer to producer endpoint (ie. InOnly MEP).
An RPC protocol (remote procedure call), might define an MEP that consists of only a request and a reply message (ie. InOut MEP). Currently, Apache Camel supports the following MEPs:
InOnly
RobustInOnly
InOut
OutOnly
InOptionalOut
OutIn
OutOptionalIn
RobutstOutOnly
Processors
A processor is a node in a route that can access and modify the stream of exchanges passing through the route. Processors can accept either expression or predicate arguments that can modify their behavior. As an example, the local routing rule shown earlier on this page includes a Filter processor that takes an XPath() predicate as its passed argument.