Re: Please don't rely on JMSMessageID for Protocol 2038.

Hi David,

Follow-up question.  I asked some of my colleagues whether it made sense
to simplify the scenario that you identified, and they agreed that it did.

Specifically, the notion of "broker" is somewhat ambiguous.  If you
intend it to be a conforming implementation of a SOAP/JMS broker, it
would effectively have to work according to spec, and it doesn't seem
like it would be problematic for it to work either way.  That is, the
broker, if it understands SOAP/JMS, would have to make sure that the
responses it sends are setting the correlation ID to the message ID of
the request.  Certainly, this might be annoying, but I don't see that it
is impossible.

The more interesting problem-child is the "bridge" that you mention.  My
colleagues mentioned the possibility of "Topic to Queue" or "Queue to
Topic" bridges (or presumably, Queue to Queue - perhaps to bridge
between JMS providers), where, by definition, the message ID leaving the
bridge is different from the message ID coming into the bridge.

Thinking about it, it seems like there are really two scenarios:

Case 1) Replacing "JMSReplyTo"
C --> bridge --> S (leads to reply)
C <-- bridge <-- S

Case 2) Preserving "JMSReplyTo"
C --> bridge --> S (leads to reply)
C <-- S

At least for "Case 1", I could argue that if "S" is using message ID for
correlation purposes, the bridge could might notice that it is supposed
to substitute on the return.  Seems like extra overhead for the bridge,
so that's perhaps not a good idea, but it is at least possible.

For "Case 2", there's no possibility for the bridge to affect the
message on return, so there's no alternative but to rely on some other
correlation ID than the message ID.  Possibilities include setting the
correlation ID on the request message, or using WS-Addressing with
wsa:RelatesTo

Does that about capture it?

Thanks.

-Eric.


On 06/15/2010 02:37 PM, David Naramski wrote:
> I have a problem with Protocol-2038
> <http://www.w3..org/TR/2009/CR-soapjms-20090604/#Protocol-2038>.
>
> It works well when you have the client (C) and the server (S) without
> intermediary.
>
> 1) C sends the message. The JMSMessageId "originalId" is then
> generated by the producer.
> 2) S receives directly the message. Then S copies the JMSMessageId 
> "originalId" in the JMSCorrelationId of the response. S sends the
> message in the reply queue. 
> 3) C waits for a message with JMSCorrelationId = "originalId"
>
> But if you have a less ideal infrastructure such as, two JMS brokers
> linked together, you can have something like this :
>
> C  ----> brokerA ------> bridge ------> brokerB ------> S
>
> Then C cannot rely on the JMSMessageID to correlate the response.
> Actually, the bridge will read the original message and send it to the
> brokerB. A new JMSMessageID = "newId" is then generated by the JMS
> provider. The server S will respond with JMSCorrelationID = "newId"
> and the client C will not be able to correlate the message, because it
> waits on the "JMSCorrelationID = 'originalId'" selector.
>
> A solution will be to set the JMSCorrelationId at the client level.
> The JMSCorrelationId will be preserved during all the cycle.
>
> The protocol 2038 can be rewriten as follows  :
>
> - If no JMSCorrelationID is set in the request, then S MUST copy the
> JMSMessageID from the original request to the JMSCorrelationID of the
> response.
> - If a JMSCorrelationID is set in the request, S MUST copy the
> JMSCorrelationID from original request to the JMSCorrelationID of the
> response.
>
> Alternatively, the protocol 2038 could be simplified as follows:
> - S MUST copy the JMSCorrelationID from original request to the
> JMSCorrelationID of the response.
>
> I have not seen the Protocol 2038 discussed in the mailing list, so I
> hope this issue is not a duplicate.
>
> I'm not sure how to sent my comments. I'm trying the mailing list, but
> if you think another way will be more appropriate, feel free to give
> me any instruction in that respect.
>
> You can see in |*setJMSMessageID
> <http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html#setJMSMessageID%28java.lang.String%29>
> that the *|JMS providers set this field when a message is sent.
> More, you can see in |*setJMSCorrelationID
> <http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html#setJMSCorrelationID%28java.lang.String%29>*|
> that JMSCorrelation is a mean to the client for correlating the
> request and the response.
>
> I hope the above is helpful and remain a your disposal for any queries
> you may have.
>
> Kind regards,
>
> David Naramski