OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] proposed edits for enhancing composability

Title: RE: [wsrm] proposed edits for enhancing composability


-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Monday, August 09, 2004 1:46 PM
To: Jacques Durand
Cc: WSRM (E-mail)
Subject: Re: [wsrm] proposed edits for enhancing composability


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."

<JD> Agree. That would be fine.

> - 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?

<JD> misunderstanding here: what I am trying to say, is that the COnsumer, on receiving side, *may* be a SOAP processor. We have to accommodate this possibility.

(I think we agree an RMP implementation may or may not be an "ultimate" SOAP destination for Reliable messages.) Agree this is nothing more than regular SOAP processing, but now we have a slight complication if we add a failed invocation of "Deliver" as another fault case. See my next insert.

> 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.

<JD> I assume our spec requires a specific faultcode value here: "Server" (SOAP 1.1, section 4.4.1)
and that "...a SOAP server fault SHALL be returned"
actually means:
 "...a SOAP fault with faultcode "Server" (in SOAP 1.1) or "Receiver" (SOAP 1.2) SHALL be returned". Am I right? We need at least to clarify the meaning of "SOAP server fault" (and of SOAP client fault).

If my assumption is correct, what I am saying is that we cannot at the same time
impose a specific faultcode like "Server", and accommodate faults that *may be* generated by a failed Deliver operation, which could send back a different faultcode in the response.

This Deliver involving SOAP processing may look like an implementation corner case, but actually means a lot in terms of how flexible our messaging model is when composing with other specs/processors.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]