Configuration is as follows.

1). JMSQueueRequester activity.

2). With static queues.

3). JMS Correlation ID is used.

It is assumed by developers that since the JMSCorrelationID of the request message and the reply message is different, the requestor should not receive the reply message.  This is not true. The requestor listening on the queue "ReplyQueue" will receive all messages sent on that queue no matter what the JMSCorrelationID of the reply message is. 

As per the JMS specification, the QueueRequestor constructor is given a QueueSession and a destination queue. It creates a Temporary Queue for the responses and provides a request method that sends the request message and waits for its reply. It is well documented in both the JMS and BW documentation that the requestor logic uses temporary destinations. However, it is also mentioned in the JMS specification that "This is a basic request/reply abstraction that should be sufficient for most use cases. JMS providers and clients can create more sophisticated versions".  For more details, refer to the JMS specification.

1). TIBCO ActiveMatrix BusinessWorks 6.x developers can use built-in JMS Queue requestor activity with its default nature, that being, without specifying the replyTo queue. It allows the activity to receive replies on temporary destinations. It is important characteristics of temporary destination that they support only local use. That is, only the client connection that has created a temporary destination can consume messages from it. Therefore, no client other than who those wo have created it can pick messages from that destination. Refer to the TIBCO Enterprise Message service documents for more detail. The design goal of the JMS queue requester is to implement synchronous request-reply mode, which makes JMSCorrelationID useless in this scenario. With default use , i.e. with temporary destinations, a request message already has a one-to-one relationship with the response message.

2). TIBCO ActiveMatrix BusinessWorks 6.x developers can create their own requestor logic using Send JMS message (to send request) and Get JMS message activity (to receive reply). This approach uses static destinations for reply and by making use of a selector, Get JMS activity picks only messages among all available message which evaluates to the selector.  Along with the selector, there is a timeout provision available in the GetJMSMessage activity to timeout the request after a specific time.

3). If TIBCO ActiveMatrix BusinessWorks developers still want to use static queues as replyTo destinations in a JMS Request reply activity, they will have to consider the notes given in the TIBCO ActiveMatrix BusinessWorks 6.x documents. The documentation specifically points to these notes.

"This activity uses temporary destinations to ensure that reply messages are received only by the process that sent the request. However, the user has the ability to use pre-existing JMS destinations. "If more than one job has the same replyToDestination (for example, you specify a constant in this field), then the correct reply may not be received by each job.  Make certain that you specify an expression in this field that assigns a different replyToDestination to each process instance".

Refer to the TIBCO ActiveMatrix BusinessWorks Palette Reference Guide for more details.