As with any WCF service, the client and the service need to agree beforehand on the response contract and what it will be used for; that is, whether it will be used for returned values and error information, or just returned values. Note that you can also split the response service into two services, and have one response service for results and another for faults and errors. As an example, consider the ICalculator contract implemented by the queued MyCalculator service:

[ServiceContract]
interface ICalculator
{
   [OperationContract(IsOneWay = true)]
   void Add(int number1,int number2);
   //More operations
}
class MyCalculator : ICalculator
{...}

The MyCalculator service is required to respond to its client with the result of the calculation and report on any errors. The result of the calculation is an integer, and the error is in the form of the ExceptionDetail data contract presented in Chapter 6. The ICalculatorResponse contract could be defined as:

[ServiceContract]
interface ICalculatorResponse
{
   [OperationContract(IsOneWay = true)]
   void OnAddCompleted(int result,ExceptionDetail error);
   //More operations
}

The response service supporting ICalculatorResponse needs to examine the returned error information; notify the client application, the user, or the application administrator on the method completion; and make the results available to the interested parties. Example 9-21 shows a simple response service that supports ICalculatorResponse.

class MyCalculatorResponse : ICalculatorResponse
{
   public void OnAddCompleted(int result,ExceptionDetail error)
   {
      if(error != null)
      {
         //Handle error
      }
      else
      {
         MessageBox.Show("Result = " + result,"MyCalculatorResponse");
      }
   }

   //More operations
}

As demonstrated by Example 9-21, the response service is just that—a simple service. There is nothing special about it other than its designation as a response service.

[ServiceContract]
interface ICalculator
{
   [OperationContract(IsOneWay = true)]
   void Add(int number1,int number2,string responseAddress,string methodId);
}

[ServiceContract]
interface ICalculatorResponse
{
   [OperationContract(IsOneWay = true)]
   void OnAddCompleted(int result,ExceptionDetail error,string methodId);
}

[DataContract]
public class ResponseContext
{
   [DataMember]
   public readonly string ResponseAddress;

   [DataMember]
   public readonly string FaultAddress;

   [DataMember]
   public readonly string MethodId;

   public ResponseContext(string responseAddress,string methodId) :
                                               this(responseAddress,methodId,null)
   {}
   public ResponseContext(string responseAddress) : this(responseAddress,
                                                        Guid.NewGuid().ToString())
   {}
   public ResponseContext(string responseAddress,string methodId,
                          string faultAddress)
   {
      ResponseAddress = responseAddress;
      MethodId = methodId;
      FaultAddress = faultAddress;
   }

   public static ResponseContext Current
   {
      get
      {
         return GenericContext<ResponseContext>.Current.Value;
      }
      set
      {
         GenericContext<ResponseContext>.Current =
                                        new GenericContext<ResponseContext>(value);
      }
   }
   //More members
}

My HeaderClientBase<T,H> proxy base class (defined in Appendix B) is designed to automate passing information in the headers from the client to the service:

public abstract class InterceptorClientBase<T> : ClientBase<T> where T : class
{
   protected virtual void PreInvoke(ref Message request)
   {}
   //More members
}
public abstract partial class HeaderClientBase<T,H> : InterceptorClientBase<T>
                                                      where T : class
{
   public H Header
   {get;protected set;}

   public HeaderClientBase(H header);
   public HeaderClientBase(H header,string endpointName);

   //More members
}

However, when it comes to the response context, there are differences compared with the raw headers management discussed in Appendix B: specifically, changing the context (that is, the headers) on each call as opposed to setting it only at construction time, generating method IDs and providing them to the client, and enqueuing rather than merely invoking the service call. While the client can easily use my HeaderClientBase<T,H> to do all that, all clients will have to repeat such code for every contract and proxy they have. It is better to automate and encapsulate these steps in a dedicated proxy base class such as my ClientResponseBase<T>, shown in Example 9-23.

public abstract class ClientResponseBase<T> :
                               HeaderClientBase<T,ResponseContext> where T : class
{
   protected readonly string ResponseAddress;

   public ClientResponseBase(string responseAddress)
   {
      ResponseAddress = responseAddress;
      Endpoint.VerifyQueue();
   }
   public ClientResponseBase(string responseAddress,string endpointName)
   {...}
   public ClientResponseBase(string responseAddress,
                             NetMsmqBinding binding,EndpointAddress address)
   {...}

   /* More constructors */

   protected override void PreInvoke(ref Message request)
   {
      string methodId = GenerateMethodId();
      Header = new ResponseContext(ResponseAddress,methodId);
      base.PreInvoke(ref request);
   }
   protected virtual string GenerateMethodId()
   {
      return Guid.NewGuid().ToString();
   }
}

