Channel Bindings

We're back to the channel development tour for another pair of articles. Today's article is the first of four in this segment on channel construction. The first half of the segment is background and the second half of the segment talks about code. In each half, there is an article on bindings and an article on channel managers. After we're done with this segment, everything else in the series deals directly with implementing the channel interfaces.

Channels go through a somewhat complicated construction process. This construction process essentially has three stages: design, evaluate, and build. Bindings are the typical user-accessible part of the construction process and correspond to the design stage. We have to take a few steps back before it becomes clear how bindings fit into the model.

1. You have a service.
2. Your service has endpoints that enforce a particular contract for exchanging data.
3. One part of your endpoint's contract is the protocol for how the client and server can send each other a message.
4. The implementation of a protocol contract is called a binding. There are many ways to build this implementation, including through configuration files or writing code.
5. Bindings expose design settings that allow the user to configure various aspects of the network protocols. The binding is a rough equivalent to the channel stack, a composition of all of the chosen protocols.
6. Given a specific set of design settings, the binding can produce a set of binding elements that correspond to those settings. Each binding element is a rough equivalent to one channel in the channel stack. We'll see some examples latter where that isn't true, but it's generally the case.

We'll stop here in the process for now because at the next step we'll be producing the channel managers that are the subject of tomorrow's article. The binding and binding element expose methods that allow us to perform the evaluate and build stages. The evaluate stage allows the user to query whether the chosen design settings of the binding make sense for building a channel manager. This is a cheap way of verifying the build process without having to actually initiate a build. The build stage locks the design settings of the binding in place and produces the corresponding channel manager. From the channel manager, the build process is going to continue a little bit farther until we have actual channels.

Next time: Channel Managers

Comments

• Anonymous
  March 19, 2007
  When I run my non-HTTP service in IIS, I get an error message that the protocol is not supported. How

• Anonymous
  March 19, 2007
  So does this mean that by implementing my own channel (binding) I could use WCF infrastructure to develop - lets say - Ftp server?

• Anonymous
  March 19, 2007
  Yes, it is possible to write a transport channel that understands ftp and an application layer that acts as an ftp server.  It would be quite a bit of work though as the FTP protocol is complex and has many commands.