W3C home > Mailing lists > Public > public-soap-jms@w3.org > June 2010

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

From: Amelia A Lewis <alewis@tibco.com>
Date: Tue, 22 Jun 2010 09:25:07 -0400
To: David Naramski <david@nowina.net>
Cc: Eric Johnson <eric@tibco.com>, public-soap-jms@w3.org
Message-ID: <20100622092507769002.11adb421@tibco.com>
Cool.  I like your suggestion.

:-)

Amy!
On Sun, 20 Jun 2010 19:28:03 +0000, David Naramski wrote:
> Following your email, for which I thank you, I understand that we agree that
> amending the Protocol 2038 is the best solution. Because :
> 
> 1) It works entirely without  WS-A.
> 2) It only relies on the JMS core mechanisms (JMSMessageId and
> JMSCorrelationID).
> 3) This is a minimal change to the current specification that does not
> change the default behaviour.
> 
> The original rule :
> 
>     S MUST copy the JMSMessageID from the original
>     request to the JMSCorrelationID of the response
> 
> Becomes :
> 
>     if there is no JMSCorrelationId set in the request,
>         S MUST copy the JMSMessageID from the original
>         request to the JMSCorrelationID of the response.
>     else
>         S MUST copy the JMSCorrelationID from original
>         request to the JMSCorrelationID of the response.
> 
> With this change, the scenarios related to "ISSUE-39" are included.
> 
> David
> 
> 2010/6/18 Amelia A Lewis <alewis@tibco.com>
> 
>> 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
>> 
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Tuesday, 22 June 2010 13:25:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:24 GMT