Overview

WCF is a framework for building services that allows you to transmit messages using different transport protocols and using different XML representations. It allows you to enhance message interactions with a suite of SOAP protocols. WCF uses a channel stack
that handles all of these communication details.

It would be to build a channel stack from scratch, as you would have to decide the ordering of the components and whether or not they are compatible with one another. For this reason, WCF indirectly configures the underlying channel stack with the help of configurable
endpoints. An endpoint specifies an address, a binding, and a contract. The address specifies the network address where you want to listen for messages, the contract specifies what the messages arriving at the specified address should contain and the binding
provides the channel stack needed to process the message. When loading a service, WCF builds the channel stack by following the instructions outlined by the binding description.

WCF Built-In Bindings

Bindings define how clients can connect and communicate with your service. All the bindings in WCF are represented by the System.ServiceModel.Channels.Binding class which is the base class for all bindings. Each class defines a different channel stack configuration
through its implementation. A binding includes definition for the WS-* protocols used, the message encoding, and the transport protocol.

WCF comes out of the box with a set of bindings configured for the most common scenarios. If none of the bindings are a good fit you can create a custom binding to configure the service explicitly to your needs.

The following table summarizes common bindings:

Binding

Description

basicHttpBinding

It represents a binding that configures and expose endpoints that are able to communicate with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1. By defaults it has security disabled.

wsHttpBinding

Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport
is HTTP, and message encoding is Text/XML encoding. By default it provides message security with windows authentication.

ws2007HttpBinding

Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport
is HTTP, and message encoding is Text/XML encoding. The ws2007HttpBinding provides binding similar to wsHttpBinding but uses the standard for OASIS (Organization for the Advancement of Structured Information Standards). By default it provides message security
with windows authentication.

Defines a binding that is secure, reliable, optimized for on-machine cross process communication. By default, it generates a runtime communication stack with WS-ReliableMessaging for reliability, transport security for transfer security, named pipes for
message delivery, and binary message encoding. It is not secured by default.

netMsmqBinding

Defines a queued binding suitable for cross-machine communication.

wsFederationHttpBinding

Defines a binding that supports federated security. It helps implementing Federation which is the ability to flow and share identities across multiple enterprises or trust domains for authentication and authorization. WCF implements federation over message
and mixed mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport

ws2007FederationHttpBinding

ws2007FederationHttpBinding. Defines a binding that derives from wsFederationHttpBinding and supports federated security. It helps implementing Federation which is the ability to flow and share identities across multiple enterprises or trust domains for
authentication and authorization. WCF implements federation over message and mixed mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport. The ws2007FederationHttpBinding provides binding
similar to ws2007FederationHttpBinding but uses the standard for OASIS (Organization for the Advancement of Structured Information Standards)

wsDualHttpBinding

Defines a secure, reliable and interoperable binding that is suitable for duplex service contracts or communication through SOAP intermediaries.

customBinding

Allows you to create a custom binding with full control over the message stack.

Bindings Behaviors and Endpoints

A WCF service endpoint comprises of an Address, a Binding and a Contract. Bindings define how clients can connect and communicate with your service. A binding includes definition for the WS-* protocols used, the message encoding, and the transport protocol.
For instance the wsHttpBinding uses HTTP, XML 1.0 encoding, message security, reliable sessions, and transactions by default. Bindings are exposed by a service endpoint which includes the binding plus a URI to which the client will send messages. Bindings
can be configured either through code or by using configuration elements in the configuration file.

Below is an example of a wsHttpBinding that has been configured to use transport security:

Behaviors. Behaviors control impersonation levels, how client credentials are authenticated and authorized, and service credentials.

Bindings Summary

Use the following binding summaries to help you choose the right binding for your scenario.

basicHttpBinding

If your service needs to support legacy clients that expect an ASMX web service, consider using the basicHttpBinding. basicHttpBinding does not implement any security by default, if you require message or transport security you should configure it explicitly
on this binding. Use basicHttpBinding to expose endpoints that are able to communicate with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1. When configuring transport security, basicHttpBinding defaults to
no credentials just like a classic ASMX web service. BasicHttpBinding allows you to host your service in II5 or IIS6.

wsHttpBinding

If your service will be called by WCF clients over the Internet, consider using the wsHttpBinding. wsHttpBinding is a good choice for Internet scenarios in which you do not have to support legacy clients which expect an ASMX web service. If you do need to support
legacy clients, consider using basicHttpBinding instead. wsHttpBinding allows you to host your service in II5 or IIS6.

netTcpBinding

If you need to support clients within your intranet, consider using netTcpBinding. netTcpBinding is a good choice for the intranet scenario if transport performance is important to you and it is ok to host the service in a Windows service instead of in IIS.
The netTcpBinding uses the TCP protocol and provides full support for SOAP security, transactions, and reliability. Use this binding when you want to provide a secure and reliable binding environment for .NET-to-.NET cross-machine communication. NetTcpBinding
does not allow you to host your service in IIS5 or IIS6, instead host in a Windows service or in IIS7.

