only for RuBoard |
Apart from using the SOAP extension, you can use other tools, such as the SOAP Trace Utility ( MsSoapT.exe ) that is packaged along with the Microsoft SOAP Toolkit 2.0 and the tcpTrace available from www.pocketsoap.com/default.asp. MsSoapT.exe enables you to debug the SOAP request, and the tcpTrace.exe enables you to check out the entire HTTP conversation. Both tools make it possible for you to review SOAP requests by intercepting and forwarding the requests . To intercept a request, you must tell your client to talk to a port (for example, 8080) on which the chosen trace utility is listening. So it is required that you change the location attribute in the address element of the WSDL file, as shown in the following code.
The following code is the service section before changing:
<service name="TracingAddressEntries"> <port name="TracingAddressEntriesSoap" binding="s0:TracingAddressEntriesSoap"> <soap:address location="http://localhost/WebServices/SoapMessagesTracing/service1.asmx" /> </port> </service>
The following code is the service section after changing:
<service name="TracingAddressEntries"> <port name="TracingAddressEntriesSoap" binding="s0:TracingAddressEntriesSoap"> <soap:address location="http://localhost:8080/WebServices/SoapMessagesTracing/service1.asmx" /> </port> </service>
But in the case of a .NET web service, where you have a dynamic WSDL file generated, you do not have the flexibility to make the previously mentioned changes. You can do this change in the client proxy code that's generated. This location is available to be changed through the Url property of the generated proxy . You can change it at run-time so you don't have to modify the generated proxy object's code. The following code shows how you can set the Url property in the client application:
localhost.TracingAddressEntries addrEntries = new localhost.TracingAddressEntries(); addrEntries.Url = "http://localhost:8080/WebServices/SoapMessagesTracing/service1.asmx"; localhost.AddressEntry addrEntry = addrEntries.GetAddressEntry();
Many other advantages of being able to dynamically change the Url property of the proxy object exist. If your call to a certain web service times out or fails due to some server error, you can use this feature to dynamically connect to another web service, provided that the other web service supports the same services.
Now you can view the SOAP messages using these tools, as shown in Figure 11.14 and Figure 11.15.
These tools will immensely help you as you discover the faults sent by the web service to the clients and convert them into a proper format or predefined error codes through the detail element:
<detail> <e:myfaultdetails xmlns:e="http://newriders.com/webservices/addressbook/faults"> <message>Invalid User</message> <errorcode>1001</errorcode> </e:myfaultdetails> </detail>
You can see an implementation of a web service returning error codes in the next section, "Building a Public Address Book Web Service." In cases where your server is not accepting the underlying TCP connection, or you are attempting to perform SOAP communications over a Secure Sockets Layer (SSL) channel, these two tools will not help much. So you might choose to use Microsoft Network Monitor, which is an administrative tool that enables you to monitor packets on your network, or you can write custom HTTP handler that views all the data that's received by and being sent to your web server.
only for RuBoard |