Using an External Client to Validate and Troubleshoot

You should begin validating the service on the server side first by using an external client because unless the web service class exists, deployment is setup properly, etc. a client failure may not be clearly distinguishable. To keep the path length and areas you may have to investigate for possible errors as small as possible you should use a known, working client to invoke your service. Common areas of failure that a known, working external client can help validate include: service packaging, receiver processing, security configuration, and implementation processing. An example of an external client you might use is the freely available soapUI client (www.soapui.org), which is relatively easy and fast to setup and begin using. While a detailed treatment of soapUI is beyond the scope of this document the following is an outline of the steps you would use, which are similar for Axis2 and Axis 1.4:

Download, install, and start soapUI.
When validating your service(s) (above) save the generated WSDL.
In soapUI select the File menu -> New soapUI Project and in this dialog specify the location of your saved WSDL and click OK. This will create and open a new soapUI project from where you can invoke your web services.
From the soapUI tree control expand your newly created project and expand the "Soap12Binding" or "Soap11Binding". Under this tree branch you will see your service operations and under each operation a "Request 1" (default name) request. Double-clicking the request will open a request editor. In the left pane you must code your SOAP message (e.g. parameters, etc.) and a template is provided for doing this. In the right pane is where the result is displayed. Once you've coded your SOAP message click the right green arrow/triangle in the tool bar to execute the service. If you've coded the SOAP message correctly the service output will be displayed in the right pane. However, if an error occurs there will be error information in this pane. In the event of an error verify your SOAP message syntax and content; also see Tools and Techniques for Troubleshooting Axis2 and Axis 1.4 Errors for some further techniques for resolving and addressing these.

Note: For Axis2 you must keep in mind the default security behavior and that you must include the custom SOAP header credentials in your request. This would look something like this:

<soap:Envelope
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:rem="http://remote.my.package">
  <soap:Header>
    <curam:Credentials
      xmlns:curam="http://www.curamsoftware.com">
      <Username>beantester</Username>
      <Password>password</Password>
    </curam:Credentials>
  </soap:Header>
   <soap:Body>
...
   </soap:Body>
</soap:Envelope>

Note: For Axis2 the first access of a web service may timeout due to the large number of jar files and processing done at first initialization. This can easily be mitigated in a Java client (e.g. see Creating a Client and Invoking the Web Service), but for soapUI you can just re-invoke the service and the subsequent request will likely not timeout; otherwise, see Tools and Techniques for Troubleshooting Axis2 and Axis 1.4 Errors for further techniques for resolving and addressing general web services errors.