The constructors of ClientResponseBase<T> accept the response address and the regular proxy parameters, such as the endpoint name, address, and binding. The constructors store the response address in the read-only public field ResponseAddress. In addition, the constructors use the VerifyQueue() endpoint extension method to verify that the service queue (and the DLQ) exists and to create it if necessary.

ClientResponseBase<T> provides the virtual GenerateMethodId() method, which by default uses a GUID for the method ID. However, your subclasses of ClientResponseBase<T> can override it and provide their own unique strings, such as an incremented integer.

The heart of ClientResponseBase<T> is the overridden PreInvoke() method. PreInvoke() is defined as virtual in the InterceptorClientBase<T> base class of HeaderClientBase<T,H>. InterceptorClientBase<T> is part of a generic interception framework I wrote (defined in Appendix E) that enables you to perform custom pre-call and post-call interception steps. For every operation invoked by the client, PreInvoke() generates a new method ID, provides it to a new ResponseContext object (along with the response address supplied to the constructor), and assigns the new ResponseContext object to the Header property of HeaderClientBase<T,H>. Thanks to generics, Header is of the type ResponseContext.

[ServiceContract]
interface ICalculator
{
   [OperationContract(IsOneWay = true)]
   void Add(int number1,int number2);
   //More operations
}

class CalculatorClient : ClientResponseBase<ICalculator>,ICalculator
{
   public CalculatorClient(string responseAddress) : base(responseAddress)
   {}
   public CalculatorClient(string responseAddress,string endpointName) :
                                                 base(responseAddress,endpointName)
   {}
   public CalculatorClient(string responseAddress,
                           NetMsmqBinding binding,EndpointAddress address) :
                                             base(responseAddress,binding,address)
   {}
   //More constructors

   public void Add(int number1,int number2)
   {
      Channel.Add(number1,number2);
   }

   //More operations
}

string responseAddress = "net.msmq://localhost/private/MyCalculatorResponseQueue";

CalculatorClient proxy = new CalculatorClient(responseAddress);
proxy.Add(2,3);
proxy.Close();

CalculatorClient proxy = new CalculatorClient(responseAddress);
proxy.Add(2,3);
string methodId = proxy.Header.MethodId;
proxy.Close();

The service needs to construct a proxy that will dispatch messages to the client-side response service. To simplify this, use my ServiceResponseBase<T>, defined as:

public abstract class ServiceResponseBase<T> : HeaderClientBase<T,ResponseContext>
                                                                   where T : class
{
   public ServiceResponseBase();
   public ServiceResponseBase(string bindingName);
   public ServiceResponseBase(NetMsmqBinding binding);
}

ServiceResponseBase<T> automates reading the response context from the message headers and writing the response itself to the outgoing headers. Other than that, you can use it like any other proxy base class. Example 9-25 demonstrates the usage of ServiceResponseBase<T>.

class CalculatorResponseClient : ServiceResponseBase<ICalculatorResponse>,
                                                               ICalculatorResponse
{
   public void OnAddCompleted(int result,ExceptionDetail error)
   {
      Channel.OnAddCompleted(result,error);
   }
}
class MyCalculator : ICalculator
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void Add(int number1,int number2)
   {
      int result = 0;
      ExceptionDetail error = null;

      try
      {
         result = number1 + number2;
      }
      //Don't rethrow
      catch(Exception exception)
      {
         error = new ExceptionDetail(exception);
      }
      finally
      {
         CalculatorResponseClient proxy = new CalculatorResponseClient();

         proxy.OnAddCompleted(result,error);

         proxy.Close();
      }
   }
}

In Example 9-25, the MyCalculator service catches any exception thrown by the business logic operation and wraps that exception with an ExceptionDetail object. The service does not rethrow the exception. As you will see later, in the context of transactions and response services, rethrowing the exception would also cancel the response. Moreover, when using a response service, being able to respond in case of an error is a much better strategy than relying on WCF’s playback error handling.

In the finally statement, regardless of exceptions, the service responds. It creates a new proxy to the response service to enqueue the response. The proxy in Example 9-25 will default to using the same MSMQ binding as the host.

Example 9-26 shows the implementation of ServiceResponseBase<T>.

