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] issue with use of SOAP Faults


Title: RE: [wsrm] issue with use of SOAP Faults

>
>
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Thursday, May 27, 2004 10:56 AM
> To: Jacques Durand
> Cc: WSRM (E-mail)
> Subject: Re: [wsrm] issue with use of SOAP Faults
>
>
> >> Also,  in case replypattern is something else: do we still need to use
> >> SOAP Faults? (I don't
> >> believe there is a point to it.)
> >
> >I do not think there is any text in the current document which implies
> >this.  I agree, we will not send soap
> >faults for callback or poll response.
>
> The current text is ambiguous in that SOAP Faults were associated
> with Req-Resp ops, which can in turn be used with any reply pattern.
> While what we only want (and only can do), is to associate them with
> Response reply pattern. The rewording I proposed fixes that.
>
> > Jacques
>
Ooops, what happens when callback reply pattern is used with request
response operation and the message
is duplicate. 

<JD> The RMP does not know again if it is a requ-resp or a one-way.
So  the proper behavior in that case is NO SOAP Fault in the HTTP response at all
(with a callback pattern, it could be - most likely - a one-way...)
So the Sending RMP would get a bad HTTP status code in that case (as BP 1.0 requires)
and empty payload (even if a SOAP body was expected).
The SOAP stack will escalate teh exception to the app/producer, like for any transport
error. So that is why I propose to make this status code return more explicit (in HTTP binding).
The separate callback would come later with RM Reply that explains more.
</JD>

In this case their is no information to put into the
reply to the original message.  Perhaps sending
a soap fault for this condition is a proper thing to do.   they would
get an ack for the duplicate in the
callback, but what would be returned in the http response to the
duplicate request.




> >
> >
>
> --
> ----------------------------------------------------
> Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
>

--
----------------------------------------------------
Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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