Try OpenEdge Now
skip to main content
Messaging and ESB
Implementing Messaging : Consuming messages : Reply mechanisms
 

Reply mechanisms

This section applies to both the Pub/Sub and the PTP domains.
Java–JMS provides no built-in mechanism for replies. It is the responsibility of the application to:
*Designate a Destination object (typically a temporary destination) for replies
*Send this Destination object to the receiver (typically through the ReplyTo field in the message header, a set of fields containing values to identify and route the message)
The receiver must extract the reply destination from the message and follow the normal publish (or send) steps to reply.
The ABL–JMS API simplifies this process, both for the sender needing a reply and for the receiver needing to reply:
*Sender — The ABL–JMS API requestReplyprocedure can publish messages in the same way as the publish procedure, or send messages to a queue in the same way as the sendToQueue procedure. In addition, a Message Consumer object for replies is passed to the requestReply procedure as an input parameter. The ABL–JMS implementation automatically routes all the replies to that Message Consumer object. See Request/Reply for additional information.
*Receiver — To reply, the message receiver returns a reply message handle as an output parameter in the message-handling routine. The application can call the setReplyPersistencyprocedure in the Message Consumer object to automatically delete replies after sending them.
An application can also publish a reply message or send it to a queue by first calling the getReplyToDestinationType function to extract the name of the reply destination, and then calling the publish procedure or sendToQueue procedure directly.
Note: If the ReplyTo destination is a temporary destination, an application must send a reply before deleting the original message. (See the Java Message Service specification and SonicMQ Programming Guide for information on temporary destinations.) Deleting the original message tells the ABL–JMS implementation that the ReplyTo temporary destination will no longer be used.
By default, the type of the ReplyTo destination matches the type of the origin of the message:
*If the message was created by a Pub/Sub Session object, the value of the ReplyTo field is considered a topic name
*If the message was created by a PTP Session object, the value of the ReplyTo field is considered a queue name
However, it is legal to designate a queue for replying to a published message, or a topic for replying to messages received from a queue. To accommodate this, the ABL–JMS API supports the setReplyToDestinationType procedure and the getReplyToDestinationType function, both of which support the CHARACTER values topic and queue.
The setReplyToDestinationType procedure can be called if the OpenEdge application calls the setJMSReplyTo procedure and sets a destination from a domain other than that of the session. The getReplyToDestinationType function must be called when the OpenEdge application receives a message and wants to reply to it, but is not certain about the ReplyTo domain.