Server-side asynchronous Web method (i)

web| Server | Asynchronous Summary: Matt Powell Describes how to use asynchronous Web methods on the server side to create high-performance Microsoft asp.net Web services.

Brief introduction

In the third column in September (English), I talked about the issue of using the Microsoft®.net Framework's client capabilities to invoke Web services asynchronously via HTTP. This method of invoking Web services is useful, and you do not have to lock your application or generate too many background threads when you use it. Now let's look at asynchronous Web methods that provide similar functionality on the server side. Asynchronous Web methods have a high performance similar to the hse_status_pending approach in writing ISAPI extensions, but do not need to write code for managing their own thread pools, while having all the benefits of running in managed code.

First we consider the regular synchronous microsoft®asp.net Web approach. When you return from the synchronization Web method, a response to the method is sent. If a longer time is required to complete the request, the thread that processes the request is occupied until the method call is finished. Unfortunately, most of the longer calls are caused by long database queries or calls to another Web service. For example, if you call a database, the current thread waits for the call to complete. Threads have nothing to do, just wait until they hear the query return. Similar problems can occur when a thread waits to complete a call to a TCP socket or back-end Web service.

It's not good to keep the thread waiting, especially if the server is under a lot of pressure. Threads in wait will not perform any effective work, such as servicing other requests. We need to find a way to start a long background process on the server while returning the current thread to the asp.net process pool. Then, when the long background process completes, we call a callback function, end the processing of the request, and somehow notify the asp.net that the request has been completed. In fact, this functionality can be provided by ASP.net using asynchronous Web methods.

How asynchronous Web methods work

When you write a typical asp.net Web service using Web methods, microsoft®visual studio®.net simply compiles your code to create the assembly, which is called when you receive a request for its Web method. The assembly itself does not know anything about SOAP. Therefore, when your application starts for the first time, the ASMX handler must reflect your assembly to determine which WEB methods are provided. For general synchronization requests, these operations are simple: Find out which methods have the associated WebMethod property, and set the logic for invoking the correct method based on the SOAPAction HTTP header.

For asynchronous requests, in the reflection process, the ASMX handler looks for WEB methods that have some kind of signature and recognize the signature as asynchronous. The handler will look for a method pair that meets the following rules:

BeginXXX and EndXxx Web methods, where XXX is any string that represents the name of the method to be provided.
The BeginXXX function returns a IAsyncResult interface and accepts AsyncCallback and an object, respectively, as its last two input parameters.
The ENDXXX function accepts a IAsyncResult interface as its only parameter.
All two methods must be identified by using the WebMethod property.
If the ASMX handler finds that two methods meet all of the above criteria, the method XXX is provided in its WSDL as a regular Web method. The method will accept the parameter defined before the AsyncCallback parameter in the BeginXXX signature as input and return the content returned by the ENDXXX function. Therefore, if a Web method has the following synchronization declaration:

[WebMethod]

public string LengthyProcedure (int milliseconds) {...}

The asynchronous declaration will be:

[WebMethod]

Public IAsyncResult BeginLengthyProcedure (

int milliseconds,

AsyncCallback CB,

Object s) {...}



[WebMethod]

public string EndLengthyProcedure (IAsyncResult call) {...}

The WSDL for each method is the same.

After an ASMX handler reflects an assembly and detects an asynchronous Web method, it must handle a request to that method in a different way than to handle the synchronization request. It calls the BeginXXX method, not some simple method. It serializes the incoming request restore to the parameter to be passed to the function (as in the case of the synchronization request), but it also passes the pointer to an internal callback function (as an additional AsyncCallback parameter for the BeginXXX method).

This approach is similar to the asynchronous programming pattern for WEB service client applications in the. NET Framework. If the client supports asynchronous Web service calls, you can release the thread that is occupied for the client computer, and if the server side supports asynchronous Web service calls, you can free the threads that are occupied on the server computer. But here are two key differences. First, the BeginXXX and ENDXXX functions are not called by server code, but are called by the ASMX handler. Second, you write code for the BeginXXX and ENDXXX functions, and you can't use the WSDL. EXE or code generated by the Add Web Reference (adding Web References) Wizard in Visual Studio. NET. But the result is the same, freeing the thread so that it can perform other processes.

When the ASMX handler calls the server's BeginXXX function, it returns the thread to the process thread pool so that it can handle any other requests received. However, you cannot release the requested HttpContext. The ASMX handler waits until the callback function passed to the BeginXXX function is invoked to end the processing request.

Once the callback function is invoked, the ASMX handler calls the ENDXXX function so that your Web method can perform any processing you want, and you can get the return data that is serialized into the SOAP response. When the EndXxx function returns, the response is sent and only the HttpContext of the request is released.