WCF Extensibility – Channels

Artigo
07/11/2011

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

Channels are possibly the most fundamental concept in WCF that (almost) nobody knows about. This is quite a heavy subject, so I’ll break it down in two parts: this post will deal with the concepts for channels and the client part, and the next one will dive deeper into the server part of the channels.

Channels (also known as “protocol channels”) make up the stack over which WCF messages are sent and received. They are called “protocol channels” because they’re usually used to implement some sort of, well, protocol between the communicating parties. Security (WS-Security), reliable messaging (WS-RM), transactions (WS-Transaction), composite duplex (where two HTTP connections are used to implement a duplex pattern over HTTP, which is a request/reply protocol), those are all implemented as channels in WCF. Other examples, such as the Polling Duplex protocol from Silverlight, or the chunking protocol implemented by the Chunking Channel sample are also implemented internally as channels. Channels can do essentially anything with the message: change it, add / remove headers, fiddle with its properties, invoke user code (which I used on the post about extensibility points for Windows Phone / Silverlight 3), even change the message completely. The channel then passes the message to the “inner” channel until it reaches the final destination - for outgoing messages (the request on the client side, the reply on the server), it’s the transport which will send the message over the wire; for incoming messages (request on server, reply on client), it’s the formatter which will unwrap the parameters out of the message to either call the service operation or send the result back to the client code. The diagram below has been drawn in many similar ways and shapes, but it illustrates quite well the path that a request takes from the client to the server (for the response, just invert the direction of the vertical arrows).

But this diagram doesn’t even tell everything that a channel can do: it doesn’t have to receive one message, play with it and pass it along. It can take one message, then send several of them – for example, a very time-sensitive client can send multiple requests to different services, and take the first response thus reducing the odds it will hit a dead server. It can, even before a client sends a request, to do some communication with the server side – the protocol can do some handshaking when the channel is being opened (and also do some teardown handshaking when the channel is being closed). It can even not send the message to the inner channel – and thus bypass the whole stack returning a message directly to the caller. The same can be done for incoming messages as well – a channel can simply inspect / modify the incoming message and pass it along, it can collect many messages and aggregate them into a single message to pass it along (like in the Chunking Channel sample), or it can simply deal with the message directly without passing it along (in the case of handshaking messages, for example). Channels can also be used where the “normal” extensibility points don’t work, for example, to catch errors in the channels themselves, outside of the service model realm.

One aside about encoders: many diagrams for channels in WCF put them in the same category as the other channels. In fact, they should not be considered as such. On outgoing messages, the last protocol channel in the stack doesn’t hand its message to the encoder for processing – it hands it over to the last channel in the stack, the transport channel. It’s the transport which may use an encoder in the binding context to convert the message into bytes to send over the wire (it doesn’t have to, it can do the encoding itself if the implementation so desires). Similarly for incoming messages, the transport may use the encoder to decode the bytes into a Message object, and then it passes it along to the next protocol channel in the stack. I’ll cover encoders in more details in an upcoming post about them.

Channel Shapes

There are many different shapes (or kinds) of channels in the WCF pipeline. Depending on the message exchanging pattern which is being used, a certain kind of channel needs to be used, so the type of custom channel you need to write will be determined by the pattern as well. The list below shows briefly the types of WCF channels:

IOutputChannel: Defines a channel which can only send messages. Useful in one-way communication.
IInputChannel: The receiving counterpart of the IOutputChannel, defines a channel which can only receive messages
IRequestChannel: Defines a channel which can send a message, and return a response to it. Useful in request/reply protocols such as HTTP
IReplyChannel: The receiving counterpart of the IRequestChannel, defines a channel which can receive a request and reply with another message
IDuplexChannel: Defines a channel which can both send and receive messages independently. A duplex channel is equivalent to a pair of IInputChannel and IOutputChannel.

In addition to those basic shapes, there are also their session-full equivalent which extend their contract by also implementing ISessionChannel to support session-full communication: IOutputSessionChannel, IInputSessionChannel, IRequestSessionChannel, IReplySessionChannel and IDuplexSessionChannel.

