Mapping JMS to a native WebSphere MQ application
This section describes what happens if you send a message from a JMS client application to a traditional WebSphere MQ application with no knowledge of MQRFH2 headers. Figure 1 shows the mapping.
The administrator indicates that the JMS client is communicating with such an application by setting the WebSphere MQ destination's TargetClient value to JMSC.MQJMS_CLIENT_NONJMS_MQ. This indicates that no MQRFH2 field is to be produced. Note that if this is not done, the receiving application must be able to handle the MQRFH2 field.
The mapping from JMS to MQMD targeted at a native WebSphere MQ application is the same as mapping from JMS to MQMD targeted at a true JMS client. If JMS receives a WebSphere MQ message with the MQMD format field set to other than MQFMT_RFH2, data is being received from a non-JMS application. If the format is MQFMT_STRING, the message is received as a JMS text message. Otherwise, it is received as a JMS bytes message. Because there is no MQRFH2, only those JMS properties that are transmitted in the MQMD can be restored.
If a WebSphere MQ JMS application receives a message that does not have an MQRFH2 header, the TARGCLIENT property of the Queue or Topic object derived from the JMSReplyTo header field of the message, by default, is set to MQ. This means that a reply message sent to the queue or topic also does not have an MQRFH2 header. We can switch off this behavior of including an MQRFH2 header in a reply message only if the original message has an MQRFH2 header by setting the TARGCLIENTMATCHING property of the connection factory to NO.
Figure 1. How JMS messages are transformed to WebSphere MQ messages (no MQRFH2 header)
