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:
- Sender — The 4GL–JMS API requestReply method can publish messages the same way as the publish method, or send messages to a queue the same way as the sendToQueue method. In addition, a messageConsumer object for replies is passed to it as an input parameter (see the "Subscribing To a Topic" and "Receiving Messages From a Queue" sections for information about message reception). The 4GL–JMS implementation automatically routes all the replies to that messageConsumer object.
- Receiver — To reply, the message receiver returns a reply message handle as an output parameter in the message-handler routine. The application can call the setReplyAutoDelete procedure in the messageConsumer object to automatically delete the replies after sending them.
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 useptpsession.p
to receive the reply.The 4GL–JMS API supports this functionality with these limitations:
- The JMSReplyTo header field cannot be set with the name of a temporary destination that came from a session different from the one used to send the message.
- If the 4GL application sets the JMSReplyTo with a destination domain different from the session that will be used to send the message, it must use the Java Naming and Directory Interface (JNDI) (or other administered object storage) name of that object. (See the "Finding Administered Objects In JNDI Or Proprietary Directories" section in
Using the SonicMQ Adapter.")- An automatic reply (through the output reply parameter of the message-handling routine) does not work if the domain of the JMSReplyTo header field is different than the domain of the session. The application must send the reply explicitly through a second session.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |