Bindings

Choosing the right binding for your particular scenario is important from both a security and performance perspective. One general rule of thumb you can follow is o use netTcpbinding in an intranet scenario and wsHttpBinding in an Internet scenario. You can then fine-tune your selection based on your unique needs and your infrastructure limitations.

Consider the following recommendations when choosing a binding option:

• If you need to support clients over the Internet, consider using wsHttpBinding.
• If you need to expose your WCF service to legacy clients as an ASMX Web service, use basicHttpBinding.
• If you need to support WCF clients within an intranet, consider using netTcpBinding.
• If you need to support WCF clients on the same machine, consider using netNamedPipeBinding.
• If you need to support disconnected queued calls, use netMsmqBinding.
• If you need to support bidirectional communication between a WCF client and WCF service, use wsDualHttpBinding or netTcpBinding.

Each of these guidelines is described in the following sections.

If you need to support clients over the Internet, consider using wsHttpBinding

If your service will be called by 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 has the following characteristics:

• It provides interoperability with non-WCF clients that support the WS* stack.
• It supports the WS* stack, including reliable messaging, message security, and secure transactions.
• Message security is turned on by default. Transport security is also available.
• It allows the service to be hosted in IIS 5.0 or IIS 6.0.
• If you choose transport security, you can use certificate, Windows, or token authentication.
• If you choose message security, you can use certificate, username, Windows, or issue token authentication (Windows CardSpace).

The following example shows how to configure wsHttpBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="wsHttpBinding" bindingConfiguration=""
                name="wsBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel>

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.

If you need to expose your WCF service to legacy clients as an ASMX Web service, use basicHttpBinding

If your service needs to support legacy clients that expect an ASMX Web service, consider using basicHttpBinding. basicHttpBinding does not implement any security by default. If you require message or transport security, configure it explicitly using this binding. Use basicHttpBinding to expose endpoints that are able to communicate with ASMX-based Web services and clients as well as 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 has the following characteristics:

• Because it does not support the WS* stack, it does not provide reliable messaging and secure transactions.
• Neither transport nor message security is turned on by default.
• It allows interoperability with legacy clients that expect to consume an ASMX Web service.
• It allows the service to be hosted in IIS 5.0 or IIS 6.0.
• If you choose to use message security, you can only use Basic or certificate authentication.
• If you choose to use transport security, you can use certificate, Windows, or issue token authentication (Windows CardSpace).

The following example shows how to configure basicHttpBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="basicHttpBinding" bindingConfiguration=""
                name="basicBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel>

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.

If you need to support WCF clients within an intranet, consider using 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 and it is acceptable to host the service as a Windows service instead of in IIS. netTcpBinding uses the Transmission Control Protocol (TCP) and provides full support for Simple Object Access Protocol (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 has the following characteristics:

• It can only be consumed by WCF-enabled clients.
• It supports the WS* stack, including reliable messaging, message security, and secure transactions.
• Transport security is turned on by default. Message security is also available.
• The service can be hosted in IIS 5.0 or IIS 6.0, but as it is not message-activated, you can consider hosting in a Windows service or IIS 7.0 instead.
• If you choose to use message security, you can use certificate, username, Windows, or issue token authentication (Windows CardSpace).
• If you choose to use transport security, you can only use certificate or Windows authentication.

The following example shows how to configure netTcpBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
                name="TcpBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel>

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.

If you need to support WCF clients on the same machine, consider using netNamedPipeBinding

If you need to support WCF clients on the same machine as your service, consider using netNamedPipeBinding. Use this binding when you want to make use of the NamedPipe protocol and provide full support for SOAP security, transactions, and reliability.

netNamedPipeBinding has the following characteristics:

• It can only be consumed by WCF-enabled clients.
• It supports the WS* stack, including reliable messaging and secure transactions.
• It only supports transport security; you cannot turn on message security.
• The service can be hosted in IIS 5.0 or IIS 6.0, but as it is not message activated, you can consider hosting in a Windows service or IIS 7.0 instead.
• Your only authentication option is Windows.

The following example shows how to configure netNamedPipeBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="netNamedPipeBinding" bindingConfiguration=""
                name="namedPipeBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel> 

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.

If you need to support disconnected queued calls, use 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 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 has the following characteristics:

• It supports asynchronous, disconnected operations.
• It can only be consumed by WCF-enabled clients.
• Transport security is turned on by default. Message security is also available.
• The service can be hosted in IIS 5.0 or IIS 6.0, but as it is not message activated, you can consider hosting in a Windows service or IIS 7.0 instead.
• If you choose to use message security, you can use certificate, username, Windows, or issued token authentication.
• If you choose to use transport security, you can only use certificate or Windows authentication.

The following example shows how to configure netMsmqBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="netMsmqBinding" bindingConfiguration=""
                name="MsmqBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel> 

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.

If you need to support bidirectional communication between a WCF client and WCF service, use wsDualHttpBinding or netTcpBinding

If you need to support a duplex service, use wsDualHttpBinding or netTcpBinding. 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 wsDualHttpBinding binding to support communication via SOAP intermediaries.

wsDualHttpBinding has the following characteristics:

• It supports two-way communication between the client and the service.
• It provides interoperability with non-WCF clients that support the WS* stack.
• It supports the WS* stack, including reliable messaging and secure transactions.
• It only supports message security; you cannot turn on transport security.
• It allows the service to be hosted in IIS 5.0 or IIS 6.0.
• If you choose to use message security, you can use certificate, username, Windows, or Issue token authentication (Windows CardSpace).

The following example shows how to configure wsDualHttpBinding:

<system.serviceModel>
....
    <services>
        <service behaviorConfiguration="" name="WCFServicecHost.MyService">
            ...
            <endpoint address="" binding="wsDualHttpBinding" bindingConfiguration=""
                name="DualBinding" contract="WCFServicecHost.IMyService" />
            ...
        </service>
    </services>
</system.serviceModel> 

Additional Resources

• For more information on bindings, see Windows Communication Foundation Bindings.
• For a binding Q&A, see the Bindings section of WCF Security Questions and Answers.