netNamedPipeBinding

If you need to support WCF clients on the same machine as your service, consider using the netNamedPipeBinding. The netNamedPipeBinding provides a secure and reliable binding environment for cross-process, same machine communication. Use this binding when you
want to make use of the NamedPipe protocol and provide full support for SOAP security, transactions, and reliability. NetNamedPipeBinding does not allow you to host your service in IIS5 or IIS6, instead host in a Windows service or in IIS7.

netMsmqBinding

If you need to support disconnected queuing, use the netMsmqBinding. Queuing is provided by using the MSMQ (Microsoft Message Queuing) as a transport, which enables support for disconnected operations, failure isolation, and load leveling. You can use netMsmqBinding
when the client and the service do not have to be online at the same time. You can also manage any number of incoming messages by using Load leveling. MSMQ supports Failure isolation where messages can fail without affecting the processing of other messages.
NetMsmqBinding does not allow you to host your service in IIS5 or IIS6, instead host in a Windows service or in IIS7.

wsDualHttpBinding

If you need to support a duplex service, use wsDualHttpBinding. A duplex service is a service that uses duplex message patterns which provides the ability for a service to communicate back to the client via a callback. You can also use this binding to support
communication via SOAP intermediaries. wsDualHttpBinding does not allow you to host your service in IIS5 or IIS6, instead host in a Windows service or in IIS7.

Custom Binding

A custom binding is created in code using the CustomBinding class found in the System.ServiceModel.Channels namespace. This class exposes a collection of binding elements that you can add binding elements to. This allows you to compose a new binding based on
a set of existing binding elements.

User-Defined Bindings are bindings that are created by inheriting from the Binding class. You can prefer creating user-defined bindings when you want to reuse the binding in a number of applications.

Internet Binding Scenarios

If you are exposing your WCF service interface over the Internet, use the following guidelines to help choose the appropriate binding:

If you are exposing your WCF service over the Internet to clients that expect a legacy ASMX web service then use the basicHttpBinding. Keep in mind that this binding does not have any security enabled by default so all messages will be sent in plain text.

If you are exposing your WCF service over the Internet to Windows Forms clients then use wsHttpBinding. It provides the best WS-* interoperability features including WS-SecureConversation, WS-Addressing, and WS-AtomicTransaction. The combination of features
offered by wsHttpBinding makes for the most reliable connection offered by WCF over the Internet.

If you are exposing your WCF service over the intranet to an ASP.NET application which in turn is exposed to the clients over the internet, then use netTcpBinding

If your clients and the service require full-duplex communication, then use the wsDualHttpBinding. It is the only binding that supports full-duplex.

If your service is interacting with WSE clients, you must use the customBinding. The service must use a custom binding to be compatible with the August 2004 version of the WS-Addressing.

Intranet Binding Scenarios

If you are exposing your WCF service interface over the Internet, use the following guidelines to help choose the appropriate binding:

If you are exposing your WCF service over your Intranet to clients that expect a legacy ASMX web service then use the basicHttpBinding. Keep in mind that this binding does not have any security enabled by default so all messages will be sent in plain text.

If you are exposing your WCF service over your Intranet to Windows Forms or ASP.NET clients then use the netTcpBinding. You can use any binding over an Intranet, but the netTcpBinding will provide the best throughput performance. On an Intranet, you generally
do not need to worry as much about the connection going down as with an Internet connection, so some of the WS-* advantages that are supplied with the wsHttpBinding may not be as necessary on an Intranet.

Binding Elements

WCF provides numerous channels and encoders that are used in the preconfigured bindings. You can use these channels provide binding elements that can be used in custom bindings.

A binding element is a class that derives from System.ServiceModel.Channels.BindingElement.

You can add the binding elements by adding the desired BindingElement objects to its Elements collection. The order in which the binding element is added is very important. The order of adding the binding elements is given below

Transaction Flow (Not Required)

Reliable Messaging (Not Required)

Message Security (Not Required)

Composite Duplex (Not Required)

Message Encoding (Required)

Transport Security (Not Required)

Transport (Required)

The transport binding element is the only required element when defining a custom binding. The Message encoding is required for each binding, but if you don’t specify one, WCF will add a default encoding. The default encoding for HTTP(S) is text and for all
other transports it is binary.

The myWSHttpBindingConfiguration configuration is similar to the built-in wsHttpBinding except it uses the binary message encoding and it enables transaction flow and ordered reliable messaging. The myNetTcpBindingConfiguration configuration is like netTcpBinding
except it uses the text message encoding and enables transaction flow.