Andrea Smyth wrote:
If a server-side in-interceptor throws a Fault when processing the
inbound (soap) message for a oneway request, I can, using the
LoggingOutInterceptor, see that a soap fault is sent back to the client:
INFO: Outbound message: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>FaultThrowingInterceptor
interceptor failed to handle
message.</faultstring></soap:Fault></soap:Body></soap:Envelope>
But the client does not decode the fault and simply throws a Fault (as
opposed to a SoapFault) with code: "COULD_NOT_SEND", and message:
"Could not send Message. (and a wrapped IOException: Server returned
HTTP response code: 500 for URL: ...).
If addressing is used, and the fault throwing interceptor executes after
the logical addressing interceptor, the client does not receive a Fault
at all. The reason is that the partial response has already been sent
(from within the logical addressing interceptor), so all faults
occurring after that are practically ignored and the client has no idea
that the actual invocation on the server never occurred.
I don't believe this is correct either. At the very least it is not
consistent with the non-addressing case where the client can surround
the oneway invocation with a catch(Fault ...) clause.
BTW an example of such an interceptor would be the logical RM
interceptor, which executes after the logical addressing interceptor.
Also, I am not quite sure how to interpret the following extract from
the addressing spec:
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrprops
>>In a one-way interaction pattern a source sends a message to a
destination without any further definition of the interaction.
"Request-response" is a common interaction pattern that consists of an
initial message sent by a source endpoint (the request) and a subsequent
message sent from the destination of the request back to the source (the
response). A response in this case can be either an application message,
a fault, or any other message. Note, however, that reply messages may be
sent as part of other message exchanges as well, and are not restricted
to the usual single Request, single Response pattern, or to a particular
WSDL transmission primitive or MEP. The contract between the interacting
parties may specify that multiple or even a variable number of replies
be delivered.<<
I would tend to read it as: even if the operation is oneway, the
contract between the interacting parties may mandate the use of RM, and
as such require that e.g. non-existent sequence ids result in SoapFaults
with prescribed fault code. The question is: does this go as far as
mandating the sending of that fault back to the client, or is it
sufficient to log such an error on the server side?
Andrea.
If the message is twoway, the client receives a SoapFault, with
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server and the
expected reason.
Is this intended behaviour? IMO it is not correct, considering that in
the first case the correct fault code and faultstring is available it
should as well be decoded so the client gets a idea of what went wrong
on the server side. In particular, I think the soap fault should be
decoded to correctly implement fault handling in addressing and rm,
where server side interceptors may fail because of duplicate message
ids, duplicate sequence ids, etc. which can occur in the context if
both oneway and twoway requests.
Andrea.
