Writing a WCF Transport Channel, Part 2

The first thing I asked myself when I started writing my custom Windows Communication Framework transport channel was: What exactly do I need to implement? The information on what classes you need to write and what interfaces you need to implement is out there in the documentation and elsewhere (as I pointed out in my previous entry).

However, it still took a bit of time for it to "click" for me. To make it easier to remember, here's a small figure I created outlining what I think are the key concepts in the transport channel model:

I think the figure is pretty self explanatory, but let's add a few comments anyway:

• The "Configuration Binding Element" is purely a configuration-level entity. That is, it's purpose is to be used in the XML configuration files (or programatically) to configure the transport-part of the binding you'll be using. As such, it's main purpose is to gather some required configuration options and create the transport binding element.
  Confused by the naming of all the element classes? You're not the only one. I think the whole binding element + configuration element part of WCF was horribly named making it unnecessarily confusing.
• The transport binding element will usually derive from the TransportBindingElement class (or one of its subclasses). One of its primary purposes is to create the Channel Managers for your transport, which are the Channel Factory (IChannelFactory implementation) and the Channel Listener (IChannelListener implementation).
  Your Channel Factory will typically inherit from ChannelFactoryBase and your Channel Listener from ChannelListenerBase.
•  The actual channels are created from the two channel manager classes. What I mean by "Primarily Send" and "Primarily Receive" is this:
• Primarily Send channels start by "establishing a connection" to the remote endpoint. In that send, they are proactively opened by the client. These are somewhat analogous to Send-side Adapters in BizTalk Server. This does not mean however, that they only send data, as they can be two way (request/response) channels or even full duplex channels.
• Primarily Receive channels usually start because a connection was accepted from a remote endoint. These are somewhat analogous to Receive-side adapters in BizTalk Server. Again, they can be two way (reply/response) channels or even full duplex channels.