Asynchronous Calls in .NET When you make a method call on an object, typically you must block the client while the object executes the call, and control returns to the client only when the method completes execution and returns.However, there are quite a few cases where you want to call methods asynchronously?that is, you want control to return immediately to the client while the object executes the called method in the background, and then somehow let the client know when the method execution is completed. Such an execution mode is called asynchronous method invocation and the action is an asynchronous call. Asynchronous calls allow you to improve availability, increase throughput and performance, and make your applications more scalable. Standard, Consistent Mechanism In the past, developers often had to create their own proprietary mechanism to asynchronously invoke calls on their components. One recurring mechanism was to have the object spin off a worker thread to process the client's request and immediately return control to the client. The object would later signal the client somehow when the call completed (if the client wanted to know), and the client had to distinguish between multiple method completions. These mechanisms were difficult to develop and test, and they forced developers to spend a disproportionate amount of their time reinventing the wheel instead of adding business value to the application. In addition, such solutions coupled the clients to the objects, and were not consistently designed or implemented. Different vendors provided slightly different solutions, requiring at times different programming models on the client side. This predicament diminished the benefits of component-oriented programming because the component developer had to make some assumptions about the client's way of using the component, and vice-versa. The .NET mechanism for asynchronous calls is a mainstream facility used consistently and pervasively across the .NET application frameworks and base classes. .NET asynchronous calls are an essential addition to your arsenal as a component developer. Implementing robust asynchronous execution on your own is a demanding task, requiring a lot of effort spent on design, implementation, and testing. Requirements for an Asynchronous Mechanism To make the most of the various options available with .NET asynchronous calls, you first need to understand the generic requirements set for any modern, component-oriented asynchronous calls support: Use the same component code for both synchronous and asynchronous invocation. This allows the component developer to focus on the business logic, and facilitates using a standard mechanism. A corollary of the first requirement is that you let the client decide whether to use the component synchronously or asynchronously. That, in turn, implies that the client will have different code for each case (whether to invoke the call synchronously or asynchronously). The client should be able to issue multiple asynchronous calls, and manage multiple asynchronous calls in progress. The client should be able to distinguish between multiple methods as they complete their tasks. By that same token, the component should be able to serve multiple concurrent calls. When component methods have out-going parameters or return values, these parameters are not available when control returns to the client. The client should have a way of getting these parameters or results when the method completes. | " |
Asynchronous calls allow you to improve availability, increase throughput and performance, and scale up your application
| " |
Similarly, errors on the component's side should be propagated to the client side. An exception thrown when the method executes should be played back to the client later on. The last item is less of a requirement and more of a design guideline: The asynchronous calls mechanism should be straightforward and simple to use. For example, the mechanism should hide its implementation details as much as possible, such as the worker threads used to dispatch the call. The client has a variety of options for handling method completion, all of which support these requirements. The client issues an asynchronous method call, and then can choose to: Perform some work while the call is in progress, and then block until completion. Perform some work while the call is in progress, and then poll for completion. Receive notification when the method has completed. The notification will be in the form of a callback on a client-provided method. The callback should contain information identifying which method has just completed and its return values. Perform some work while the call is in progress, and then wait only for a pre-determined amount of time and then stop waiting, even if the method execution has not completed yet. Wait simultaneously for completion of multiple methods. The client can choose to wait for any or all of the pending calls to complete. .NET offers all these options to clients, which can be confusing when you first start using asynchronous calls. This article will demonstrate each option and recommend when (or if) to use them. First, though, we need to discuss delegates. |