Channel Writing Checklist (Required)

This pair of articles marks the checkpoint between the "big picture" introductory segments and the segments where we actually start getting down into the code. The transition is going to be gradual so there's still some philosophy left, particular around the construction of bindings and binding elements. However, the objective of the articles is going to be less about how to think about the system and more about how to think about the code.

Here, we get into a checklist of the bare minimum necessary to write a channel. The first few items come from past topics, and you can use the rest as a roadmap of where we're going to go next.

1. Understand why you're writing a channel. Forever more in this series, I'm assuming that you've looked at the other extensibility points and decided that writing a channel is the best way to solve your problem.
2. Identify whether the channel you need is a protocol channel or a transport channel.
3. Identify the channel shapes, one or more, that your channel needs to be able to surface.
4. Write a binding element so that your channel can plug into the build process. The binding element is going to take one of the supported channel shapes and return the factory object that produces channels. Writing a binding is not required as you can always use your binding element in a custom binding. The binding element is also going to hold all of the configurable settings for your channel.
5. Write a client channel factory that can produce instances of your channel for use by client applications. If you have an integration scenario where you're only writing channels for use in a web service, then you can skip this step. For example, if the client is going to be a web browser that doesn't use WCF, then you might not ever have a need to create client channels.
6. Write a service channel listener that can produce instances of your channel for use by service applications. If you have an integration scenario where you're only writing channels for use in a client, then you can skip this step. For example, if you are trying to communicate with an existing mainframe service, then you're only going to produce channels to bridge the connection between WCF and the other system.
7. Write channel instances to cover each of the supported channel shapes. I think it's easier to have separate classes for each channel shape that all use a central communication library. However, you may find it easier to implement multiple channel shapes in a single class.

I've put the channel writing steps in a particular order, although some people prefer to go in the opposite direction. It doesn't really matter in structuring the code whether you write the classes from binding element to channel or from channel to binding element. I find that everything but the actual communication is so simple, that it's better to have all the pieces in place so that you can test sending and receiving in a real application.

Tomorrow, we'll look beyond the bare minimum to get a sense of the bells and whistles you can add.

Next time: Channel Writing Checklist (Optional)

Comments

• Anonymous
  March 12, 2007
  What is the content type of the message returned by a service? The idea of a content MIME type is very