HTTP binding upgrade for Callback : proposal

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

Title: HTTP binding upgrade for Callback : proposal

Here is a more precise proposal on how the HTTP binding of Callback (and Poll) requests (Section 6.2 and 6.3)  can:
(1) support both One-way and Request-response SOAP MEPs,
(2) remain fully conforming with BP 1.0

Summary of HTTP binding requirements as they would have to be reworded in 6.2:

(A) general requirements (same as before):

- the initial message carrying the RM Request with Callback element, is an HTTP request.
- the RM Reply must be returned  on a different HTTP connection (in a request)

(B) requirements related to BP 1.0 conformance:

(b1)  If the HTTP request carrying  the Callback reply pattern element is binding to a WSDL One-way operation:
(then current requirements are OK):
- no SOAP envelope should be returned in the HTTP response (HTTP entity-body is empty)
- in case of RM fault, NO SOAP Fault MUST be returned (and HTTP status code should be...)
(NOTE: Abstracting this from WSDL, we can require this for any SOAP One-way MEP)

(b2)  If the HTTP request carrying  the Callback reply pattern element is binding to a WSDL Request-response operation
(this need be added):
- a SOAP envelope may be returned in the HTTP response by the responding party (Consumer)
- in case of RM fault, a SOAP Fault MUST be returned (and following same requirements as for Response reply pattern, L1033-1047 Section 4.5...) and L1048-1050 must be corrected accordingly.

(NOTE: Abstracting this from WSDL, we can require this for any SOAP Request-response MEP)

I'll send a "contribution" matching these asap, as Tom's contribution remains silent on the (b2) part above.

Regarding (B) above, a precision/correction must be added to my previous sending:

When complying to BP 1.0, a Receiving RMP (if not the Sending RMP) must be able to distinguish the case (b1) from (b2) above,

especially in order to know how to handle faults. But it is always expected that this features is supported by BP 1.0 compliant WS stacks on which the RMP is deployed, so that an implementor of WS-R is always in a measure to know when to add a SOAP Fault in the body (b2), and when not (b1), in case of RM error, and this without having to be explicitly instructed of which MEP is being used.

The requirement that an RMP who invokes "Deliver" knows whether or not a related "Respond" will be invoked, is satisfied in the same manner.

Some implementation examples:

(case 1) the RM features are implemented as a Java handler in a WS stack complying with BP 1.0 (e.g. Axis 1.2).
 In that case, when a request is faulted due to RM fault, the handler will systematically generate an exception.
The effect of this exception tells the responding RM handler what to do: if the stack generates an empty HTTP response with the

right status code as BP 1.0 requires for One-ways WSDL ops, then our handler will not add anything to it (b1). If the stack generates

an HTTP response with a SOAP Fault as BP 1.0 requires for Request-response WSDL ops,  then our handler will make sure the Fault has the right code, and let the WS stack forward it to Sender (b2).

(case 2) the RMP is an endpoint itself. In that case, it has knowledge of the [WSDL] operation types the messages it receives/sends bind to.

If no WSDL is used, the RMP will still have knowledge of the SOAP MEP involved.

Jacques