Asp.net|web|web Services | Skills First, disable HTTP Post/get protocol
Unless otherwise specified,. NET will attempt to bind Web services to three protocols: Http/post, Http/get, and soap. The reason for "trying" is that the Http/get protocol may not be available because it relies on the parameters and return type of the service. NET generates a WSDL file that automatically contains instructions for binding these three protocols, and the client program is free to choose which protocol to use to communicate with the service.
You can easily delete bindings to the Http/post and http/get protocols by adding the following in the Web.config file:
<webservices>
<protocols>
<remove name= "HttpPost"/>
<remove name= "HttpGet"/>
</protocols>
</webservices>
Why avoid Web services through the Http/post and Http/get protocols? The main two reasons are security and interoperability. Http/get is less secure than soap, and because Http/get is common to web links, malicious people might use it to implement spoofing, allowing others to unknowingly invoke Web services with their own security identity, but still think they are clicking on a web link.
In terms of interoperability, soap is a widely used Web service communication standard, while Http/get and Http/post are not. So, for. NET generates the default Http/get and Http/post bindings contained in the WSDL document, many of the tools that automatically generate proxy servers do not understand. Therefore, if your Web service is not unbound to the Http/get and http/post protocols, it is a good idea to cancel both of these bindings.
Second, use Tcptrace to view SOAP request/Reply messages
For people who develop Web services applications, debugging can be a very difficult task because neither the. NET SDK nor the vs.net provides the tools to view the SOAP messages between the client and the server.
If. NET and non-. NET clients, server-side interaction processes are problematic, and the ability to view SOAP messages is particularly important in order to find the source of the problem, because such questions are often related to the format of the SOAP message (for example, "Does the message contain SOAPAction?"). ”）。
Tcptrace (Www.pocketsoap.com/tcptrace) is an excellent tool for viewing this kind of message exchange process by setting up a tunnel between the client and server side. When Tcptrace is started, it asks for the destination URL and port number, and the local port number that the Tcptrace listens to. In this way, you can point to the local port (for example, localhost:8080) by setting the URL property of the proxy stub. Tcptrace is able to log all requests and replies to HTTP messages.
One limitation of Tcptrace is that its location in the message flow determines that it cannot be used to view messages sent over SSL. If you want to view SOAP messages sent over SSL, you can only write a custom ISAPI filter.
Simplification of interface design
In many aspects of N-Layer application design, the design of simplified interface design can be said to be everywhere. However, for a distributed computing environment such as Web services, the importance of simplifying interface design is more prominent.
When designing distributed applications, for performance and scalability reasons, you should ensure that calls between the client and server side are as small as possible. Reducing network calls not only helps reduce communication overhead (never send three messages if you can achieve a goal with only one SOAP message), reduces network traffic, and improves application performance. Obviously, all this is the goal that developers are dreaming of. So what is the characteristic of a simplified interface?
First, let's look at an example of a complex interface:
Namespace Chattyservice {
public class Chattyservice:webservice {
private string Username;
private string password;
public string Username {
[WebMethod]
set {
Username = Username;
} }
public string Password {
[WebMethod]
set {
Password = password;
} }
[WebMethod]
public bool Logon () {
Verify identity
return true;
}
}
}
In this example, username and password are two attributes that must be set first before the logon () method is invoked. There's a problem. It's not easy to see this code, which is what username and password are all drawn as Web methods. This means that each get/set operation on the property results in a call to the service.
In accordance with the requirements for simplifying the interface design, the improved code is as follows:
Namespace Chattyservice {
public class Chattyservice:webservice {
[WebMethod]
public bool Logon (string Username, String Password) {
Verify identity
return true;
}
}
}
Now, username and password are the parameters of the logon () method. The advantage of the modified code is that it reduces the logon operation to three calls to the server one time. On the other hand, if the number of arguments is too much, this method may look very bad. At this point, you might want to sort out the parameters of the method into several complex types, for example, encapsulate the username and password two parameters into a credential (certificate) object.
Four, save the application private data in the Web.config
Web services developed with ASP.net can play all the strengths of the. aspx application, including the ability to use Web.config files to store the private data (for example, database connection strings, file paths, and so on). The advantage of using Web.config instead of Global.asax files is that you do not have to reconstruct the application after you modify the configuration.
V. Avoid the use of ASP.net session state
. NET implementation of the session state management capabilities of its predecessor, ASP 3.0, there are many problems, such as request serialization, but there are still some limitations. It should be recognized that. NET's session state management features are not designed specifically for session state in a Web service environment, but are designed to manage session state in a wider range of asp.net applications, depending on the HTTP cookie (there is a pattern that does not require a cookie by overwriting the URL). But not for Web services.
Cookies are unique to HTTP. On the web, all browsers support HTTP, so cookies are ideal for use in Web applications. However, the application of cookies in a Web service limits the service to the HTTP protocol. On the other hand, the SOAP protocol runs independently of the transport protocol, so if the Web Service application is limited to the HTTP protocol, the flexibility of the application is limited, and once the service is provided via a non-HTTP transport protocol (such as SMTP), things can become cumbersome
