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

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
>