Re: [wsrm] proposed edits for enhancing composability

[Doug Bunting <Doug.Bunting@Sun.COM>]

Jacques,

A few comments below.

On 09-Aug-04 13:09, Jacques Durand wrote:
> When looking at some composition patterns of WS-R with other specs,
> I observed the following, which I think deserves our attention for this 
> release:
> 
> - One case of failure is missing: we have implicitly recognized that the 
> Deliver invocation
> may fail (as we require it to be "successful" in our RM contracts) but 
> we do not say what happens in that case (after the message has passed 
> every other test).
> 
> We know the message will not / should not be acked. But what kind of 
> fault is returned?
> 
> Proposal: Edit Table 25 to add in the entry for MessageProcessingFailure:
> "In case of failure of the Deliver operation, a MessageProcessingFailure 
> RM fault SHALL be generated."

This table covers faults in every situation I believe.  We need to be 
careful about SHALL in this context since the Receiving RMP is *not* 
required to publish any fault unless AckRequested was enabled for the 
received Reliable Message.  The only current RFC 2119 terminology in these 
tables is a single MUST NOT which is fully described in that clause.  I 
would recommend toning down this requirement and phrasing it as an addition 
to the existing list: "3. The Deliver operation fails."

> - A requirement of composability, is that we need to be accommodating of 
> 3rd party faults:
> in Section 4.5 (rules for processing faults): The response message (in 
> case of Response reply pattern) may also contain a SOAP Fault generated 
> by the next processor in case the next processor faults it.

This seems to go against our overall Messaging Model as introduced in 
Section 2.1.  How can a "next processor" exist if the Receiving RMP is the 
SOAP ultimate destination?

On the other hand, the RMP implementation may include other components 
operating in parallel with the infrastructure described in the 
WS-Reliability specification.  We make that provision explicit in a few 
places, including the "RMP" definition itself.  Since the RMP also includes 
generic SOAP processing capabilities, SOAP Faults are easily returned with 
or without RM Faults.  For example, the Sending RMP may include something 
in the Reliable Message that causes a SOAP Fault (such as a mustUnderstand 
fault) -- preventing any WS-Reliability-specific handling of that message. 
  Since SOAP Faults are fatal and prevent other processing of a received 
message, I believe the combined SOAP Fault / RM Fault cases are limited to 
the list already described in Section 4.5.

If you believe it necessary to warn implementors again that the SOAP 
processing model remains in effect, I guess some words about "bare SOAP 
Faults might arrive back at the Sending RMP in situations not described in 
this specification" could be added to Section 4.5.  I probably would not 
bother.

> If we accept the proposal that "Deliver operation failure" is one more 
> case of MessageProcessingFailure, we must also consider the following:
> 
> depending on implementations, the Deliver operation itself may involve 
> some external SOAP processing in order to complete successfully.
> 
> A specific SOAP Fault may be generated when Deliver fails on Receiving 
> side (cannot complete). Then we need to relax the requirement that a 
> "SOAP Server fault SHALL be returned". It could be another fault 
> generated by the next processor (e.g. MustUnderstand).
> 
> Proposal: Edit in 4.5 "rules for processing faults" as follows:
> Replace:
> 
>       "If the specific RM Fault encountered was due to a problem with
>       processing by the Receiving RMP, a SOAP server fault SHALL be
>       returned."
> 
>       with:
>       "If the specific RM Fault encountered was due to a problem with
>       processing by the Receiving RMP, before the Deliver operation
> 
>       was invoked onthis message, a SOAP server fault SHALL be returned."

I would prefer we rely on our normative references to the two SOAP 
specifications for this type of constraint.  It should not be necessary to 
repeat rules from those specifications.

>       Jacques