Partager via

It Makes the WWW Go Round, Part 2: IReplyChannel

  • Article

After a short break, let's continue looking at the request-reply message pattern.  In the previous article in this series, we saw that the IRequestChannel interface for the client side of the pattern was almost identical to the IOutputChannel interface for the client side of the one-way message  and duplex patterns.  I hinted that there was also a strange similarity between IReplyChannel and the IInputChannel interface for the server side.  Today, we'll see that similarity but introduce the slight twist of the pattern.

The key aspect of the request-reply message pattern is that it correlates the messages between the client and server.  For every message that the client sends, the server must send back exactly one message in reply.  The client can't send another request until the first request is finished, and the server can only communicate with the client in response to a request.

On the client side, we saw that this correlation appears in the welding together of a Send and Receive method into a single Request method.  Let's look at the equivalent part of the server side.

 public interface IReplyChannel : IChannel, ICommunicationObject, IDisposable
{
   EndpointAddress LocalAddress { get; }

   IAsyncResult BeginReceiveRequest(AsyncCallback callback, object state);
   IAsyncResult BeginReceiveRequest(TimeSpan timeout, AsyncCallback callback, object state);
   IAsyncResult BeginTryReceiveRequest(TimeSpan timeout, AsyncCallback callback, object state);
   IAsyncResult BeginWaitForRequest(TimeSpan timeout, AsyncCallback callback, object state);
   IRequestContext EndReceiveRequest(IAsyncResult result);
   bool EndTryReceiveRequest(IAsyncResult result, out IRequestContext context);
   bool EndWaitForRequest(IAsyncResult result);
   IRequestContext ReceiveRequest();
   IRequestContext ReceiveRequest(TimeSpan timeout);
   bool TryReceiveRequest(TimeSpan timeout, out IRequestContext context);
   bool WaitForRequest(TimeSpan timeout);
}

There's certainly a striking resemblance looking back at IInputChannel.  We have the same three varieties of Receive, and the same flavors for synchronous/asynchronous and explicit/default timeouts.  However, all of our messages have been replaced by instances of an IRequestContext interface.  This is the equivalent server side correlation of the input and output messages.  Conceptually, this is a much bigger leap than just changing the methods around because we've introduced this correlation abstraction that acts a lot like a channel.  The request context not only encompasses the message, but it's also the mechanism to use for sending the reply.

We'll wrap up this flurry of posts about channel shapes on Monday by examining this channel that isn't, IRequestContext.

Next time: It Makes the WWW Go Round, Part 3: IRequestContext

Comments

  • Anonymous
    March 17, 2006
    The final WCF message exchange pattern that I'm going to look at is the request-reply version of two-way...
  • Anonymous
    March 21, 2006
    The final player in the drama between IRequestChannel and IReplyChannel is the link connecting requests...
  • Anonymous
    April 18, 2006
    During the last few weeks I've been going over various parts of the channel model and giving some commentary...
  • Anonymous
    June 08, 2006
    I've talked about the request-reply message exchange pattern that HTTP uses, but we've never looked at...