The role of service bindings

The WCF service binding (or the B in the WCF endpoint ABCs) is the channel stack that ties up how a service actually transmits data across the wire. The stack is made up of inpidual elements that make up the message communication. This includes elements that control security options, session capacity, and transaction capabilities. They are also used to determine how a message is actually encoded during transmission, whether that is in text/XML, binary format, or the new Message Transmission Optimization Mechanism (MTOM) format.

WCF provides a series of bindings for the available WCF transports, which offer the most compatible and logical component order for a given transport. Let's review the key bindings that are also available with BizTalk Server 2013 as adapters:

• BasicHttpBinding: This binding works great for ASMX SOAP clients that only support the SOAP 1.1 Basic Profile. By default, there is no security aspect enabled, no session or transaction capabilities, and its default data encoding is plain text. This is your "safe bet" binding that is the most interoperable for clients that don't support the latest WS* web services standards.
• BasicHttpRelayBinding: Use this binding when you expose services via Microsoft Azure Service Bus relays, if you want them to have the same capabilities as BasicHttpBinding. Configuration of authentication is all that is required because an outbound connection initiates a session to receive messages from the Service Bus relay endpoint.
• WSHttpBinding: Like BasicHttpBinding, this binding is for HTTP and HTTP/S traffic. This is a rich HTTP-based binding with full support for transactions, sessions, and a default message-based security scheme. With WSHttpBinding, you have the choice of not only encoding the payload in plain text but also the more compressed MTOM format.
• NetTCPBinding: If you need fast, secure connectivity between WCF endpoints, NetTCPBinding is an excellent choice. Data is transferred over TCP in binary format while still getting full support for sessions, transactions, and the full range of security options. Note, however, that this binding will only work for .NET-based service clients.
• NetTCPRelayBinding: This replaces NetTCPBinding for the exposing of services via Microsoft Azure Service Bus relays using a publicly reachable TCP endpoint. A secure outbound TCP connection creates a TCP listener that receives messages from the Service Bus relay.
• NetNamedPipeBinding: If your client communicates with a WCF service and both reside on the same physical server, this is the binding for you. NetNamedPipeBinding uses IPC (named pipes) to transport data in a binary encoding with a secure transmission channel.
• NetMsmqBinding: This binding uses queuing technology that is ideal for disconnected applications. Data is transferred in a binary encoding with rich security options available, but there is no support for sessions or request/response scenarios. That makes sense because, in a queue scenario, the publisher and subscriber are not aware of each other.
• WebHTTPBinding: This supports integration scenarios with RESTful APIs. Security can be configured in the same way as with BasicHTTPBinding. Transactions and data encoding do not come out of the box. RESTful services are simple and easy to use and this is what this binding delivers.

The BasicHttpRelayBinding and NetTCPRelayBinding Service Bus bindings only became available as adapters in BizTalk 2013. Chapter 6, Azure Service Bus and Chapter 13, New SOA Capabilities in BizTalk Server 2013 – Azure Hybrid Patterns have been added to this version of the book to describe how to use them. For now, you should realize that these open up exciting new possibilities where an on-premise WCF service can be exposed securely in Azure without having to change your corporate infrastructure. For example, there is no requirement to open up a firewall port to facilitate the connection if ports 9350, 9351, 9352, 9353, and 80/443 are already open.

If a situation arises where none of these bindings meet your needs, you can always craft a custom binding to mix and match available binding elements to your liking. What if your service consumer can only send binary messages over HTTP? The out-of-the-box HTTP bindings don't support such an encoding, but we could configure a custom binding that matches this business requirement. Or what if you need a transmission protocol not offered in the standard WCF toolset? We'll see in Chapter 9, Asynchronous Communication Patterns, that the WCF SQL Server Adapter delivers a custom binding, which includes SQL Server communication as a valid service transport. Such control over the WCF channel stack is a key aspect of the framework's flexibility.

Note

Note that there are additional bindings provided by WCF in .NET Framework 4.5, which are not explicitly set up as BizTalk adapters. These include WSDualHttpBinding (for duplex communication between endpoints), WS2007FederationHttpBinding (which supports federated security scenarios), and NetPeerTcpBinding (for peer-to-peer networking).