Notice that the channels in the stack don’t need to be all of the same shape: it’s possible that protocol channels are used to modify the shape of the communication as well. For example, the composite duplex channel (used in the WSDualHttpBinding) converts an output (in the sender) and input (in the receiver) channels into a duplex channel (a duplex session channel, actually), by essentially creating a “server” at the client side. The reliable messaging channel, used in WSHttpBinding, adds a session to the HTTP transport (essentially transforming an IRequestChannel into an IRequestSessionChannel at the client, and an IReplyChannel into an IReplySessionChannel at the server). And so on.

So, channels are very powerful, very flexible, and can do a lot of nice features. Why aren’t they used more widely then? First of all, they’re difficult to implement. Even for simple channels which just pass along a message to the inner channel and don’t do anything like shape changing, there is a lot of code which needs to be written (in the example later in this post you’ll see what I’m talking about). Also, channels deal with Message objects. Unless one is very versed in SOAP-speak, chances are they just want to define a service and let WCF (or whichever stack they’re using) take care of the protocols underneath. And start throwing asynchronous code paths which can be used, the implementation of even the simplest of the channels can become complex quickly. So most people (with very good reason), myself included, avoid going down to the channel level unless it’s absolutely necessary.

Public implementations in WCF

None. All channels in WCF (and in most examples I’ve seen) are implemented either as internal or nested (private) classes of the binding elements which add them. Since the channels can only be created following a certain pattern (the binding element creates the channel factory / listener, then the factory / listener creates the appropriate channel), it doesn’t make sense for those classes to be public (maybe with the exception for unit testing purposes)

Interface declarations

The interfaces for the channel shapes have so many methods that I’ll skip this section in this post – follow the links on the channel shapes section for them.

How to add custom channels (client side)

Channels stacks are created using the factory pattern from the binding. So to create a custom channel, one needs to write a binding element, and create a binding containing this element. The binding element class would override CanBuildChannelFactory<TChannel> (to determine whether the channel shape is supported) and BuildChannelFactory<TChannel> to actually return a channel factory which is capable of building the requested channel type. The channel factory implementation needs to override the CreateChannel methods (or OnCreateChannel, if the class inherits from ChannelFactoryBase<TChannel>), besides a lot of boilerplate methods (Open, BeginOpen, EndOpen, Close, etc.) to finally return the channel which will be used in the pipeline. To illustrate the verboseness of all of this, this is I think the simplest code to write a client channel that I can think of (it just passes the message along, and supports only IRequestChannel).

