A binding is a type that is the primary means by which a developer expresses intent for how a messaging application will interact with other messaging participants. Functionally, bindings create a stack of channel factory or channel listener objects. In Design Pattern terms, a binding is a factory. In terms of the service model layer and the channel layer, a binding is visible in the service model layer, and the objects it creates impact the channel layer. As you saw in Chapter 6, “Channels,” and Chapter 7, “Channel Managers,” the objects a binding directly (channel factories and channel listeners) and indirectly (channels) creates are the physical means by which a Microsoft Windows Communication Foundation (WCF) endpoint implements a set of messaging functionality (for example, transport, WS-* protocol, security, and transactional capability). With this in mind, one way to think of a binding is that it is a developer-facing type that encapsulates the run-time messaging functionality of an endpoint.
By default, WCF supports a wide variety of transports, message encodings, WS-* protocols, security options, and transactional capabilities. At first, the possible combinations of these capabilities might seem a bit overwhelming. For the most part, it is safe to assume that some combinations are going to have more relevance to real-world messaging requirements than others. To this end, the WCF team selected several broadly appealing messaging capabilities and exposed them in a set of bindings that are available in the WCF application programming interface (API). Among these default bindings are the BasicHttpBinding, WsHttpBinding, NetMsmqBinding, NetPeerTcpBinding, and NetTcpBinding. In general, the names of these bindings map fairly well to the functionality that they can create. For example, the BasicHttpBinding creates channel factory stacks and channel listener stacks for sending and receiving basic text-encoded messages over the HTTP transport. The BasicHttpBinding creates a messaging infrastructure that is WS-I Basic 1.1 compliant. The NetMsmqBinding, on the other hand, creates channel factory stacks and channel listener stacks for sending and receiving binary-encoded messages over MSMQ.
Like other parts of the WCF type system, bindings are extensible. This is very useful when an application needs capabilities that are not available in this out-of-the box set of bindings. As you saw in Chapters 6 and 7, the first steps in creating custom functionality in the channel layer (for example, new transport or protocol) are to create a custom channel, a custom channel factory, and a custom channel listener. When these types are in place, a custom Binding rounds out the custom types needed so that you can actually use the channels, channel factory, and channel listener. A custom Binding can consist of parts of existing bindings or be composed of entirely new functionality. In this chapter, we will build a custom binding that inserts a DelegatorChannelListener and DelegatorChannelFactory into their respective stacks, thereby finishing off the DelegatorChannel example started in Chapter 6 and continued in Chapter 7.