Chapter 8: Bindings

Article
04/27/2010

WCF Built-in Bindings
Binding Behaviors and Endpoints
Bindings Summary
Internet Binding Scenarios
Intranet Binding Scenarios
Binding Elements

Objectives

Understand what bindings and behaviors are and how they are used in WCF.
Understand when to use each binding supplied by WCF.
Understand which bindings are best for the Internet.
Understand which bindings are best for an intranet.

Overview

Microsoft® Windows Communication Foundation (WCF) is a framework for building services that allows you to transmit messages using different transport protocols and different XML representations. It allows you to enhance message interactions with a suite of Simple Object Access Protocol (SOAP) protocols. WCF uses a channel stack that handles all of these communication details.

It would be challenging 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 meet your needs.

The following table summarizes common bindings.

Binding	Description
basicHttpBinding	Represents a binding that configures and exposes 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 specification. By default, basicHttpBinding 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 using 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 using Windows authentication.
netTcpBinding	Specifies a secure, reliable, optimized binding suitable for cross-machine communication. By default, it generates a run-time communication stack with transport security and Windows authentication as default security settings. It uses the Transmission Control Protocol (TCP) for message delivery, and binary message encoding.
netNamedPipeBinding	Defines a binding that is secure, reliable, and optimized for cross-process communication on the same machine. By default, it generates a run-time 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 in 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	Defines a binding that derives from wsFederationHttpBinding and supports federated security. It helps in implementing federation. 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 OASIS standard.
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.

For more information on bindings, see Windows Communication Foundation Bindings.

Binding Behaviors and Endpoints

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

The following example shows wsHttpBinding configured to use transport security:

<bindings>
  <wsHttpBinding>
    <binding name="wsHttpEndpointBinding">
      <security mode="Transport">
      </security>
    </binding>
  </wsHttpBinding>
</bindings>

The following configuration snippet shows an endpoint that exposes this binding:

<endpoint address="" binding="wsHttpBinding" bindingConfiguration="wsHttpEndpointBinding" name="wsHttpEndpoint" contract="IService">

When creating an overall security policy for your services, you will use bindings and behaviors to configure your service as follows:

Bindings. Bindings control the security mode, client credential type, and other security settings.
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 basicHttpBinding. Because 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 specification. When configuring transport security, basicHttpBinding defaults to no credentials just like a classic ASMX Web service. basicHttpBinding allows you to host your service in Internet Information Services (IIS) 5.0 or IIS 6.0.

wsHttpBinding

If your service will be called by WCF clients over the Internet, consider using wsHttpBinding. wsHttpBinding is a good choice for Internet scenarios in which you do not have to support legacy clients that 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 IIS 5.0 or IIS 6.0.

netTcpBinding

If you need to support clients within your intranet, consider using netTcpBinding. netTcpBinding is a good choice for an intranet scenario if transport performance is important to you and it is acceptable to host the service in a Windows service instead of in IIS. 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 IIS 5.0 or IIS 6.0; instead, host in a Windows service or in IIS 7.0.

netNamedPipeBinding

If you need to support WCF clients on the same machine as your service, consider using netNamedPipeBinding. 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 Named-Pipe protocol and provide full support for SOAP security, transactions, and reliability. netNamedPipeBinding does not allow you to host your service in IIS 5.0 or IIS 6.0; instead, host in a Windows service or in IIS 7.0.

netMsmqBinding

If you need to support disconnected queuing, use netMsmqBinding. Queuing is provided by using Microsoft Message Queuing (MSMQ) 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 IIS 5.0 or IIS 6.0; instead, host in a Windows service or in IIS 7.0.

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 IIS 5.0 or IIS 6.0; instead, host in a Windows service or in IIS 7.0.

CustomBinding

