about Request-Response MEP

Title: about Request-Response MEP

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.