Five tips for developing web services using ASP. NET

Unless otherwise specified,. NET will attempt to bind the Web service to three protocols: HTTP/post, HTTP/get, and soap. The reason for "trying" is that it depends on the service parameters and return type, and the HTTP/get protocol may not be available ......

1. Disable the http post/get Protocol

Unless otherwise specified,. NET will attempt to bind the Web service to three protocols: HTTP/post, HTTP/get, and soap. The reason for "trying" is that it depends on the service parameters and return type, and the HTTP/get protocol may be unavailable .. The WSDL file generated by. NET will automatically contain commands bound to these three protocols.ProgramYou can choose which Protocol to use to communicate with the service.

You can easily Delete the binding of HTTP/post and HTTP/get by adding the following content to the Web. config file:

** <WebServices> ** <Protocols> ** <Remove name = "httppost"/> ** <Remove name = "httpget"/> ** </Protocols> ** </WebServices>

Why do we avoid using HTTP/post and HTTP/get protocols to introduce web services? The two main reasons are security and interoperability. HTTP/get is not as secure as soap, and because HTTP/get is common in web links, malicious people may use it for spoofing, this allows others to call web services with their own Security Identifiers without knowing they are clicking web links.

In terms of interoperability, soap is a widely used Web service communication standard, whereas HTTP/get and HTTP/post are not. Therefore, many tools that automatically generate proxy servers do not understand the default binding of HTTP/get and HTTP/post contained in. Net-generated WSDL documents. Therefore, if your web service is not bound to the HTTP/get and HTTP/post protocols, it is best to cancel these two bindings.

2. Use tcptrace to view SOAP request/response messages

Debugging may be extremely difficult for developers who develop web service applications, because. net SDK or. no tool is provided to view soap messages between the client and the server.

If. net and non. the interaction process between the client and the server has encountered a problem. To identify the root cause of the problem, it is particularly important to have the ability to view soap messages, this type of problem is often related to the SOAP message format (for example, "Does a message contain soapaction? ").

Tcptrace (www.pocketsoap.com/tcptrace) is an excellent tool for viewing such message exchange processes. It works by setting a tunnel between the client and the server. When tcptrace is started, it requires that the target URL and port number and the local port number of the tcptrace listener be entered. In this way, you can set the URL attribute of the proxy stub to point stub to the local port (for example, localhost: 8080 ). Tcptrace can record all requests and responses to HTTP messages.

One limitation of tcptrace is that its position in the message flow determines that it cannot be used to view messages sent through SSL. If you want to view soap messages sent through SSL, you can write only one custom ISAPI filter.

Iii. Simplified Interface Design

In many discussions about N-layer application design, the key to simplifying the interface design can be seen everywhere. However, for distributed computing environments such as Web Services, simplified interface design is more important.

In the design of distributed applications, for performance and scalability considerations, the call between the client and the server should be minimized. Reducing Network calls not only reduces communication overhead (if only one SOAP message can be used to reach the target, no three messages should be sent), reduces network traffic and improves application performance. Obviously, all these are developers' dream goals. What are the features of a simplified interface?

First, let's look at a complex interface Example:

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 your identity Return true; } } }

In this example, username and password are two attributes. You must set these attributes before calling the logon () method. Let's look at this issue.CodeIt is not easy to note that both username and password are extracted as web methods. This means that each get/set operation on the attribute will result in a call to the service.

According to the requirements of simplified interface design, the improved code is as follows:

Namespace chattyservice { Public class chattyservice: WebService { [Webmethod] Public bool Logon (string username, string password ){ // Verify your 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 three calls of the login operation to the server once. On the other hand, if there are too many parameters, this method may not look decent. In this case, you may need to sort the parameters of the method into several complex types. For example, encapsulate the parameters username and password into a credential (certificate) object.

4. Save private application data in Web. config

Use ASP. web services developed by. Net can be used. all features of the aspx application, including the use of web. the config file can store private data of an application (for example, database connection strings and file paths ). The advantage of using web. config instead of the global. asax file is that you do not have to reconstruct the application after modifying the configuration.

5. Avoid using ASP. NET session Status

The session state management function implemented by. Net solves many problems existing in ASP 3.0 of its predecessors, such as serialization of requests, but there are still some limitations. We should realize that ,. the session state management function of net is not designed specifically for the session state in the Web service environment, but for the wider range of ASP. it is designed to manage session states in A. NET application. It depends on HTTP cookies (there is a pattern that requires no cookie by rewriting the URL, but it is not applicable to Web Services ).

Cookie is unique to HTTP. On the web, all browsers support HTTP, So cookies are very suitable for use in Web applications. However, the application of cookies in Web Services limits the service to the HTTP protocol. On the other hand, the operation of the SOAP protocol is independent of the transmission protocol. Therefore, if you restrict web service applications to the HTTP protocol, the flexibility of applications is also limited, once a service is provided through a non-HTTP transmission protocol (such as SMTP), it will become very troublesome.