« BizTalk 2006 Documentation | Main | Asynchronous Programming Model in .NET Framework 2.0 - Part II,,, »

Asynchronous Programming Model in .NET Framework 2.0 - Part I,,,

One of my favorite features in my book “101 reasons to go for .NET Framework 2.0” is Event based asynchronous mechanism. I had mentioned that asynchronous mechanism in .NET Framework 2.0 is more based on events rather than relying on delegates. We all know that event and delegate are distinct ones but differences between them are very subtle as one depends on another.


Events are basically to trigger a special occurrence in an application, and these special occurrences should be notified to subscribers who are interested in them. In subscribers’ side, invariably the delegates (if loosely defined, managed functional pointers) are being used to bind callback methods to these events. Thus, implementation of event based programming depends on both events and delegates. Asynchronous programming model is one that requires this event/delegate mechanism.

.NET Framework 1.x makes it easy to invoke any synchronous method in asynchronous manner, through internal creation the asynchronous method invocation mechanisms for them, by default. The widely used asynchronous pattern, through Begin<MethodName> and End<MethodName>, heavily depends on delegates. Once you used to the intricacies of this asynchronous model such as IAsyncResult, AsyncCallback and how to retrieve the result from within callback methods through End<MethodName> by passing IAsyncResult object (that is returned by Begin<MethodName> ) as a parameter into that method, you might start liking its simplicity. However, you might also have felt that this simple mechanism can be made simpler by letting the developers not to deal with certain threading related aspects such as waiting for a signal from the worker thread to proceed further in main thread or not to deal with bit of tedious coding practice to retrieve the result by invoking the mandatory End<MethodName>. (You might also aware of dreadful consequences of not invoking End<MethodName> ). New event based asynchronous programming model (if you are an acronymphil, start using catchy EBAPM now onwardsSmile) in .NET Framework 2.0, makes asynchronous programming simpler by abstracting out those above mentioned nagging points. And it also provides better support to invoke same asynchronous calls multiple times (looking back at DBAPM – delegates based asynchronous programming mode – another tidbit to acronymphils – it is tedious to do that as you have to pass appropriate and specific IAsyncResult objects of Begin<MethodName> into End<MethodName> methods), to cancel as well as to get the incremental status on the ongoing async operation.

In .NET Framework 2.0, to invoke methods of components are based on this EBAPM model, asynchronously, you no longer require invoking the famous pair of Begin and EndInvoke methods. Instead, you will invoke <MethodName>Async().No more dealing with that nice interface “IAsyncResult”. Retrieving the result from the asynchronously invoked method is also not through the invocation of End<MethodName> .  To be brief, developer need not bother too much about the threading aspects involved in asynchronous programming model. Though asynchronous invocation is so easy and clutter-free, implementing asynchronous mechanism into your component or class requires thorough understanding of new EBAPM concepts and newly introduced classes such as AsyncOperation, AsyncOperationManager, etc. I will provide details on them in my subsequent blogs.

However, before we delve deep into those concepts, we have to see how easy it would be to invoke the methods of components that are based on new EBAPM. And ASP.NET Web Service in .NET Framework 2.0 is one of such components. What it means is, don’t get surprised not to see those Begin and End methods syntax in the web service proxy. Instead you would see a method “<MethodName>Async” and an event “<MethodName>Completed”.

So, let us build a simple web service in .NET Framework. The following is the code snippet of that simple web service.

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Threading;
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class OrderProcessingWebService : System.Web.Services.WebService
    public OrderProcessingWebService () {
    public string ProcessAnOrder() {
        return "Order Processed!!!";

Now, let us build a windows form application that consumes this web service. You have to use “Add Web References” to create the proxy for the web service.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Threading;
namespace MyAsyncWebServiceWindowApp
    public partial class Form1 : Form
        OrderProcessingWS.OrderProcessingWebService proxy = null;
        public Form1()
            proxy = new OrderProcessingWS.OrderProcessingWebService();
            proxy.ProcessAnOrderCompleted += delegate(object sender,  OrderProcessingWS.ProcessAnOrderCompletedEventArgs e)
                  callbackThreadTextBox.Text = Thread.CurrentThread.ManagedThreadId.ToString();
                  statusTextBox.Text = e.Result.ToString();
        private void button1_Click(object sender, EventArgs e)
            uiThreadTextBox.Text = Thread.CurrentThread.ManagedThreadId.ToString();
            statusTextBox.Text = "Order is to be processed, asynchronously!!!";

Now, you can compare this approach with previous one in .NET Framework 1.x. If you liked the previous asynchronous model very much, you would miss things such as Begin and End Methods, IAsyncResult interface and dealing with WaitHandle, but you would not deny that this approach is more intuitive and clutter-free. And you would also have noticed in the above code, that one tiny but a neat feature in .NET Framework 2.0, anonymous method, eliminates the necessity of creating a separate method to be linked with a delegate in event binding.

And another important thing that you would have noticed is that you need not worry about using delegate to switch over from worker thread to main UI thread, when you try to update the UI controls from within callback method, in this approach, as you have to do in DBAPM in .NET Framework 1.x in Win Form applications.

In my next blog, let us see more conceptual and technical details of EBAPM. Hope we would say good bye to DBAPM soon Smile.


How about a discussion on BackgroundWorker class introducted in .net framework 2.0? It additionally helps work with UI elements with lot more ease and does away with the issues of calling UI components on threads other than those, that created them.

Keep up the great writing. I really like reading your articles. Thanks.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter