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

Indeed, the two scenarios capture the essence of my issue. The cases make
sense in term of real architecture. ie : in "Case 1", the bridge can be an
adapter component that will translate all the requests from C to S.

In a nutshell, the underlying issue is that the JMSMessageId is not
generated by the WS-* stack.

As you said, except in "Case 2)",  correlating request/response is not
impossible for components implementing current specification. Unfortunately,
there is not other way than having all the intermediaries keeping
information about the exchanges.

I have the conviction that the success of SOAP/JMS will rely on the
asynchronous property of JMS. Furthermore having all the components of an
SOA architecture stateless is a good thing.

I think the specification should not only mimic what is possible with the
HTTP transport. The specification should permit the creation of services
that are asynchronous and stateless. It's why I think it is not advisable to
impose the intermediary to keep a list of which messageId correspond to
which correlationId.

Concerning the use of WS-Addressing, you are right again. We can use the
"was:relatesTo" property to correlate the incoming message, but it will be
more difficult to have a message selector for this property without parsing
the message. Maybe including wsa* properties in the JMS message header could
help us to create a message selector.

The current "Protocol 2038" rule is a direct application of the "Correlation
Identifier" pattern (as in
http://www.eaipatterns.com/CorrelationIdentifier.html). But the
specification of JMS was published long before this pattern.

Maybe the JMSMessageId property as specified in J2EE* is not appropriate for
identifying messages.

If the specification is meant to stick to the "Correlation Identifier"
pattern, we could use other ways to identify a message, such as using some
JMS header properties to store "was:MessageId" and "was:relatesTo". Then, it
will be the WS-* stack implementation that will control the MessageId, not
some obscure JMS provider.

Using the "Correlation Identifier" pattern for correlating request/response
is a good way to see the architecture level. But at the implementation
level, using directly the JMSMessageId property is maybe not the most
flexible way. Hence, I would rather propose to replace the "Procol 2038"
rules by the following :

- 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.

We diminish the impact of the change made to the current specification. It
will be the client responsibility to choose the most appropriate way to
correlate the messages.

Regards,

David Naramski


Ref :

JMSMessageID behaviour :
http://java.sun.com/j2ee/1.4/docs/api/java/jms/Message.html#setJMSMessageID%28java.lang.String%29

2010/6/16 Eric Johnson <eric@tibco.com>

>  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
>
>