public abstract class ServiceResponseBase<T> : HeaderClientBase<T,ResponseContext>
                                                                   where T : class
{
   public ServiceResponseBase() : this(OperationContext.Current.Host.
                               Description.Endpoints[0].Binding as NetMsmqBinding)
   {}
   public ServiceResponseBase(string bindingName) :
                                              this(new NetMsmqBinding(bindingName))
   {}

   public ServiceResponseBase(NetMsmqBinding binding) :
                                              base(ResponseContext.Current,binding,
                      new EndpointAddress(ResponseContext.Current.ResponseAddress))
   {
      Endpoint.VerifyQueue();
   }
}

The default constructor of ServiceResponseBase<T> uses the same queued binding the host was using to dequeue the client’s call. You can also specify an MSMQ binding section in the config file or provide the constructor with the binding instance to use. Both of these constructors delegate the work to the third constructor, which accepts the MSMQ binding to use. That constructor reads the response address out of the response context and provides those two along with the response context to the base constructor of HeaderClientBase<T,H>. It also verifies the presence of the response queue.

Note that ServiceResponseBase<T> sends the response service the entire response context (not just the ID). This is done both for simplicity’s sake and because it may be beneficial for the response service to have access to the fault and response address used.

The response service accesses its response context, reads from it the method ID, and responds accordingly. Example 9-27 demonstrates a possible implementation of such a response service.

class MyCalculatorResponse : ICalculatorResponse
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void OnAddCompleted(int result,ExceptionDetail error)
   {
      string methodId = ResponseContext.Current.MethodId;
      ...
   }
}

class CalculatorResponse :
                        FormHost<CalculatorResponse>,
                                  ICalculatorResponse
{
   [OperationBehavior(TransactionScopeRequired=true)]
   public void OnAddCompleted(int result,
                              ExceptionDetail error)
   {
      Text = "Add returned: " + result;
      ...
   }
}

A queued service typically queues up the response as part of the incoming playback transaction. Given the queued service definition of Example 9-28, Figure 9-13 depicts the resulting transaction and the participating actions.

class MyCalculator : ICalculator
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void Add(int number1,int number2)
   {
      ...
      try
      {
         ...
      }
      catch //Do not rethrow
      {
         ...
      }
      finally
      {
         CalculatorResponseClient proxy = new CalculatorResponseClient();

         proxy.OnAddCompleted(result,error);

         proxy.Close();
      }
   }
}

Figure 9-13. Queuing up in the playback transaction

Design-wise, the nice thing about having the queued call playback and the queued response in the same transaction is that if the playback transaction is aborted for whatever reason (including due to other services in the transaction aborting), the response is canceled automatically. This is by far the most common choice for most applications.

Note in Example 9-28 that the service catches all exceptions and does not rethrow them. This is important, because any unhandled exception (or rethrown exception) will abort the response, so there won’t be any point in the service bothering to respond. Using a response service intrinsically means that the service does not rely on the automatic retry mechanism of WCF, and it handles its own business logic failures because the clients expect it to respond in a prescribed manner.

Using a new transaction

As an alternative to always having the response be part of the playback transaction, the service can respond in a new transaction by encasing the response in a new transaction scope, as shown in Example 9-29 and illustrated in Figure 9-14.

Example 9-29. Responding in a new transaction

class MyCalculator : ICalculator
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void Add(int number1,int number2)
   {
      ...
      finally
      {
         using(TransactionScope transactionScope =
                          new TransactionScope(TransactionScopeOption.RequiresNew))
         {
            CalculatorResponseClient proxy = new CalculatorResponseClient();

            proxy.OnAddCompleted(result,error);

            proxy.Close();
         }
      }
   }
}

Figure 9-14. Responding in a new transaction

Responding in a new transaction is required in two cases. The first is when the service wants to respond regardless of the outcome of the playback transaction (which could be aborted by other downstream services). The second case is when the response is nice to have, and the service does not mind if the playback transaction commits but the response aborts.

class MyCalculatorResponse : ICalculatorResponse
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void OnAddCompleted(...)
   {...}
}

class MyCalculatorResponse : ICalculatorResponse
{
   public void OnAddCompleted(int result,ExceptionDetail error)
   {
      using(TransactionScope scope = new TransactionScope())
      {...}
   }
}

class MyCalculatorResponse : ICalculatorResponse
{
   public void OnAddCompleted(...)
   {...}
}