A custom binding is created in code by using the CustomBinding class found in the System.ServiceModel.Channels namespace. This class exposes a collection of binding elements to which you can add further binding elements. 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. Creating user-defined bindings is preferred 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, use basicHttpBinding. Keep in mind that this binding does not have any security enabled by default, so all messages will be sent in plaintext format.
If you are exposing your WCF service over the Internet to Windows Forms clients, use wsHttpBinding. wsHttpBinding 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 an intranet to an ASP.NET application, which in turn is exposed to the clients over the Internet, use netTcpBinding.
If your clients and the service require full-duplex communication, then use wsDualHttpBinding. It is the only binding that supports full-duplex.
If your service is interacting with Web Services Enhancements (WSE) clients, you must use customBinding. The service must use a custom binding to be compatible with the August 2004 version of the WS-Addressing specification.

Intranet Binding Scenarios

If you are exposing your WCF service interface over an intranet, 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, use basicHttpBinding. Keep in mind that this binding does not have any security enabled by default, so all messages will be sent in plaintext format.
If you are exposing your WCF service over your intranet to Windows Forms or ASP.NET clients, use netTcpBinding. You can use any binding over an intranet, but netTcpBinding provides 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 supplied with 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 to provide binding elements that can be used in custom bindings.

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

WCF provides some different lists of binding elements that include the Protocol Binding Elements, Message Encoding Binding Elements, Transport Security Binding Elements, and Transport Binding Elements.

Protocol Binding Elements

Protocol	Class	Element
Transaction Flow	TransactionFlowBindingElement	<transactionFlow/>
Reliable Messaging	ReliableSessionBindingElement	<reliableSession/>
Security	SecurityBindingElement	<security/>

Message Encoding Binding Elements

Message encoding	Class	Element
Text	TextMessageEncodingBindingElement	<textMessageEncoding/>
MTOM	MtomMessageEncodingBindingElement	<mtomMessageEncoding/>
Binary	BinaryMessageEncodingBindingElement	<binaryMessageEncoding/>

Transport Security Binding Elements

Transport security	Class	Element
Windows	WindowsStreamSecurityBindingElement	<windowsStreamSecurity/>
SSL	SslStreamSecurityBindingElement	<sslStreamSecurity/>

Transport Binding Elements

Transport	Class	Element
HTTP	HttpTransportBindingElement	<httpTransport/>
HTTPS	HttpsTransportBindingElement	<httpsTransport/>
TCP	TcpTransportBindingElement	<tcpTransport/>
Named pipes	NamedPipeTransportBindingElement	<namedPipeTransport/>
MSMQ	MsmqTransportBindingElement	<msmqTransport/>
MSMQ	MsmqIntegrationBindingElement	<msmqIntegration/>
P2P	PeerTransportBindingElement	<peerTransport/>

You can add 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 as follows:

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 element is required for each binding, but if you do not 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 following code shows how to create a custom binding:

CustomBinding myHttpBinding = new CustomBinding();
myHttpBinding.Name = “myHttpBinding”;
myHttpBinding.Elements.Add(new HttpTransportBindingElement());

host.AddServiceEndpoint(typeof(IChat), myHttpBinding, 
    “https://localhost:8080/chat/custom”);

The following code shows how to create a custom binding by using the customBinding element in the configuration:

<bindings>
      <customBinding>
        <binding name=”myHttpBindingConfiguration”>
          <textMessageEncoding
            messageVersion=”Soap11WSAddressingAugust2004”/>
          <httpTransport 
            useDefaultWebProxy=”true” transferMode=”Streamed”/>
        </binding>
      </customBinding>
</bindings>

Custom Binding Configuration Examples

The following example shows a custom binding that performs functions similar to those of wsHttpBinding and netTcpBinding:

<configuration>
  <system.serviceModel>
    …
    <bindings>
      <customBinding>

        <binding name=”myWSHttpBindingConfiguration”>
          <transactionFlow/>
          <reliableSession ordered=”true”/>
          <security authenticationMode=”SspiNegotiated”/>
          <binaryMessageEncoding/>
          <httpTransport/>
        </binding>
        <binding name=”myNetTcpBindingConfiguration”>
          <transactionFlow/>
          <textMessageEncoding/>
          <windowsStreamSecurity/>
          <tcpTransport/>
        </binding>

      </customBinding>
    </bindings>
    …
  </system.serviceModel>
</configuration>

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

Share via