First, disable the HTTP Post / Get protocol
Unless otherwise specified, .NET will try to bind Web services to three protocols: http / post, http / get and soap. The reason why "trying" is because the HTTP / Get protocol may not be available because of the parameters and return types that depend on the service. The WSDL file generated by .NET will automatically contain instructions for binding these three protocols, and the client can freely choose which protocol and service communication.
Just add the following in the web.config file, you can easily delete the binding of HTTP / POST and HTTP / GET protocols:
Why avoid the introduction of web services via HTTP / POST and HTTP / GET protocols? The main two reasons are safety and interoperability. HTTP / GET is not as good as SOAP, and because HTTP / GET is common in web links, the malicious people may use it to implement deception, so that others use their own security logo to call the web service, but I thought I have Click on the web link.
For interoperability, SOAP is a widely used Web service communication standard, while HTTP / GET and HTTP / POST are not. Therefore, many of the HTTP / GET and HTTP / POST bindings included in .NET generated, many automatically generated proxy servers will not understand. Therefore, if your web service is not binding to the HTTP / GET and HTTP / POST protocols, it is best to cancel these two bindings.
Second, use TCPTRACE to view SOAP request / answer message
For those who develop web services applications, debugging may be an exotic difficulty, because whether it is .NET SDK or VS.NET, there is no tool to see the SOAP message between the client and the server.
If .NET and non-.NET clients, the server-side interaction process has problems. To find out the root of the problem, you have the ability to view SOAP messages, because this type of problem is often related to the format of SOAP messages (for example, "Is there soapaction in the message?").
TCPTrace (www.pocketsoap.com/tcptrace) is an excellent tool for viewing such message exchange processes, which sets a tunnel between a client and server. When TCPTrace is started, it requires input target URL and port numbers, and local port numbers listening to TCPTrace. In this way, you can point STUB to this local port by setting up the URL attribute of the agent STUB (eg, localhost: 8080). TCPTrace can record all requests and answers to HTTP messages.
One limitation of TcPtrace is that it determines the location where it cannot be used to view the message sent via SSL in the location of the message process. If you want to see the SOAP message sent by SSL, you can only write a custom ISAPI filter.
Third, simplify interface design
In numerous discussion on N-layer application design, simplifying the design of the interface design can be said to be everywhere. However, for the distributed computing environment such as web services, the importance of simplifying interface design is more prominent.
When designing distributed applications, due to performance and scalability considerations, the call between the client and the server should ensure that the call between the server is as small as possible. Reducing network calls are not only beneficial to reduce communication overhead (if only one SOAP message can reach the target, do not send three messages), reduce network traffic, and improve the performance of the application. Obviously, all this is the goal of the developer dreams of. So what is the simplified interface? First 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 identidy
Return True;
}
}
}
In this example, UserName and Password are two properties, and the two properties must first be set before calling the Logon () method. There is a problem light to see this code is not easy to note, this is UserName and Password as a web method. That is to say, each time the GET / SET operation for attributes will cause a call to the service.
According to the simplified interface design, the improved code is as follows:
Namespace ChattyService {
Public Class ChattyService: WebService {
[WebMethod]
Public Bool Logon (String Username, String Password) {
// Verify identidy
Return True;
}
}
}
Now, UserName and Password are the parameters of the logon () method. The advantage of the code after the modification is that it reduces the login operation to the server's three calls to once. On the other hand, if the number of parameters is too much, this method may look very unregistered. At this time, it may be necessary to put the parameters of the method into several complex types, for example, package username and password two parameters to a Credential object.
Fourth, save the application private data in web.config
Web services developed with ASP.NET can play all specials of .ASPX applications, including the ability to apply private data with the web.config file (for example, database connection string, file path, etc.). The benefits of using Web.config rather than the Global.asax file are not required after modifying the configuration.
5. Avoid using ASP.NET session status
The session state management function of .NET resolves many of its Seniors ASP 3.0 existence, such as request serialization, but there are still some limitations. It should be appreciated that .NET's session state management function is not designed specifically for session state in a web service environment, but designed to manage session state in a broader ASP.NET application, it depends on http cookies. By rewriting the URL-implemented mode, it is not required to use the WEB service).
