Progress
External Program
Interfaces


Reply Mechanisms

This section applies to both the Pub/Sub and the PTP domains. In Java–JMS, there is no built-in mechanism for replies. It is the responsibility of the application to designate a destination (typically a temporary destination) for replies. It is also the responsibility of the application to send this Destination object to the receiver (typically through the replyTo message header field). (A message header is a group of fields in a message containing values to identify and route messages.) The receiver must extract the reply destination from the message and follow the normal publish (or send) steps to reply.

The 4GL–JMS API simplifies that process for the sender who wants to receive a reply as well as for the receiver who wants to reply:

An application can also publish a reply message (or send it to a queue) by extracting the name of the reply destination by calling getJMSReplyTo and then calling publish (or sendToQueue) 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 the SonicMQ Programming Guide for information on temporary destinations.) Deleting the original message tells the 4GL–JMS implementation that the replyTo temporary destination is not going to be used anymore.

By default, the type of the ReplyTo destination matches the type of the origin of the message:

However, it is legal to designate a reply queue for a published message and to designate a reply topic for messages received from a queue. To accommodate this, the 4GL–JMS API supports the setReplyToDestinationType procedure and the getReplyToDestinationType function. The values that an application can set or get are “topic” and “queue.” The setReplyToDestinationType procedure must be called when the 4GL application calls setJMSReplyTo with a destination from a different domain than the session. The getReplyToDestinationType function must be called when the 4GL application receives a message and wants to reply to it, but is not certain about the ReplyTo domain.

Using a Second Session For Replying

There are scenarios where the 4GL application might need to reply through a session different from the one that received the original message. For example, the publisher of the message might like to designate a queue, rather than a topic, for receiving the replies. The publisher would set the JMSReplyTo header field to the name of the queue and then publish the message. The receiver would receive the message through a Pub/Sub session, extract the queue from the JMSReplyTo header field, and send the reply to that queue using ptpsession.p. Then, the original publisher would use ptpsession.p to receive the reply.

The 4GL–JMS API supports this functionality with these limitations:


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095