It Makes the WWW Go Round, Part 2: IReplyChannel

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