[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Duplicate message responses [was Re: [wsrm] about Request-Response MEP]
All, Splitting this[1] part out to keep the topics somewhat separate. The issue here is generally about responding to duplicate messages and should not be specific to the Request-Response MEP or Response RM-Reply pattern. It does, however, touch on payload content and whether it is available when creating a response to a duplicate message. Except to say that my various payload inclusion options (especially alternative A) may restrict situations to which this discussion applies, I will attempt to focus on the duplicate messages only. Note that existing implementation choices allow payload(s) from the consumer to be available when a duplicate message is received. The Respond operation does not have to be invoked more than once when the RMP "remembers" an earlier invocation -- caching, if you will. There are more choices than always returning either a SOAP fault or an empty SOAP Body. Nothing in section 3.2.2 describes this important area of the protocol requirements. (If other sections of the document describe the processing steps or other semantics involved in duplicate elimination, please point them out!) We have a number of options for responding to a duplicate message: a. Require a SOAP fault along with the acknowledgement indication. This is incorrect at many levels since duplicate message elimination is part of the normal RMP processing. Such a fault could result in a SOAP processor within the sending RMP (were it implemented using a generic processor) passing the exception up to the "application" and preventing this normal processing. I would prefer *not* to disallow implementation using a generic SOAP processor. This choice is specific to the Response and synchronous RM-Reply patterns. The explicit or implicit operation invoked as part of the Callback or asynchronous pattern (from the original receiving RMP back to the sending RMP) would likely not include a SOAP fault in the outbound underlying transport request. This requirement would also disallow "normal" processing of producer / consumer interactions described as one-way. b. Require a SOAP fault only when payload content is not available. Again, this choice is specific to the Response and synchronous RM-Reply patterns and may prevent use of a generic SOAP processor. Payloads may be available due to any caching the receiving RMP implementation happens to provide, allowing the enhancements Tom mentions. c. Require an empty SOAP Body along with the acknowledgement indication. This seems initially reasonable but may lead to unexpected faults, as we discussed with regard to RM faults in general yesterday. Unlike (a) and (b), this requirement could apply to all publication methods. This requirement would match the sending RMP's expectations when the WSDL description of the operation (as known to the producer, just to be clear) is one-way. d. Require an empty SOAP Body only when payload content is not available. This comes closest to meeting the sending RMP expectations and will, in most cases, result in an identical response (however publicized) to the original request. ---- I lean toward (d) and would prefer such "caching" be strongly recommended in our specification. It may appear to increase the RMP storage requirements but supports full round-trip reliability. This option was a MUST in the ebXML Messaging 2.0 document for good reason. To summarize, we have apparently made it explicit in the specification (section 5.2 as it stands, for example) that responses may be lost[2], I would suggest we also mostly punt on the question of responding to a duplicate. That would avoid an incorrect SOAP fault (which would, in turn, lead to extraordinary handling in the sender RMP for a normal condition) and make the optimal solution possible. That "optimal solution" is the same as the choice we have made for the sending RMP (when resending): Store payload(s) for responses until the original message has expired and return them in the appropriate duplicate message responses. thanx, doug [1] I am responding to both of the following comments made earlier on the "about Request-Response MEP" thread. I am not sure exactly where Tom is going (beyond our existing abstract Notify operation) in (2) but agree with the general "do not disallow" stance he outlines in (1). On 09-Jun-04 15:50, Tom Rutt wrote: On a tangential matter, with the duplicate elimination with response reply pattern, I though of another set of behaviours which should be allowed: 1) The receiving RMP could provide its own QOS enhancements, where it would buffer the previous response, and just resend that response in the case of a duplicate invocation. Surely this is desired behaviour, and should not be disallowed by the spec. 2) in the absence of having a response to send back for the duplicate invocation, we could just have the protocol allow the Receiving RMP to just not send any return message in this case. The Sending RMP is the one doing the resend, so if it got an ack to the preceding invoke it would be happy. In the rare case where the original response was lost (say due to a transport connection going down due to a backHoe incident) the sending RMP state machine would eventually time out and it could to invoke a special (api specific) notification operation to the Submitter. This simple solution should also be allowable behaviour. On 09-Jun-04 00:11, Jacques Durand wrote: NOTE: For [non-expired] duplicates with response reply pattern, because there is no "Deliver" and "Respond" invocations, the issue remains the same as previously: the RMP generates an RM Reply with either an empty body, or a SOAP Fault. To be decided. [2] I remain unclear what "does not support reliability of WSDL response messages" means but "responses may be lost without notice" seems close and troubling. My earlier alternative B provides some level of reliability through its direct link of RM-Replies with any provided consumer payload(s) and alternative C is entirely unreliable with respect to the payload(s). In any case, the quality of service offered sits on a sliding scale and "does not support" seems extreme. I also believe too many MEPs at different levels of abstraction and in different wire-level exchanges are involved to talk about the reliability of responses in general. However, that point is somewhat tangential to the issue at hand.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]