Server-side asynchronous Web methods

Server-side asynchronous Web methods

When to use asynchronous Web methods

There are a few issues to consider when determining whether an asynchronous Web method is appropriate for your application. First, the BeginXXX function that is called must return a IAsyncResult interface. IAsyncResult is returned from multiple asynchronous I/O operations, including access to the data flow, microsoft® windows® Sockets invoke, perform file I/O, interact with other hardware devices, invoke async methods, and of course include invoking other WEB services. You can get IAsyncResult from these asynchronous operations in order to return it from the BeginXXX function. You can also create your own classes to implement the IAsyncResult interface, but you might later need to wrap one of the previously mentioned I/O operations in some way.

For most of the asynchronous operations mentioned earlier, it makes sense to wrap back-end asynchronous calls using asynchronous Web methods to make the Web service code more efficient. Except when using delegates for asynchronous method calls. A delegate causes an asynchronous method call to occupy a thread in the process thread pool. Unfortunately, the ASMX handlers also use these threads when servicing incoming requests. Therefore, unlike calls to perform true I/O operations on hardware or network resources, asynchronous method calls using delegates will still occupy one of the process threads at execution time. You can also use the original thread to run your Web method synchronously.

The following example shows an asynchronous Web method that invokes a back-end Web service. It has used the WebMethod property to identify the Begingetage and Endgetage methods to run asynchronously. The code for this asynchronous Web method calls the back-end Web method named Userinfoquery to get the information it needs to return. The call to Userinfoquery is executed asynchronously and is passed to the AsyncCallback function, which is passed to the Begingetage method. This causes the internal callback function to be called when the backend request completes. The callback function then calls the Endgetage method to complete the request. The code in this example is much simpler than the code in the previous example, and has the added advantage of not starting back-end processing in the same pool of threads that served the middle-tier Web method request.

[WebService]

public class GetMyInfo:System.Web.Services.WebService

{

[WebMethod]

Public IAsyncResult Begingetage (AsyncCallback cb, Object State)

{

Invokes an asynchronous Web service call.

localhost. Userinfoquery Proxy

= new localhost. Userinfoquery ();

Return proxy. Begingetuserinfo ("User name",

Cb

proxy);

}

[WebMethod]

public int Endgetage (IAsyncResult res)

{

localhost. Userinfoquery Proxy

= (localhost. Userinfoquery) Res. asyncstate;

int age = Proxy. Endgetuserinfo (RES). Age;

In this case, the results of the WEB service are

Processing.

return age;

}

}

One of the most common types of I/O operations that occur in a Web method is a call to a SQL database. Unfortunately, the current microsoft® ADO has not yet defined a good mechanism for asynchronous invocation, but simply wrapping the SQL call into an asynchronous delegate call is not helpful in improving efficiency. Although you can sometimes choose to cache the results, you should also consider publishing your database as a Web service using Microsoft SQL Server Web Services Toolkit. This allows you to invoke the Web service asynchronously to query or update the database by leveraging support in the. NET Framework.

There are a number of back-end resources to be aware of when accessing SQL through a WEB service invocation. If you are using a TCP socket to communicate with a Unix computer, or if you have access to some other available SQL platforms through a dedicated database driver, or even have access to resources using DCOM, you may consider publishing these resources as Web services using a multitude of Web service toolkits.

One of the advantages of using this approach is that you can take advantage of the client Web service architecture, such as asynchronous Web service calls using the. NET Framework. This gives you the ability to get asynchronous calls for free, and your client access mechanism works efficiently with asynchronous Web methods.

Aggregating data using asynchronous Web methods

Many Web services now access multiple resources on the backend and aggregate information for the front-end Web services. Although invoking multiple back-end resources increases the complexity of the asynchronous Web method model, it can ultimately be significantly more efficient.

Suppose your Web method calls two back-end Web services: Service A and service B. From your BeginXXX function, you can invoke service A and service B asynchronously. You should pass your own callback function to each asynchronous call. After receiving the results from service A and service B, to trigger the completion of the Web method, the callback function you provide will verify that all the requests have been completed, that all processing is done on the returned data, and then call the callback function passed to the BeginXXX function. This triggers a call to the ENDXXX function, and the return of this function will result in the completion of the asynchronous Web method.

Summary

Asynchronous Web methods provide an effective mechanism in an ASP. NET Web service that can call back-end services without taking advantage of valuable threads in the process thread pool.