Binding Basics in WCF

Introduction



This article will not explain what a binding is or how to use them. Instead, it gives you a clear picture of what the various types of binding are and why we require these bindings. How do we need to configure a binding? How do we need to set multiple bindings? Why we need to modify bindings? Yes, there are many more interesting concepts explained.

Bindings

The following table shows the types of bindings and their uses

Binding Name	Description
BasicHttpBinding	Allows us to create and consume ASMX-style services within WCF. No Security provided for the messages. No Reilable Messaging, Responses will not come in order. Suitable for clients who do not have .Net 3.0 installed. Transport: HTTP.
webHTTPBinding	Allows us to create and expose your services as HTTP requests. Used for REST Based Services.
wsHttpBinding	Exposes web services using ws-* specifications. Security provided (Ws-Security) for messages by default. Uses for WS-Transactions, WS-BusinessActivity.
wsDualHttpBinding	This is like the preceding one, but it uses duplex contracts. This means the both client and server can both send and receive messages
wsFederationHttpBinding	Provides a mechanism for exposing a federated service. The client uses a security token issued by a security token service to authenticate.
netTCPBinding	Service to Service Communication in an intranet. Features include transactions and security. For WCF to WCF service communication netTCPBinding is best.
netPeerTCPBinding	Used when you require more security for Peer to Peer Communication as netTCPBinding.
netMsMqBinding	Binding for asynchronous communication using Microsoft Message Queue (MSMQ). Best when you need to execute service operations in a queued manner.

Configuring Binding Declaratively and Programmatically

I must say the binding is the first and foremost configuration you need to do in WCF, actually it defines the parts of your service. Have a look at the following configuration:

<services>
   <service name="Rameshkartik.WCFSamples.Transactions.Implementation.PurchaseImpl"    behaviorConfiguration="OnlinePurchaseServiceBehaviour">
   <endpoint address="" binding="wsHttpBinding" contract="Rameshkartik.WCFSamples.Transactions.Contracts.IPurchase"       bindingConfiguration="wshttpbind">
      <identity>
         <dns value="localhost"/>
      </identity>
   </endpoint>
<host>
   <baseAddresses>
      <add baseAddress="http://localhost:8733/Rameshkartik/WCFSamples/Transactions/OnlinePurchaseService"/>
   </baseAddresses>
</host>
</service>

A little vague, right? If you look at the preceding configuration, which element comes under which element, how do I remember this hierarchy? For anyone new to WCF, the hierarchy is a bit challenging, but I have one technic as college goer Bigard. For the college semesters, services have service rights, in the service you have the "e" as the last letter. E represents the endpoint that is nothing but an ABC, ABC represents an address, binding and contract.

Services->Service->endpoint->ABC

Finally, wherever we define the host, addresses are the required field as in the following:

Host->BaseAddresses

Now let's see how we can define the same in programmatically.



As you see in the preceding snapshot, you must define the host first in which endpoint must be defined.

Base Addresses

What is the base Address? Very simple, you can define the address in the base and refer to it down the line. This is how I used to map in my mind. At every endpoint we are about to define the address, but do you think it is easy to change to an address if you have more than 5 endpoints? Very tough, right? Yes, we need to search each and every endpoint in the config file and change it. But if we have a facility to put up in one common place and relatively map into each and every endpoint then that's a really cool idea to know. This is called base addresses. If you have an entire library of endpoints, it's really hard to manage without base addresses. We can have multiple base bind addresses for each service, but only one address for each protocol. WCF will automatically map the correct address based on the binding configuration of the endpoint. Please look at the following snapshot to get a better understanding.



Default Configurations

The WCF 4.0 release actually simplifies the configurations by defining the default configurations for several aspects of WCF. WCF has a predefined protocol mapping, that maps the protocol schema to the WCF binding.

Schema	WCF Binding
Http	basicHttpBinding
net.tcp	netTcpBinding
net.msmq	netMSMQBinding
net.pipe	nameNamedPipeBinding

Still, if you are not satisfied with the default mapping, you can change the default settings by making the following changes in the configuration file:



Default Behaviors

Without defining the behavior explicitly, we have an option in WCF to write a default behavior. The following is the example of defining the explicit behavior, in other words we must provide a name for the behavior and refer to the same name in the endpoint configuration.



In the default behavior, there is no need to specify the behavior name, by default WCF takes the behavior that is configured. Please refer to the following snapshot of default behavior:



Multiple Bindings

Do you like your service to be consumed by any type of client? The solution is to create multiple endpoints with varying sets of bindings, in other words your service logic will be the one, but the transport mechanism and the address will be different for each.



Summary

Binding is all about how the message will be transmitted, one service Implementation can have multiple bindings for many types of clients to consume it. Default behaviors and default bindings are the latest features in WCF 4.0.