XMLSPY SOAP Debugging | The Official XMLSPY Handbook

The other way that XMLSPY helps with SOAP is in the testing of a Web service. XMLSPY helps you to code SOAP and WSDL in multiple ways, but the two most important ways are SOAP debugging and WSDL editing. To debug SOAP Service from the XMLSPY menu, choose SOAP → SOAP Debugger Session. A dialog box appears asking for a WSDL file. Before you specify the WSDL file created previously, be aware that you need a running server to test the Web service. In the case of this chapter, the sample SOAP session is based on the Java Axis server. Axis has the capability to dynamically generate a WSDL file from a Web service when given the correct URL. After the URL has been entered in the XMLSPY dialog box and the OK button is clicked, another dialog box appears asking for the server host and port id. Click OK and the XMLSPY IDE should look similar to Figure 8-6.

click to expand
Figure 8-6: SOAP debugger XMLSPY IDE layout.

On the CD A copy of Apache Axis, a Java framework for constructing SOAP processors, including clients, servers, and gateways, is available on the CD that accompanies this book. Axis includes utilities for working with WSDL files, including a tool that generates Java classes from WSDL.

To activate the debugger, choose SOAP → GO. At that point, the SOAP debugger is running. Because there is no action, you may wonder whether anything is happening at all. The XMLSPY SOAP debugger is a proxy that intercepts SOAP requests and allows the developer to check the validity of the SOAP request. This means that to test a SOAP request, you need both a client and server application. The difference is that the client application needs to redirect the SOAP request to the XMLSPY proxy. The address of the XMLSPY proxy is the IP address where XMLSPY is executing, and the port ID is the same as the WSDL file has specified. In Figure 8-6, in the bottom window, the Function-Breakpoints tab is active. On the right side of that window, it is possible to capture SOAP requests and perform a breakpoint, as shown in Figure 8-7.

click to expand
Figure 8-7: SOAP debugger hitting a request breakpoint.

After the breakpoint has been hit, it is possible to investigate the SOAP message and test the correctness. The default view of the SOAP Request window is the graphical XML view, but you can switch to Text view and look at the SOAP request or SOAP response.

The usefulness of the SOAP debugger is not for the simple RPC SOAP requests. Where the XMLSPY SOAP debugger becomes useful is when the SOAP request is a large or complicated piece of XML. XMLSPY has built-in schema validation, and it is possible to check a specific state of the SOAP message.