Indigo Bindings

Previous articles (starting from Indigo installation to getting a simple "Hello World" client/service working) in this series can be read here:

1. Indigo Installation Blues
2. Resolved the Indigo installation error
3. Indigo client: Channel not found error
4. Indigo client now working

Going forward, I plan to dig into different Indigo concepts and provide my understanding of them.

Indigo separates out the communication details from the actual service endpoint and client code using Bindings. From Indigo documentation, "Bindings are objects used to specify the communication mechanisms required to talk to an endpoint."

Binding consists of protocol (security, reliability, transaction, session), transport (HTTP or TCP) and encoding (text/XML, Binary or MTOM). Binding can be specified either in a configuration file or imperatively in the code. The advantage of defining a binding in the configuration file is that provides pluggability (more about this later) without impacting the client and service endpoint code.

Indigo ships with 9 predefined standard bindings available out-of-the-box that cater to the most common scenarios. I classify them in 5 buckets:

1. Basic Profile Binding: Suitable for talking to WS-I Basic Profile conformant services.
2. WS Profile Binding and WS Profile Dual Http Binding: Basic Profile Binding + several WS-* specs; one with Dual allows duplex contracts (more about this in a later blog)
3. NetProfile[Tcp, DualTcp, NamedPipe, Msmq]Binding: .NET Only + Binary encoding
4. Msmq Integration Binding: Communication with existing MSMQ applications, over HTTP, TCP or NamedPipe
5. Intermediary Binding: Binding for a SOAP intermediary

Most of the bindings are secure and reliable. In subsequent blogs, I'll be exploring the dual bindings that enable duplex contracts.

The matrix on standard bindings page says that only WSPDualHttp and NetProfileTcpDual binding has "Clients must be addressable" where as NetProfileTcp, NetProfileNamedPipe and NetProfileMsmq bindings, along with previous two, support duplex pattern. I need to understand better how duplex pattern is supported in the bindings where client is not "addressable".

Here is a sample configuration file using standard binding:

<configuration>
  <system.serviceModel>
    <services>
      <service serviceType="Calculator">
        <endpoint
          address=""
          contractType="Calculator"
          bindingType="basicProfileHttpBinding"/>
      </service>
    </services>
  </system.serviceModel>
</configuration>

As mentioned earlier, basicProfileHttpBinding is an out-of-the-box binding and thus can be specified in the configuration file. I can substitute basicProfileHttpBinding with wsProfileHttpBinding and thus get a secure, reliable message exchange using WS-Addressing headers. And my service endpoint code does not need to change for this to happen. This is what I meant by saying pluggability earlier. 

However if you like to stack up the behaviors in a different manner, for instance HTTP transport that uses reliability but not security, then you can define a custom binding such as:

<configuration> <system.serviceModel>
  <bindings>
    <customBinding>
      <binding configurationName="httpReliableBinding">
        <httpTransport/>
        <reliableSession/>
      </binding>
    </customBinding>
  </bindings>
  <services>
    <service serviceType="Calculator">
      <endpoint
        address=""
        contractType="Calculator"
        bindingType="customBinding"
        bindingConfiguration="httpReliableBinding"
        configurationName="serviceChannel"/>
     </service>
  </services>
<configuration>

In the configuration fragment above, a new custom binding is defined by the name httpReliableBinding and is referred by endpoint/@bindingConfiguration. All the standard bindings are defined in terms of custom bindings as well. Steve Maine posted an entry describing all the standard bindings in terms of custom bindings.

That was my short tutorial on Indigo bindings, next I'll explore what it takes to write a duplex contract.