RE: [wsrm] clarification on Respond primitive

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

Title: RE: [wsrm] clarification on Respond primitive

inline <JD>

> ii) Just saying "send a SOAP Fault" is very  bad for a spec. as it is
> not interoperable.
>     We need to be very specific about the Fault information  to be
> sent. Is it Client/Sender or
>      Server/Receiver or what sub-code etc.?

we used to say that it is a client soap fault if it is message formatn
category,
a server soap fault if it is message processing
Perhaps that text went away in Jacques. edits?   It should be there

<JD> That went away inadvertently. We need to add it back.

>  iii) In most cases, the Sending RMP will formulate a Fault/Exception
> to the Consumer if
>       required based on the RM fault itself. A combination of RM Fault
> and SOAP Fault
>       could be problematic in such cases as they could conflict.
>
Well we do not have a body to send back since we did not delivery the
message, so the
sending rmp does not know what to put in the soap body.  Are you
proposing that for response reply
pattern we send empty soap body with rm reply header?

<JD> Our implementor is in favor of the combination:
it makes sense to have both RM Fault and SOAP Fault:
the first one has meaning for the RMP, the other one for the application that was expecting a payload.
Now, here is a position on the duplicate issue:
- The response to a duplicate - whether acknowledged or not - should never
be passed through the WS stack of the sending side. It should be caught by the RMP
and discarded. The Producer should never be aware of it, simply because the Producer
in the first place did not / cannot have generated this duplicate ! (it has to originate
at RMP level, because a duplicate Submit call on an RMP will translate
into different message IDs.)
- so the question is : how can the receiving RMP "mark" this response so that
teh sending RMP will not pass it to the Producer?

Jacques