public class MyBindingElement : BindingElement
{
public override BindingElement Clone()
{
return new MyBindingElement();
}
public override T GetProperty<T>(BindingContext context)
{
return context.GetInnerProperty<T>();
}
public override bool CanBuildChannelFactory<TChannel>(BindingContext context)
{
return typeof(TChannel) == typeof(IRequestChannel) &&
context.CanBuildInnerChannelFactory<TChannel>();
}
public override IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context)
{
if (typeof(TChannel) != typeof(IRequestChannel))
{
throw new InvalidOperationException("Only IRequestChannel is supported");
}
var factory = new MyFactory(context.BuildInnerChannelFactory<IRequestChannel>());
return (IChannelFactory<TChannel>)factory;
}
class MyFactory : ChannelFactoryBase<IRequestChannel>
{
IChannelFactory<IRequestChannel> innerFactory;
public MyFactory(IChannelFactory<IRequestChannel> innerFactory)
{
this.innerFactory = innerFactory;
}
protected override IRequestChannel OnCreateChannel(EndpointAddress address, Uri via)
{
return new MyChannel(this, this.innerFactory.CreateChannel(address, via));
}
protected override IAsyncResult OnBeginOpen(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerFactory.BeginOpen(timeout, callback, state);
}
protected override void OnEndOpen(IAsyncResult result)
{
this.innerFactory.EndOpen(result);
}
protected override void OnOpen(TimeSpan timeout)
{
this.innerFactory.Open(timeout);
}
protected override void OnAbort()
{
this.innerFactory.Abort();
}
public override T GetProperty<T>()
{
return this.innerFactory.GetProperty<T>();
}
protected override IAsyncResult OnBeginClose(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerFactory.BeginClose(timeout, callback, state);
}
protected override void OnClose(TimeSpan timeout)
{
this.innerFactory.Close(timeout);
}
protected override void OnEndClose(IAsyncResult result)
{
this.innerFactory.EndClose(result);
}
}
class MyChannel : ChannelBase, IRequestChannel
{
IRequestChannel innerChannel;
public MyChannel(ChannelManagerBase channelManager, IRequestChannel innerChannel)
: base(channelManager)
{
this.innerChannel = innerChannel;
}
protected override void OnAbort()
{
this.innerChannel.Abort();
}
protected override IAsyncResult OnBeginClose(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerChannel.BeginClose(timeout, callback, state);
}
protected override IAsyncResult OnBeginOpen(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerChannel.BeginOpen(timeout, callback, state);
}
protected override void OnClose(TimeSpan timeout)
{
this.innerChannel.Close(timeout);
}
protected override void OnEndClose(IAsyncResult result)
{
this.innerChannel.EndClose(result);
}
protected override void OnEndOpen(IAsyncResult result)
{
this.innerChannel.EndOpen(result);
}
protected override void OnOpen(TimeSpan timeout)
{
this.innerChannel.Open(timeout);
}
public IAsyncResult BeginRequest(Message message, TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerChannel.BeginRequest(message, timeout, callback, state);
}
public IAsyncResult BeginRequest(Message message, AsyncCallback callback, object state)
{
return this.innerChannel.BeginRequest(message, callback, state);
}
public Message EndRequest(IAsyncResult result)
{
return this.innerChannel.EndRequest(result);
}
public EndpointAddress RemoteAddress
{
get { return this.innerChannel.RemoteAddress; }
}
public Message Request(Message message, TimeSpan timeout)
{
return this.innerChannel.Request(message, timeout);
}
public Message Request(Message message)
{
return this.innerChannel.Request(message);
}
public Uri Via
{
get { return this.innerChannel.Via; }
}
}
}

As I mentioned before, that’s a lot of code for a channel which does absolutely nothing…

Real world scenario: a Chaos Monkey channel

One very interesting blog post I’ve seen lately was the Netflix team describing their experience using Amazon Web Services for their product, and Jeff Atwood’s post about it in the aftermath of the big outage suffered by AWS. One of the techniques used by Netflix to ensure a good response is what they called the “Chaos Monkey”, whose job is to randomly kill instances and services in their architecture, to ensure that the other parts which depended on them were resilient to errors and normal downtime of the network systems. With that chaos resiliency, Netflix didn’t suffer nearly as much as other companies when AWS stopped working for extended periods of time.

If we are building an application which talks to services, and we want to emulate that technique, we can also periodically disconnect / shut down the services and add guards in our application to deal with those situations. But in many cases we don’t really own the services we’re talking to, so we can’t do exactly that. Enter the “chaos monkey channel”, one implementation of a WCF channel which occasionally throws wrenches in the code by returning a custom messages (normally a fault for SOAP-based services). In this implementation I’m using a “chaos controller” which lets the user define via an interface how much “chaos” they want to introduce into the system.

And before I go further, the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios - it does not work for TCP (duplex) or one way (IInput / IOutput) channels. Please let me know if you find a bug or something missing. A more complete implementation would also include support for more channel types, and possibly provide some helper methods for the user to create known faults (i.e., from the fault contract of the operation) instead of leaving it completely up to the user.

To start off, the interface which allows the user to add “chaos” to the system. I tried to keep it simple, but it could be made more user-friendly so that the user wouldn’t need to deal with Message objects directly, but I opted for simplicity on the channel itself.

public interface IChaosController
{
bool ShouldFault(ref Message request, out Message fault);
}

Next I had to decide which channel shape to use. Since HTTP is the most common protocol used in communication, I started with an IRequestChannel implementation, which worked fine for a custom binding based on the BasicHttpBinding. Here’s the binding element which can be added.

