If a client sends an misformatted or invalid SOAP request, the service can reject the request and return a SOAP Fault. In such a situation, the SOAP Fault should indicate a fault code of "env:Client", and the service should provide additional information about the cause of the fault in the <detail> element in the SOAP Fault.
If you would like to equip your service to serve any kind of request, then you should define your service to accept an input message with a schema structure of <xsd:any>. For example, the WSDL input message would be described as follows:
<wsdl:message name="anyInput"> <wsdl:part name="body" element="xsd:any"/> </wsdl:message>
Note that this message structure is not WS-I compliant, and therefore I do not recommend that you define services this way. Also, this message definition provides no information to your potential clients as to what the proper format of an input message might be. It's always a better idea to define the expected format of your input messages in your WSDL document.
Also, you will need to use "message" style processing when building your service. When using this type of processing, your SOAP server does not process the SOAP Body. Instead it simply hands the application the SOAP message as a DOM, and your application must then process the DOM. (That's, of course, assuming that the message is in fact XML.)I'm not sure that I see tremendous value in trying to make your service serve any kind of request. For example, if you provide a service that accept commercial retail orders, the input message should contain an XML document formatted according to your order schema. What would your service do if it received an input message containing an insurance claim?
Dig Deeper on Topics Archive
Related Q&A from Anne Thomas Manes
Anne Thomas Manes explains the differences between open source clients and open source implementations. Continue Reading
Anne Thomas Manes discusses the best way to go about creating an enterprise data dictionary and why the systems works well. Continue Reading
Anne Thomas Manes explains the difference between 'hard' real time and 'live' real time systems. Continue Reading