When you write a Web Services, you will need a client (call end) to call it to check if the run is normal. In Visual Studio.net, you can directly click the "Run" button, the system will automatically generate a web service test page to call WebMethod, although it is very convenient, but this test page is added to the URL through the HTTP / GET protocol. Passing to Web Method, this call mode (HTTP / POST is also the same for relatively simple Web Services, such as the passing parameters are simple types, or SOAP messages are not included in the SOAP request.
If our Web Services applies some complicated features, for example, the request parameter is a complex type that does not encode the GET and POST protocols, and the custom SOAP eNCoding is applied, and SOAP extensions are used. At this time, you need to use the WSDL SOAP binding, and the SOAP protocol is made to call, that is, we have to write a client specifically for this Web Services. One of these is that if the Web Services client wants to call using SOAP, the client's proxy class must be derived from the SOAPHTTPCLIENTPROTOCOL class, and the proxy class of the VS.NET automatically generated test page is derived from the HTTPGETCLIENTPROTOCOL class. Of course, VS.NET can also be more convenient to write clients, and you don't have to pay attention to the agent class, because it is automatically generated, you have to do it like to call Web Method like locally.
But the problem is coming, if you want to directly edit the SOAP request message sent by the client and view the received response message, the implementation in the vs.net is more troublesome, but also has a SOAP extension, so that work The amount can be big. It is good to release the .NET WebService Studio (WSS) in Microsoft, which is used to interact with Web Services. WSS is a small (116K) Windows Form application that combines the Early WSDL Verification and WSDL Browser tools in the GotdotNet website and adds an intuitive user interface. The current version number is 1.0.
Let's take a look at the use of this software in accordance with the call to a web service.
First, enter a valid ASMX or WSDL file URL in the WSDL Endpoint text box, you can also open a local WSDL file through the Browse WSDL button. Then enter the text box, WSS downloads WSDL (if you are an ASMX file in the text box), generate it to generate and compile a client agent for the web services, and the entire process can be seen in the Massages panel. Finally, a tree view including all methods of the Web Services is displayed in the Invoke panel. At the same time, you can see the WSDL files generated by this tool and the XML document defined by this tool, and the client proxy class (Proxy), the client call code (CLIENTCODE). In the Proxy code, we can clearly see the proxy class inherit from SoapHttpClientProtocol, so this tool is undoubtedly based on the SOAP protocol to call Web Sevices, so we can use the various features related to SOAP.
Take a look at the Invoke panel, click on a web method, and immediately display the parameters and its structure you need to call this method according to the SOAP message in the INPUT box on the right; click on a certain parameter, corresponding input The type information of this parameter is also displayed immediately, and the value of this parameter can be filld into the value of this parameter or the value is empty, and the parameters can be called via the Invoke button. After the call is over, the OUTPUT box also displays the result of the return result and its data structure in the same way as the INPUT box, and the data type and value of the return result can also be displayed. It is exciting that you can directly edit the elements in the message header in the Input and Output boxes, which is necessary to test the Web Sevices that provides a message header in the test requirement. If you want to use a message header (of course, the premise is the relevant agreement in WSDL), click on a head element in the message head, and the relevant type information is displayed in the corresponding value box, then set the ISNULL to FALSE. At this time, there are more plus, and you can see the parameters under this, and the method of the head element can be set. After setting the parameters, you can call the Web Sevices that you need a message header. Really convenient!
Finally, it will introduce Request / Response, this panel mainly shows that the request message generated by the WSS will call the request message generated and the content of the received response message. When you call a method in the Invoke Panel, you can see the original request message and response message in the Request and Response box, and you can modify the SOAP request message, such as modifying the value or attribute of an element, etc. , Then press SEND to recall, you can see the result, which has a great help for in-depth understanding of SOAP messages. In the left side of the panel, you can set the properties (GET / POST), basic authentication usernames, and passwords, whether to use cookies, etc. to call Web Services in a more flexible way.
If you use VS.NET to develop Web Services with VS.NET in the LAN, you may find that you can only add Web Services within the local area network through the web reference, but the service provided on the Internet (this problem can be encoded) Setting up the HTTP proxy attribute of the client agent class to solve it), because most of the Web Services is called via HTTP protocol, while the local area network HTTP proxy server requires authentication of external access requests. Because the VS.NET is not a proxy setting mechanism for web references to cause the above problems. Therefore, you must fill in the correct verification information (such as user name and password, etc.) to enable SOAP request messages that bind the HTTP protocol to the server to reach the server. At this point, WSS is once again a good simplified step.
Open the options of the Edit menu, you can set the domain, user name, password of the proxy server in the WSDLSettings item, so you can easily call the Web Services on the Internet in the local area network, simple enough! At the same time, you can also choose other data encoding modes except SOAP (http / get, http / post), and automatically generated language (C #, VB.NET, JS), and display style of SOAP messages.
