Re: [wsrm] about Request-Response MEP

[Tom Rutt <tom@coastin.com>]

I like proposal 2, it goes a long way to fix the real problems that Doug 
Bunting has made us aware of.

On a tangential matter, with the duplicate elimination with response 
reply pattern, I though of another set of behavours 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 
preceeding 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) notificaiton operation to the Submitter.  This 
simple solution should also be allowable behaviour.

Tom Rutt

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
>
> -----------------------
>
> We have currently the following situation:
>
> - RMPs are assumed to be deployed over a request-response messaging 
> protocol
> (section 2.1, 3rd bullet).
>
> - WSDL-level request-response MEP is supposed to bind to a 
> protocol-level request-response,
> at least in the general case (WS-I BP 1.0), and this regardless of how 
> far we decide
> to support the reliability of the Request-Response MEP.
>
> - The RMP has to support this binding if we want to support the 
> "Response" reply pattern,
> even if only the reliability of the request part of a request-response 
> MEP is supported.
>
> - But the abstract operations we define for the RMP, do not allow an 
> RMP to bind
> an application-level request-response MEP to a protocol req-response, 
> because
> using "submit" operation on the receiving RMP to send back a response 
> payload,
> does not support any correlation with a previous "deliver" operation 
> invocation.
>
> - 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.
>
> - In the context of our current spec, where we only support the 
> reliability of the
> "request" part of a request-response MEP (WSDL), we do not need to say 
> much about
> this "Respond" abstract operation, but it needs to be there if only to 
> allow
> an RMP to bind a payload response with a protocol response.
>
> - In our current RMP implementations, as far as we can speak for the 
> TC, this model is
> actually assumed: whether deployed as a SOAP node or a handler, an RMP 
> is always able
> (1) to distinguish a "response" payload submitted to it from a 
> "request" payload (Respond vs Submit), and
>  (2) to correlate this response  with the right protocol response 
> (HTTP response).
>
>
> 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.
>
> Solution 2: we extend the model. That is not as high impact as it seems.
> - we define (terminology) a new "Respond" abstract operation.
> - All messaging model figures show the "Respond" abstract operation on 
> the receiving RMP.
> - specify in 2.2.1 ("Response reply pattern") that if "Respond" is 
> invoked, its content
> must be carried in the same message as the RM Reply.
> - We add the following requirements for an RMP: (1) it must correlate 
> a "Respond"
> invocation to a previous "Deliver" invocation, (2) it must bind a pair 
> of Deliver-Respond
> invocations, to an underlying request-response protocol.
> - We clearly state that the reliability of payloads submitted via 
> "Respond" is out of
> scope for this release.
> - no other change is needed. The definition of the main RM features,
> which currently ignore the response payload, stay the same. No schema 
> change.
>
> 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.
>
> I will draft the editorial details for (2), if no further comments.
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133