In a project using TIBCO BusinessWorks we had to call a webservice with a one-way operation (this means only a request message is defined in the operation in the WSDL) to deliver messages to a back-end system. During development we discovered a ‘feature’ of this asynchronous use of webservices in TIBCO BusinessWorks. We noticed that when the response http status code was 500 (internal server error of the service provider) BusinessWorks did not raise an exception.
In TCPmon (http://ws.apache.org/tcpmon/) we can see the http status code 500 is returned.
When we take a look at the SOAP 1.1 specification we can see the reason for this behaviour. In the SOAP specification section 6.2 it states:
“SOAP HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client’s request including the SOAP component was successfully received, understood, and accepted etc.
In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 “Internal Server Error” response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error. ”
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
Since a one-way operation can not return any soap message including a soap fault the 500 status code is actually not conform specifications.
This also means that a one-way operation should be treated as a truly asynchronous message exchange pattern, even though a http response is returned. If there are requirements for guaranteed delivery this behaviour should be considered if you want to use a one-way soap interaction.
