SOAP response body has plain text without any nodes

Question

How to handle SOAP message response like below?

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:new="http://foo/bar">
    <S:Header/>
    <S:Body>OK</S:Body>
</S:Envelope>

here are my definitions in WSDL:

<wsdl:operation name="MyRequest">
            <wsdl:input message="tns:MyRequest" name="MyRequest">
            </wsdl:input>
            <wsdl:output message="tns:MyRequestResponse" name="MyRequestResponse">
            </wsdl:output>
</wsdl:operation>

<xs:element name="MyRequestResponse" type="xs:string"/>

Service:

 @WebMethod(operationName = "MyRequest")
 @WebResult(name = "MyRequestResponse", targetNamespace = "http://foo/bar", partName = "parameters")
 @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
 public String MyRequest(
            @WebParam(name = "MyRequest", targetNamespace = "http://foo/bar", partName = "parameters")
            MyRequest parameters);

I did tried to use interceptor and wrap the response 'OK' with nodes. But, wondering if there is any cleaner way of doing it by handling in JAXB/WSDL layer itself.

Answer 1

This is not a valid SOAP 1.1 Body element according to the specification. So it is, in fact, not a SOAP response.

Because it is not a valid SOAP response and you don't send any complex parameters, it really has little value trying to invoke such a service using a SOAP framework.

It will make more sense to treat it as a plain HTTP service with a proprietary format. Send HTTP POST request and extract the "OK" part inside the body from the response. If the namespace prefix is not expected to change, you can do it even without parsing XML.

Despite looking like a "hack", it is a much more clean and maintainable approach than going with non-obvious interceptors and an obscure setup to hack the framework and force it to do things outside of the specification. Anybody coming after you, examining the code, will have to spend time understanding all the gears behind handling this one-eyed SOAP.

If, however, there IS sometimes a valid complex SOAP body conforming to the spec, and sometimes there is invalid arbitrary content like OK, reimplementing SOAP parsing is not justified and interceptors are the way to go, to bring invalid messages inline with the spec. In the mixed case I think there is no simple clean way to map using the SOAP/WSDL specification, unless messages are pre-processed and fixed by interceptors.