In order to understand WCF Bindings in details, it's important to understand the Channel Stack as part of the WCF runtime.
WCF binding is composed of binding elements and each binding element is corresponds to a specific channel in the Channel Stack. The Channel Stack can be categorized into two major areas i.e. Protocol Channels and Transport Channels.
Protocol Channels are Transaction Protocol, Reliable Messaging Protocol and Security Protocol while Transport Channels includes Message Encoding and Transport Protocol.
Transaction flow is the optional element that enables specifying a protocol flow for incoming transactions and interrupt the transaction flow at certain points.
Reliability is also the optional element that specifies sending and receiving channels for reliable sessions.
Security is another element that specifies features such as authorization, authentication, protection, and confidentiality.
Encoding is the required message encoding element that specifies text, binary, or MTOM message encoding methods.
Transport is also a required transport element that specifies one of the available protocols i.e. TCP, NamedPipes, HTTP, HTTPS, MSMQ, or Peer-to-Peer or we can define our own custom one.
![WCFChnl1.jpg]()
Each request coming from the client will go through a Channel Stack from top to bottom and then an encoded byte stream message will travel over the wire. On the other end, messages travel from the bottom to the top and reaches the service as shown in the above diagram.
A complete picture of the WCF runtime with Service Instance, Dispatcher and Channel Stack is as follows:
![WCFChnl2.jpg]()
WCF is extensible, so we can define our own bindings but there are various built-in bindings available in WCF, each designed to fulfill some specific need:
- basicHttpBinding
- wsHttpBinding
- netNamedPipeBinding
- netTcpBinding
- netPeerTcpBinding
For example, if interoperability is critical and we must communicate with non-WCF systems, we can go for basicHttpBinding or wsHttpBinding.
If we know the service can reside on a single computer, the netNamedPipeBinding will be the most efficient.
If we need to communicate across computers, netTcpBinding or netPeerTcpBinding might work well.
And if the service requires support for disconnected or queued calls, we must use a binding that supports Microsoft Message Queue (MSMQ).
Finally an important thing to note is, if at all possible, try to customize an existing standard binding rather than creating a custom binding because creating a new one will add complexity to your solution.