Previous articles (starting from Indigo installation to getting a simple "Hello World" client/service working) in this series can be read here:
- Indigo Installation Blues
- Resolved the Indigo installation error
- Indigo client: Channel not found error
- 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
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:
- Basic Profile Binding: Suitable for talking to WS-I
- 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)
- NetProfile[Tcp, DualTcp, NamedPipe, Msmq]Binding: .NET Only + Binary
- Msmq Integration Binding: Communication with existing MSMQ
applications, over HTTP, TCP or NamedPipe
- 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.
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:
As mentioned earlier,
basicProfileHttpBinding is an
out-of-the-box binding and thus can be specified in the configuration file. I
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:
In the configuration fragment above, a new custom binding is defined by the
httpReliableBinding and is referred by
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.