Skip to main content

Indigo Bindings

Posted by arungupta on May 13, 2005 at 2:57 PM PDT

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
  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:

      <service serviceType="Calculator">

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
such as:

<configuration> <system.serviceModel>
      <binding configurationName="httpReliableBinding">

    <service serviceType="Calculator">

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
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.

Related Topics >>