Request-reply messaging

JMS messaging with Camel (and in general) is asynchronous by default. Messages are

sent to a destination, and the client doesn’t wait for a reply. But there are times when

it’s useful to be able to wait and get a reply after sending to a destination. One obvious

application is when the JMS destination is a frontend to a service—in this case, a client

sending to the destination would be expecting a reply from the service.

JMS supports this type of messaging by providing a JMSReplyTo header, so that the

receiver knows where to send the reply,

and a JMSCorrelationID, used to match

replies to requests if there are multiple

replies awaiting. This flow of messages is

illustrated in figure 7.5.

Camel takes care of this style of messaging,

so you don’t have to create special

reply queues, correlate reply

messages, and the like. By changing the

message exchange pattern (MEP) to

InOut, Camel will enable request-reply

mode for JMS.

To demonstrate, let’s take a look at an order validation service within Rider Auto

Parts’ backend systems that checks orders against the company database to make sure

the parts listed are actual products. This service is exposed via a queue named validate.

The route exposing this service over JMS could be as simple as this:

from("jms:validate").bean(ValidatorBean.class);

 

When calling this service, you just need to tell Camel to use request-reply messaging by

setting the MEP to InOut. You can use the exchangePattern option to set this as follows:

from("jms:incomingOrders").to("jms:validate?exchangePattern=InOut")...

You can also specify the MEP using the inOut DSL method:

from("jms:incomingOrders").inOut().to("jms:validate")...

With the inOut method, you can even pass in an endpoint URI as an argument, which

shortens your route:

from("jms:incomingOrders").inOut("jms:validate")...

By specifying an InOut MEP, Camel will send the message to the validate queue and

wait for a reply on a temporary queue that it creates automatically. When the ValidatorBean

returns a result that message is propagated back to the temporary reply

queue, and the route continues on from there.

Rather than using temporary queues, you can also explicitly specify a reply queue.

This can be done by setting the JMSReplyTo header on the message or by using the

replyTo URI option described in table 7.5.

A handy way of calling an endpoint that can return a response is by using the

request methods of the ProducerTemplate. For example, you can send a message into

the incomingOrders queue and get a response back with the following call:

Object result = template.requestBody("jms:incomingOrders",

"<order name=\"motor\" amount=\"1\" customer=\"honda\"/>");

This will return the result of the ValidatorBean.

To try this out for yourself, go to the chapter7/jms directory in the book’s source,

and run this command:

mvn test -Dtest=RequestReplyJmsTest

The command will run a unit test demonstrating request-reply messaging as we’ve discussed

in this section.

In the JMS examples we’ve looked at so far, several data mappings have been happening

behind the scenes—mappings that are necessary to conform to the JMS specification.

Camel could be transporting any type of data, so that data needs to be

converted to a type that JMS supports. We’ll look into this next.