public class ChaosMonkeyBindingElement : BindingElement
{
IChaosController controller;
public ChaosMonkeyBindingElement(IChaosController controller)
{
if (controller == null)
{
throw new ArgumentNullException("controller");
}
this.controller = controller;
}
public override bool CanBuildChannelFactory<TChannel>(BindingContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (typeof(TChannel) == typeof(IRequestChannel))
{
bool innerCanBuild = context.CanBuildInnerChannelFactory<TChannel>();
return innerCanBuild;
}
return false;
}
public override IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (typeof(TChannel) != typeof(IRequestChannel))
{
throw new InvalidOperationException("Only IRequestChannel is supported");
}
var factory = new ChaosMonkeyRequestChannelFactory(context.BuildInnerChannelFactory<IRequestChannel>(), this.controller);
return (IChannelFactory<TChannel>)factory;
}
public override BindingElement Clone()
{
return new ChaosMonkeyBindingElement(this.controller);
}
public override T GetProperty<T>(BindingContext context)
{
return context.GetInnerProperty<T>();
}
}

On to the channel factory. Implementing it for this scenario was fairly simple, just with a bunch of boilerplate methods which delegated the call to the factory of the next element in the binding element stack.

class ChaosMonkeyRequestChannelFactory : ChannelFactoryBase<IRequestChannel>
{
IChannelFactory<IRequestChannel> innerFactory;
IChaosController controller;
public ChaosMonkeyRequestChannelFactory(IChannelFactory<IRequestChannel> innerFactory, IChaosController controller)
{
this.innerFactory = innerFactory;
this.controller = controller;
}
protected override IRequestChannel OnCreateChannel(EndpointAddress address, Uri via)
{
return new ChaosMonkeyRequestChannel(this, this.innerFactory.CreateChannel(address, via), this.controller);
}
#region Boilerplate methods which simply delegate to the inner factory
public override T GetProperty<T>()
{
return this.innerFactory.GetProperty<T>();
}
protected override IAsyncResult OnBeginOpen(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerFactory.BeginOpen(timeout, callback, state);
}
protected override void OnEndOpen(IAsyncResult result)
{
this.innerFactory.EndOpen(result);
}
protected override void OnOpen(TimeSpan timeout)
{
this.innerFactory.Open();
}
protected override void OnAbort()
{
this.innerFactory.Abort();
}
protected override IAsyncResult OnBeginClose(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerFactory.BeginClose(timeout, callback, state);
}
protected override void OnClose(TimeSpan timeout)
{
this.innerFactory.Close(timeout);
}
protected override void OnEndClose(IAsyncResult result)
{
this.innerFactory.EndClose(result);
}
#endregion
}

Finally the channel itself. To keep the channel simple, I removed the code which dealt with messages and moved it into a separate (private) helper class, so the implementation of the request channel itself would be kept simple.

class ChaosMonkeyRequestChannel : ChannelBase, IRequestChannel
{
IRequestChannel innerChannel;
IChaosController controller;
RequestChannelHelper helper;
public ChaosMonkeyRequestChannel(ChannelManagerBase channelManager, IRequestChannel innerChannel, IChaosController controller)
: base(channelManager)
{
this.innerChannel = innerChannel;
this.controller = controller;
this.helper = new RequestChannelHelper(innerChannel, controller);
}
public IAsyncResult BeginRequest(Message message, TimeSpan timeout, AsyncCallback callback, object state)
{
return this.helper.BeginRequest(message, timeout, callback, state);
}
public IAsyncResult BeginRequest(Message message, AsyncCallback callback, object state)
{
return this.BeginRequest(message, this.DefaultSendTimeout, callback, state);
}
public Message EndRequest(IAsyncResult result)
{
return this.helper.EndRequest(result);
}
public Message Request(Message message, TimeSpan timeout)
{
return this.helper.Request(message, timeout);
}
public Message Request(Message message)
{
return this.Request(message, this.DefaultSendTimeout);
}
#region Boilerplate methods which simply delegate to the inner channel
protected override void OnAbort()
{
this.innerChannel.Abort();
}
protected override IAsyncResult OnBeginClose(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerChannel.BeginClose(timeout, callback, state);
}
protected override IAsyncResult OnBeginOpen(TimeSpan timeout, AsyncCallback callback, object state)
{
return this.innerChannel.BeginOpen(timeout, callback, state);
}
protected override void OnClose(TimeSpan timeout)
{
this.innerChannel.Close(timeout);
}
protected override void OnEndClose(IAsyncResult result)
{
this.innerChannel.EndClose(result);
}
protected override void OnEndOpen(IAsyncResult result)
{
this.innerChannel.EndOpen(result);
}
protected override void OnOpen(TimeSpan timeout)
{
this.innerChannel.Open(timeout);
}
public override T GetProperty<T>()
{
return this.innerChannel.GetProperty<T>();
}
public EndpointAddress RemoteAddress
{
get { return this.innerChannel.RemoteAddress; }
}
public Uri Via
{
get { return this.innerChannel.Via; }
}
#endregion
}

