In the case of diagnosing problems with
SOAP web services the
Java code is often only of secondary importance.
Show the WSDL (and possibly any referenced schemas). The WSDL is the blueprint that the web service client bases it requests and responses on. Many errors can be traced back to improperly formed WSDLs or the client misinterpreting the WSDL. In such cases it is often necessary to tweak a version of the WSDL for the code generation tool used by the client so that the generated code will create the requests that the service is expecting and expect the format of the responses that the service will be emitting.Show sample request and responses from the client intercepted with Apache TCPMon (Tutorial) or tcpmon. Don't forget to include the HTTP version, headers and response code. This shows the request that client generates and the response that the service emits. This information is necessary as it establishes the context of any Java exception which in many cases is an XML parsing error on either the service or the client side.Show sample requests and responses intercepted from a working (possibly non-Java) client. This shows the requests that the service can consume and the responses that the service will emit. This is important if some aspect of the WSDL definition is ambiguous or incomplete. Even if the WSDL is complete and correct it can help identify which aspect of the WSDL the broken client has trouble with. For example if you have trouble accessing a .NET web service from a Java platform, obtain request/response samples from a working .NET client (which may require building a test client).
For an idea how to present this information see this
topic
