Protocol Channels

There are only two kinds of channels in the world. Today we'll talk about protocol channels. Tomorrow we'll talk about transport channels.

1.
Transport channels move data to and from the network 2. Protocol channels move data between the application and transport channel

The name "protocol channel" for the second group is a lie. Of the channels we shipped in the product, the most common representative for the second group happens to be protocols. That doesn't mean that every channel in the second group has to an implement a protocol though. The key distinction for the second group is really "moves data between the application and transport channel". In other words, the second group is made up of everything that is not a transport channel. However, if you're following the advice from yesterday about when to write a channel, then I think you'll find that most of the channels that you write are either transport channel or implement some kind of protocol.

A channel has two ends to it. The outer end points to the application. The inner end points to the network. If you start stitching together channels end-to-end, you come out with something called the channel stack. The inner end of one channel links to the outer end of another channel. In relative terms, these are the inner and outer channels of the channel that we're looking at.

Obviously, we run into a problem if we keep following down the path of inner (or outer) channels. If we follow down the path of inner channels, eventually we'll hit a channel that has no other channel on the inner end to pass data to. That innermost channel is the transport channel that we'll talk about tomorrow. If we follow up the path of outer channels, eventually we'll hit a channel that has no other channel on the outer end to pass data to. Beyond the outermost channel is the application. In between the outermost channel and user code is a large mass called the service model. We'll have a brief look at the architecture of the service model in a few days. Otherwise, there's nothing particular distinctive about the outermost channel. Every channel along the way, except the innermost channel, is a protocol channel.

The job of a protocol channel is to pump data between its inner and outer sides. That data is a structure called the XML InfoSet. An infoset is a standardized concept but really you don't have to understand the standard to make use of it. The pump that acts on these infosets is any arbitrary code you care to write. As a channel author, you have total control over what happens to the infosets you receive and how you come up with the infosets you send. There is a very rigid contract for how channels plug together but no contract for what a channel does with messages.

Next time: Transport Channels

Comments

• Anonymous
  February 21, 2007
  Today's article is about the tension between two simple points. Writing channels can generally be used

• Anonymous
  February 26, 2007
  What about encoder channels?  Steve Swartz has repeatedly referred to 3 channel types: transport, encoder, and protocol.

• Anonymous
  February 26, 2007
  Whoops, I just got to your Transport Channels post mentioning encoders.  It's interesting you describe encoders as transport channel plugins rather than as channels in their own right.

• Anonymous
  February 26, 2007
  Hi Oran, Message encoders are not channels.  A channel is something that implements one of the basic channel shapes that we'll look at in a few days.  MessageEncoder doesn't even implement IChannel.  The idea of a message encoder is really just a nicely reusable bit of implementation for our transport channels.

• Anonymous
  March 13, 2007
  This pair of articles marks the checkpoint between the "big picture" introductory segments and the segments