Channel Writing Checklist (Optional)

Let's fill in some of the spaces around yesterday's checklist with a list of additional features for a custom channel. Nothing that's been added to this list is required to actually send or receive messages. By doing the things listed here, you can enable some additional scenarios and make your channel easier to use. However, if you're looking to write a channel as cheaply as possible, then these are the features that you might consider cutting. I'll summarize the previous list using italics and interlace the descriptions of the new checklist items.

1.
Understand why you're writing a channel. 2. Identify whether the channel you need is a protocol channel or a transport channel. 3. Identify the channel shapes that your channel needs to be able to surface. 4. Write a binding element so that your channel can plug into the build process. 5. Add configuration support to your binding element. Configuration allows the settings of your binding element to be specified through XML files rather than through imperative code. You implement this configuration support by writing a binding element extension that duplicates the property settings of your binding element in a format that can be picked up by the configuration system. You will quickly grow tired of performing this duplication by hand and start thinking about how this process can be done automatically instead. 6. Write a standard binding that demonstrates the proper usage of your binding element. A standard binding represents the stacks of binding elements for your core scenarios along with the most commonly used configuration settings for those binding elements. Creating a standard binding allows people to frequently make use of your channel without having to write a custom binding of their own. 7. Support generating and consuming policy assertions that describe the capabilities of your binding element. Policy assertions allow you to advertise particular features of your channel so that the two sides can coordinate ahead of time about how the channel stack should be constructed. Policy support is implemented through a pair of interfaces for policy import extensions and policy export extensions. 8. Write a client channel factory that can produce instances of your channel for use by client applications. 9. Write a service channel listener that can produce instances of your channel for use by service applications. 10. Write channel instances to cover each of the supported channel shapes. 11. For transport channels, add a description of your supported addressing modes through WSDL extensions. Although addressing is most frequently handled by the message encoder, the transport is the one that is responsible for performing the advertisement. WSDL has a similar pair of interfaces to policy for creating import and export extensions. 12. For transport channels, write a protocol listener and listener adapter to make services using your channel activatable through WAS. The protocol listener for your channel sits on the machine waiting to accept messages on the behalf of activatable applications. The listener adapter for your channel plugs in to WAS and triggers the creation of processes in response to a message arriving for a service that isn't currently running.

Next time: Getting the Client Identity