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

Early in the specification process, members of the working group were 
very clear that creating a dependency upon ws-addressing was 
inadvisable and out of scope.

The basic specification needs to work entirely *without* WS-A.  If it 
so happens that some scenarios are as a consequence precluded (because 
replicating the work of WS-A is also inadvisable) ... so be it.  With a 
basic specification, WS-A can be layered on top, potentially enabling 
further scenarios--which remain out of scope for the working group 
until the basic specification is completed.

This is not to reject the issue or the arguments here, simply to 
reiterate some decisions made quite a while ago, and the reasons for 
them.  I believe, in fact, that these scenarios were posited, and a 
solution requiring more than what is provided in JMS itself (that is, 
message id and correlation id, even knowing that these are *not* 
assigned by the webservice application but by the service provider 
implementation) was recognized to be more complex than could be 
justified within the scope of a basic, foundational specification.

That said ... I'm afraid that on those grounds, I *do* reject a 
solution that would require WS-A or a significant-subset 
reimplementation thereof, especially at this stage of the specification 
(we are hoping to achieve PR soon).  That almost certainly means 
message id + correlation id, either a) ruling out scenarios that cannot 
be supported, or b) stating that an external specification *may* 
override the "native" correlation requirements.  However, I think that 
the latter is unnecessary--an external specification can specify 
whatever it likes, after all.

Amy!
On Fri, 18 Jun 2010 07:49:04 +0000, David Naramski wrote:
> 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
>> 
>> 
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 18 June 2010 14:26:18 UTC