Loosely coupled applications require special techniques when it is important for the publisher to certify that a message was delivered in either messaging domain:

A message producer can request a reply when a message is sent. A common way to do this is to set up a temporary destination and header information that the consumer can use to create a reply to the sender of the original message.

In both request and reply samples, the replier’s task is a simple data processing exercise: standardize the case of the text sent—receive text and send back the same text as either all uppercase characters or all lowercase characters—then publish the modified message to the temporary destination that was set up for the reply.

While request-and-reply provides proof of delivery, it is a blocking transaction—the requestor waits until the reply arrives. While this situation might be appropriate for a system that, for example, issues lottery tickets, it might be preferable in other situations to have a formally established return destination that echoes the original message and a correlation identifier—a designated identifier that certifies that each reply is referred to its original requestor.

The sample applications use JMS sample classes TopicRequestor and QueueRequestor. You should create the Request/Reply helper classes that are appropriate for your application.

These request and reply samples show that request/reply mechanisms are very similar across messaging models, and that, while there might be zero or many subscriber replies, there will be, at most, one PTP reply.