From Developer Community

by exteNd Composer Product Team, eBusiness Integration Products, Novell
Date Created: 2001-09-04 09:09:00.000

Contents 1 Introduction 2 Roundtrip Messaging 3 Using the ReplyTo header field 4 The Example Scenario 5 Conclusion

Introduction

In version 2.7 of xCommerce, some major new features have been added to the Enterprise Enabler for JMS, including:

• Multiple concurrent listeners for a single deployed JMS Listener Service
• The ability to send messages to temporary (scratch) queues created on the fly
• Greatly facilitated Request/Reply

This article will describe how to implement a simple Request/Reply scenario with xCommerce's Enterprise Enabler for JMS

Roundtrip Messaging

Roundtrip messaging is a common scenario in applications that use messaging middleware. Some typical use cases are:

• Your application sends a message to a queue or topic with the expectation of receiving an immediate reply (or replies).
• Your application sends a message to a queue or topic without any expectation of getting a response; but for purposes of error notification, your app specifies a ReplyTo destination in the outgoing message. (The ReplyTo queue might be in an entirely different domain, and might be set up solely to accumulate error notifications.) Your app sends messages out to one queue, but asks that error reports be sent to another queue.
• Your application is a JMS Service that listens on a queue or topic and is designed to process an incoming message, then reply to it. The sender needs to supply a queue or topic name in the JMSReplyTo header field of the sent message. In responding to a query, you can set up your Send Message action so that it automatically uses the queue or topic that was present in the JMSReplyTo field of the last received message. (In the Send Options tab of the Send Message dialog, there is a radio button called Use Prior Message ReplyTo Field, provided for this purpose.)

Using the ReplyTo header field

The key to setting up request-reply and solicit-response action models is to fill in the JMSReplyTo header field on outgoing messages (and inspect this field on incoming messages).

By default, the JMSReplyTo field in an outgoing message is empty. To override the default behavior, first check the Specify ReplyTo checkbox (in the Send Message action dialog; see screenshot further below), then select one of the two radio buttons underneath.

There are two possible reply scenarios: asynchronous and synchronous. The radio buttons are designed to handle these two scenarios.

• The Named radio button implies an asynchronous scenario. When you select this radio button, you are specifying a queue or topic name in the outbound message's JMSReplyTo field. In essence, you are saying to the receiver: "If a reply is sent, be sure it goes to this address." You must type a queue name (or topic name) manually, enclosed in quotes, in the associated text field; or create an ECMAScript expression that evaluates to a queue/topic name.
• The Temporary radio button is designed to be used in cases where you expect to receive a reply in a synchronous manner. When you select this radio button, a "scratch" queue is created for purposes of receiving an immediate reply, and the outbound message will automatically have the temporary queue name placed in its JMSReplyTo header field so that the receiving process knows where to send its response. The temporary queue will exist only for the lifetime of your component. (Think "local variable.")

The Example Scenario

The Request/Reply scenario we're going to describe is a simple example of how this capability can be exploited. It will involve two JMS Components and one JMS Listener Service. The first component will send a request message to a queue with the ReplyTo queue specified. The Listener Service will receive this message, perform some simple transformations, and send a reply message to the ReplyTo queue that was specified in the initiating request message. Lastly, the second JMS Component will receive the reply message sent by the Listener Service.

This example assumes you are already familiar with the xCommerce Enterprise Enabler for JMS. The best way to get started with this example is to create two queues (using MQSeries, Jbroker MQ, or other third-party JMS provider software) called "Q1" and "Q2", then create appropriate connection resources to these queues in xCommerce (also named "Q1" and "Q2").

Here's how to create a Request/Reply Scenario using these two queues:

