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
