Exception propagation for one way messaqges

[adinn]

Can anyone clarify the intention of the WS 2.0 specification regarding the propagation of exceptions from server to client for messages whicih are tagged @OneWay. It is not clear to me whether an exeception generated by the web method implementation is supposed to be caught and handled by generating a corresponding exception for the client call.

The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single < input > message and no < output > or < fault > messages and is bound ot a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases.

I have tested the case mentioned above on JBossWS 2.0.1GA (with AS5.0.0.Beta3), generating either a SOAPFaultException or a WebServiceException. The test invokes the one way method via a client proxy obtained from the generated soap service class. In both cases a client exception was not thrown. However, I'll note that neither is this definitive of what the spec intends nor does it necessarily indicate that this is the behaviour desired by the implementation. The latter point is explained below.

An HTTP error was returned to the invoking client and a SOAP fault containing the generated exception details was serialised into the response stream and dispatched back to the client. Affter I patched a bug in the remoting code the soap envelope was read from the http connection response stream as a String. This format was employed because the unmarshaller installed on the connection before invocation was an HTTP unmarshaller, not a SOAP unmarshaller. This appears to explain why the fault was not thrown in the client context. Given all the work involved in returning the SOAP fault I wonder if this was really what was meant to happen?

[adinn]

By way of comparison I'll add the following:

glassfish swallows any SOAPFaultException thrown by the implementation of an @Oneway method and does not generate a client side exception

CXF notifies the error by returning a 500 code error to the http client. This results in the JaxWS proxy throwing an exception

[thomas.diesler]

Jason sais:

>> When I generate the interface and server stub code the corresponding web
>> methods are tagged with an @OneWay annotation. My question regarding the
>> spec is very simple: what is meant to happen if the implementation of
>> such a one way method throws a SoapFaultException, a ProtocolException
>> or some other Exception? Is the JaxWS implementation supposed to throw a
>> corresponding exception in the client context? The sections of the spec
>> I cited in my original post do not make the answer clear.

No, it can not, it violates the WS-I BP 1.0 which JAX-WS conforms to:

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16651160

"R2714 - For one-way operations, an INSTANCE MUST NOT return a HTTP
response that contains a SOAP envelope. Specifically, the HTTP response
entity-body must be empty."

That said, you can still present a different WSDL to a consumer than the
semantic one in operation. Just removing @OneWay should do the trick If
a XTS endpoint returns SOAP responses, then it really is a two-way endpoint.

[jason.greene]

"adinn" wrote:

CXF notifies the error by returning a 500 code error to the http client. This results in the JaxWS proxy throwing an exception

This isn't correct either. A one way message is not guaranteed to be processed when you submit it, so the response just indicates whether or not transmission, not the processing of the message is successful. So it would not be portable to return a 500 as a fault, nor would it be portable to interpret a 500 from a one way service as meaning anything more than a transmission problem.

Relevant sections:

"The HTTP response to a one-way operation indicates the success or failure of the transmission of the message."

"R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it."

-Jason