1. First, create a sample XML template you wish to use for this example. To keep it simple, this example will assume the template contains a root node with two child nodes in its tree: <FirstName> and <LastName>.
2. Now create a new JMS component called "sendRequestQ1" using your XML template for Input and Output DOMs and using the Connection to Q1. (This component is going to send the initial request message to Q1.).
3. Create Map actions to set values to the FirstName and LastName nodes such as "John" and "Smith".
4. From the Action menu, select the Send Message action to create a new Send action. At the bottom of the Send Message dialog, you will see a checkbox labeled "Specify ReplyTo Queue." Check this box and specify "Q2" as the ReplyTo queue (Note: queue names are specified as expressions so you will need to use quotes for literal strings).
   All of the other sending options in the dialog can use their defaults (the Component Connection is Q1 so it will send a message to Q1). After the Send Message action is created, you will see Before Send Actions and After Send Actions labels in the Action Model.
5. In the Before Send Actions section, create a Map action that maps the Input DOM to the JMS message's Send DOM in the Native Environment Pane.
6. In the After Send Actions section, create a Map action that maps the message's Send DOM in the native environment pane to the Output DOM so the component will output the XML content that was sent in the message. Save this component. The first piece of the Request/Reply scenario, the component that sends the initial request message, is now complete. Your Action Model should now look similar to the following:
7. Next, create a new JMS Listener Service called "receiveRequestQ1" using your XML template for Input and Output DOMs and specifying the Connection to Q1 (this Service is going to receive the request message sent to Q1 and send a reply message to Q2).
8. From the Action menu, select the Receive Message action to create a Receive action. All of the receiving options in the dialog can stay as their defaults for this example (the Component Connection is Q1 so it will receive messages on Q1). After the Receive Message action is created, you will see Receive Message Actions label in the Action Model. Under the Receive Message Actions label, create a map action that maps the Receive DOM in the Native Environment Pane to the Input DOM. The Input DOM should now contain the XML content from the request message, which is a root node with two child nodes in its tree: <FirstName> with the value "John" and <LastName> with a value of "Smith".
9. Now in the Input DOM, map a third child node to the root node's tree named <ID> with a value of "100".
10. From the Action menu, select the Send Message action to create a new Send action. In the center of the Send Message dialog, you will see a checkbox labeled "Override Connection Queue". You want to check this box and also select the "Prior Receive's ReplyTo" option.
    This will send the message to Q2 because that was the value specified in the original request message that was just received from Q1. All of the other sending options in the dialog can stay as their defaults. After the Send Message action is created, you will see Before Send Actions and After Send Actions labels in the Action Model.
11. In the Before Send Actions section, create a new map action to map the Input DOM with the three values (<FirstName>, < LastName>, <ID>) into the Send DOM in the Native Environment Pane. So the initial fields of <LastName> and <FirstName> that were sent in the request message will now be sent to Q2 in a reply message along with an <ID> field. Your should resemble the following:
    So now the second piece of the Request/Reply scenario that receives the request message and sends a reply message is now complete. Save this JMS Service.
12. Next, create another JMS component called "receiveReplyQ2" using your XML template for Input and Output DOMs and using the Connection to Q2 (this component is going to receive the reply message on Q2 sent by the Listener Service).
13. Select a new Receive Message action from the Action menu. All of the receiving options in the dialog can stay as their defaults for this example (the Component Connection is Q2 so it will receive messages on Q2). Under the Receive Message Actions label, create a map action that maps the Receive DOM in the native environment to the Output DOM.
    The Output DOM will now contain the XML content from the reply message, which is a root node with three child nodes in its tree: <FirstName> with the value "John", <LastName> with a value of "Smith" and <ID> with a value of "100".

That should complete the design of a JMS Request/Reply scenario in xCommerce. We have constructed a JMS component (sendRequestQ1) that sends a request message to Q1 with a ReplyTo of Q2 specified, a JMS Listener Service (receiveRequestQ1) that receives the request message on Q1 and sends a reply message to the queue specified in the request message (Q2), and finally another JMS component (receiveReplyQ2) that receives the reply message from Q2 and displays the message content in the Output DOM.

Conclusion

Two-way asynchronous message scenarios of the type just described are common in the world of JMS use cases. It should be noted, however, that synchronous roundtrip scenarios involving temporary queues are also common (and also facilitated by version 2.7 of the xCommerce Enterprise Enabler for JMS). See the JMS enabler documentation for details.

• Article
• Discussion
• Edit
• History

Personal tools