WCF and the AsyncPattern property (part 3)

This is the third in a series of posts about the AsyncPattern in WCF.

The previous two posts described the purpose and usage of this property on the service side. The present post addresses the client side.

AsyncPattern at the client side

The AsyncPattern=true is used at the client side to expose an asynchronous programmatic interface to a service operation. Similarly to what happens at the service side, this property defines the local communication pattern between the service’s client code and the WCF runtime (at the client side).

Consider the following WSDL excerpt defining a portType with two request-response operations

   1: <wsdl:portType name="IService">
   2:  
   3:   <wsdl:operation name="Operation1">
   4:     <wsdl:input wsaw:Action="..." message="..." /> 
   5:     <wsdl:output wsaw:Action="..." message="..." /> 
   6:   </wsdl:operation>
   7:  
   8:   <wsdl:operation name="Operation2">
   9:     <wsdl:input wsaw:Action="..." message="..." /> 
  10:     <wsdl:output wsaw:Action="..." message="..." /> 
  11:   </wsdl:operation>
  12:  
  13: </wsdl:portType>

By default, the interface generated by svcutil.exe has a synchronous interface

   1: public interface IService {
   2:         
   3:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   4:     ReplyData Operation1(RequestData rd);
   5:         
   6:     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IService/Operation2", ReplyAction="http://tempuri.org/IService/Operation2Response")]
   7:     ReplyData Operation2(RequestData rd);
   8:  
   9: }

However, using the /async switch, the svcutil.exe can also generate an interface with synchronous and asynchronous methods.

   1: public interface IService {
   2:     
   3:     // Operation 1 synchronous method   
   4:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   5:     ReplyData Operation1(RequestData rd);
   6:  
   7:     // Operation 1 asynchronous method pair         
   8:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation1", ReplyAction=".../Operation1Response")]
   9:     System.IAsyncResult BeginOperation1(RequestData rd, System.AsyncCallback callback, object asyncState);        
  10:     ReplyData EndOperation1(System.IAsyncResult result);
  11:         
  12:     // Operation 2 synchronous method   
  13:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation2", ReplyAction=".../Operation2Response")]
  14:     ReplyData Operation2(AsyncPattern.Client.AsyncClient.RequestData rd);
  15:         
  16:     // Operation 2 asynchronous method pair         
  17:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation2", ReplyAction=".../Operation2Response")]
  18:     System.IAsyncResult BeginOperation2(RequestData rd, System.AsyncCallback callback, object asyncState);        
  19:     ReplyData EndOperation2(System.IAsyncResult result);
  20:     
  21: }

Note that:

  • This setting does not change the communication pattern between the client and the service.
  • Using AsyncPattern=true at the client side is not in any way related to using AsyncPattern=true at the service side (the service doesn’t even have to implemented over WCF!)

AsyncPattern=true versus BeginInvoke

As stated here, using the delegate’s BeginInvoke method is not a way to achieve the same effect as AsyncPattern=true.

Namely:

  • If the delegate target is a client channel instance (returned by a ChannelFactory), then the call will block (as described in a previous post).

 

  • If the delegate target is a “client proxy” (ClientBase derived class generated by svcutil.exe), then the call will not block. However a thread will remain blocked until the reply is received (the thread from the thread pool used to call the asynchronous method). This does not happens when using AsyncPattern=true, since the WCF supports full asynchronous requests.
    The blocking of this thread may not be significant on a smart client scenario. However, this “thread consumption” may be problematic on a middle-tier scenario, where a significant amount of requests may be pending at a given moment in time.

One thought on “WCF and the AsyncPattern property (part 3)

  1. Pingback: WCF asynchronous processing and IIS hosting « Pedro Félix’s shared memory

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s