I've done a bit of grouping for the remaining binding elements as there are fourteen non-transport binding elements that I'm covering in this list. I've pointed out the ones that respond to a type with GetProperty on the base class as opposed to repeating the same code in each subclass.
Our standard message encoders respond to two types, although only one is on the base class. These two interfaces will override the ones given by the transport if a message encoder is in the binding. The transport delegates to the message encoder before giving its useless default response.
- MessageVersion (on the message encoder base class)
- XmlDictionaryReaderQuotas (on the Text, MTOM, and Binary encoders)
The one-way and transaction channels both support just a single interface.
All of the security binding elements support a pair of interfaces and the actual security channels add an additional type.
- ISecurityCapabilities (on the security base class and on the Windows and SSL stream upgrades)
- IdentityVerifier (on the security base class and on the Windows and SSL stream upgrades)
- ChannelProtectionRequirements (on the asymmetric, symmetric, and transport security binding elements)
The reliable message binding element supports a pair of interfaces as well.
Finally, the composite duplex binding element has a pair of types. If you're curious why composite duplex is interacting with a security interface, then you should read the earlier article on layering between composite duplex and security.
Next time: Starting a Hosted Service