about Request-Response MEP

[Jacques Durand <JDurand@us.fujitsu.com>]

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.