The synchronous path of the helper class is fairly straightforward: if the controller says that we should return a fault, we just return the message returned by the chaos controller, and the rest of the stack is bypassed (the request won’t be sent to the server). On the asynchronous case, we need to return an IAsyncResult to the caller, and depending on whether the chaos should happen or not, this asynchronous result will come from different sources. Here I used the same pattern as I described in the post about operation invokers, in which the response is wrapped in a custom IAsyncResult implementation (I’ll omit the class CorrelatingAsyncResult in this post, it can be seen in the code for this post link at the bottom).

class RequestChannelHelper
{
IRequestChannel innerChannel;
IChaosController controller;
public RequestChannelHelper(IRequestChannel innerChannel, IChaosController controller)
{
this.innerChannel = innerChannel;
this.controller = controller;
}
public IAsyncResult BeginRequest(Message message, TimeSpan timeout, AsyncCallback callback, object state)
{
Message result;
if (this.controller.ShouldFault(ref message, out result))
{
Func<Message> getMessage = () => result;
CorrelationState correlationState = new CorrelationState
{
OriginalCallback = callback,
OriginalAsyncState = state,
FaultMessage = result,
};
IAsyncResult funcResult = getMessage.BeginInvoke(this.MonkeyRequestCallback, correlationState);
return new CorrelatingAsyncResult(funcResult, state, correlationState);
}
else
{
return this.innerChannel.BeginRequest(message, timeout, callback, state);
}
}
public Message EndRequest(IAsyncResult result)
{
CorrelatingAsyncResult correlatingResult = result as CorrelatingAsyncResult;
if (correlatingResult != null)
{
return ((CorrelationState)correlatingResult.CorrelationData).FaultMessage;
}
else
{
return this.innerChannel.EndRequest(result);
}
}
public Message Request(Message message, TimeSpan timeout)
{
Message result;
if (this.controller.ShouldFault(ref message, out result))
{
return result;
}
else
{
return this.innerChannel.Request(message, timeout);
}
}
private void MonkeyRequestCallback(IAsyncResult asyncResult)
{
CorrelationState state = (CorrelationState)asyncResult.AsyncState;
(((System.Runtime.Remoting.Messaging.AsyncResult)asyncResult).AsyncDelegate as Func<Message>).EndInvoke(asyncResult);
IAsyncResult newAsyncResult = new CorrelatingAsyncResult(asyncResult, state.OriginalAsyncState, state);
state.OriginalCallback(newAsyncResult);
}
class CorrelationState
{
public AsyncCallback OriginalCallback { get; set; }
public object OriginalAsyncState { get; set; }
public Message FaultMessage { get; set; }
}
}

And that’s it – we can now test it. For that I’ll use a very simple server (a simple Add operation) and controller (which randomly creates problems for 20% of the messages).

[ServiceContract]
public interface ITest
{
[OperationContract]
int Add(int x, int y);
}
public class Service : ITest
{
public int Add(int x, int y)
{
Console.WriteLine("[service] {0} + {1}", x, y);
return x + y;
}
}
class MyMonkeyController : IChaosController
{
Random rndGen = new Random();
public bool ShouldFault(ref Message request, out Message fault)
{
if (this.rndGen.Next(0, 5) == 0)
{
var exception = new FaultException("Chaos!!!", new FaultCode("chaos!"));
var messageFault = exception.CreateMessageFault();
fault = Message.CreateMessage(request.Version, messageFault, "Chaos");
return true;
}
else
{
fault = null;
return false;
}
}
}

And running the code below, we see that many of the requests to the service throw an exception, just as we wanted. We have chaos!

