[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] about Request-Response MEP
Jacques, Thank you for your detailed consideration of the issue and for your suggested resolution. On 09-Jun-04 00:11, Jacques Durand wrote: > Following-up on Doug's remark about our lack of handling reliability of > Request-Response MEP (WSDL). > > After careful thoughts on this and more discussion with Hamid, it > appears we cannot dodge the issue > even if we decide to support only partially the reliability of such MEPs > (as we do): > See below analysis and proposal. > > Jacques ... > - A proper extension to the Messaging Model would be to add a "Respond" > operation > for passing a response payload from Consumer to Receiving RMP, > correlating in some > way with a previous "Deliver" invocation. On the Producer / Sending RMP side, is a similar operation required or would the existing Notify operation include any delivered payload(s)? ... > Proposal: > > Solution 1: we could just restrict our spec to the one-way operation > only. It would > be restrictive, though as we hint at in the FAQ, the value of RM as > defined here > is less for req-resp than for a One-Way. I agree this is not the best solution. On the rather pedantic side, I believe you mean the "request / response MEP with no OUT content" sub-sub-option Tom described on the call yesterday. Our existing text disallows use of the Response RM-Reply pattern with a WSDL one-way operation because one-way apparently applies at every level (SOAP processor, RMP, producer and consumer). Put another way, we have interpreted WSDL descriptions to constrain both the producer to consumer and RMP-to-RMP interactions; such an interpretation limits our options. > Solution 2: we extend the model. That is not as high impact as it seems. ... > - no other change is needed. The definition of the main RM features, > which currently ignore the response payload, stay the same. No schema > change. I suspect we need to look at the non-normative text around the deliver operation in particular. At the moment, an implementation could place an incoming message into a queue and issue an underlying protocol response immediately. When using the Response RM-Reply pattern, we probably need to delay such a response until the consumer has had a "chance" to invoke the Respond operation. This may trickle into message ordering and the exact semantic meaning of an acknowledgement (again) but only when using this reply pattern. ... > I will draft the editorial details for (2), if no further comments. thanx very much, doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]