To wait or not to wait; that is the question! Whether or not to implement asynchronous processing is one of the fundamental issues that a developer must answer when invoking function calls across process boundaries. Given that the option to invoke an asynchronous call is available, the programmer has to weigh the relative ease of coding synchronous calls with its inherent drawback - when a synchronous call is made, the calling thread is blocked and has to wait until the function completes. In many instances, this is an acceptable shortcoming, as in the case when a program's logic flow should not continue until data is retrieved from a database. Asynchronous processing, on the other hand, allows more parallelism. A thread that initiates an asynchronous call is not blocked and can therefore do almost any computation while the method is in transit. The case for asynchronous processing becomes very compelling in the enterprise computing space where systems need to handle hundreds of thousands of function call requests and synchronicity may become a barrier to scalability.
Having programmed in Visual Basic for most of my professional career, I used to be envious of my C++ counterparts and their seemingly magical ability to create multi-threaded applications that did any number of parallel tasks, which is a requirement for asynchronous processing. Sure, I was able to mimic asynchronous behavior in VB using out-of-process servers and the use of the dreaded timer control. It worked, but it just wasn't elegant. And the application definitely didn't scale.
Life became easier with the advent of VB 6 and its ability to use apartment-model threading. In addition, the programmer's arsenal of tools increased with Windows 2000 providing more ways to make asynchronous calls using COM+ events, and COM asynchronous interfaces.
Although it's still a non-trivial undertaking, the .NET framework makes programming asynchronous processes much easier than before. .NET has asynchronous code built in, and asynchronous programming is a feature supported by many areas of the .NET framework, including I/O operations, networking, messaging, message queues, Async delegates, ASP.NET web forms and, of course, Web Services.
A Common Design Pattern :
In order to provide a consistent framework for modeling asynchronous processes, the .NET framework provides an important common design pattern as a core guiding concept. The basic ideas behind this pattern are as follows:
- The .NET framework will provide services needed for supporting the asynchronous programming model.
- It is the client code that decides if a particular call should be asynchronous.
- It is not necessary for a called object to do additional programming to support asynchronous behavior by its clients. The common language runtime infrastructure should be able to handle the difference between the caller and called object views.
- The called object can choose to explicitly support asynchronous behavior, either because it can implement it more efficiently than a general architecture, or it wants to support only asynchronous behavior by its callers. However, it is recommended that such called objects follow the asynchronous design pattern for exposing asynchronous operations.
- The common language runtime provides type safety. For Async delegates, which are explained in the next section, the compiler generates type-safe method signatures for the BeginInvoke and EndInvoke method calls.