Share via

It Makes the WWW Go Round, Part 3: IRequestContext

  • Article

The final player in the drama between IRequestChannel and IReplyChannel is the link connecting requests to replies.  As we saw last time, when a server receives a request, it doesn't have direct access to the message that the client sent.  Instead, the message is wrapped up inside an IRequestContext, which contains both the message and something that looks a lot like a channel for sending the response.

 public interface IRequestContext : IDisposable
{
   Message RequestMessage { get; }

   void Abort();
   IAsyncResult BeginReply(Message message, AsyncCallback callback, object state);
   IAsyncResult BeginReply(Message message, TimeSpan timeout, AsyncCallback callback, object state);
   void Close();
   void Close(TimeSpan timeout);
   void EndReply(IAsyncResult result);
   void Reply(Message message);
   void Reply(Message message, TimeSpan timeout);
}

The RequestMessage property gives you access to the client request for processing.  However, there are some tricky semantics in play here.  In WCF, resources like messages and channels need to be closed when you're done using them.  Every one of these objects should have the concept of an owner assigned to it so that it's clear who is responsible for ultimately calling Close.  When you get the message out of a request context, you become the owner of that message and need to close it when you're done.  Exposing the message as a property really doesn't communicate this responsibility.  Try to remember that you need to treat a message coming from a request context just like you treat a message coming directly from a channel.

The remaining methods of IRequestContext should be very familiar to you by now.  They're a subset of the standard methods on an IOutputChannel along with a few of the necessary methods from ICommunicationObject.  Think of a request context as a short-lived channel where you first read one message, write one message, and then close the channel.

Next time: Creating Channels for Talking

Comments

  • Anonymous
    March 20, 2006
    After a short break, let's continue looking at the request-reply message pattern.  In the previous...
  • Anonymous
    April 04, 2006
    Although the WCF channel model has a relatively simple set of APIs, it has a very subtle set of rules...
  • Anonymous
    April 18, 2006
    During the last few weeks I've been going over various parts of the channel model and giving some commentary...