W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2012

Re: WSA FaultTo Question

From: Doug Davis <dug@us.ibm.com>
Date: Wed, 13 Jun 2012 08:17:41 -0400
To: mail2jimma@gmail.com
Cc: public-ws-addressing@w3.org
Message-ID: <OFF50FE914.EEDBF913-ON85257A1C.0043633A-85257A1C.00438A1B@us.ibm.com>
If you look at:  http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html 
 section 3.7.10, and in particular R1148, it might provide the guidance 
you're looking for.

STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

Jim Ma <mail2jimma@gmail.com> 
06/12/2012 06:34 AM
Please respond to


WSA FaultTo Question

Hi All,
When I looked at a wsa faulto issue, I didn't find there is
some specification conformance to address how to
respond to the client when the fault occurred in the following ws
invocation scenario:

1. A client sends a request to invoke a request/response operation from
EndpointA, the request's wsa faultTo header point another endpointB
and not the requester

2. There is error occurred during EndpointA processing the request, so
the fault message is sent to EndpointB to notify the faultTo target
endpointB which is specified in request wsa headers.

3. It's a two way webservice invocation , so we need to reply to the
initial requester.

So my question is what should the endpoint respond to client/requester? A 
error with the same fault message sent to faultTo endpoint or we need to
forward the response from the faultTo target EndpointB  to requester ?
 Or EndpointA should
mix this message and let the requester clearly know the exact soap fault
message, and also if the fault message has successfully notified the
endpointB ? Which option do you think
it's the ideal way to handle this ? Is there any future specification
will address this scenario ?

Thanks in advance !

Received on Wednesday, 13 June 2012 12:19:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:18 UTC