static void Main(string[] args)
{
string baseAddress = "https://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));
BasicHttpBinding basicBinding = new BasicHttpBinding();
host.AddServiceEndpoint(typeof(ITest), basicBinding, "");
host.Open();
Console.WriteLine("Host opened");
CustomBinding binding = new CustomBinding(basicBinding);
MyMonkeyController chaosController = new MyMonkeyController();
binding.Elements.Insert(0, new ChaosMonkeyBindingElement(chaosController));
ChannelFactory<ITest> factory = new ChannelFactory<ITest>(binding, new EndpointAddress(baseAddress));
ITest proxy = factory.CreateChannel();
for (int i = 0; i < 30; i++)
{
try
{
Console.WriteLine("10 + {0} = {1}", i, proxy.Add(10, i));
}
catch (FaultException ex)
{
Console.WriteLine("{0}: {1}", ex.GetType().Name, ex.Message);
}
}
}

Since it worked for a simple HTTP binding, I tried changing it to WSHttpBinding instead of a BasicHttpBinding. And now nothing worked – the channel in the client could not be created! The problem was that while the HTTP transport can only build IRequestChannel instances, WSHttpBinding adds a ReliableMessagingBindingElement to the stack, and it changes the shape to an IRequestSessionChannel. And we have to go back to the binding element to add support for it again… which means writing a new factory (IChannelFactory<IRequestSessionChannel>) and a new ISessionChannel implementation. And here goes a lot more code… This is the new implementations of [Can]BuildChannelFactory<TChannel> on the binding element.

public override bool CanBuildChannelFactory<TChannel>(BindingContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (typeof(TChannel) == typeof(IRequestChannel) || typeof(TChannel) == typeof(IRequestSessionChannel))
{
bool innerCanBuild = context.CanBuildInnerChannelFactory<TChannel>();
return innerCanBuild;
}
return false;
}
public override IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (typeof(TChannel) != typeof(IRequestChannel) && typeof(TChannel) != typeof(IRequestSessionChannel))
{
throw new InvalidOperationException("Only IRequestChannel / IRequestSessionChannel are supported");
}
if (typeof(TChannel) == typeof(IRequestChannel))
{
var factory = new ChaosMonkeyRequestChannelFactory(context.BuildInnerChannelFactory<IRequestChannel>(), this.controller);
return (IChannelFactory<TChannel>)factory;
}
else
{
var factory = new ChaosMonkeyRequestSessionChannelFactory(context.BuildInnerChannelFactory<IRequestSessionChannel>(), this.controller);
return (IChannelFactory<TChannel>)factory;
}
}

The implementation of the factory and the channel are really similar to the IRequestChannel. But since we’re passing an inner factory / channel of a certain type, we can’t really reuse much of the code and we end up with a lot of copy/paste code.

Finally, channels are powerful. And I’ve mentioned it before and will do it again – only use it when no other extensibility points can be used for your needs. But if you really need them, hopefully this post will help you a little in understanding them.

Coming up

More channels – this time at the server side (listeners).

[Code for this post]

[Back to the index]

Comments

Anonymous
July 29, 2011
Hi,Your articles look very nice!! I have a question on the diagram mentioned above. Where does the OperationSelector fit in the diagram?ThanksRajasekhar
Anonymous
July 29, 2011
The comment has been removed
Anonymous
July 29, 2011
Thank you very much for the information.It is very usefulRajasekhar
Anonymous
December 19, 2011
Hi Carlos,Great post. i have a question about the channel stack which will be build for a WsHttpBinding. Like you mentioned in your post the WsHttpBinding contains a reliable messaging channel which will convert a IRequestChannel into an IRequestSessionChannel (client) and an IReplyChannel into an IReplySessionChannel (server). Does this convertion only happen for the reliable messaging channel or will it affect the whole channel stack?Thanks
Anonymous
December 19, 2011
Hi Dennis. This conversion hapens at RM channel, so anything below it is still an IRequestChannel, but anything above it is now sessionful. If you add a channel "under" the RM channel (which in practice means having its corresponding binding element in a position greater than the RM one), then the shape is still IRequestChannel. For channels "above" it, then they see an IRequestSessionChannel.
Anonymous
December 20, 2011
Hi Carlos,This makes sense to me. Thanks!
Anonymous
April 09, 2015
very informative

Compartilhar via