Chapter 8 – Bindings

- J.D. Meier, Carlos Farre, Jason Taylor, Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher

Objectives

  • Know what Bindings and Behaviors are and how they are used in WCF
  • Understand when to use each binding that supplied by WCF
  • Learn the best bindings for the Internet
  • Learn the best bindings for the intranet

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.
netTcpBinding Specifies a secure, reliable, optimized binding suitable for cross-machine communication. By default, it generates a runtime communication stack with transport security and windows authentication as default security settings. It uses TCP protocol for message delivery, and binary message encoding.
netNamedPipeBinding 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.


For more information on bindings, see “MSDN Windows Communication Foundation Bindings” at http://msdn.microsoft.com/en-us/library/ms733027.aspx.

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:
<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:
  • Bindings. Bindings control 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 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.

WCF provides some different list 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 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
  1. Transaction Flow (Not Required)
  2. Reliable Messaging (Not Required)
  3. Message Security (Not Required)
  4. Composite Duplex (Not Required)
  5. Message Encoding (Required)
  6. Transport Security (Not Required)
  7. 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 following code shows how to create a custom binding by code
CustomBinding myHttpBinding = new CustomBinding();
myHttpBinding.Name = “myHttpBinding”;
myHttpBinding.Elements.Add(new HttpTransportBindingElement());

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

The following code shows how to create a custom binding by using the customBinding element in 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 which does the similar functions as that 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 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.

Last edited Jun 11, 2008 at 8:20 PM by prashantbansode, version 1

Comments

No comments yet.