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