Bindings describe exactly how a service will be communicated with. Binding definitions specify transport method, encoding, security, and other service feature capabilities. A binding provides a large portion of the information required to define the policy a consumer needs to adhere to if it wants to exchange messages with that service. Depending on the actual binding, different features are either enabled or disabled. Different bindings will also mean different levels of interoperability.

 

Exactly what does the binding tell us?

Bindings are capable of answering a number of questions about how a client and a service will communicate. Here are the key questions that are answered.

1. What level of interoperability does this service have?

Answer: The binding will specify if communication can take place only in a .NET to .NET scenario, if it is usable by any consumer, or if it can be used by a consumer that adheres to the WS* specifications.

2. What type of encoding is used?

Answer: The binding will specify what encodings are supported. Options include Text, Message Transmission Optimization Mechanism (MTOM), and Binary.

3. What type of transports can be used?

Answer: The binding will limit the transport options. This can include TCP, HTTP, Named Pipe, and MSMQ.

4. What type of messaging patterns can be used?

Answer: We discussed earlier the use of simplex, duplex, and request-reply. Depending on the binding, only a subset of those techniques may be available.

5. What are the location limitations?

Answer: In the case of some bindings, the call cannot go outside of the machine (ex. Named Pipes).

6. What type of security is supported?

Answer: Options include windows security, WS-Security, and transport level security.

7. Is transaction flow supported? Are reliable sessions supported?

Answer: The binding will specify whether or not these features are supported.

 

Standard Bindings Delivered in the Service Model

When developing WCF services, the flexibility exists to define custom bindings that can answer the questions above based on the features available in the underlying channels. In most cases, the standard bindings delivered with the service model will satisfy your needs. The following is a list of the standard bindings available and their support for varying WCF features and underlying transports.

Binding	Interop	Encoding	Transport	Messaging	Security	Transaction	Reliable
BasicProfile	Basic	Text	HTTP, HTTPS	Request-reply, Simplex	Transport	No	No
WSProfile	WS*	Text, MTOM	HTTP, HTTPS	Request-reply, Simplex	Transport, WS-Security	Yes	Yes
WSProfileDualHTTP	WS*	Text, MTOM	HTTP	Request-reply, Simplex, Duplex	WS-Security	Yes	Yes
NETProfileTcp	.NET	Binary	TCP	Request-reply, Simplex	Transport, WS-Security	Yes	Yes
NetProfileDualTcp	.NET	Binary	TCP	Request-reply, Simplex, Duplex	WS-Security	Yes	Yes
NetProfileNamedPipe	.NET	Binary	Named pipe	Request-reply, Simplex, Duplex	Transport	Yes	No
NetProfileMsmq	.NET	Binary	MSMQ	Simplex	Transport, WS-Security	Yes	No
MsmqIntegration	MSMQ	Text	MSMQ	Simplex	-	Yes	Yes
Intermediary	-	-	HTTP, TCP, named pipe	-	-	-	-

This listing is not a comprehensive definition of each of the standard bindings, but it will illustrate some of the limitations introduced. If you want more information on these bindings, you should look at the WCF documentation.

 

Does This Really Help Me Deliver Services?

The bindings in WCF help to make our communications with a consumer more explicit and truly policy based. This reinforces two of the service-oriented (SO) tenets. What Microsoft has done by enforcing these binding definitions is require consumers to agree to communicate in a specific way. At the same time, the construction of an endpoint allows for the flexibility to use multiple bindings to access a centralized service. You will see later how clients specify the information necessary to use the binding exposed by the service endpoint. At this point, we have become explicit at both ends of our communication.