If you’re not familiar with the “ABCs of Indigo” (Address, Binding, and Contract), please click here for background on some basic Indigo terminology and concepts.

When users first start playing with Indigo, there are two common approaches to the system: those that want to trace a message exchange from the “top” (by building a Service), and those that want to start at the “bottom” (by tracing the Message as it enters the system and makes its way up to the typed ServiceMethod). Those in the latter camp generally start by hunting for transports, which put your messages on the proverbial wire.

A few notes about transports in Indigo:

• Transports need to be considered in the greater context of a binding. A binding is simply an ordered list of binding elements. There are binding elements for reliability, security, transaction flow, and transports. When I talk about a transport (such as HTTP), you will likely be interfacing with it through its binding element (e.g. HttpTransportBindingElement).
• Indigo includes 4 transports in the Community Tech Preview:
  1. HTTP (for cross machine interoperable messaging)
  2. TCP (for cross machine Indigo to Indigo messaging)
  3. Named Pipes (for on machine Indigo to Indigo messaging)
  4. MSMQ (for queued messaging)
• Transports are responsible for encoding+transmitting messages (on Send/Request), and receiving+decoding messages (on Receive/ReceiveReply). Indigo is architected so that transports can delegate the task of translating between a Message and a byte array to an encoder.
• Indigo includes 3 encoders: Text, Binary, and MTOM. Each encoder is associated with an implementation of XmlReader and XmlWriter, as well as a SOAP version. By default, HTTP uses the text encoder, and TCP/Named Pipes use the binary encoder. However, an Indigo transport can be used with any encoder (either built-in or custom).
• The combinatoric possibilities involved in constructing a binding can be staggering, so Indigo includes a small number of predefined bindings that you can use for most common scenarios. The documentation gives a good high-level overview of what scenario each binding is intended for and the various tradeoffs inherent in using each one. Each predefined binding has a transport binding element associated with it, though it may only expose a subset of the properties available directly on the transport binding element itself.

While Indigo at its core is “transport agnostic” there are of course implications to choosing each transport. Up next, I’ll discuss what some of these implications are in a home networking scenario.